Microservices. The boundaries.

One of the problems with designing and implementing a distributed software system using microservices implementation technique is figuring out the boundaries of microservices. And, indirectly, the size of these artifacts.

What happens if the boundaries are incorrect? You get coupling between various components (microservices) – both spatial and temporal. Such coupling can undermine a lot of implementation and delivery aspects. Some of these include inability for one team to fully implement a feature due to a dependency on some other service that implements something they require, inability to release without coordination with other teams, issues when releasing interdependent components may and will result in instability, loss or corruption of data, emergence of distributed transactions, etc. Many tried, many failed and questioned the concepts rather than their misunderstanding or mistakes.

So, is the concept flawed? Is there something that can help us deal with such issues? As always we need to start with the foundation. In this case our main foundational concept comes from Domain Driven Design – an Aggregate.

If you don’t know what Domain Driven Design is, or have a very basic, high level knowledge of it, it is crucial for you to start digging deep and wide, over and over, to start understanding what it’s all about. It is a philosophy of successfully modeling complex business domains and implementing those in software. There is a lot written on the subject and I would recommend to keep reading.

An aggregate is a very important, yet somewhat elusive concept that takes time to fully grok. At it’s core DDD Aggregate ensures the boundary for transactional consistency. When a transaction completes all entities represented by an aggregate must be in a consistent state – any business rules governing the state must be met, the data must be fully stored in a data store and the aggregate should be fully available for any other use case. From the implementation point of view, an aggregate is one or more classes representing an entity(-ies) that govern the state and the rules associated with it.

With the concepts of DDD Aggregate in mind we can now approach the sizing of a microservice and define its boundaries. Approaching the design thinking about the business process that drives the implementation we really localize the scope of change, encapsulate the logic and state. The implementation become autonomous, we remove any potential for cross-service requests, complex orchestration goes away, unnecessary generalization of code is not a factor anymore. The codebase becomes simpler, more robust, easier to reason about. It is easier to test, easier to maintain all of which really yields greater business agility – exactly what business asks of engineering.

So, why do people run into issues we’ve mentioned at the beginning of this post? It usually happens when implementation is based on technical concerns or driven by popular but often superfluous concepts such as code reuse, DRY, generalization, centralization of some logic. With this the chances of incorrect breakdown of business process into reusable parts may and will result in the issues that lead microservices solution to become overly complex – invalid services boundaries, coupling between services, emergence of distributed transactions, dependencies on other components and teams, lack of agility. Pretty much everything that the concept promises to solve and the reason you’ve decided to adopt it in the first place.

Disclaimer: I am a strong believer that microservices is an implementation technique, not an architectural style. As such, without proper foundation it most likely will cause more harm than good. More on this here.