Service Mesh (Sidecar vs Sidecarless/Ambient/eBPF)

A mesh manages east-west traffic

A service mesh manages east-west traffic: service-to-service calls inside the cluster. Its job is to move cross-cutting network concerns out of every application's code and into a uniform infrastructure layer:

• Security: automatic mTLS between services (zero-trust: every call authenticated and encrypted, no plaintext on the wire), plus authorization policy (service A may call service B).
• Traffic control: retries, timeouts, circuit breaking, and traffic splitting / shifting (send 5 percent to v2 for a canary) without touching app code.
• Observability: uniform L7 telemetry, golden metrics, and distributed-trace context for every hop, whatever language each service is written in.

The sidecar model and its tax

The classic implementation is the sidecar model: a proxy (Envoy) is injected into every Pod, and all traffic goes app -> local sidecar -> remote sidecar -> app. This is powerful but not free. Every Pod now runs an extra container, so a 40-service fleet with hundreds of Pods pays real memory and CPU per Pod (tens of MB each, adding up to GBs cluster-wide), and every hop adds mTLS and proxy latency (often 1 to several ms per call, which compounds across a deep call graph). Operationally you now run and upgrade a fleet of proxies, which is real "proxy sprawl."

The sidecarless / ambient shift

The 2024 to 2025 shift is meshes that cut this tax:

• Istio Ambient splits the mesh into a per-node L4 component (ztunnel) handling mTLS for all Pods on the node, plus an optional per-namespace L7 proxy (waypoint) only where you need retries/splitting. Most Pods pay no per-Pod proxy.
• Cilium pushes mTLS and L4 policy into the kernel via eBPF, avoiding a userspace proxy hop for much of the work.

The win is fewer proxies, lower per-Pod memory, and lower latency for the common L4 path, while keeping mTLS everywhere. Ambient/eBPF meshes reached GA maturity around 2025 and are the direction of new adoption. Gateway API is the converging standard for both north-south and (via GAMMA) east-west config, which lets you swap the underlying implementation with less lock-in than the older bespoke CRDs.

Sidecar vs ambient data paths

Step 1 / 3

Stage 1 of 3: The classic sidecar model: an Envoy proxy injected into every Pod, all traffic app to local sidecar to remote sidecar to app. Every Pod pays memory (tens of MB each, GBs cluster-wide) and every hop adds 1 to several ms of proxy latency.

A mesh is not always warranted

For a handful of services, you can get mTLS from the platform, retries and timeouts from a shared client library, and metrics from your framework, without operating a mesh. Mesh adoption has actually declined for small fleets precisely because the operational cost outweighs the benefit until you have dozens of services in multiple languages where per-language libraries stop being viable.

Interview nuance: the strong answer is not "add Istio." It is "at 40 services in mixed languages, a mesh is justified because you cannot keep mTLS and retry logic consistent across five client libraries, and I would choose ambient/eBPF to avoid the per-Pod sidecar tax." The weak answer adds a mesh reflexively for three services.

Recap: a mesh moves mTLS, retries/timeouts, traffic shifting, and L7 telemetry out of app code; sidecars cost memory and latency per Pod, ambient/eBPF (Istio Ambient, Cilium) cut that tax and are the 2025 direction, and for a small fleet a mesh is often not worth it.