Istio Service Mesh

What is Istio?

In a microservices estate, every service needs the same networking chores: encrypt traffic, retry idempotent failures, time out, emit metrics, control who calls whom. Implementing that in every language and codebase yields drift and gaps. Istio extracts the chores into infrastructure: proxies intercept all service-to-service traffic and apply policy configured centrally — classically an Envoy sidecar per pod, or in ambient mode, shared node-level proxies that cut the per-pod overhead substantially.

What you actually get

Mutual TLS everywhere with automatic certificate rotation — workload identity and encryption in transit without touching application code, the feature that most often justifies the mesh alone (it’s the service-to-service half of zero trust). Traffic management: percentage-based splits for canaries, mirroring production traffic to test versions, retries and circuit breaking as configuration. Uniform telemetry: consistent latency/error metrics and trace propagation for every hop, regardless of implementation language.

The honest cost

Istio is a distributed system layered on your distributed system. Each proxied hop adds latency (single-digit milliseconds, but hops compound); sidecars consume memory per pod at fleet scale; and debugging gains a new suspect — “is it the app, the network, or the mesh?” is a real triage branch. The prevailing guidance has genuinely shifted: don’t adopt a mesh for two services and an ingress. Adopt it when mTLS compliance, multi-team traffic policy, or canary automation across dozens of services makes the operational tax pay for itself.

What people get wrong

• Mesh before need — a gateway plus library-level retries covers small estates at a tenth the complexity.
• Ignoring ambient mode in 2026 sizing: the sidecar-resource objection is much weaker than the folklore claims.
• Skipping incremental rollout: PERMISSIVE-mode mTLS exists so you can migrate namespace by namespace; big-bang STRICT cutovers produce big-bang outages.

Primary source: Istio documentation — architecture

Istio’s Architecture: Data Plane and Control Plane

Istio splits into two components: the data plane, made up of Envoy proxy sidecars deployed alongside every application pod that actually intercept and manage traffic, and the control plane (Istiod), which configures those proxies centrally and manages certificate issuance for mutual TLS. This separation lets platform teams define policies once at the control plane level — encrypt all traffic, retry failed requests up to three times, split 10% of traffic to a canary version — and have them automatically enforced consistently across every service in the mesh, without any of that logic needing to be implemented or maintained inside individual application codebases written by potentially many different teams.