Break a monolith into a few dozen (or a few hundred) microservices, and the network stops being plumbing and becomes the integration layer — every call between services now needs encryption, retries, timeouts, load balancing, and observability that used to be handled inside one process. A service mesh moves that logic out of application code and into shared infrastructure, so individual services don’t each have to reimplement mutual TLS and retry logic. This explainer covers how a mesh works — sidecar proxies versus the newer eBPF-based sidecar-less model — why microservices architectures tend to need one at all, and how three of the leading open-source options, Istio, Linkerd, and Cilium’s service mesh, compare on architecture, maturity, and what their own documentation claims.
At a Glance
| What it is | Infrastructure layer that handles service-to-service networking, security, and observability |
| Classic model | A proxy “sidecar” container injected into every application pod |
| Newer model | Sidecar-less, using eBPF to move networking logic into the Linux kernel |
| Core features | Mutual TLS (mTLS), traffic management (routing, retries, circuit breaking), telemetry |
| Istio | Envoy-proxy based; supports both sidecar and sidecar-less “ambient” modes; CNCF graduated (2023) |
| Linkerd | Purpose-built Rust micro-proxy sidecar (linkerd2-proxy); CNCF graduated (2021, first mesh to do so) |
| Cilium Service Mesh | eBPF datapath for L3/L4, Envoy for L7 parsing; sidecar-free option; Cilium project CNCF graduated (2023) |
What Problem This Solves
In a microservices system, every request between services is now a network call, and network calls fail, get intercepted, and need observability in ways in-process function calls never did. Without a mesh, each service team has to implement its own TLS handling, retry and timeout logic, and metrics/tracing instrumentation — inconsistently, and often incorrectly under pressure to ship. A service mesh centralizes that logic: it provides automatic mutual TLS between services so traffic is encrypted and both ends are cryptographically authenticated, traffic management features like retries, timeouts, circuit breaking, and fine-grained routing (for canary releases or A/B testing) without touching application code, and uniform observability — metrics, logs, and distributed traces — generated by the mesh’s infrastructure rather than hand-rolled in every service.
Sidecar vs Sidecar-less (eBPF) Architecture
The traditional mesh architecture injects a proxy container — a “sidecar” — into every application pod, and reroutes all of that pod’s inbound and outbound traffic through it (typically via iptables rules), so the proxy can enforce mTLS, apply routing rules, and emit metrics transparently to the application. This is how Istio’s sidecar mode and Linkerd both work by default. The newer alternative uses eBPF (extended Berkeley Packet Filter), a Linux kernel technology that lets programs run safely inside the kernel’s networking path, to handle L3/L4 traffic (IP, TCP, UDP) without a per-pod proxy process at all — Cilium’s service mesh and Istio’s newer “ambient mode” both use variations of this approach. Per Cilium’s own documentation, “protocols at the application layer such as HTTP, gRPC, and DNS are parsed using a proxy such as Envoy,” meaning even sidecar-less designs still fall back to a proxy for Layer-7-aware features — the eBPF path handles the lower-level, higher-volume traffic, while a shared (not per-pod) Envoy instance handles the parts that genuinely require application-layer parsing.
Why Microservices Need This: mTLS, Traffic Management, Observability
The three capabilities a mesh centralizes map directly onto problems that get worse as a system grows. mTLS gives every service cryptographic proof of who it’s talking to and encrypts the traffic, which matters once services are communicating across namespaces, clusters, or clouds and can no longer assume the internal network itself is trustworthy — this connects directly to the identity-centric thinking behind zero trust architectures. Traffic management — Istio’s own documentation highlights request routing, fault injection, traffic shifting, circuit breaking, traffic mirroring, and load balancing as core tasks — lets operators change how traffic flows (for a canary rollout, a failover, or a chaos test) without redeploying the services themselves. Observability gives every team the same metrics, logs, and distributed traces for free, rather than each service instrumenting itself differently (or not at all).
Istio vs Linkerd vs Cilium Service Mesh
| Dimension | Istio | Linkerd | Cilium Service Mesh |
|---|---|---|---|
| Data plane proxy | Envoy (general-purpose proxy), sidecar or ambient “ztunnel” | linkerd2-proxy, a purpose-built micro-proxy written in Rust | eBPF kernel datapath for L3/L4; Envoy for L7 (HTTP/gRPC/DNS) parsing |
| Sidecar requirement | Optional — supports classic sidecar mode and sidecar-less “ambient mesh” | Required — proxy injected into every meshed pod | Optional — can run without per-pod sidecars; falls back to Envoy for L7 |
| mTLS | Built-in, via Istio’s identity/certificate system | Built-in by default via the Identity service (a TLS certificate authority) signing proxy certs | Supported; Cilium’s own documentation currently lists mutual authentication as a “Beta” feature |
| CNCF status | Graduated, July 2023 | Graduated, July 2021 — the first service mesh project to graduate | Cilium (the overall project) graduated, October 2023 |
| Documented emphasis | Breadth of traffic-management features and multi-mode flexibility (sidecar + ambient) | Simplicity and a minimal, purpose-built proxy footprint | Kernel-level efficiency; avoiding a second proxy process per pod for most traffic |
A few caveats worth flagging directly from the documentation: Linkerd’s own architecture docs make no quantitative performance claims and don’t publish head-to-head benchmarks against Istio or Cilium. Cilium’s launch material (from Isovalent, the company founded by Cilium’s creators) does include comparative latency charts for its sidecar-free design versus a two-sidecar Istio setup, but presents them as illustrative figures in a vendor blog post rather than as a reproducible, numbered benchmark — so readers should treat them as a vendor claim, not an independently verified result. Istio’s ambient mode and Cilium’s service mesh are both newer than their respective projects’ sidecar-based roots, and both are evolving faster than their sidecar counterparts.
Trade-Offs
- Istio: The broadest feature set and strongest ecosystem/tooling support, but historically the heaviest resource footprint and steepest operational learning curve in sidecar mode (mitigated, but not eliminated, by ambient mode).
- Linkerd: Praised in its own documentation and by the CNCF for simplicity and a lightweight, purpose-built proxy; narrower feature surface than Istio, and still requires a sidecar in every meshed pod.
- Cilium Service Mesh: Lowest per-pod overhead when the sidecar-free path is used, and it comes bundled with Cilium’s broader eBPF-based networking/CNI capabilities; L7 features still depend on Envoy, and its mTLS/mutual-authentication feature is documented as Beta at the time of writing.
- General trade-off: All three add real operational complexity (certificate rotation, proxy upgrades, policy CRDs) — a mesh is a net win once the number of services and the cross-service traffic justify it, and a net cost for a handful of services that don’t need mTLS or fine-grained traffic shaping yet.
Bottom Line
All three meshes solve the same core problem — mTLS, traffic management, and observability for service-to-service traffic — but make different architectural bets. Istio trades operational weight for the broadest feature set and now offers a sidecar-less path of its own via ambient mode. Linkerd bets on a minimal, purpose-built Rust proxy and operational simplicity, and was the first service mesh to reach CNCF graduation. Cilium bets on pushing as much as possible into the kernel via eBPF, falling back to Envoy only where Layer-7 parsing genuinely requires it. For teams already running Cilium as their CNI, its service mesh is a natural extension; for teams wanting the most mature, broadly supported option, Istio and Linkerd — both CNCF-graduated — remain the safer defaults, with the sidecar-vs-sidecar-less choice increasingly available within Istio itself.
FAQ
Do I need a service mesh for a small number of microservices?
Usually not. The operational overhead (certificate management, proxy upgrades, added latency hops) tends to outweigh the benefit until the number of services and the volume of east-west traffic make hand-rolled mTLS and retry logic unmanageable.
What does “sidecar-less” actually mean?
Instead of injecting a dedicated proxy container into every application pod, networking logic runs via eBPF programs in the Linux kernel (for L3/L4) and, where needed, through a shared rather than per-pod proxy for L7 protocols.
Is Istio’s ambient mode the same as Cilium’s approach?
They’re conceptually similar — both avoid a per-pod sidecar — but Istio’s ambient mode uses a shared per-node “ztunnel” component over a secure tunneling protocol, while Cilium relies on eBPF as the in-kernel datapath directly; the two are independent implementations, not the same technology.
Which project is the most mature?
By CNCF graduation date, Linkerd was first (2021), followed by Istio (2023) and Cilium as an overall project (2023); graduation reflects governance and adoption maturity as judged by the CNCF, not a ranking of technical capability.
Can I run more than one of these at once?
Not typically on the same workloads — they compete for the same traffic-interception point (iptables rules or eBPF hooks). Some setups do combine Cilium as the CNI/networking layer with Istio’s control plane for policy, since Cilium can act purely as the dataplane underneath.