Microservice architecture has been widely used to build scalable and resilient applications. Every company wants to build application fault-tolerant and be able to build and deploy new features fast. Although Microservice architecture is a tool to achieve these goals, it is also a tool that has some requirements to be applied with success. This article explores some of these requirements.
You should rethink use Microservices when…
1. The application is too small
When the application is too small, the cost of maintaining a microservice up and running is higher than the benefits it generates.
2. The problem domain is unclear or uncertain
Microservices are created based on the capabilities that you identify on the domain you are working on. This means that you will start by the creation of a domain model with boundaries, aggregates, entities, and interfaces. When the problem domain is unclear or uncertain, changes can happen more often than you expect. Boundaries will move, aggregates will consolidate, interfaces will change, the model will split. Refactory is good to improve the design of existing code but also can slow down the team when the contract with other services is broke. A monolith, in this case, is much more flexible.
3. The Organization has a rigid business structure and cannot change
The system architecture tends to reflect the business organization. The Conway’s law states:
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
Mel Conway
Organization sometimes will need a Business Refactory to build Microservices. Different teams have different priorities that can create delays and conflicts. On Microservice architecture each service (or a small set of them) are managed by small and self sufficient teams.
4. The team lacks experience to understand the microservice concepts or conceptual design
Bad design architecture leads to a tightly coupled distributed monolith. And all the nightmare associated with it, delays, complexity, coupling deploy times. The lack of knowledge of DDD and commons patterns for Microservices is an open door to take shortcuts and implement anti-patterns. Managers also need to be comfortable with refractories and not blame the team due to bad choices. Fail often, fail early, fail fast is desired, but it is not an easy thing to learn because of the sunk cost fallacy.
5. The team turnover is high or lacks experience with delivery pipeline
Build and deploy microservices demands skills that go beyond programming and problem-solving. The team needs experience with test-driven development, code review, DevOps, infrastructure as code, continuous integration and deployment. If the turnover is high or the team lacks this skill there is a chance you ended up with a distributed monolith.
This article was based on this great post from Charles Féval where he explains some of the downsides of adopting a Microservice Architecture.
What other facts you faced that made you rethink in adopt Microservice architecture? Drop a comment here.
Good and crisp article. I see developers and architect keep suggesting architecture on basis of buzz words instead requirement fitment.
Thank you for comment. That´s a good point. As developers, we want to work with innovative technologies and sometimes this drives our decisions to adopt tools or frameworks without thinking too much about the real problem it solves. It´s a behavior to keep a watchful eye and avoid it.