Move the plumbing into a proxy beside each app
A sidecar shares the pod’s network and lifecycle; the app calls it on localhost. One implementation for every language, upgraded without rebuilding the app.
Sidecar or ambassador?
Bad: Rival patterns
Pick a helper container or an outbound proxy.
Good: Where vs what
Sidecar is where it runs; ambassador is what it does: an outbound proxy, often for a legacy app.
Every call crosses two proxies. The control plane only configures them.
iptables routes traffic through an Envoy in each pod. istiod pushes routes and certificates; if it’s down, proxies keep their last config.
0.54 ms
added at p99 by two sidecars per call
Istio 1.24’s benchmark: 0.18 ms with no mesh, 0.72 ms with sidecars. A four-call checkout adds ≈ 2.2 ms, roughly 1% of 200 ms.
Apps make 3 attempts. You add a mesh; the bank API three hops away slows.
The trap
729 attempts per tap. Istio retries twice by default: 3 × 3 = 9 per hop, cubed. Retry in one layer.
Ambient mode moves the proxy out of the pod
One ztunnel per node handles mTLS; Envoy waypoints add L7 only where needed. Join by labelling a namespace, with no pod restarts.
When is a mesh worth it?
- About 20+ services owned by several teams
- Two or more languages, and mTLS everywhere
- Frequent canaries, and a platform team to run it
- Otherwise: shared library, load balancer, API gateway
The interview line
A mesh moves mTLS, retries and telemetry out of code, for ≈ 0.5 ms a call. Skip it for five services.