<img height="1" width="1" style="display:none;" alt="" src="https://dc.ads.linkedin.com/collect/?pid=43543&amp;fmt=gif">

IT | EN

6 MIN LETTURA

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

cloud native application



Categorie: DevOps


Nikla Lazzari

scritto da Nikla Lazzari

ARTICOLI CORRELATI

07/12/20 Posted by Nikla Lazzari

Cosa significa Cloud Native? Tutto quello che devi sapere su questo approccio

Nell’epoca attuale in cui il digital è ormai diventato un elemento fondamentale, la differenziazione competitiva è basata sull’adozione di modelli di business software-driven e su uno sviluppo applicativo rapido ed efficiente. 

3 MIN LETTURA

Leggi tutto  

07/12/20 Posted by Nikla Lazzari

Le 5 fasi dell'evoluzione DevOps per una strategia di Successo

Come si sta sviluppando il DevOps Journey su scala mondiale e come le varie organizzazioni chiamate in causa stanno evolvendosi quotidianamente in questo senso? 

In questo articolo abbiamo deciso di analizzare, con l’aiuto di quanto esposto nel ...

17 MIN LETTURA

Leggi tutto  

07/12/20 Posted by Nikla Lazzari

I DevOps Tools per una Reference Architecture vincente

Nei precedenti blog post abbiamo approfondito concetti come Metodologia DevOps, Cloud, Security e pratiche e tool collegati, spiegando come la Digital Transformation abbia influenzato e modificato radicalmente l’approccio aziendale a queste tre...

6 MIN LETTURA

Leggi tutto  

Iscriviti alla nostra Newsletter