Since containerisation became more common, the option to move to a microservices have been gaining in popularity. However, they may not be the right choice for all organisations. To determine if moving to microservices should be a consideration for your organisation, we need to first understand the benefits of microservices and weigh them against the negative aspects before we can make a fully-informed decision. This article will highlight the successes and challenges of moving to microservices that I have accumulated from some of my recent API and microservice coaching sessions. These insights should help you become more informed as you make your decision to pursue, or avoid, a microservice-based architecture.
Microservices shift complexity, not remove complexity
The overhead of taking a microservice-based approach was considered more tolerable than trying to reason about a single or a few codebases that continued to grow ever more complex. Prior to today’s abundance of build, deploy, and monitoring tools, the effort required to build and support the necessary infrastructure to support was considerable. This up-front investment had to be weighed against the advantages of moving to microservices before proceeding.
With today’s availability of containers, container orchestration, and turnkey CI/CD pipelines, the friction has been reduced and therefore more teams are moving toward microservices. However, there are other factors that need to be considered. Let’s look at some of the upsides and downsides of microservices to help us make an informed decision.
Microservices reduce coordination costs between teams
Microservices originally helped provide clarity of highly complex systems by distributing these complexities across independently deployed components rather than having them within a single codebase. This is achieved by designing, developing, and deploying smaller distributed components that help to compose a system.
Realised benefits of a microservice architecture, accumulated from my recent coaching engagements, include:
- Optimisation of infrastructure resources through the independent scalability of the services, allowing hundreds or thousands of instances of critical services and just a few instances of non-essential services
- Reduced release cycles through an independent software development life cycle for each microservice, without coordinating the release of related microservices
- More effective and efficient scaling of development teams through team-based ownership of specific microservices
- Removing centralised data ownership by moving data closer to the services rather than a central data store
- Reduced risk of change due to smaller code bases that can be easily enhanced or modified, tested fully in isolation, and deployed quickly
Moving to microservices is primarily about reducing coordination costs of aligning efforts across multiple teams/developers working on a complex system. This is accomplished by limiting the scope of a single service while ensuring it is independently deployable. When an enhancement or fix is required, it is made within the microservice quickly and deployed with confidence.
The benefits of moving to microservices have less to do with technology choices and more to do with the impact they have on how the organisation structures itself and manages day-to-day development and operations – positive or negative.
Considerations when transitioning to microservices
While there are many benefits to moving to microservices, the transition shouldn’t be taken lightly. After some time and reflection, some organisations have chosen to simplify their microservice journey, others have decided to abandon their journey in favour of thinking smaller but without microservices, and the rest continue to move forward with microservices. Let’s examine some of their considerations:
Microservices require a self-service, fully automated infrastructure. Successful transitions to microservices ensure developers are able to design a microservice, register it, and deploy code as needed without any manual processes or approvals. Organisations that have not fully automated their provisioning and deployment pipeline will encounter considerable friction. The result will be that existing microservices will be used to deploy new capabilities rather than a brand new microservice, resulting in a few very large siloed services.
Microservices must have their own release cycle. Some organisations opt to use their existing release processes, such as a two-week sprint and release, rather than allowing microservices to be released when they are ready. This coordinated deployment of all microservices at once results in a tightly-coupled series of services that produce a distributed monolith, rather than independent teams that may deploy their microservices as needed.
Microservices should be owned, monitored, and managed by a single team. Teams should own only one or a few microservices. Smaller organisations that choose to move to microservices find that their developers spend more time moving between codebases, sharing the responsibility for a large number of services. This results in more complexity than if the team chose to build a few services with larger bounded contexts instead.
Microservices require a proper organisational structure. Sometimes, organisational structure and culture will be at odds with this style of service ownership, making it difficult to move to microservices while achieving the speed and safety often promised with microservices. Keep the org structure in mind before shifting to microservices by ensuring that you have buy-in from the executive team and managers that oversee your teams.
Microservices must own their own data. This can be a challenging item, as rarely do teams think beyond the source code when it comes to shifting to microservices. When services do not own their data, the coordination cost of underlying schema changes can ripple across multiple microservices that share the data. This can require large, coordinated release efforts to bring every service in line with a breaking schema change within a shared data source.
Microservices require heavy data management. If microservices own their own data, the investment must be made to ensure that proper distributed data management exists to support reporting and analytics that may be performed within a single, shared data source today. Techniques such as data streaming are often used in place of ETL processes to bring together data from multiple services for the purposes of reporting. Organisations with large shared databases must use caution when migrating to a microservice architecture.
Teams must be prepared for the challenges of distributed systems. The journey toward microservices requires a deep understanding of distributed systems. Those not as familiar with the concepts of distributed tracing, observability, eventual consistency, fault tolerance, and distributed sagas will encounter a more difficult time with microservices.
Should you make the move to microservices?
Organisations must think smaller to remain agile and compete in today’s marketplace. However, a complete shift to a microservices may not be the right answer. Microservices are an option for organisations with mid-to-large number of developers. Smaller organisations or solutions with lower complexity find that the extra work of managing independent services outweighs the benefits of a microservice architecture. Weigh the benefits and considerations outlined above and consider the decision before jumping onto the microservice bandwagon.
For more on microservices, be sure to check out microservice gateway and access patterns for three common approaches that organisations use for designing and sharing microservices.
