There is a meme going around: Tony Soprano slumped in the shower, cortisol meter pinned to red — captioned "running 700 microservices". Below him, the same man serenely smoking a cigar, cortisol in the green: "running 1 big monolith". Engineers keep sharing it because, like all good infrastructure memes, it is a postmortem wearing a joke's clothes. We operate both kinds of estate for clients — and we have been the ones paged at 3am by both — so here is the serious version: what the 700-service bill actually contains, why the industry is quietly consolidating, what the meme conveniently forgets, and how to walk sprawl back without breaking production.

The per-service bill nobody puts in the RFC

Every microservice you add is not just code with an API. It is a standing operational liability: a deploy pipeline, a dashboard, an alert set, log routing, IAM roles and secrets, dependency patching, a cost line, and a slot in someone's on-call head. That overhead is roughly linear in services — but the interactions are not. Service boundaries are network calls, and network calls fail, time out, retry, and amplify; the failure modes grow with the square of the connections, not the count of the boxes.

The place you feel it first is incident response. In a monolith, a bad request gives you one stack trace. Across 12 services, the same bug is a distributed murder investigation: correlate request IDs across log systems, find the hop where latency exploded, discover the retry storm that turned a blip into an outage. Without serious tracing discipline (metrics, logs and traces), mean-time-to-resolution scales with your service count. That is the cortisol in the meme's top panel — it is measured in sleep.

And there is a literal bill too: per-service compute headroom (every pod sized for its own peak), inter-service data transfer and load balancer hops, N copies of every dev/staging environment, and the platform tooling (service mesh, registry, CI capacity) that exists only because the pieces are separate. On cost audits we regularly find that the architecture itself — not any single resource — is the biggest line item.

How companies end up at 700

Almost never by decision; always by default. Microservices became the prestige architecture of the 2015-2022 era — conference-driven, CV-friendly, and blessed by the fact that Netflix and Amazon genuinely need them. Teams split services along entity lines ("user-service, order-service, invoice-service…"), assumed the organization would grow into the architecture, and made each new feature a new repo because that was the pattern. The result in mid-size companies: service counts an order of magnitude larger than team counts — twenty services per engineer is not an architecture, it is a distributed monolith with extra steps and a pager problem.

The correction is real — and public

The industry has been walking this back for a couple of years, sometimes loudly: the best-known example is Amazon's own Prime Video team publicly describing how consolidating a distributed monitoring pipeline into what was effectively a monolith cut that workload's infrastructure cost by around 90%. The "modular monolith" — one deployable, strictly enforced internal module boundaries — has gone from consolation prize to respectable default, which is exactly the position we argued in our microservices adoption guide: most teams should start there and extract services only when something concrete (independent scaling, team autonomy, a different runtime) forces the split.

What the meme gets wrong

Honesty requires defending the top panel a little. The cigar-smoking monolith owner is relaxed until deploy day: one deployable means one blast radius, deploy fear that grows with team size, merge contention between teams, and scaling the whole application because one hot path is busy. Monoliths also rot in their own way — module boundaries erode until everything imports everything, and then you have the worst of both worlds with no network to blame. The meme's real lesson is not "one big monolith"; it is that service count is a cost you pay in stress, and you should buy as little of it as your organization actually needs. The defensible heuristic: your service count should look like your team count — each service owned end-to-end by exactly one team — plus the rare genuine outliers with independent scaling or compliance needs.

The consolidation playbook (walking it back safely)

  • 1. Inventory and map. List every service with owner, request rate, deploy frequency and infra cost; then map the call graph from traces. Services nobody can name an owner for are your first candidates — and there will be some.
  • 2. Pick merge candidates by symptom. The reliable signals: services that always deploy together (a distributed monolith confessing), chatty pairs whose traffic is mostly each other, tiny utility services with a request a minute, and clusters owned by a single team anyway.
  • 3. Merge as modules, not mud. Bring the code into a modular monolith keeping the old service boundaries as module boundaries — same interfaces, now function calls instead of network hops. You keep the design discipline and delete the failure modes (and the mesh config).
  • 4. Keep what earns its keep. Genuinely independent scaling profiles, isolation/compliance boundaries, different runtimes, or hard team-autonomy needs — those services stay. Consolidation is pruning, not demolition.
  • 5. Measure the outcome. On-call pages per week, deploy lead time, p95 latency, and the infra bill, before and after. In consolidations we have run, the first two move fastest — which is fitting, because they are the cortisol metrics.

Frequently asked questions

How many microservices should we have?
A defensible heuristic: on the order of your team count — each service owned end-to-end by one team — plus rare outliers with genuinely independent scaling, isolation or runtime needs. Twenty services per engineer is sprawl, not architecture.

Are microservices dead in 2026?
No. At genuine scale — many teams, independent scaling domains — they remain the right tool. What is ending is microservices as the default; the modular monolith has become the respectable starting point, with extraction on demonstrated need.

Can we merge microservices without downtime?
Yes — it is the strangler pattern in reverse: move code into the consolidated deployable behind the same interfaces, shift traffic gradually, retire the old service when it goes quiet. Boring and incremental is the point.

Does Kubernetes require microservices?
No. A modular monolith runs happily on Kubernetes — often better, since you drop the mesh and most inter-service networking. See our Kubernetes in real life guide.

Bottom line

The meme is funny because the bill is real: every service you run is rent paid in operations, incidents and sleep. Pay it where it buys you something — independent scaling, team autonomy, isolation — and consolidate the rest into well-bounded modules. The goal was never 700 services or 1; it was an architecture whose cortisol meter matches your actual needs.

Suspect you're paying the sprawl tax? Our Cost Optimization audit (fixed €5,000) quantifies the architecture-shaped part of your bill, and managed operations is who carries the pager either way. A free health scan will tell you quickly whether consolidation belongs on your roadmap.

Tags: #Microservices #Monolith #Architecture #DevOps #CloudCost