The microservice problem
With Kubernetes’ maturation (1.0 in 2015) and the spread of microservice architecture, recurring operational problems emerge that are not natural territory of the orchestrator or the application:
- mTLS between services — all internal services should authenticate each other
- Observability — tracing cross-service calls, aggregating metrics, collecting logs
- Traffic management — canary releases, blue-green, A/B testing, failover, rate limiting
- Policy — authorising who can call what
- Retries, timeouts, circuit breakers — network resilience
Implementing these concepts in every microservice leads to duplication, errors, inconsistency across languages. The architectural answer is service mesh: an infrastructural layer that extracts these responsibilities from the application and delegates them to a data plane operating on each pod.
Istio 1.0
Istio 1.0 was released on 31 July 2018 as a joint initiative of Google, IBM and Lyft. The project had been launched in May 2017 with a first 0.1; 1.0 marks production maturity.
Architecture:
- Data plane — Envoy Proxy sidecar (Lyft, 2016) auto-injected into every Kubernetes pod. All inter-service traffic goes through the sidecar
- Control plane — composed in 2018 of four components:
- Pilot — distributes configuration to sidecars
- Mixer — handles policy and telemetry (deprecated late 2019 in Istio 1.5)
- Citadel — issues certificates for mTLS
- Galley — configuration validation
Apache 2.0 licence. Code hosted on GitHub.
Capabilities
Automatic mTLS — every call between services is encrypted and authenticated, without application code changes. Identity based on SPIFFE (Secure Production Identity Framework For Everyone).
Traffic management — via VirtualService and DestinationRule CRDs (Custom Resource Definitions):
- Route traffic by header, percentage, weight
- Canary deployment
- Mirroring (traffic shadowing)
- Configurable retries
- Per-service timeout
- Circuit breaker
- Fault injection for testing
Observability — metrics exposed to Prometheus, distributed tracing with Jaeger/Zipkin, structured logs. Pre-configured Grafana dashboards (RED metrics: Rate, Errors, Duration).
Policy enforcement — service-to-service access rules, rate limiting, allow/deny lists.
Kubernetes-native
Istio 1.0 is Kubernetes-native. Configurations are YAML CRDs versionable in Git, manageable with kubectl, integrated with GitOps (ArgoCD, Flux). Example:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews-route
spec:
hosts:
- reviews
http:
- match:
- headers:
end-user:
exact: jason
route:
- destination:
host: reviews
subset: v2
- route:
- destination:
host: reviews
subset: v1Competitors
Istio is not the only emerging service mesh in 2018:
- Linkerd 2.x (Buoyant, CNCF) — focus on simplicity and performance; Rust data plane after 2.0
- Consul Connect (HashiCorp) — integrated with Consul for service discovery
- AWS App Mesh, GCP Traffic Director — cloud-specific managed services
- Kuma (Kong) — cross-platform mesh (2019)
Istio establishes itself as the most functionally complete but also the most operationally complex. Linkerd 2 carves a niche for those prioritising simplicity.
Operational complexity
A recurring theme in the Istio 1.x community is complexity: installing and operating Istio is not trivial. The control plane has many components; sidecar injection adds overhead to every pod; debugging network issues requires understanding Envoy, XDS APIs, cert management.
The Istio 1.5 series (March 2020) will introduce Istiod — consolidation of Pilot, Citadel, Galley into a single binary — significantly reducing complexity. Mixer will be deprecated in the same release.
Adoption
At 1.0 release Istio is adopted by:
- Google GKE — Istio-on-GKE as managed service
- IBM Cloud — managed Istio
- Red Hat OpenShift — integrated with OpenShift Service Mesh
- Large SaaS — Salesforce, eBay, Autotrader, FICO, internal projects
CNCF (Cloud Native Computing Foundation) entry will come in September 2022 as a graduated project.
In the Italian context
As of 2018 Italian Istio adoption is exploratory:
- Large companies with advanced Kubernetes adoption (banks, telco, insurance) — proof-of-concept evaluations
- Italian cloud providers — start of managed offerings
- Cloud-native startups — some direct adoption
Adoption will consolidate in the following three years, in parallel with Kubernetes maturity in the Italian market.
References: Istio 1.0 (31 July 2018), Google + IBM + Lyft. Apache 2.0 licence. Envoy Proxy (Lyft, 2016) as data plane. Kubernetes CRDs (VirtualService, DestinationRule, Gateway). SPIFFE identity. CNCF graduated project (September 2022).