Cos'è un Service Mesh

Un service mesh è un livello di infrastruttura configurabile a bassa latenza che viene progettato per gestire un volume elevato di comunicazioni tra servizi e applicazioni tramite l’utilizzo di API.

Il suo utilizzo rende possibile mettere in sicurezza, monitorare e connettere tra di loro i diversi servizi che vanno a comporre un’applicazione.

In un ambiente cloud in cui lo sviluppo di nuove applicazioni è all’ordine del giorno e dove ognuna di esse può essere composta da centinaia di diversi servizi, il service mesh diventa molto importante per riuscire a gestire e a tracciare la comunicazione che intercorre tra di esse.

Ma facciamo un passo indietro e diamo un contesto per capire come è nato e perché questo servizio è così importante.

L’introduzione dei microservizi

Il passaggio ai microservizi ha definito un nuovo approccio vincente nell’architettura delle infrastrutture IT. L’abbandono delle grandi applicazioni monolitiche a favore dei container ha fatto in modo che i servizi fossero indipendenti tra di loro e che il malfunzionamento di uno di essi fosse più facilmente isolabile, aggirabile, rideployabile o all’occorrenza scalabile nel caso di bassa performance.

Infatti, i microservizi possono essere modificati senza coinvolgere l’intera applicazione e, nel caso di implementazione di una procedura di Continuous Integration efficace, è possibile accorgersi immediatamente se l’impatto di questa modifica è positivo o meno e, in caso negativo, di correggere l’errore e mandare l’app in produzione.

Allo stesso modo, scalare una singola funzionalità non comporta necessariamente l’upgrade dell’intero sistema e, in caso di sviluppo di una nuova applicazione, è possibile riutilizzare le parti di altri microservizi già prodotte precedentemente e concentrarsi sulla creazione della nuova funzionalità.

Tuttavia, un’architettura di questo tipo ha delle problematiche intrinseche, come la difficile gestione delle comunicazioni tra i diversi componenti all’interno di un container: ogni applicazione può essere composta da centinaia di servizi, i quali possono avere altrettante istanze in continuo aggiornamento.

Da qui è facile comprendere come la comunicazione tra i servizi containerizzati e spesso effimeri possa essere molto complessa e difficile da monitorare, ma è ugualmente fondamentale per garantire l’affidabilità, la sicurezza e le performance di un’applicazione.

Cosa fa un Service Mesh

Il suo funzionamento permette di:

• monitorare: da una visibilità estesa e completa del sistema di microservizi presente all’interno di un container e aggiorna le sue informazioni in modo automatico alla modifica delle componenti. Inoltre, un service mesh si integra con tool di monitoraggio esterni, come ad esempio Prometheus;
• connettere: gestisce in modo più efficace il flusso di traffico e di chiamate API tra i diversi servizi e libera gli sviluppatori da questo lavoro, in modo che possano dedicarsi ad altre attività più remunerative;
• mettere in sicurezza: la comunicazione tra le componenti è più affidabile poiché consente di rafforzare le policy, permettendo o negando la connessione;
• fornire funzionalità critiche tra cui la service discovery, il bilanciamento del carico, la crittografia, l'osservabilità, la tracciabilità, l'autenticazione e l'autorizzazione e il supporto per il modello di interruttore automatico;
• in ultima, ma tra le caratteristiche più interessanti di un service mesh, di semplificare l’adozione di servizi di rilascio e di adottare strategie di deployment alternative più efficaci.
  Tra queste:
  - blue-green deployment. Esso consiste nell’eseguire due ambienti di produzione in parallelo, di cui uno live (Blue) e l’altro utilizzato come luogo di test (Green). In questo modo, le nuove versioni del software vengono prodotte e testate nel secondo ambiente, mentre nel primo il servizio rimane attivo. Una volta che il risultato è approvato, il router viene switchato in modo che le richieste arrivino all’ambiente green e che l’ambiente blue risulti inattivo;
  - canary release. In questo caso il processo di implementazione è introdotto a piccoli step in modo da ridurre il rischio di introduzione di un nuovo software. Come funziona? Il nuovo update viene proposto ad un piccolo gruppo di utenti i quali determinano se il servizio è pronto per la produzione su larga scala. Se il software passa questo primo test, viene riproposto ad un numero maggiore di utenti fino a sostituire la vecchia versione.

Come si compone

Solitamente un service mesh è formato da due parti:

• il control plane, ossia un’interfaccia utente oppure un’API che gestisce il servizio e fornisce i criteri attraverso cui vengono raccolte le informazioni e applicate determinate funzionalità;
• il data plane. È solitamente costituito da un proxy, chiamato sidecar, che viene inserito a livello infrastrutturale nel pod dove è presente l’applicazione in esecuzione.
  Viste dall’esterno, le due componenti condivideranno lo stesso namespace e lo stesso IP ma, all’interno del pod sono due oggetti distinti, hanno un file system separato e sono isolate a livello di processo. Ciò consente di creare e distribuire l’applicazione e di lasciar sviluppare il ciclo di vita del proxy separatamente. I sidecar gestiscono le comunicazioni tra servizi, il monitoraggio, la sicurezza e qualsiasi informazione che può essere estrapolata da essi. Il proxy ha, quindi, il compito di controllare il traffico di rete prodotto in entrata e in uscita da ogni componente.

I vantaggi

I benefici legati all’implementazione di un servizio di questo tipo si possono così riassumere:

• Tutte le istanze di servizio che avvengono all’interno della sfera di azione del service mesh, tipicamente più di un cluster, sono individuate e monitorate
• Il servizio consente di distribuire il carico di lavoro in modo uniforme e di dirigere routing e connessione delle richieste di servizio alle istanze corrette
• È possibile attivare dei servizi di autenticazione, autorizzazione e crittografia per convalidare le richieste in arrivo e mettere in sicurezza il canale di comunicazione
• Controlla lo stato e la disponibilità dei servizi tramite health check e circuit breaker e, all’occorrenza, interrompe le connessioni se l’endpoint del servizio viola i parametri di prestazione
• Risolve il problema dell’osservabilità tramite un monitoraggio operativo, per definire correttamente lo stato di salute di un’applicazione e per comprendere meglio lo stato interno del sistema tramite i suoi output
• Fornisce un’interfaccia utente per gestire e configurare i criteri di sicurezza e routing, i parametri di prestazione ecc

La domanda da un milione di dollari: mi serve un Service Mesh?

Questo approccio non è nulla di nuovo, non comporta l’introduzione di nessuna nuova funzionalità, ma, piuttosto, propone un nuovo modo di leggere e comprendere le funzionalità a disposizione.

Le moderne applicazioni cloud native combinano l’utilizzo dei microservizi con i container, che consentono il giusto isolamento delle risorse, e il livello di orchestrazione che gestisce le interconnessioni e le interazioni tra i carichi di lavoro.

Insieme, queste tre componenti permettono alle applicazioni di adattarsi e scalare in base alle necessità e all’infrastruttura, ma la presenza di una moltitudine di servizi e di applicazioni in continua evoluzione rende il tracciamento del loro percorso ancora più complesso.

Qual è quindi la risposta alla domanda “mi serve un service mesh”? La risposta è sì, se:

• stai gestendo un grande numero di microservizi e non sei in grado di rimanere al passo con le loro interconnessioni e di avere bene in mente il quadro generale
• il rilascio di nuove funzionalità viene rallentato perché il team DevOps deve prima occuparsi degli aspetti operativi
• il numero di microservizi è talmente ampio da non consentire più al team di sicurezza di gestire correttamente le minacce
• più team stanno lavorando sullo sviluppo di una singola applicazione e ognuno necessita di un accesso specifico
• gli sviluppatori utilizzano linguaggi di programmazione differenti per la creazione delle applicazioni
• vuoi espandere l’utilizzo di Kubernetes non solo ai microservizi ma all’intera organizzazione.

Nel caso in cui la scelta sia quella di passare al service mesh, i migliori tool sul mercato sono Istio e Consul.

Istio è nato tre anni fa ed è diventato il più popolare tra gli strumenti per la gestione della comunicazione tra servizi. Funziona per uno o più cluster insieme e si installa tramite la propria interfaccia a linea di comando. È, inoltre, stato scelto da Google e Red Hat.

Consul, prodotto da HashiCorp, si compone di una versione open source, per la gestione dei servizi all’interno di ambienti cloud, locali e ibridi, e enterprise che consente di far lavorare diversi team insieme e di abilitare la governance capability.

Le caratteristiche che accomunano entrambi i prodotti sono il supporto:

• di applicazioni sviluppate sia su macchine virtuali che tramite Kubernetes
• della mutual TLS encryption, con la possibilità di gestire nativamente i certificati e di rimuoverli in caso di compromissione
• di blue-green deployment, circuit breaking, fault injectione rate limiting come sturmenti di traffic management
• di Prometheus per il monitoring e il distributed tracing

Dalla sua parte, Consul risulta un tool più facile da installare e configurare, mentre Istio può risultare più complesso. Tuttavia non permette di eseguire attività di testing, cosa che Istio consente tramite l’introduzione di ritardi o errori all’interno delle richieste al server per migliorare la resilienza del sistema.