Cos'è un service mesh e quando conviene davvero?

Un service mesh è uno strato infrastrutturale dedicato che gestisce la comunicazione fra i servizi di un'architettura a microservizi con confini di dominio ben delimitati: instrada le chiamate, cifra il traffico con mTLS, applica retry e timeout, e raccoglie la telemetria su ogni scambio, senza che questa logica viva nel codice applicativo. Storicamente si realizza con un proxy leggero (sidecar) accanto a ogni istanza di servizio, che intercetta il traffico in entrata e in uscita; dal 2024 l'alternativa ambient, senza sidecar, sposta la stessa funzione su proxy a livello di nodo basati su eBPF, riducendo l'overhead di risorse e la complessità operativa che il modello a sidecar comportava. Il mesh governa il traffico est-ovestfra servizi interni, mentre un gateway di ingresso governa il traffico nord-sud che entra dall'esterno: sono due strati distinti, spesso confusi nella stessa conversazione.

Dal sidecar al modello ambient

Il pattern sidecar, popolarizzato da Istio e Linkerd, inietta un proxy in ogni pod: robusto e maturo, ma con un costo per servizio in CPU, memoria e latenza che cresce linearmente col numero di istanze, e con un ciclo di aggiornamento del proxy da coordinare a ogni rilascio. Il modello ambient nasce per eliminare esattamente questo: un singolo proxy per nodo gestisce il traffico di più servizi, con un secondo livello opzionale per le funzionalità L7 più avanzate solo dove servono davvero. Il risultato è un profilo di risorse più leggero e un'adozione incrementale, perché un servizio può entrare nella mesh senza redeploy. Non è tutto guadagno, però: il piano di controllo resta, e con lui la superficie da capire, monitorare e tenere aggiornata a ogni nuova versione del progetto scelto.

Un esempio enterprise

Una banca che scompone un core bancario monolitico in una trentina di microservizi (pagamenti, conti, anagrafica clienti) introduce un service mesh per rispondere a un requisito di compliance preciso: ogni chiamata interna deve essere cifrata e autenticata, non solo quelle esposte all'esterno. Il mesh applica mTLS end-to-end e produce un log di chi ha chiamato chi, con che esito, utile sia per l'audit sia per isolare rapidamente un servizio che degrada durante un incidente. Lo stesso mesh applica anche il circuit breaking: se il servizio anagrafica risponde lento, il mesh limita le richieste in ingresso prima che l'intero flusso di pagamento si blocchi a cascata. Nessuna di queste regole vive nel codice dei singoli servizi, e questo è precisamente il motivo per cui l'azienda ha scelto il mesh invece di implementarle trenta volte, una per servizio.

Perché conta per chi decide

Un service mesh introduce un piano di controllo aggiuntivo, latenza per hop e competenze operative da mantenere nel tempo, e questo costo è fisso: si paga anche con dieci servizi stabili quanto con cento. Sotto una certa scala, o quando i servizi cambiano raramente e i team che li possiedono sono pochi, il costo operativo del mesh supera il beneficio: mTLS fra due o tre servizi si può ottenere con certificati gestiti direttamente nell'applicazione, e il retry si scrive in una libreria condivisa. La domanda da porsi prima di adottarlo non è "un service mesh risolve questo problema?", quasi sempre la risposta è sì, ma "il numero di servizi e team che li possiedono giustifica un piano di controllo dedicato invece di una libreria condivisa?". È la domanda che nessun fornitore di mesh scrive nella propria documentazione, perché la risposta onesta esclude buona parte del mercato a cui vende.