Posted on by Software Architecturein
Microservices is one of those buzzwords that generate a lot of hype but is ill defined. In another post, I comment about defining microservices. In this post, my main goal is to discuss pros and cons of using microservices in contrast with the monolithic approach, so let's cut to the chase.
Benefits of using microservices:
Challenges of using microservices:
Much of what I read about microservices mentions autonomy as a benefit. For example, Sam Newman's Building Microservices book says increased autonomy is a huge advantage of microservice architecture. But what is autonomy? And why didn't I list it in the pros of microservices above (or the cons either)?
First off, there's design autonomy: how much freedom you have to design, implement, and modify a software element. But more important to our discussion is runtime autonomy: how much control a component has over everything that is executed when the component is invoked. A service that doesn't need to interact with any other components outside its boundary is highly autonomous. If a service calls another service, accesses a shared database, sends a message or event to a message broker, then it loses a little bit of autonomy. A design goal is not to get rid of these kinds of interactions, but to avoid problematic ones so that the level of service autonomy doesn't compromise performance or reliability.
And what about the autonomy of microservices? They certainly beget high degrees of design autonomy--the team can employ different technologies and patterns to design and implement each microservice, and can change and redeploy each microservice independently. On the other side, services within a monolith often have to follow the same design constraints and change+deploy cycles--less design autonomy.
As for runtime autonomy, I'm afraid the very idea of microservices goes in the other direction. We're splitting the monolith into small distributed services. The overall business logic that was once collocated in the monolith is now spread across microservices. It's more likely that a microservice will interact with other microservices over the network--that interaction decreases autonomy. If the interaction between microservices involves changing data, the need for a transactional boundary further compromises autonomy. To quote Newman, "Don't also be surprised if things like distributed transactions or CAP theorem start giving you headaches."
The good news is that much of the schooling about microservices I've seen emphasizes this apprehension with autonomy. To avoid autonomy issues, the experts advise you to employ techniques such as eventual consistency, event-driven architecture, CQRS, cache (data replication), and aligning microservices with DDD bounded contexts. My point is that these great techniques are not inherent to microservices, but are desirable to prevent service autonomy issues that are inherent to microservices.