A platform team proposes adopting a service mesh for 40 services. Make the case for and against, then decide.
Show the full answer Hide the answer
What it genuinely provides
mTLS everywhere, with automated certificate rotation. This is usually the deciding factor. Doing mTLS by hand means short-lived certificates rotated automatically in every language and framework in the estate — an unrealistic amount of work done consistently. The mesh makes it configuration.
Uniform resilience policy — retries, timeouts, circuit breaking, outlier ejection — applied without touching application code and without each language's client library implementing it differently.
Zone-aware load balancing, keeping traffic in-zone. Cuts latency and cross-zone data transfer charges, which is a line item large enough to notice.
Traffic splitting for canaries and dark launches, with header-based routing.
Consistent per-hop metrics and traces for every service, without instrumentation work.
What it costs
A second thing to debug. "Connection refused" becomes a question of identity, policy, certificate validity, trust bundle or proxy configuration. Teams need to learn a new failure vocabulary.
Per-workload resources — CPU and memory for every sidecar — and one to two milliseconds per hop, which matters on a deep call chain.
Operational ownership. The mesh control plane is production-critical. If nobody owns upgrades, it becomes a liability.
The decision
Yes, if you have a security requirement for mTLS or fine-grained authorisation between services, multiple languages (so library-based policy would be duplicated), and a platform team that can own it.
No, if you have a handful of services in one language, no mTLS mandate, and no platform team. A shared client library gives most of the resilience benefit at a fraction of the operational cost.
Forty services in multiple languages with a platform team is the case where it usually pays.
How to adopt it if you do
Start with observability only — mTLS in permissive mode, no policy enforcement. Get the estate running with sidecars before adding rules. Then strict mTLS. Then authorisation policy, service by service.
Evaluate the ambient / sidecar-less model, which shares a node-level proxy and exists specifically to reduce the per-pod overhead.