A platform is considering a sidecar to provide mTLS, retries and telemetry without changing application code. What does that buy and what does it cost?
Show the full answer Hide the answer
What it buys
- Uniform behaviour across a polyglot estate. Retries, timeouts, circuit breaking, mTLS and telemetry implemented once rather than per language, per framework and per team's level of care.
- Change without redeploying applications. A policy update is a sidecar configuration change.
- The strongest single justification: mutual TLS with workload identity, which replaces network-location trust with something that cannot be spoofed by being inside the network — and which is genuinely hard to retrofit into every application.
What it costs
- A process per pod, with its own memory, CPU and latency contribution. At large fleet sizes that is a meaningful proportion of the infrastructure bill.
- A new failure mode on every request path. A misconfigured or failing sidecar breaks the application it was added to protect, and it is a component the application team does not own or understand.
- Debugging complexity. A request now traverses two proxies, and diagnosing "why did this call fail" requires understanding a layer most engineers have not read.
- Upgrade coordination across the entire fleet, which is a large, recurring operational commitment.
When it is not justified
When the estate is single-language and the same behaviour could be a shared library. A library is simpler, faster and easier to debug, and its only real weakness — that every service must adopt and update it — is manageable in a homogeneous estate with a small number of services.
And when the motivation is traffic management or observability alone. Both are available more cheaply, and adopting a sidecar for them means taking on its full operational cost for a fraction of its value.
The judgement
Adopt it for identity and uniformity in a polyglot estate at meaningful scale; use a library otherwise. And be explicit that the value arrives when the cryptographic identity is used for authorisation — a mesh with mTLS and no authorisation policy has encrypted channels between services that will still do whatever they are asked.