advanced 2 min answer

A platform is evaluating a service mesh. What should be checked before adopting, and what is the honest justification?

service-meshcomplexityobservabilitymtlsgrabarchitecture-selection
Show the full answer Hide the answer

What to check first

1. Is policy drift actually causing incidents? Look at the last ten incidents and count how many a mesh would have prevented. If retry behaviour is inconsistent but nothing has broken, the mesh is solving a theoretical problem.

2. Is the real problem observability? Very often the pain is "we cannot tell which service is slow", and a mesh is being considered because it provides that as a side effect. Distributed tracing, adopted directly, may deliver the actual need at a fraction of the cost — and this is the single most useful question to ask.

3. Could a shared library do it? With few languages, one well-maintained library each is a real option and dramatically cheaper.

4. Can the team operate a control plane? It is a distributed system and a correlated failure domain where a bad push affects everything at once.

5. What is the per-instance overhead across the fleet? Worth calculating rather than assuming.

The honest justification

Mutual TLS everywhere without touching applications, where a compliance requirement demands service-to-service encryption and identity — otherwise a per-language project repeated and maintained forever.

And consistency across languages and teams: retries, timeouts, circuit breaking and outlier ejection implemented once, so a platform-wide decision such as a retry budget becomes possible at all. With library-based policy across many languages, drift is structural rather than a discipline failure.

The deciding factor is usually organisational — the number of teams and languages — rather than technical.

The adoption approach

Incrementally, in value order: mutual TLS and telemetry first, since they deliver most of the benefit with least risk; traffic policy later.

And a specific caution: the control plane's blast radius must be understood before it is trusted. Staged configuration rollout, health-gated promotion on served-traffic signals, and a rollback path that does not depend on the control plane a bad configuration may have broken.