I’m trying to understand whether the software industry is shifting from microservices back to monolith architecture. My team broke our app into services for scalability, but we ended up with more deployment issues, higher cloud costs, and harder debugging. Now leadership wants to revisit a monolith, and I need help figuring out if this is a real trend, what tradeoffs others are seeing, and how to decide between microservices vs monolith for a growing product.
Yes, the pendulum did swing a bit. Not because microservices failed, but because teams used them too early.
What changed:
A lot of companies learned the hard way. Microservices add network calls, retries, versioning, tracing, service ownership, CI/CD sprawl, and on-call pain. If your team is small, or your app is one product with one database and one release train, a monolith often wins.
What microservices are good at:
Independent scaling.
Clear team boundaries.
Different runtime needs.
Isolating failure domains.
High deploy frequency per domain.
What they cost:
More infra.
More debugging.
More deploy breakage.
More local dev pain.
More platform work.
You felt this part already.
A useful rule:
Start with a modular monolith.
Split only where you have proven pressure.
Examples:
One module needs 10x more scale.
One part needs stricter security boundaries.
Teams block each other every week.
Release risk stays high because one area changes constantly.
A lot of shops are doing this now. Fewer services. Bigger services. Better internal module boundaries. Same idea, less ops tax.
If your team broke things apart and got worse outcomes, I’d check 3 things.
- Did you split by business domain, or by technical layers.
- Did you build platform support first, logs, tracing, deploy tooling, contract tests.
- Did you have a team size and product complexity big enough to pay for the split.
If 2 or 3 are ‘no’, a partial move back makes sense. Not full rewite panic mode. Merge low-value services first. Keep hard boundaries in code. Track deploy time, MTTR, infra cost, and change failure rate. If those improve, you’ve got your answr.
Yeah, kinda, but I’d phrase it less like “the industry is going back” and more like “the industry stopped pretending microservices are the default adult choice.”
@shizuka is right about teams adopting them too early. I’d push one point a little further though: sometimes the problem is not architecture first, it’s org design. A lot of companies used microservices to paper over messy team coordination. Then they discovered they had simply moved the mess onto the network.
That’s why you see “modular monolith” getting popular again. Not because monoliths are magically simple, but because in-process calls are still cheaper than distributed systems drama. Latency, partial failures, schema drift, queue weirdness, auth between services, duplicated observability… all that stuff is very real and very expesnive.
What I’m seeing now:
- fewer tiny services
- more “macroservices” or bounded apps
- stronger internal APIs inside one codebase
- a lot less tolerance for service sprawl
One thing I slightly disagree on with the usual advice: “independent scaling” is often oversold. Plenty of teams split for scaling and never actually hit a scale profile that justified the split. They just got 14 deploy pipelines and worse sleep.
If your team already split and regrets it, that doesn’t automatically mean “rebuild the monolith.” It might mean:
- combine the noisiest low-value services
- keep async boundaries only where they truly help
- reduce service count before changing everything else
- stop optimizing for hypothetical future scale
So yes, pendulum swung back a bit. Not to big ball of mud monoliths, but to pragmatism. Fewer moving parts, clearer ownership, less archiecture cosplay.
I think @shizuka is mostly right, but I’d add one uncomfortable point: a lot of “microservices pain” is actually platform immaturity. Teams blame the architecture when the real issue is they never built decent CI/CD, tracing, contract testing, or runtime ops.
So no, the pendulum did not swing cleanly back to monoliths. It swung away from naive microservices.
A good test is this: if you merged 5 services tomorrow, would your business logic get clearer or would your team just lose useful isolation? That tells you whether the split is artificial.
What changed in the industry:
- people now price operational complexity more honestly
- service boundaries are expected to match business boundaries, not technical fashion
- consolidation is acceptable
- “monolith first” is no longer seen as unsophisticated
Where I slightly disagree with the common take: monoliths also create hidden coupling, slower builds, risky deployments, and political ownership fights. They are not automatically the safer choice.
Pros for ':
- simpler readability if it helps document architecture decisions
- can make tradeoff discussions more searchable internally
Cons for ':
- only useful if kept current
- can turn into vague architecture theater fast
My advice: do a service-by-service audit. Keep the boundaries that protect volatility or compliance. Merge the ones that only create handoffs. That is usually the real middle path.