Did you have to migrate everything to Kubernetes to get the overhead reduction?

No. The biggest reduction came from standardizing deployment and observability. Kubernetes (EKS) helped by enforcing consistent runtime patterns, but the real win was eliminating snowflake pipelines and making services debuggable by default.

Why not use a service mesh like Istio to solve reliability problems?

I’ve seen Istio become a second platform teams have to operate. We deferred a mesh until basic hygiene was consistent: timeouts, retries, circuit breakers, tracing, and sane SLO-based alerting. Only then does a mesh become additive instead of overhead.

How did you decide which services to consolidate?

We consolidated services that were ownerless, low-traffic but high-noise, or tightly coupled (always deployed/failing together). We did not consolidate core domain services just to reduce the count—service count is a vanity metric if operability is still inconsistent.

What metrics should we track to prove overhead is going down?

Pager volume, MTTR, change failure rate, deploy frequency, and engineer-hours spent on deploy/debug toil. Cost per service can be useful too, but only if you separate runtime cost from incident and coordination cost.

Case-studies · Jan 19, 2026 · 8 minute read

The 84-Service Migration That Finally Stopped Waking Up the On‑Call

A real microservices “cleanup” that reduced operational overhead by standardizing deployment, observability, and service boundaries—without pretending we could rewrite the business in a quarter.

Back to all posts

The 84-Service Migration That Finally Stopped Waking Up the On‑Call

Key takeaways

Implementation checklist