Updated: 2026-07-07

The service mesh field in 2024 is more mature than ever. The two major projects, Istio and Cilium, have converged on a sidecarless philosophy with Istio Ambient Mesh and Cilium Service Mesh. Linkerd keeps sidecars, but with minimal overhead. The question is no longer "sidecar or not?", but which one fits your stack and your team.

Key takeaways

  • Istio Ambient (GA in version 1.24, November 2024): per-node ztunnel + optional per-namespace waypoint. No per-pod sidecars for L4; Envoy per namespace for L7 (Istio’s GA announcement[1]).

  • Cilium Service Mesh (GA since 2022, with Cilium 1.12): eBPF-native with integrated CNI. The CNI and the mesh are the same piece (CNCF blog on the Cilium 1.12 announcement[2]).

  • Linkerd: very light Rust sidecars (~10 MB RAM/pod). The simplest option for small teams.

  • The decision is not "which is better" but which fits current CNI, required features, and ops team size.

  • All three are safe production bets in 2024.

The sidecarless shift

Until 2023, Istio and Linkerd used per-pod sidecars. The criticisms were concrete:

  • Resource overhead: 50-200 MB RAM per pod at large fleet scale.

  • Added latency: 2-5ms per network hop.

  • Lifecycle complexity: versioning and updating sidecars in a coordinated way.

The 2024 sidecarless solutions:

  • Istio Ambient (GA): per-node ztunnel handles L4 (mTLS, basic telemetry); per-namespace Envoy waypoint when L7 is needed (HTTP routing, retries, circuit breakers). According to Istio’s own team, the ztunnel image passed one million pulls on Docker Hub, and some deployments report resource-usage cuts of more than 90% versus the classic sidecar model.

  • Cilium Service Mesh: eBPF in the kernel, Envoy only when L7 is switched on. The CNI and the mesh are the same piece.

Linkerd still ships linkerd2-proxy sidecars written in Rust, light but sidecars all the same, betting on simplicity as its competitive edge. The project itself documents that its proxy uses roughly a tenth of the resources of an equivalent Envoy sidecar (under the hood of Linkerd’s Rust proxy[3]).

Comparison table

Aspect Istio Ambient Cilium Mesh Linkerd
Architecture ztunnel + waypoint eBPF + Envoy Sidecar linkerd2-proxy
Sidecars No (optional waypoint) No Yes (Rust, ~10 MB/pod)
CNI Separate from the mesh Integrated Separate
mTLS Per identity Per node/identity Per identity
L7 features Waypoint (per namespace) Envoy on-demand Sidecar
Observability Kiali + metrics Hubble linkerd-viz
Learning curve Medium-high High Low
Multi-cluster Strong Very strong Basic

When to pick each

Istio Ambient

Good fit when:

  • You already run Istio sidecar and want to migrate without losing features or rewriting VirtualServices/AuthorizationPolicies.

  • The environment demands strict compliance: JWT validation, OPA integration, and granular rate limits.

  • The use case is multi-tenant with strict per-namespace identities.

  • The full ecosystem matters: mesh + gateway + policy in a single project.

Approximate overhead for 100 nodes, 1000 pods:

  • ztunnel per node: ~100 MB RAM.

  • Waypoint per namespace (if L7 is used): ~200 MB extra.

  • Total: ~15 GB versus ~100 GB for the classic sidecar model.

Cilium Mesh

For the full architectural detail before deciding, see Cilium Service Mesh: when you don’t need sidecars.

Good fit when:

  • Greenfield project on Kubernetes, or you’re willing to change the CNI.

  • Throughput is critical: kernel-level eBPF avoids memory copies and context switches.

  • You want unified observability with Hubble for flows, service map, and policy verdicts.

  • You need network policy and service mesh in the same piece, without duplicating layers.

  • Multi-cluster with identity: Cilium Cluster Mesh is the most advanced option on the market.

The main implication: because it changes the CNI, migrating to Cilium is the most disruptive of the three projects. It requires a new-cluster plan and a coordinated cutover. For monitoring the resulting stack, see container monitoring beyond cAdvisor.

Linkerd

Good fit when:

  • The organization has a small team with no dedicated mesh operator.

  • Simplicity matters more than features: mTLS plus basic observability is enough.

  • The cluster is small to medium sized and sidecar overhead isn’t a budget concern.

Overhead: ~10 MB RAM per pod. On a 1000-pod cluster: ~10 GB, the lowest of the three.

Migrations

Istio sidecar → Ambient: officially supported path, incremental per namespace. Before moving, it’s worth reviewing how native sidecar containers changed in Kubernetes 1.28:

istioctl install --set profile=ambient
kubectl label namespace my-ns istio.io/dataplane-mode=ambient
# Remove sidecar annotations from the deployments

No app changes. Route-by-route migration.

Istio → Cilium: the most disruptive one because it changes the CNI. It requires a new-cluster plan, parallel testing, and a coordinated cutover. A 2-6 month project in mid-sized environments.

Linkerd → Istio Ambient: possible but not a drop-in swap. Istio’s CRDs are different, and so is the observability setup.

Built-in observability

Each project brings its own stack:

  • Istio: Kiali for the service graph, Prometheus, Jaeger/Zipkin for traces.

  • Cilium: Hubble with flow logs, policy verdicts, and a native service map.

  • Linkerd: linkerd-viz with golden-metrics dashboards and tap.

All three export to Prometheus. Each project’s Grafana dashboards are available in the public registries.

Real adoption, named and sourced

To avoid staying in generalities, here are published examples of production adoption:

  • Istio: Airbnb, Spotify, and Salesforce appear among the more than one hundred case studies the project itself collects, and they value its extensibility and the full mesh-plus-gateway-plus-policy coverage above all (Istio case studies[4]).

  • Cilium: Datadog was one of the earliest large-scale adopters, and today uses it as pod and service networking, to enforce network policies, and to encrypt host-to-host traffic in its own clusters (Cilium project journey report, CNCF[5]).

  • Linkerd: Nordstrom chose it as a lightweight way to secure communication between microservices without adding operational complexity (Buoyant case studies[6]).

These examples don’t dictate what to choose for your case, but they confirm that all three compete today on real production workloads, beyond blog comparisons.

Decision framework

Five questions to help you choose:

  • How much overhead can you afford? Linkerd < Cilium < Istio Ambient.

  • What features do you need? Istio > Cilium > Linkerd on enterprise features.

  • What’s your current CNI? If it’s already Cilium, Cilium Mesh is the natural fit. If not, Istio Ambient without changing the CNI.

  • Multi-cluster? Cilium or Istio.

  • Ops team size? Linkerd if small; Cilium or Istio Ambient with a dedicated team.

Conclusion

Service mesh in 2024 sits at a sweet spot: mature sidecarless solutions, low-overhead alternatives, and projects with solid governance. The right decision isn’t which project is best in the abstract, but which one fits your team, your existing stack, and the features you need. All three are safe production bets.

Sources

  1. Istio’s GA announcement
  2. CNCF blog on the Cilium 1.12 announcement
  3. under the hood of Linkerd’s Rust proxy
  4. Istio case studies
  5. Cilium project journey report, CNCF
  6. Buoyant case studies