Come migliorare l’osservabilità, la sicurezza e l’affidabilità di un’applicazione a microservizi? Le service mesh sono la risposta: vediamo cosa sono e come implementarle.
La 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.
Una service mesh è composta da due livelli: il data plane e il control plane. Il primo è costituito da diversi proxy di servizio, ciascuno distribuito insieme a ogni istanza del microservizio, che si occupa di implementare la maggior parte delle funzionalità.
Parliamo quindi di un “modello sidecar”: quelli che possiamo definire come Cross Cutting Concerns vengono spostati in un proxy fuori dal microservizio. La business logic e le business metrics rimangono invece all’interno del microservizio.
Il secondo elemento è il control plane, che si occupa di orchestrare le configurazioni di tutti i proxy e di comunicare all’esterno con i sistemi di monitoraggio. La service mesh diventa così il punto di ingresso da cui osservare ciò che succede nei microservizi.
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. Ecco che nell’ambito della CNCF è nato anche il progetto Service Mesh Interface, l'interfaccia standard per le service mesh su Kubernetes. 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.
Sicuramente la soluzione più conosciuta è Istio. 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.
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.
Sono da ricordare anche:
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.
Sviluppare microservizi semplifica e accelera numerosi processi. 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.
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:
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.
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:
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.
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:
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à.