What Is a Service Mesh: Istio, Linkerd and When You Need One

What a service mesh is

In a microservice system, services constantly call each other. Each call needs encryption, timeouts, retries, metrics and access rules. Without a mesh, every team implements this in its own code and libraries, in every language.

A service mesh moves this logic into the infrastructure. It has two parts:

• Data plane: proxies that sit in the path of every request between services and actually apply the rules.
• Control plane: the component that configures all those proxies, issues certificates and collects their settings from your config.

Your application just makes a normal HTTP or gRPC call. The mesh decides how that call is secured, routed and measured.

Sidecar and sidecarless

Sidecar model. A proxy container runs next to each application container in the same Kubernetes pod. All traffic in and out of the pod goes through it.

[Pod A: app | proxy] ---mTLS---> [Pod B: proxy | app]

• Pros: fine-grained per-workload control, mature and well understood.
• Cons: an extra container in every pod, more memory and CPU overall, upgrades often require restarting pods.

Sidecarless model. Instead of a proxy per pod, a shared component per node handles basic encrypted transport, and optional heavier proxies handle advanced HTTP features only where needed. Istio's ambient mode follows this approach; some meshes also use eBPF in the kernel.

• Pros: less overhead, no pod restarts to join the mesh.
• Cons: newer, fewer production stories, different failure and isolation model.

What a mesh gives you

• mTLS between services: every connection is encrypted and both sides prove their identity with certificates the mesh issues and rotates automatically.
• Authorization policies: "only orders may call payments", enforced by identity rather than IP.
• Retries and timeouts: configured centrally, consistent for every service.
• Traffic splitting: send a portion of traffic to a new version for canary releases, or mirror traffic for testing.
• Circuit breaking and outlier detection: stop sending requests to failing instances.
• Telemetry: request rates, error rates and latencies for every service pair, plus support for distributed tracing, without code instrumentation for the basics.

Note: tracing still needs your services to pass trace headers along. The mesh cannot connect incoming and outgoing calls inside your process on its own.

Istio vs Linkerd

Both are CNCF projects and both are used in production. Check current licensing and release model of each before committing, since distribution terms can change.

Honest criteria: do you need one?

A mesh is real infrastructure that someone must upgrade, debug and understand at 3 a.m. Consider skipping it if:

• You have a handful of services owned by one team.
• You are not on Kubernetes or have no one comfortable operating it.
• Your requirement is just "HTTPS inside the cluster" — a simpler solution may do.
• You have not yet set up basic metrics, logs and alerts. Do that first.

A mesh starts to make sense when:

• Many services in several languages need consistent security and reliability rules.
• Compliance requires encryption and identity for all internal traffic.
• You do frequent canary releases and need precise traffic control.
• A platform team exists to own it.

Alternatives for small teams: an API gateway at the edge, retries and timeouts in a shared client library, and network policies in Kubernetes.

Common mistakes

• Installing a mesh to "look modern" before there is a concrete problem to solve.
• Double retries: retries in the app and in the mesh multiply load during an incident.
• Turning on strict mTLS in one step and breaking services that are not yet in the mesh. Use a permissive mode first.
• Ignoring resource limits for proxies and getting surprised by cluster costs.