Transition from monolith to microservices

Each more or less successful product comes to a state when adding new features to the existing code base becomes so hard that the cost of new functionality exceeds all possible benefits from its use. Of course, a good and attentive architect will take care of the application in advance and guide the development in the right direction. The most popular approach at the moment involves cutting one large piece of code into many small projectors, each of whom is responsible for their specific capabilities. When designing such a system hangs a huge responsibility. It is necessary to think over and develop this type of interaction between these separate pieces, so that future changes do not require rewriting everything to hell.

It is clear that there are a huge number of expert articles in the network, which show us the importance of such an architecture and tell about what kind of architecture can be called good and which is not very good. There are a huge number of methods of interaction between individual programs of a large application with its own protocols, protocol versioning and documentation, writing software interfaces, how to deploy and synchronize all this stuff together. Of course, each such article or method is logical and consistent, and especially if the method described is confirmed by practice. But the trouble is not that the designers do not know what system they want to get in the end. The trouble is how to move on to such a proper architecture and when can we stop writing a monolithic application and start writing adult microservices so that the boys are not ashamed.

First monolith

First, the common “monolith first” approach is fully justified and seems to be a reasonable compromise between the cost of development and the speed of development. A small monolithic application has several quite obvious advantages, one of the main ones is the speed of adding new functionality. In our monolithic project, it is easier to see the connectivity of the code base and make sure that the new, just added, functionality works. Undoubtedly, an experienced reader will notice that microservices make it possible to achieve weak coherence of different parts of the application, but one should not forget that in most cases actively developing monolithic projects have a code base not of the highest quality.

From microservices not to leave

The second statement is that an infinitely huge application with infinite functionality cannot be monolithic. Sooner or later, parts of the application appear that run on different servers, or at least just by different processes.

The main thing to start

The third conclusion is derived from the first two and it says that any monolithic application sooner or later changes the architecture to microservice. Accordingly, there is a point in time in the development of an application, when it is necessary to change the development strategy and begin to introduce microservices.

The above three statements put two questions before us: when and how. Let's take it in order.

How to understand that the very moment has come that it is time to nag microservices?

Let's approach this question especially practically, and we will restrict the desired time point from above and below. Clearly, it is early to engage in the cutting of a monolith, if all team members are still oriented in any part of the application. Also, a sign of the timeliness of the monolithic architecture is that a newcomer to a team can easily and naturally begin to develop a new functionality immediately after familiarization.

Allocating microservices is already getting late, if you want to cache html-pages entirely, because they slow down, and to speed up, you need to rewrite half of the application, replace the ORM, or rewrite everything in another language, where everything is good and the applications do not slow down.

It is still early to switch to architecture with microservices, if any of the types of Fowler refactorings can be easily applied in a monolithic application. But it would be necessary to replace the monolithic architecture for a long time, if simple refactoring is not foreseen, or in general it is difficult to find such a place that could be refactored in a purely fauler way.

And the most important criterion for the need to start switching to the microservice architecture is when the cost of adding a new feature begins to outweigh the benefits from this feature itself.

How to start the migration of architecture in favor of microservices?

There are several strategies for changing the paradigm. The simplest and almost always wrong is to develop a microservice architecture from scratch, using a monolithic application, as an example to follow. Probably, the prevalence of this approach is the main argument of the adherents to write applications immediately on microservices. But it seriously adds value to the initial development of the application.

A more adequate approach to the transition from the monolith to microservices is the gradual budding of microservices and the writing of new functionality already separate from the main application. The approach is good and working, but it has one major drawback - the main monolithic application will not disappear in the foreseeable future. As a result, we will have a monolith and a bunch of supporting services, instead of a set of independent microservices.

Ultimately, in a sane way to go to the microservice architecture, we can call the way in which the main monolithic application is divided into several large-caliber applications with strong mutual connectivity. After that, sub-applications are considered and refactored separately, simultaneously touching neighbors and forcing them to adapt and change together. Gradually, this approach will lead to a decrease in connectivity and the emergence of the well-established interface of each sub-application. Upon reaching such an established time point, it seems possible to make changes to the sub-applications without affecting the neighboring ones. And this sub-application is considered as a monolith simpler and lower level. And similar procedures are done with it. Gradually, the application fights into more or less equal parts. Some parts in the process become unnecessary, some duplicate existing parts or merge into one common service to eliminate duplication. As a result, sooner, or rather late, an established application on microservice architecture is obtained.

Instead of conclusions.

Microservices - good. Monolith - good. Good code is good. The working code is good. The article does not urge to urgently change the principle of development in applications that inhibit, crookedly written or not written the way we would like. Also microservice architecture is not a panacea for all the troubles of developers. The article describes the points and ways of transition from monolithic to microservice architecture.

"Fault tolerance", "distribution", "scalability" is certainly good, but this is not the main advantage of microservice architecture. The most important thing that gives such an approach is to reduce the cost of making changes.