It seems the peak hype about microservices is behind us. We no longer read posts titled 'How I migrated my monolith to 150 services' several times a week. Now, I more often hear sensible thoughts: 'I don't hate monoliths; I just care about efficiency.' We've even observed several migrations . When transitioning from one large application to several smaller services, you'll have to tackle several new problems. Let's list them as briefly as possible.
Setup: from basic chemistry to quantum mechanics
Configuring a basic database and application with a background process was quite a straightforward process. I publish readme files on Github—and often within an hour, at most a couple of hours, everything is running, and I start a new project. Adding and launching code, at least for the initial environment, is done on the very first day. But if we dare to venture into microservices, the time to initial launch skyrockets. Yes, we now have Docker with orchestration and a cluster of K8 machines, but for a beginner programmer, this is orders of magnitude more complex. For many juniors, this burden really is an unnecessary complication.
The system is hard to understand
Let's take a moment to pause on our junior developer. With monolithic applications, when an error occurred, it was easy to trace it and immediately start debugging. Now we have a service talking to another service, which queues something on the message bus, which processes another service—and here an error arises. We have to piece together all these parts to eventually find out that Service A is running version 11 while Service E is already awaiting version 12. This is vastly different from my standard consolidated log: I need to use an interactive terminal/debugger to walk through the process step by step. Debugging and understanding have fundamentally become more challenging.
If it can't be debugged, perhaps we should test it.
Continuous integration and continuous development are becoming commonplace. Most new applications I see automatically create and run tests with each new release and require tests to pass and be reviewed before they are registered. These are excellent processes that cannot be skipped, representing a significant shift for many companies. However, to truly test the service, I need to bring up a full working version of my application. Remember that new engineer with the K8 cluster of 150 services? Well, now we will teach our CI system how to spin up all these systems to check that everything is truly working. This might be too much effort, so we will just test each part in isolation: I'm confident that our specifications are good enough, the APIs are clean, and service failures are isolated from affecting others.
Every compromise has a good reason, right?
There are many reasons to switch to microservices. I've seen it done for greater flexibility, for team scalability, for performance, to ensure better operational resilience. But in reality, we've invested decades in tools and practices for monolithic development that continue to evolve. I work with professionals across various technologies. Typically we talk about scalability because they encounter the limits of a single Postgres database node. Most of the conversation revolves around .
But I'm always curious about their architecture. At what stage of the transition to microservices are they? It's interesting to see more and more engineers expressing satisfaction with their monolithic application. For many, microservices will be beneficial, and the rewards will outweigh the bumps in the migration path. But personally, just give me my monolithic application and a spot on the beach — and I'm completely happy.
Source: habr.com
