Service Mesh: cos’è, come funziona e a cosa serve

Uno dei cambiamenti che avvengono nell’IT sotto la bandiera della trasformazione digitale è l’abbattimento di grandi applicazioni monolitiche in microservizi (piccole e discrete unità di funzionalità) che vengono eseguiti in container, pacchetti software che includono tutto il codice del servizio e le dipendenze che possono essere isolati e facilmente spostati da un server all’altro.

Le architetture containerizzate come queste sono facili da scalare ed eseguire nel cloud e i singoli microservizi possono essere rapidamente implementati e iterati. Tuttavia, la comunicazione tra questi microservizi diventa sempre più complessa man mano che le applicazioni diventano più grandi e vengono eseguite contemporaneamente più istanze dello stesso servizio. Una service mesh è una forma architetturale emergente che mira a collegare dinamicamente questi microservizi in modo da ridurre il sovraccarico amministrativo e di programmazione.

Cos’è una service mesh?

Nel senso più ampio, una service mesh è, come descrive Red Hat, “un modo per controllare in che modo le diverse parti di un’applicazione condividano i dati una con l’altra”. Questa descrizione potrebbe però comprendere molte diversi aspetti. In effetti, sembra molto simile al middleware con cui la maggior parte degli sviluppatori ha familiarità con le applicazioni client-server.

Ciò che rende una service mesh univoca è il fatto che è costruita per adattarsi alla natura unica degli ambienti distribuiti di microservizi. In un’applicazione su larga scala creata da microservizi potrebbero esserci più istanze di un determinato servizio in esecuzione su vari server locali o nel cloud. Tutte queste parti in movimento rendono ovviamente difficile per i singoli microservizi trovare gli altri servizi di cui hanno bisogno per comunicare. Una service mesh si occupa automaticamente della scoperta e della connessione dei servizi, in modo che sia gli sviluppatori umani, sia i microservizi individuali non debbano farlo.

Pensate a una service mesh come qualcosa di equivalente all’SDN per il livello 7 del modello di rete OSI. Proprio come l’SDN crea un livello di astrazione in modo che gli amministratori di rete non debbano gestire connessioni di rete fisiche, una service mesh disaccoppia l’infrastruttura sottostante dell’applicazione dall’architettura astratta con cui interagite. L’idea di una service mesh è nata in modo organico quando gli sviluppatori hanno iniziato a cimentarsi con i problemi di architetture distribuite veramente enormi. Linkerd, il primo progetto in quest’area, è nato come una propaggine di un progetto interno di Twitter.

Il bilanciamento del carico della service mesh

Una delle caratteristiche chiave di una service mesh è il bilanciamento del carico. Di solito consideriamo il bilanciamento del carico come una funzione di rete; si desidera impedire a qualsiasi server o collegamento di rete di essere travolti dal traffico e quindi si indirizzano i pacchetti di conseguenza. Le service mesh fanno qualcosa di simile a livello di applicazione e agiscono come una SDN per il livello dell’applicazione.

In sostanza, uno dei compiti della service mesh è quello di tenere traccia di quali istanze di vari microservizi distribuiti attraverso l’infrastruttura siano “più sane”. Potrebbe sondarle per vedere come si stanno comportando o tenere traccia di quali istanze stiano rispondendo lentamente per servire richieste e inviare richieste successive ad altre istanze. La service mesh può fare un lavoro simile per i percorsi di rete, notare quando i messaggi impiegano troppo tempo per arrivare a destinazione e prendere altri percorsi per compensare.

Questi rallentamenti potrebbero essere dovuti a problemi con l’hardware sottostante o semplicemente ai servizi che sono sovraccarichi di richieste o che lavorano alla loro capacità di elaborazione. L’importante è che la service mesh possa trovare un’altra istanza dello stesso servizio e indirizzarla verso di essa, sfruttando in tal modo l’uso più efficiente della capacità complessiva dell’applicazione.

Service mesh vs. Kubernetes

Se avete una certa dimestichezza con le architetture basate su container, vi starete chiedendo dove Kubernetes, la popolare piattaforma open source di orchestrazione di container, rientri in tutto ciò. Dopotutto, non è il punto centrale di Kubernetes gestire il modo in cui i container comunicano tra loro? Potreste pensare al “servizio” di Kubernetes come a un tipo molto semplice di service mesh, poiché fornisce il rilevamento dei servizi e il bilanciamento round-robin delle richieste.

Tuttavia, le service mesh complete offrono molte più funzionalità, come la gestione delle policy di sicurezza e della crittografia, il “circuit break” per sospendere le richieste alle istanze a risposta lenta, il bilanciamento del carico come descritto sopra e molto altro. Tenete presente che la maggior parte delle service mesh richiede effettivamente un sistema di orchestrazione come Kubernetes per essere installato.

Service mesh vs gateway API

Ogni microservizio fornirà un’interfaccia di programmazione dell’applicazione (API) che funge da mezzo attraverso il quale altri servizi comunicano con esso. Ciò solleva la questione delle differenze tra una service mesh e altre forme più tradizionali di gestione dell’API, come i gateway API. Come spiega IBM, un gateway API si frappone tra un gruppo di microservizi e il mondo “esterno”, instradando le richieste di servizi necessarie in modo che il richiedente non debba sapere che si tratta di un’applicazione basata su microservizi. Una service mesh, d’altra parte, media le richieste “dentro” l’app dei microservizi, con i vari componenti pienamente consapevoli del loro ambiente.