Service mesh without sidecars

A few years ago, the service mesh was the hottest topic in cloud-native. Every conference had talks about Istio, every architecture diagram had little proxies next to every service. Then reality hit: meshes were complex, resource-hungry and hard to debug. Many teams tried one and quietly removed it.

The technology has changed a lot since then. The biggest shift: you no longer need a sidecar proxy in every pod. So it's worth looking again.

What a mesh does

A service mesh handles communication between services, outside your application code. Typical features:

• mTLS everywhere: encrypted traffic between services, with automatic certificate management and service identity.
• Authorisation policies: "only the checkout service can call payments".
• Traffic management: retries, timeouts, circuit breaking, traffic splitting for canary releases.
• Observability: request metrics, traces and a map of which services talk to which, without changing code.

All of this can be built into each application with libraries, but then every team, in every language, has to do it right. A mesh does it once, for everyone.

Sidecar vs sidecarless

The sidecar model (classic Istio, Linkerd): every pod gets an extra proxy container. All traffic in and out of the pod goes through it.

• Pros: strong isolation, rich per-pod features.
• Cons: a proxy per pod uses CPU and memory (it adds up across thousands of pods), adds latency, complicates pod startup and shutdown, and upgrading the mesh means restarting every workload.

The sidecarless model moves the proxy out of the pod:

• Istio ambient mode (generally available since Istio 1.24, late 2024) splits the mesh into two layers. A lightweight per-node proxy called ztunnel handles mTLS and basic L4 policies for all pods on the node. Optional waypoint proxies handle L7 features (HTTP routing, retries, header-based policies) only for the services that need them.
• Cilium service mesh uses eBPF in the kernel for networking and L4 features, with a shared per-node Envoy for L7 features.

Benefits: much lower resource overhead, no changes to pods, upgrades without restarting applications, and you only pay for L7 processing where you use it.

The best part of the new service meshes is how much less of them there is.

The main options today

• Istio: the most feature-rich, now with both sidecar and ambient modes. Large ecosystem, more complexity. A CNCF graduated project.
• Linkerd: focused on simplicity and low overhead, with a very small, Rust-based proxy. Still sidecar-based, but light. Note that the creator, Buoyant, changed how stable releases are distributed, so check the current licensing and release model before adopting.
• Cilium: if you already use Cilium as your CNI, its mesh features come almost for free, including mutual authentication and transparent encryption.
• Cloud provider meshes: managed options on some clouds, often based on Istio.

What you get

When a mesh fits, the benefits are real:

• Zero-trust networking with almost no application changes. Every service has an identity, every connection is encrypted and authorised.
• Consistent reliability features (timeouts, retries) without each team implementing them.
• Canary releases with precise traffic splitting.
• Golden metrics (requests, errors, latency) for every service, out of the box.

What it costs to run

Even sidecarless, a mesh is a significant component:

• Another control plane to install, upgrade and monitor.
• Learning curve: new concepts, new resources, new failure modes.
• Debugging: when a request fails, is it the app, the mesh, or the network?
• Policy sprawl: authorisation policies need to be managed carefully.

Do you need a mesh?

Questions I'd ask:

• Do you need mTLS between services for compliance or zero-trust requirements? A mesh is the easiest way to get it at scale.
• Do you have many services in many languages, where library-based solutions would be inconsistent?
• Do you need fine-grained traffic control for progressive delivery?
• Do you have the team capacity to run it?

If you have a handful of services in one language, probably not. If you have dozens or hundreds of services and security requirements, probably yes, and ambient-style meshes make the decision much easier than it used to be.

Also note: Gateway API now covers some of what people used meshes for (traffic splitting, header routing at the edge), and its GAMMA initiative extends the same API to service-to-service traffic in meshes. That means less mesh-specific configuration to learn.

So, should you look again?

If you rejected service meshes a few years ago because of sidecar overhead and complexity, yes. Istio ambient and Cilium have removed the biggest pain points. Start with just mTLS and observability, add L7 features only where needed, and see if it earns its place.

My take: a mesh used to be a big commitment. Without sidecars, it's finally something you can adopt one small step at a time.

— Desly