service mesh

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.

Come funzionano le service mesh

service mesh vs. microservices

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.

 

Scopri le strategie delle aziende più innovative!  Scarica il White Paper con 10 storie Cloud Native di successo

 

Implementazioni di service mesh

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.

Istio

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.

Linkerd

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.

Altri prodotti

Sono da ricordare anche:

  • Consul Service Mesh, sviluppato da HashiCorp’s;
  • AWS App Mesh, che non è un prodotto open source ma il servizio che AWS propone ai propri clienti;
  • Open Service Mesh, creato da Microsoft e che utilizza la Service Mesh Interface; 
  • Kuma, sviluppato dal Kong.

Come scegliere un'implementazione di Service Mesh

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 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.

Security

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

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à

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

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 che quello nuovo funzioni correttamente 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.

Conclusione e sviluppi futuri

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à.

case history cloud native