The problem
Every service in every language re-implements TLS, retries, timeouts, metrics and canary routing, and they all do it slightly differently.
How it works
- Data plane: an Envoy proxy beside each app intercepts all traffic in and out.
- Control plane: pushes routing rules, security policy and certificates to the proxies.
- Istio objects you'll meet:
Gateway(edge),VirtualService(routing rules, e.g. 90/10 canary),DestinationRule(subsets, load-balancing, circuit breaking),PeerAuthentication(mTLS).
- Many services in many languages need uniform security and traffic policy
- You need canary or blue-green routing and zero-trust mTLS
- Platform team exists to operate it
- A handful of services — a library or ingress is enough
- No team to own the mesh (it's real infrastructure)
- Tight latency budgets where an extra hop matters
I've been studying this through the GitOps flow I worked alongside: Helm charts deployed by ArgoCD to EKS, with Istio routing. Next step is running canary releases with VirtualService weights end to end in a lab cluster.
Sources & further learning
Videos, courses, docs and books I recommend for this topic.
Related topics
Kubernetes Essentials for Architects
The objects that matter — Deployment, Service, Ingress, ConfigMap/Secret, HPA — and the settings that decide reliability (probes, requests/limits, PDBs).
Circuit Breaker, Retry, Timeout & Bulkhead
The resilience toolkit — fail fast, retry safely, bound waiting, and isolate resources so one slow dependency can't take down the whole system.
Observability — Logs, Metrics, Traces
Know what your system is doing in production — the three pillars, OpenTelemetry, SLIs/SLOs, and alerting on symptoms not causes.
API Gateway & Backend-for-Frontend (BFF)
A single entry point that handles cross-cutting concerns (auth, rate limits, routing); BFFs go further with one tailored backend per client type.