Over the past few years, many teams and companies have faced the challenge of rebuilding product architectures from monolithic to microservice architectures. The term “microservice” has become so popular and often seen in speeches, articles, and books that it might seem like this is almost the only correct way to build applications in 2021. However, to put it mildly, this is not the case.
Business expectations and the engineering team’s expectations of the move to a microservices architecture can be very different. Without a balanced assessment of all the pros and cons, such a transition may not only fail to meet expectations but also lead to both a technical disaster and business problems. Even when the choice is made, further concrete steps always depend on many factors, and it is rather difficult to find a single guide on how to do such a migration. But in our opinion, Sam Newman succeeded. He decomposed different conditions and factors into general decision-making patterns and methods of migration, clearly described the criteria for choosing one or another path, and showed the possible consequences of each of them.
Monoliths to Microservices thoroughly cover architecture selection, migration steps, and details database migration patterns, application components, and infrastructure. It will be useful for both developers and architects, as well as CTOs and Engineering Managers. It will be useful for top managers and people from business to read the first two chapters, which are devoted directly to organizing architecture migration.
At the beginning of the book, as expected, the main differences between a microservice and the so-called monolith are described, because even the concept of a monolith is not so unambiguous. The author goes through these two concepts in sufficient detail, giving both definitions and examples of what they mean in real applications. And all the examples described are provided with a corresponding graphical representation, which makes it easier to understand.
In the following, the author describes effective methods for gradual, but not instantaneous migration, which is most likely necessary in 99% of existing products with a monolithic architecture. First, you need to choose which parts of the system should be transferred first, and here the reader is given the option of joint brainstorming (Event storming) with a team to prioritize migration components. Many factors are considered, such as “business importance,” “readiness to move,” “skills and team structure,” and provide examples of possible time frames for a change, which are always significant from a business perspective.
To separate the system components “communicating” over the network, the Strangler Fig pattern is described in detail in all implementations: routing through Proxy and Reverse Proxy, using various protocols and intercepting messages. For almost every project, the Branch By Abstraction and Parallel Run patterns come in handy. We have not forgotten the Decorating Collaborator and Change Data Capture patterns. Specifically for the migration of the UI part, the UI Composition, and Micro Frontends patterns are described. All of them are given with examples, so it will be quite simple to apply them in your project.
The chapter on database migration patterns deserves special attention: the most common partitioning methods (at the schema, instance, and table level), as well as solutions for data synchronization, issues of data consistency, and patterns of its achievement, are described. The options for implementing transactions in distributed systems are discussed in detail, and the Saga pattern is described as an alternative option to combat the complexity and weaknesses of distributed transactions.
And of course, a separate part of the book is devoted to the infrastructure around microservices: architecture scaling, logging and monitoring, service lifecycle management, and product health. Mentioned, although, it seems to me, the issues of using Service Mesh and Kubernetes, as well as End-To-End testing, are not fully disclosed, but for this, you probably need to write a separate book.