Here's a fun game: find a company that adopted microservices because of a genuine technical need.
I'll wait.
In fifteen years of consulting, I've seen maybe two. Everyone else adopted microservices because someone in a suit read an article about how Netflix does it, and Netflix is successful, so clearly the architecture is the reason.
This is like assuming Michael Jordan was great because of his shoes.
Microservices don't solve a technical problem. They solve a management problem.
The management problem is this: you have teams that don't trust each other, can't coordinate, and ship at different speeds. Instead of fixing the teams, you build walls between them and call it "service boundaries."
Now nobody has to talk to anyone. Each team owns their little kingdom. They can use whatever framework they want, deploy whenever they want, and blame the other services when things break.
It's organisational debt laundered through architecture.
If you're a consultancy, microservices are a gift from heaven.
Think about it. A monolith has a natural limit. At some point, it's done. Features ship, the codebase stabilises, and there's less work to do. Terrible for billing.
But microservices? Microservices are forever.
First, you need to build the services. That's six months.
Then you need to build the infrastructure to run them. Kubernetes, service mesh, observability. Another six months.
Then you need to figure out why service A can't talk to service B, and why deploys take four hours, and why that one service keeps running out of memory. Another year.
Then you need to re-architect because it turns out the service boundaries were wrong, and now you have a distributed monolith with all the complexity of microservices and none of the benefits.
That's three years of billing, minimum. For a system that a competent team could have built as a monolith in four months.
I've seen this play out so many times it feels like a script. The consultancy comes in, proposes microservices, gets the contract, and disappears three years later leaving behind a system that requires a full-time team just to keep running.
It's not malicious. It's just incentives. When you bill by the hour, complexity is your friend.
Here's something nobody says out loud: a lot of managers prefer slower development.
Not consciously. They'd never admit it. But think about what fast development actually means.
Fast development means things change quickly. Decisions get tested immediately. Ideas get proven wrong the same week they're proposed. There's nowhere to hide.
Slow development is safer. You can have meetings about the architecture. You can debate approaches for months. You can write documents and review documents and schedule meetings to discuss the documents. By the time anything ships, everyone's forgotten what the original goal was, so it's hard to call it a failure.
Microservices are perfect for this. They give you an endless supply of legitimate-sounding reasons why things take so long.
"We're still setting up the CI/CD pipeline." "The service mesh is being configured." "We're waiting on the platform team."
None of these are excuses. They're real work. Necessary work, if you've committed to the architecture. It's just that the architecture itself was the mistake.
There's a deeper thing happening here, and I've never seen anyone write about it.
Managers want control. This is understandable. It's their job to make sure things get done. They're responsible when things go wrong.
But control and speed are in tension. Fast teams are autonomous teams. They make decisions without asking. They ship without approval. They break things and fix them before anyone notices.
This is terrifying if you're a manager who needs to know what's happening.
So managers, without realising it, select for controllable developers. People who ask before acting. People who document before building. People who wait for approval.
These developers are slower. By definition. The behaviours that make them controllable are the same behaviours that slow them down.
And then the managers get frustrated that development is slow.
It's a trap of their own making. They built a team optimised for control, then complained about the lack of speed. And instead of changing the team dynamics, they adopt an architecture that legitimises the slowness.
Microservices are the perfect cover. Now the slowness isn't a people problem. It's a technical problem. And technical problems can be solved with more consultants.
You want to know the funny thing about Netflix?
They didn't start with microservices. They started with a monolith. They scaled the monolith as far as it could go. They hit real, genuine, technical limits — the kind you only hit when you have a hundred million users.
Then, and only then, they broke it apart.
They also had teams of world-class engineers who could handle the complexity. Engineers who'd been working on the system for years and understood it deeply. Engineers who could make the transition because they knew exactly where the boundaries should be.
Your startup with twelve developers and ten thousand users is not Netflix.
But you knew that already.
Here's what's happening now: the monolith is coming back.
Not because people got smarter. Because the tools got better. Rails got faster. Postgres got better. Single servers got ridiculously powerful. The "scale" problems that justified microservices in 2015 can now be solved with a bigger database and some caching.
And AI? AI loves monoliths. It's much easier to understand and modify a single codebase than to navigate fifty services with their own repos, their own deploy pipelines, and their own tribal knowledge.
The complexity that once felt sophisticated now just feels expensive.
If you're about to adopt microservices, ask yourself this:
Are we doing this because we have a genuine technical problem that can only be solved with service boundaries?
Or are we doing this because our teams can't coordinate, and this is easier than fixing the actual problem?
If it's the second one — and it usually is — you're not solving anything. You're just converting an organisational problem into a technical one. And technical problems compound in ways organisational problems don't.
Three years from now, you'll have the same dysfunctional teams, plus a distributed system that nobody fully understands.
The consultants will be long gone.
But the invoices will remain.