Modeling microservices. Part 3

In the previous two articles, we covered the key ideas behind microservices. In the first part, the qualitative characteristics of the boundaries of microservices were described. In the second part, a domain-oriented approach and methods for identifying service boundaries were presented. In today’s final article, we’ll look at alternatives to a domain-specific approach, and then we’ll explore patterns for splitting a monolith into microservices.

Decomposition based on volatility

A common alternative to domain-specific decomposition is volatility. Volatility-based decomposition involves separating the most frequently changing parts of the system into separate microservices. This method can be very useful if your primary goal is time to market (TTM). But if this approach forces you to take the service beyond organizational boundaries, the delivery rate of the product will inevitably begin to decline.

Decomposition based on organizational structure

According to the law Conway, there is a direct relationship between the organizational structure and the resulting system architecture. Defining the boundaries of a service should not lead to a situation where ownership of it will be spread over several teams. The first way to resolve this situation is to separate a part of the functionality into a separate service and transfer ownership to another team. The second way is to change the organizational structure. A good solution here would be to switch to stream commandswhich I discussed in a separate article.

Templates for splitting a monolith into microservices

Before I go into the description of the templates, I want to give a disclaimer. Microservices should not be an end in itself. This is not a panacea. Focusing on microservices leads to the fact that you stop considering alternative solutions for solving tasks. Sometimes it’s easier and smarter to use a monolith. For example, scaling an existing monolith is sometimes more efficient through the use of a load balancer than a long sequential decomposition into microservices. Therefore, first of all, determine your goals. And then choose the simplest tools to achieve them.

Code or database

If you have consciously approached the division of your monolith into microservices, you should decide on the steps. What should be taken out first – the code or the database? It is recommended to study in detail the possibility of highlighting the code and the database, and then decide on the priority. The most common first step is to move the code out while maintaining a single (monolithic) database. Typically, if you can’t extract code, you can stop work and avoid having to unravel database dependencies.

A less common approach is when the database is retrieved first. This approach has advantages – you solve data integrity issues in advance. In this case, the subsequent extraction of the code will be less risky.

Strangler Template

Strangler Template (Strangler Fig Pattern) is to gradually transfer the functionality of the old system to the new one. Calls to an existing monolithic system are intercepted and redirected to a microservice for new functionality. The remaining functionality is provided by the monolith and the corresponding requests are sent to it. A distinctive feature of this template is that no changes are made to the monolith. This advantage can be used to execute calls on the old and new code in parallel, and then compare the results.

Switched Function Pattern

Switched Function Pattern (feature toggle or feature switcher) is the mechanism used to enable, disable, and switch between versions of functionality. In our case, the functionality in the monolith and the microservice can be different, and this mechanism allows you to switch between implementations depending on the circumstances (for example, through the boolean flag).

Conclusion

Before you start porting monolith functionality to microservices, you need to be clear about the end goal. If microservices are going to be the best solution, then consider a strategy for progressive porting of functionality. Take into account that the process of extracting one microservice from a monolith can also be divided into several stages.
With this article, I complete the cycle of publications about modeling microservices. All articles in the series (part 1, part 2 and part 3) are designed to improve your understanding of the optimal division of the system into modules within the framework of a microservice architecture. Subscribe to my telegram channelso you don’t miss the latest posts. And see you soon!