It seems, the peak of HYIP on microservices is left behind. We no longer read the posts "How I transferred my monolith to 150 services" several times a week. Now I hear rational thoughts more often: “I don’t hate monolith, I just care about efficiency.” We even observed several migrations from microservices back to the monolith . When moving from one large application to several smaller services, you will have to solve several new problems. We list them as briefly as possible.

Installation: from basic chemistry to quantum mechanics

Setting up a basic database and application with a background process was a fairly clear process. I publish a readme on Github - and often after one hour, maximum, a couple of hours, everything works, and I start a new project. Adding and running code, at least for the initial environment, is done on the first day. But if we ventured on microservices, the time of the initial launch takes off to the skies. Yes, now we have a Docker with orchestration and a cluster of K8 machines, but for a novice programmer, all this is an order of magnitude more complicated. For many juniors, this is a burden that really is unnecessary complexity.

The system is not easy to understand

Let's stop on our junior for a minute. With monolithic applications in the event of an error, it was easy to track and go straight to debugging. Now we have a service that talks to another service, which puts something in a queue on a message bus that processes another service - and then an error occurs. We have to put all these parts together in order to eventually find out that service A is working in version 11, and service E is already waiting for version 12. This is very different from my standard consolidated journal: you have to use an interactive terminal / debugger to go through the process step by step. Debugging and understanding in essence have become more difficult.

If you can't debug it, maybe we’ll test them.

Continuous integration and continuous development are now becoming commonplace. Most new applications that I see with each new release automatically create and run tests and require that tests pass and be viewed before registering. These are excellent processes that cannot be abandoned; they have become a big shift for many companies. But now, in order to really test the service, I have to pick up the full working version of my application. Remember that new engineer with a K8 cluster of 150 services? Well, now we will teach our CI system how to raise all these systems to check that everything really works. It’s probably too much effort, so we’ll just test each part in isolation: I’m sure that our specifications are good enough, the APIs are clean, and the failure of the service is isolated and will not affect the others.
')

There is a good reason for all compromises. Right?

There are many reasons for switching to microservices. I have seen this done for greater flexibility, for scaling commands, for productivity, to ensure better stability of work. But in reality, we have invested decades in the tools and practices of developing monoliths that continue to evolve. I work with professionals in different technologies. We usually talk about scaling because they collide with the limits of a single node of the Postgres database. Most of the talk is about scaling the database .

But I am always interested in learning about their architecture. At what stage of the transition to microservices they are. It is interesting to observe how more and more engineers say that they are satisfied with their monolithic application. For many, microservices will benefit, and the benefits will outweigh the bumps on the migration path. But personally, please give me my monolithic application, a place on the beach - and I am absolutely happy.