The worst microservices system I have ever seen was not a monolith. It was a monolith that someone had chopped into twenty services which all still had to be deployed together, in the right order, or nothing worked. They had paid the full price of distribution and kept almost none of the benefits. There is a name for that, and it is not a compliment: a distributed monolith.
I have led the other kind too, the migrations that worked, and the difference between them was almost never the technology. Adopting microservices is not really a technical decision. It is a readiness decision, and you have to ask it at every level at once: are you ready as an individual, as a leader, as a team, as a company, and as a business domain, to change how you design, develop, deploy, monitor, and operate what you build? That, and not the architecture diagram, is what microservices actually change.
I saw the version that works at a payments company, the first German company I joined. We broke its monolith into more than ten services on Spring and domain-driven design, and an onboarding flow that used to take three months came down to about two weeks. It would be easy to credit Spring, or the diagram. But it worked because the domains were genuinely separable and the teams were ready to own them. Hand the same toolkit to teams that are not ready, and you get the distributed monolith instead.
They are a tool for solving specific problems, not a default you adopt because the industry is talking about them. I have written elsewhere about the choice between optimising the system you have and disrupting it for a new one – sometimes you push the engine you own as far as it will go, and sometimes you build a different machine, and the only real skill is knowing honestly which the moment in front of you calls for. The readiness question splits cleanly into three: people, processes, and technology. The green flags and the red flags live in each.
People
Microservices are an organisational shape before they are a technical one. The green flag is teams that are genuinely self-sufficient: able to own a service end to end, from design through deployment to the two a.m. page, working inside a culture of ownership and psychological safety where it is safe to say "this one is mine, and it broke." The deeper principle is the one I keep returning to: the right mindset and the right skillset come before the architecture, never after it.
The red flag is the same picture inverted, and it shows up fastest during a failure. Undefined ownership. Finger-pointing. No team willing to take a service from analysis through to monitoring. If a change breaks and the first conversation is about whose fault it is rather than how to recover, microservices will multiply that instinct by the number of services you run. Resistance to change, and a thin bench in DevOps or distributed-systems design, are the same flag wearing different clothes. People readiness is not the soft part of this decision. It is the foundation the rest stands on.
Processes
The green flag in process is clear domain boundaries. If your system divides into well-scoped, loosely coupled domains, the kind domain-driven design gives you, each one can become a service that owns its own data and its own decisions. The red flag is when it does not divide cleanly and you force the split anyway. That is precisely how you build the distributed monolith from the start of this piece: services so entangled they must change and deploy together, which turns out to be harder to operate than the monolith you began with. Microservices do not magically fix bad design; they amplify it. The same unclear boundaries that made the monolith tangled come back as version mismatches between services, latency on calls that used to happen in-process, and questions of consistency and event ordering that a single database used to answer for free. A bad function call becomes a bad network call, and now you need distributed tracing just to find where it went wrong.
Process readiness is also the boring, non-negotiable plumbing being thought through in advance rather than discovered in production: data validation and transformation, transaction management, eventual consistency, error handling and reporting, and a clear lifecycle for every API, schema, configuration, and database script, each with a version and an expiry. Teams that treat these as afterthoughts meet them later, one outage at a time. And if you cannot say what success looks like, which outcomes the move is meant to improve, you are not ready to make it, because you will have no way to tell whether it worked.
Technology
Technology is the readiness level everyone reaches for first, and the one that matters least on its own. The green flags are real but unglamorous: a robust CI/CD pipeline, automated testing, and genuine observability, with centralised logging, tracing, and error dashboards, so that when something fails in a distributed system you can find it and recover quickly instead of excavating. There should also be an actual need: a system straining against load, throughput, or capacity it cannot meet, or a real case for scaling a few components independently rather than scaling the whole application at once.
The red flags are the mirror image. Manual error detection and recovery. No real pipeline. And the quiet one that sinks more microservices projects than any outage: the cost and complexity simply outweigh the benefit. Microservices add overhead in deployment, orchestration, monitoring, and debugging, and a small or moderately complex system that serves its load comfortably on a monolith gains nothing by paying that tax. Overengineering with no business reason behind it is not architecture. It is expensive theatre.
Go, or Stay a Monolith
Put the flags together and the decision tends to make itself.
- Your system is complex and growing, with a real need for scalability and independent, modular deployment.
- Your teams are technically capable, and leadership is aligned with the cultural and operational shift, not just the technical one.
- You have a clear roadmap for cross-cutting concerns, non-functional requirements, and monitoring.
- Your team is still growing and has not yet run distributed systems in anger.
- The application is small to medium, with no real scalability or deployment bottleneck.
- The overhead of operating many services would outweigh the benefit.
If the green flags line up with where you are and where you are going, microservices can unlock genuine value. If the red flags dominate, the right move is not to adopt anyway and hope the readiness arrives later. It is to invest in the foundation first, the people, the process, and the platform, so that when you do split, you are splitting from strength rather than from wishful thinking.
In the end it was never about microservices. It is about delivering value.