Il problema del microservizio
Con la maturazione di Kubernetes (1.0 nel 2015) e la diffusione dell’architettura a microservizi, emergono problemi operativi ricorrenti che non sono dominio naturale dell’orchestratore né dell’applicazione:
- mTLS tra servizi — tutti i servizi interni dovrebbero autenticarsi reciprocamente
- Observability — tracciare chiamate cross-service, aggregare metriche, raccogliere log
- Traffic management — canary release, blue-green, A/B testing, failover, rate limiting
- Policy — autorizzazione a chi può chiamare cosa
- Retries, timeouts, circuit breakers — resilienza di rete
Implementare questi concetti in ogni microservizio porta a duplicazione, errori, inconsistenza tra linguaggi diversi. La risposta architetturale è il service mesh: un livello infrastrutturale che estrae queste responsabilità dall’applicazione e le delega a un data plane che opera su ogni pod.
Istio 1.0
Istio 1.0 è stato rilasciato il 31 luglio 2018, come iniziativa congiunta di Google, IBM e Lyft. Il progetto era stato lanciato in maggio 2017 con una prima 0.1; la 1.0 segna la maturità di produzione.
Architettura:
- Data plane — sidecar Envoy Proxy (Lyft, 2016) iniettato automaticamente in ogni pod Kubernetes. Tutto il traffico tra servizi passa per il sidecar
- Control plane — composto al 2018 da quattro componenti:
- Pilot — distribuisce configurazione ai sidecar
- Mixer — gestisce policy e telemetria (deprecato a fine 2019 in Istio 1.5)
- Citadel — emette certificati per mTLS
- Galley — validazione di configurazione
Licenza Apache 2.0. Codice ospitato su GitHub.
Capabilities
mTLS automatica — ogni chiamata tra servizi è cifrata e autenticata, senza modifica del codice applicativo. Identità basata su SPIFFE (Secure Production Identity Framework For Everyone).
Traffic management — via VirtualService e DestinationRule CRD (Custom Resource Definitions):
- Route traffic per header, percentuale, weight
- Canary deployment
- Mirroring (traffic shadowing)
- Retries configurabili
- Timeout per-service
- Circuit breaker
- Fault injection per testing
Observability — metriche esposte a Prometheus, tracing distribuito con Jaeger/Zipkin, log strutturati. Dashboard Grafana pre-configurate (RED metrics: Rate, Errors, Duration).
Policy enforcement — regole di accesso service-to-service, rate limiting, allow/deny list.
Kubernetes-native
Istio 1.0 è Kubernetes-nativo. Le configurazioni sono CRDs YAML versionabili in Git, gestibili con kubectl, integrate con GitOps (ArgoCD, Flux). Esempio:
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: v1Concorrenti
Istio non è l’unico service mesh emergente al 2018:
- Linkerd 2.x (Buoyant, CNCF) — focus su semplicità e performance; Rust data plane dopo la 2.0
- Consul Connect (HashiCorp) — integrato con Consul per service discovery
- AWS App Mesh, GCP Traffic Director — servizi gestiti cloud-specific
- Kuma (Kong) — cross-platform mesh (2019)
Istio si afferma come il più completo funzionalmente ma anche il più complesso operativamente. Linkerd 2 si ritaglia una nicchia per chi privilegia semplicità.
Complessità operativa
Un tema ricorrente nella comunità Istio 1.x è la complessità: installare e operare Istio non è banale. Il control plane ha molti componenti; il sidecar injection aggiunge overhead a ogni pod; debugging di problemi di rete richiede comprensione di Envoy, XDS API, cert management.
La serie Istio 1.5 (marzo 2020) introdurrà Istiod — consolidamento di Pilot, Citadel, Galley in un singolo binario — riducendo significativamente la complessità. Mixer verrà deprecato nella stessa release.
Adozione
Al rilascio 1.0 Istio è adottato da:
- Google GKE — Istio-on-GKE come servizio managed
- IBM Cloud — managed Istio
- Red Hat OpenShift — integrato con OpenShift Service Mesh
- Grandi SaaS — Salesforce, eBay, Autotrader, FICO, progetti internal
L’ingresso nel CNCF (Cloud Native Computing Foundation) arriverà nel settembre 2022 come progetto graduated.
Nel contesto italiano
Al 2018 l’adozione italiana di Istio è in fase esplorativa:
- Grandi aziende con adozione Kubernetes avanzata (banche, telco, assicurazioni) — valutazioni di proof of concept
- Provider cloud italiani — inizio di offering managed
- Startup native cloud — alcune adoption dirette
L’adozione si consoliderà nei tre anni successivi, parallelamente alla maturità di Kubernetes nel mercato italiano.
Riferimenti: Istio 1.0 (31 luglio 2018), Google + IBM + Lyft. Licenza Apache 2.0. Envoy Proxy (Lyft, 2016) come data plane. CRDs Kubernetes (VirtualService, DestinationRule, Gateway). SPIFFE identity. CNCF graduated project (settembre 2022).