The Microservices Train
Do you really need to jump aboard?
It seems like the entire software development world has jumped on the microservices train. But the decision to do so is not without its consequences. Below we discuss microservices, what they are and the benefits and drawbacks of microservices.
What Are Microservices?
Martin Fowler and James Lewis describe microservice architecture as a particular way of designing software applications as suites of independently deployable services.
Chris Richardson of Microservices.io describes microservice architecture as an architectural style that structures an application as a collection of services that are highly maintainable and testable, loosely coupled, independently deployable, organized around business capabilities, owned by a small team.
Given the overlap between the above two definitions, we can distill microservice architecture down to having [at a minimum] the following qualities.
- collection of services
- independently deployable
Certainly, there are good approaches, less good approaches and downright disastrous approaches for creating systems composed of independently deployable services. But at its core, a microservice architecture is just a system composed of independently deployable services.
Considerations for a Microservice Architecture
If you are presently trying to decide whether or not to migrate to a microservice architecture, there are many factors to consider. The most important factor, however, is the benefits you receive from solving problems that led you to consider a microservice architecture in the first place. Ideally, those benefits should outweigh the additional complexities that come with microservices.
The Benefits of a Microservice Architecture
The following are some benefits of migrating to a microservice architecture.
Reduced Impact of Deployments
In a truly monolithic system, there is a single deployment. If the deployment fails, the entire system may also fail. However, in a microservice architecture, it would be possible to do a single service deployment that, if properly bounded, could only cause the failure of a small piece of the system.
Additionally, monolithic systems will likely take longer to deploy as they grow in size and functionality — more tests will have to be executed, larger deployment size, takes longer to load. Contextually bounded microservices, on the other hand, will remain rather small and discrete since their boundaries are finite and well defined.
Improved Upgradability
It’s pretty amazing how fast the system de jour can turn into a legacy system. Anyone who has been in software development for any period time likely remembers such a system and the pains associated with upgrading the underlying technology. A microservice architecture reduces the overhead of upgrading services (because the services are small) and at the same time, it allows the technology stack to be evolved. This is because new services can be built on new tech — services are not even bound to the same tech stack since they work off of well-defined, platform agnostic service contracts.
Independently Scalable Components
It’s no surprise that different functionality within a software system likely has different scaling requirements. In a monolithic system, everything in the system scales the same, both horizontally and vertically. However, with microservices, different services can scale based on their own needs. For example, if one service provides functionality that has higher load, then only that one service can be allocated the additional capacity it needs.
The Drawbacks of a Microservice Architecture
The following are some very real drawbacks associated with a microservice architecture.
Increased System Deployment Complexity
Monolithic systems have few components to deploy, so deployments can be pretty easy. Microservices, on the other hand, have many discrete services, each maintaining their own state, some mechanism for communication wiring them together, etc. Systems with a microservice architecture do not have trivial deployments. Sure, an individual service may be easy to deploy on its own. But, that service is just a component in a suite of services that work together to provide a complete system.
This problem is not insurmountable, however. Platforms like Kubernetes and automation tools that provide Continuous Integration (CI) and Continuous Delivery (CD) can substantially ease the deployment burden for microservices. But, even with these tools, managing and orchestrating microservices and their deployments takes planning and attention.
Maintaining Consistency Across Services
The CAP theorem, also called Brewer’s theorem (after its presenter, Eric Brewer) states that any distributed data store can only provide 2 of the following 3 guarantees: Consistency, Availability, and Partition Tolerance. Any networked system must have [network] partition tolerance. So, the choice is then between availability and consistency. Since high availability is a very desirable attribute in software systems, consistency generally loses out.
In a monolithic system, there is no network partitioning between component state. So, it can have both consistency and availability. Microservices, however, cannot. So, we settle for eventual consistency as a trade-off.
Eventual consistency, however, does not come for free. It has to be planned and implemented so that (1) state shared between components does eventually become consistent state and (2) any delays in state consistency are acceptable — this is also part of demarcating services along their appropriate bounded contexts.
Testing Complexities
Chris Richardson of Microservices.io makes the case that testing in a microservice architecture is easier because the services are small. On a per-service basis, that definitely does hold water. However, testing across service boundaries can be significantly more complex when compared to a monolithic system.
In a monolithic system, any state is shared in memory or through a common datastore. There is often a pretty straightforward mechanism for deployment and any integration testing is done with external actors.
But, with microservices, other services within the system are both external actors and part of the system. Their communications with other services within the system must be tested. There is also now the possibility that a new service deployment could break its contract, which could have impacts on other services — all of which must be managed and tested.
Should You Migrate to a Microservice Architecture?
As with many things, the answer to the above question is it depends. There’s a pretty significant Monolith First camp that makes an argument for starting with a monolith and then moving to a microservice architecture when the application is big enough where the benefits of microservices outweigh the additional complexities assumed with a microservice architecture. To be sure, this is an evolutionary approach to adopting a microservice architecture that assumes an existing foundation in good software design and construction. Poorly constructed software is probably not going to fare well, regardless — although, it may be easier to hide in a monolith.
The downside about Monolith First is that the additional complexities associated with microservices are kicked down the road for a resolution at a later time. This could be a big deal for a struggling team or it could be a relatively insignificant effort for a high performing team who has good organizational support. In either case, it is something to be considered.
Finally, a small system may realize very little benefit from a microservice architecture. Indeed, the complexities associated with a microservice architecture may outweigh any benefits it provides. So, for that reason and for those mentioned further above, I would urge anyone developing a new system to start with a small monolithic application, use sound software development practices and evolve as necessary. For existing systems, evaluate whether the benefits of migrating to a microservice architecture outweighs the additional complexities that microservices bring. And if they do, use an opportunistic and evolutionary approach.
Thank you for reading. If you liked this post, please check out the Blu Flame Technologies Blog.
