Scritto da
Come migliorare l’osservabilità, la sicurezza e l’affidabilità di un’applicazione a microservizi? Le service mesh rappresentano una soluzione moderna e potente per affrontare queste sfide. In questo articolo facciamo chiarezza: scopriamo cosa sono, come funzionano e quando conviene implementarle.
Cosa sono le service mesh
Una service mesh è un layer applicativo che aggiunge funzionalità a un network tra servizi. Come intuibile, è particolarmente utile nell’ambito di applicazioni a microservizi, che prevedono la divisione dell’app in numerosi servizi di dimensioni ridotte, che comunicano tra loro usando la rete e diversi protocolli (HTTP e gRPC principalmente).
Questi componenti comunicano attraverso una rete le cui caratteristiche intrinseche sono la bassa affidabilità, l’esposizione ad attacchi e la difficile osservabilità. Le service mesh risolvono il problema gestendo il traffico tra i servizi e garantendo maggiori livelli di affidabilità, osservabilità, controllo e sicurezza. Il tutto senza richiedere cambiamenti di codice applicativo.
Monitoraggio, gestione del traffico, funzionalità di resilienza e sicurezza possono essere configurati una volta e applicati in modo automatico su tutti i servizi che fanno parte della mesh. In assenza di service mesh, queste e altre funzionalità devono essere sviluppate in ogni singolo servizio, con dispendio di tempo (dunque di costi) e maggiore rischio di bug e problemi di sicurezza.
Come funzionano le service mesh e il modello Sidecar
Dopo aver definito di cosa stiamo parlando, vediamo qualche dettaglio tecnico in più sul funzionamento. Una service mesh si basa su un’architettura composta da due piani distinti: il data plane e il control plane. Il data plane è formato da una rete di proxy sidecar, ossia componenti software distribuiti insieme a ciascun microservizio, che intercettano e gestiscono tutto il traffico in entrata e in uscita. Questi proxy svolgono funzioni chiave come l’instradamento delle richieste, l’applicazione di policy di sicurezza, il bilanciamento del carico e la raccolta di dati per l’osservabilità, senza richiedere modifiche al codice applicativo.
Il modello sidecar consente di isolare i cosiddetti Cross-Cutting Concerns (CCC), come logging, retry, autenticazione e autorizzazione, spostandoli all’esterno della business logic del microservizio. Questo approccio migliora la manutenibilità e consente agli sviluppatori di concentrarsi esclusivamente sulle funzionalità di dominio.
Il control plane è responsabile della gestione centralizzata della mesh. Si occupa di configurare dinamicamente tutti i proxy distribuiti nel data plane, orchestrare le policy di comunicazione, raccogliere metriche e log e interfacciarsi con strumenti di osservabilità. Attraverso questo livello, è possibile aggiornare regole e comportamenti della mesh in tempo reale, senza necessità di riavviare i servizi.
Insieme, data plane e control plane costituiscono l’infrastruttura della service mesh, abilitando una gestione coerente e sicura della comunicazione tra microservizi in ambienti complessi e dinamici, come quelli Cloud Native.
Service Mesh vs API Gateway: differenze e complementarità
Ora, cosa c’entrano service mesh con gli API gateway? I concetti sono distinti, eppure si tratta di strumenti spesso confusi, vediamo in che modo si differenziano.
Un gateway API agisce come punto di ingresso per le chiamate esterne, esponendo le API e gestendo autenticazione, rate limiting, trasformazione dei payload e versioning. È un componente fondamentale per tutte quelle applicazioni che dialogano con client esterni (web app, mobile app, IoT, ecc.).
Dal canto suo, una service mesh lavora all’interno del dominio dell’applicazione, governando le comunicazioni tra microservizi. Si occupa di routing interno, retry, resilienza, sicurezza end-to-end e osservabilità distribuita.
I due strumenti non sono alternativi ma complementari. In un’architettura ben strutturata, l’API gateway gestisce l’interfaccia verso l’esterno, mentre la service mesh si occupa della sicurezza, visibilità e affidabilità del traffico interno, garantendo policy coerenti e controllo granulare in ambienti complessi. Tuttavia, in contesti semplici o poco strutturati, un API gateway avanzato può coprire alcune funzionalità tipiche di una service mesh, anche se non offre lo stesso livello di controllo, osservabilità e automazione su larga scala.
Spring Boot e service mesh: un'accoppiata vincente
Dopo aver visto le differenze tra API Gateway e service mesh e il ruolo che ricoprono nelle architetture moderne, è utile capire come queste tecnologie si integrano concretamente nella realizzazione di applicazioni a microservizi. Un esempio pratico è rappresentato da Spring Boot, uno dei framework open source più utilizzati per la creazione di microservizi enterprise. Di cosa si tratta esattamente? Spring Boot consente di realizzare rapidamente microservizi indipendenti e performanti, ma non si occupa della gestione del traffico di rete, né degli aspetti di sicurezza, resilienza o osservabilità che caratterizzano un’architettura distribuita.
Qui entra in gioco la service mesh, che si integra perfettamente con servizi creati in Spring Boot. Grazie all’architettura sidecar, i microservizi Spring Boot possono delegare alla mesh tutte le funzionalità trasversali, senza dover modificare il proprio codice. Questo consente di mantenere la business logic pulita e concentrarsi sul dominio applicativo, lasciando a Istio, Linkerd o Consul il compito di gestire rete, policy, sicurezza e monitoraggio.
Spring Boot rappresenta quindi una base solida per lo sviluppo di microservizi in ambienti cloud native, mentre la service mesh aggiunge uno strato fondamentale per la gestione della complessità che nasce quando quei servizi iniziano a comunicare tra loro.
Implementazioni di service mesh
Dopo aver visto come le service mesh si integrano nelle architetture applicative, passiamo ora alle soluzioni disponibili per metterle in pratica. Le possibilità non mancano, infatti, dal 2017, anno della nascita delle service mesh come qui descritte, sono stati creati molti prodotti per permetterne l’implementazione. La maggior parte è basato su Envoy proxy.
Conseguentemente è emersa l’esigenza di definire uno standard. Con questo scopo, nell’ambito della CNCF, è nato anche il progetto Service Mesh Interface. L'obiettivo dell'API SMI è fornire un set comune e portatile di API per le service mesh che gli utenti Kubernetes possono utilizzare in modo indipendente dal provider, così da non vincolarsi strettamente a nessuna implementazione specifica.
I principali prodotti per l’implementazione delle service mesh, come Istio, Linkerd e Consul, utilizzano lo standard SMI. Vediamoli più nel dettaglio.
Istio: la soluzione più conosciuta
Sicuramente la soluzione più popolare è Istio, creato e supportato da Google ed IBM, aziende che propongono anche un’offerta commerciale per poterlo utilizzare gestito.
Nell’ambito Google va citato Istio su Google Kubernetes Engine, strumento che fornisce l'installazione e l'aggiornamento automatizzati di Istio nel cluster GKE. Per gli utilizzatori di Google Cloud, Google consiglia l’adozione di Anthos Service Mesh, ovvero la distribuzione di Istio completamente supportata da Google.
A differenza di altri progetti, Istio è utilizzabile anche fuori Kubernetes. Permette pertanto di mettere insieme vecchie infrastrutture tradizionali con un'infrastruttura Cloud Native basata sui container.
Per quanto riguarda le integrazioni Cloud, Istio funziona con Google Cloud, Alibaba Cloud e IBM Cloud.
Linkerd: semplicità su Kubernetes
Un altro prodotto molto conosciuto, anche perché nato per primo, è Linkerd. La sua particolarità è il fatto di funzionare solo su Kubernetes. Disegnato per essere non invasivo e performante, ha il vantaggio di richiedere poco tempo per essere adottato. Linkerd promette leggerezza, semplicità e sicurezza.
Il progetto è stato sviluppato nell’ambito della CNCF ed è completamente open source. L’integrazione Cloud offerta è con DigitalOcean.
Consul Service Mesh
Consul Service Mesh, sviluppato da HashiCorp, è una soluzione versatile pensata per ambienti multi-platform. Può operare sia in Kubernetes sia in ambienti bare metal e VM-based, ed è particolarmente apprezzato per la gestione flessibile dei servizi distribuiti.
Consul supporta mutual TLS (mTLS), policy avanzate di autorizzazione, oltre che integrazioni con sistemi di discovery e automazione. Inoltre, è disponibile in versione open source e enterprise, con funzionalità dedicate alla governance tra team e alla gestione multi-dominio.
AWS App Mesh
AWS App Mesh è la soluzione proposta da Amazon Web Services. Non è open source, ma è completamente gestita da AWS e pensata per essere usata con Amazon ECS, Amazon EKS, Fargate e EC2.
Basata anch’essa su Envoy proxy, AWS App Mesh permette una visibilità nativa sul traffico tra microservizi, con funzionalità di monitoraggio, controllo, resilienza e tracciamento distribuito, tutto integrato nell’ecosistema AWS.
Open Service Mesh
Open Service Mesh (OSM) è una service mesh open source creata da Microsoft, costruita per Kubernetes e completamente compatibile con lo standard SMI.
È progettata per essere semplice da installare, sicura e facilmente estendibile. OSM si integra bene con Azure Kubernetes Service (AKS), ma può essere utilizzata anche in ambienti Kubernetes generici.
Kuma
Kuma, sviluppata da Kong, è una service mesh moderna e multi-zone progettata per ambienti Kubernetes e VM-based, con il supporto di proxy sidecar oppure proxyless.
Supporta mTLS, routing avanzato, osservabilità, e si distingue per un’interfaccia amministrativa user-friendly. È adatto a realtà che operano su più cluster o in ambienti ibridi, grazie alla sua architettura control-plane globale e data-plane distribuito.
Come scegliere un'implementazione di service mesh
Insomma, le soluzioni non mancano, anzi. Ma un panorama così ricco di offerte può destabilizzare a un primo impatto: quale implementazione è meglio adottare? Cerchiamo di definire delle linee guida.
La prima considerazione riguarda il tipo di cloud utilizzato. Se l’applicazione si trova su un public cloud sicuramente il consiglio è di adottare il prodotto che il vendor propone. Nel caso di Google, Anthos Service Mesh; per AWS, AWS App Mesh.
Il discorso cambia quando si parla di cloud privato e ibrido. Se si dispone unicamente di cluster Kubernetes, la soluzione più diretta e semplice è scegliere un prodotto basato totalmente su Kubernetes come Linkerd o Kuma.
Un altro scenario è quello di un cloud ibrido dove oltre a cluster Kubernetes sono presenti anche virtual machine o addirittura bare metal. Per poter trattare l'intero network con le stesse funzionalità disponibili per i container occorre adottare un prodotto più flessibile, come Istio. Questo permette di gestire un ampio spettro di infrastrutture ma va messo in conto che è molto più complesso di altri prodotti (primo fra tutti Linkerd).
Infine, un consiglio generale: è bene scegliere sempre prodotti che adottino o implementino degli standard, e che siano supportati da grandi vendor.
Vantaggi delle service mesh
Sviluppare microservizi, si sa, semplifica e accelera numerosi processi (ne abbiamo parlato in questo articolo sui vantaggi dei microservizi e delle applicazioni Cloud Native). Di contro, chiaramente, un contesto distribuito presenta maggiori complessità per quanto concerne l’osservabilità, il monitoraggio, la gestione e la risoluzione di problematiche. Qui entrano in gioco le service mesh: vediamo quali sono i principali benefici.
Security della comunicazione tra servizi
Le comunicazioni da un servizio ad un altro (cosiddette comunicazioni laterali) possono essere oggetto di diversi tipi di attacchi. Le service mesh consentono di mettere automaticamente in sicurezza le comunicazioni tra i servizi grazie a crittografia, mTLS, autenticazione e autorizzazione.
Questi aspetti sono fondamentali in un contesto complesso come quello dei microservizi, in cui l’adozione e l’enforcing di elevati standard di sicurezza potrebbero essere molto costosi e complessi da implementare, considerando anche l'eterogeneità degli stessi in termini tecnologici (es: linguaggi di programmazione diversi).
Le esigenze più comuni sono:
- Difendersi dagli attacchi man-in-the-middle, cifrando il traffico.
- Avere un sistema flessibile di controllo degli accessi, usando mTLS ed access policies.
- Capire chi ha fatto cosa e quando, usando sistemi di auditing.
Istio ad oggi propone il sistema più completo e sofisticato in grado di entrare nel dettaglio di ogni aspetto. Per maggiori informazioni ti consigliamo di dare un’occhiata a questo approfondimento sulle funzionalità di sicurezza di Istio volte a mitigare le minacce interne ed esterne.
Resilienza: il sistema di microservizi non si blocca
Con resilienza si intende la capacità di un microservizio di funzionare anche se uno o più microservizi smettono di farlo. I service mesh favoriscono la resilienza in vari modi:
- Circuit breaker: se il servizio A chiama il servizio B e il servizio B non risponde, la service mesh sostituisce automaticamente quel pezzo di chiamata con una risposta che permette al servizio A di fermarsi per non sovraccaricare il sistema. Oppure fornisce direttamente un codice di errore e interrompe quella comunicazione.
- Timeout: assicurano che il microservizio chiamante non venga bloccato per troppo tempo, altrimenti potrebbe non essere più in grado di accettare richieste.
- Retry: quando un servizio non risponde, con service mesh il retry avviene in automatico n° volte: se l'errore è temporaneo, il nuovo tentativo può far sì che la richiesta abbia esito positivo.
Osservabilità di dati wire, tracing e logging
Le service mesh acquisiscono dati wire come origine, destinazione, protocollo, URL, codici di stato, latenza, durata e simili. Una volta rilevati, le metriche e i log vengono raccolti dal control plane e passati allo strumento di monitoraggio prescelto.
Le service mesh supportano anche il tracing. Nell’ambito dei microservizi, il tracing è cruciale per capire le dipendenze tra servizi e impostare una root cause analysis. Un corretto tracing permette di identificare problemi di sequenza, anomalie dell'albero delle chiamate di servizio e problemi specifici della richiesta.
Altro aspetto importante è il logging. Grazie alle service mesh i network log sono uniformi, indipendentemente dal tipo di tecnologia utilizzata nei microservizi, questo perché tutto il traffico tra servizi è proxato da Envoy.
Controllo del traffico con funzionalità avanzate
Le service mesh eseguono il routing delle richieste tra microservizi e dall’esterno verso il corretto microservizio. Inoltre, permettono di usufruire di funzionalità avanzate come:
- Rilascio canary: questo processo prevede il deploy di una istanza della nuova versione di un servizio mentre resta ancora attiva la precedente versione. Grazie ai service mesh, è possibile indirizzare il traffico su entrambi i servizi per verificare il corretto funzionamento della nuova versione, avendo però ancora a disposizione quello precedente per poter fare eventualmente un rollback.
- Mirroring: in questo caso la nuova e la vecchia versione di un microservizio vengono eseguite in parallelo. Entrambi ricevono traffico e i diversi comportamenti possono essere studiati nel dettaglio per determinare se la nuova versione funziona correttamente.
- A/B testing: due versioni di servizi vengono testate per verificare quale sia la più performante (ad esempio dal punto di vista della revenue generata). Entrambe le versioni ricevono traffico da gruppi di utenti selezionati secondo precisi criteri o in modo casuale.
Service mesh su multi-cluster
In definitiva, chi dovrebbe usare le service mesh? La risposta a questa domanda è semplice: chiunque sviluppi applicazioni a microservizi. Da un lato l’introduzione delle service mesh può aggiungere complessità iniziale per quanto riguarda l’installazione nel cluster, la gestione e la comprensione delle logiche di base. Tuttavia, questo sforzo iniziale viene ripagato già nel breve periodo, con vantaggi osservabili da subito.
Nella comunità tech l’importanza delle service mesh è ormai assodata, al punto che il discorso non verte più attorno alla loro eventuale adozione, bensì al loro uso in ambienti multi cloud e multi cluster.
Oggi la necessità è di poter istanziare cluster su più provider e di poterli gestire allo stesso modo. La mia applicazione deve essere in grado di parlare al servizio A su GCP e al servizio B che è su AWS senza dover implementare meccanismi di networking più complessi del service mesh. Gli sviluppi futuri di questa funzionalità si preannunciano quindi di particolare interesse anche per le aziende che devono gestire una certa complessità.
Quando non usare una service mesh
Nonostante i benefici che abbiamo visto fin qui, la service mesh non è sempre la scelta migliore, soprattutto in progetti con requisiti limitati o in fase iniziale. In particolare, se l’applicazione è composta da pochi microservizi e il team DevOps ha risorse contenute, l’adozione di una mesh può introdurre un overhead operativo e cognitivo significativo, non giustificato dai vantaggi.
Inoltre, l’implementazione richiede conoscenze specifiche, risorse compute aggiuntive e una fase iniziale di configurazione non banale. In questi casi, funzionalità di sicurezza e monitoring possono essere ottenute tramite soluzioni più semplici, come API Gateway avanzati, sidecar manuali o strumenti di osservabilità nativi.
Prima di adottare una service mesh, è quindi utile valutare attentamente lo stadio di maturità tecnologica, la complessità dell’infrastruttura, e la capacità del team di mantenere il sistema nel tempo. In poche parole, la mesh non deve essere vista come un prerequisito, ma come una leva strategica da attivare quando serve.
Evoluzione delle service mesh: verso un modello proxyless?
Proprio per superare questi limiti e semplificarne l’adozione, le service mesh stanno evolvendo rapidamente con nuovi approcci e architetture.
La service mesh è in continua evoluzione. Dopo anni di adozione basata sul modello sidecar, i principali progetti stanno esplorando approcci proxyless o ibridi. L’obiettivo di queste sperimentazioni sono volti a migliorare la scalabilità e ridurre il consumo di risorse.
Un esempio è Ambient Mesh di Istio, che sostituisce i sidecar con waypoint proxy esterni al pod. Una architettura riduce drasticamente il consumo di CPU e memoria, semplifica l’onboarding dei workload legacy e diminuisce la complessità di gestione dei certificati.
L’adozione di architetture proxyless consente di estendere la mesh a nuovi domini, come le VM, le applicazioni serverless o i workload edge, senza richiedere una profonda modifica dell’ambiente. Per i CTO, significa avere una maggiore flessibilità nel modellare la rete dei servizi senza compromessi sulle policy o sulla sicurezza.
Per concludere, le service mesh sono uno strumento prezioso, utile per migliorare sicurezza, controllo e visibilità nei sistemi a microservizi. Vuoi capire come come adottarle nel modo giusto e far crescere la tua architettura? Valuta un percorso di affiancamento come il Cloud Native Journey di SparkFabrik, che ti aiuta passo passo nella transizione verso il paradigma Cloud Native.
