Microservices or monolith: looking for a solution

When a big product or small software begins to grow into a Leviathan, which development path should we choose? Should we rewrite everything from scratch or continue “historically established” traditions? And in general, is it worth revising the very concept of architecture?

Hello, habrovchane! My name is Konstantin, and I am the lead developer of a fairly large system that began sometime as an experiment. A small site in PHP, created literally "on the knee" and, of course, a monolith. As time went on, the site grew and faced a number of problems, the solution of which posed the question “and then how?”.

Monolith or microservices? What to choose? The basic difference of approaches, in my opinion, is that the monolith implies a centralized processing cycle of the user's request, and microservices - a decentralized one. The general advantages and disadvantages of both approaches are widely known and are listed more than once (for example, here , here or here ). However, there are not so obvious and obvious factors influencing the choice of architecture.

1. Loading staff members . With the rapid development of the product, a pool of tasks accumulates, which cannot be solved in a reasonable time - everyone is busy. And if such a “blockage” is rare, it does not make sense to expand the staff of developers. The obvious solution is external contractors (companies or freelancers). But how to give them to work a piece of the product, without risking to turn it into OpenSource, roughly speaking? In the case of using microservices, this task is much easier to solve.
2. The complexity of the dive . The larger the product, the longer it takes for a new employee to settle into it. Especially if there are many different defaults in the code (yes, good documentation greatly facilitates the process, but if it is not there?) And customizations for particular cases. From this point of view, dealing with a small independent part is much easier than with the whole product at once.
3. Resources at peak loads . In my practice, there was a case when the load on the servers sometimes grew to unacceptable values ​​(and if it was concretely exhausted the RAM, the swap was used and the server turned into a vegetable for a while), with free operation all the rest time (the load was no more than 30% in terms of RAM ). And such peaks happened irregularly and with long pauses. In the case of a monolith (we believe that there is nowhere to optimize the code), only the connection of new servers with a copy of the entire system for load balancing saves. And in the case of microservices, a processing queue can be organized (of course, this is applicable only for non-critical operations that are not expected quickly, such as uploading an Excel spreadsheet).
4. Perform tasks in the "background" mode . Which way this factor “shakes the boat” depends on its size and complexity. As a rule, monolith and timer are enough (cron). But if tasks begin to accumulate in large groups, problems also arise. It is necessary to balance already and cron-tasks. Microservices significantly facilitate this situation.
5. The difficulty of maintenance . In the case of microservices, the requirements for iron maintenance are increasing - where, what and how should be set up. Monolith - roughly speaking, some settings for all nodes, microservices - the settings depend on the requirements of specific microservices that are running on the node.
6. Qualification requirements . The more technology zoo (and, as a rule, it grows, if the system is microservice), the higher the requirements for the skills and knowledge of staff members. After all, happen improvements or problems, they must cope. Or you need more specialists to cover the entire stack.

Is it even necessary to choose? Is the game worth the candle? I think definitely worth it. But it is necessary to approach the issue with a cool head. Otherwise, some problems will simply be replaced by others.
')
In my case, the turning point came when the site ceased to "fit" in the resources of one server. Then it was decided to rewrite the system in accordance with the best option in my opinion - a hybrid one. There are general recommendations for product development in the “hybrid case”. But I would like to add some recommendations.

When designing a starting monolith, the possibility of further connection of external services must be laid immediately. Immediately build interconnects as if these components are already (or almost already) “external services”. Especially if they are resource intensive.

Immediately consider the policy of working with caches and data storages (databases and files). For example, provide general access to the user session.

And most importantly - do not rush to extremes. For myself, I derived the following formula for a good project: “an effective system is a balanced system”. In particular, this is expressed in the fact that I only carry large, logically isolated kernel fragments into microservices. And then, only when fulfilling at least one of the conditions:

1. load limiting and forecasting is required, the time delay due to the execution of tasks is alternately not critical
2. separation will give significant performance gains.

As a result of this approach, the system turned out to be 95% functional, which is located in the kernel, and 5% in microservices. But at the same time, the core accounts for only 60% of the entire load. And at the same time, you can ensure that the load on individual servers does not exceed critical values.

So microservices are (from a certain size of a product) well, if you use them only in case of real need, and not because of fashion or “because it's cool.” There are great products that successfully live monolith. But sometimes the monolith does not solve the problem ...

Thank!