Cosa è un Service Mesh

https://kuma.io/docs/0.7.3/overview/what-is-a-service-mesh/

Service Mesh è un modello tecnologico che implementa un modo migliore per implementare il networking moderno e la connettività tra i diversi servizi che compongono un’applicazione. Sebbene sia comunemente utilizzato nel contesto dei microservizi, può essere utilizzato per migliorare la connettività tra ogni architettura e su ogni piattaforma come VM e container.

La connettività affidabile del servizio è un prerequisito per ogni moderna applicazione digitale. La transizione ai microservizi e al cloud può essere disastrosa se non si prende in considerazione la connettività di rete, ed è proprio per questo che è stato costruito Kuma.

Quando un servizio vuole comunicare con un altro servizio sulla rete, come un monolite che parla con un database o un microservizio che parla con un altro microservizio, per impostazione predefinita la connettività tra di loro è inaffidabile: la rete può essere lenta, non è sicura per impostazione predefinita e per impostazione predefinita, tali richieste di rete non vengono registrate da nessuna parte nel caso in cui sia necessario eseguire il debug di un errore.

Per implementare alcune di queste funzionalità, abbiamo due opzioni:

  • Estendiamo noi stessi le nostre applicazioni per affrontare queste preoccupazioni. Nel tempo questo crea debito tecnico e ancora più codice da mantenere oltre alla logica di business che la nostra applicazione sta fornendo all’utente finale. Crea anche frammentazione e problemi di sicurezza poiché più team cercano di affrontare le stesse preoccupazioni su diversi stack tecnologici.
  • Deleghiamo la gestione della rete a qualcos’altro che lo fa per noi. Come, ad esempio, un proxy out-of-process che viene eseguito sullo stesso host sottostante. Certo, dobbiamo affrontare una latenza leggermente maggiore tra i nostri servizi e il proxy locale, ma i vantaggi sono così alti che diventa rapidamente irrilevante. Questo proxy – come vedremo più avanti – si chiama proxy sidecar e si trova sul piano dati delle nostre richieste.

In quest’ultimo scenario, quando si delega la gestione della rete a un altro processo, avremo un proxy del piano dati per ogni replica di ogni servizio. Ciò è necessario per poter tollerare un guasto a uno dei proxy senza influire sulle altre repliche e anche perché possiamo assegnare un’identità a ogni proxy e quindi a ciascuna replica dei nostri servizi. È anche importante che il proxy del piano dati sia molto leggero poiché avremo molte istanze in esecuzione.

Anche se disporre di piani dati distribuiti insieme ai nostri servizi aiuta con i problemi di rete che abbiamo descritto in precedenza, introduce un nuovo problema: la gestione di così tanti piani dati diventa impegnativa e quando vogliamo aggiornare le nostre politiche di rete non vogliamo certo riconfigurare manualmente ognuno di loro. In breve, abbiamo bisogno di una fonte di verità che possa raccogliere tutta la nostra configurazione, segmentata per servizio o altre proprietà, e quindi inviare la configurazione ai singoli piani dati ogni volta che è necessario. Questo componente è chiamato piano di controllo: controlla i piani dati e, a differenza dei piani dati, non si trova sul percorso di esecuzione del traffico del servizio.

Avremo molti piani dati collegati al piano di controllo per propagare sempre la configurazione più recente, elaborando contemporaneamente il traffico da servizio a servizio tra la nostra infrastruttura. Kuma è un piano di controllo (e viene fornito in formato kuma-cpbinario) mentre Envoy è un proxy del piano dati (fornito come envoybinario). Quando si usa Kuma non dobbiamo preoccuparci di imparare a usare Envoy, perché Kuma astrae quella complessità raggruppando Envoy in un altro binario chiamato kuma-dpkuma-dpsotto il cofano verrà richiamato il envoybinario ma quella complessità è nascosta a te, utente finale di Kuma ).

Service Mesh non introduce nuove preoccupazioni o casi d’uso: affronta una preoccupazione di cui ci stiamo già occupando (di solito scrivendo più codice, se stiamo facendo qualcosa): occuparci della connettività nella nostra rete.

Come impareremo, Kuma si prende cura di queste preoccupazioni in modo che non dobbiamo preoccuparci della rete e, a sua volta, rendere le nostre applicazioni più affidabili.

Perché Kuma?

Durante la creazione di qualsiasi applicazione digitale moderna, introdurremo inevitabilmente servizi che comunicheranno tra loro effettuando richieste sulla rete.

Ad esempio, pensa a qualsiasi applicazione che comunica con un database per archiviare o recuperare dati oppure pensa a un’applicazione più complessa orientata ai microservizi che effettua molte richieste su diversi servizi per eseguire le sue operazioni:

Ogni volta che i nostri servizi comunicano sulla rete, mettiamo a rischio l’esperienza dell’utente finale. Come tutti sappiamo, la rete tra i diversi servizi può essere lenta e imprevedibile. Può essere insicuro, difficile da tracciare e porre molti altri problemi (ad esempio, routing, versioning, implementazioni canary). In una frase, le nostre applicazioni sono a un passo dall’essere inaffidabili.

Di solito, a questo punto, gli sviluppatori intraprendono una delle seguenti azioni per rimediare alla situazione:

  • Scrivi più codice : gli sviluppatori scrivono codice, a volte sotto forma di un client intelligente , che ogni servizio dovrà utilizzare quando effettua richieste a un altro servizio. Di solito, questo approccio introduce alcuni problemi:
    • Crea più debito tecnico
    • È tipicamente specifico della lingua; quindi, impedisce l’innovazione
    • Esistono più implementazioni della libreria, il che crea frammentazione a lungo termine.
  • Proxy sidecar : i servizi delegano tutti i problemi di connettività e osservabilità a un runtime out-of-process, che si troverà nel percorso di esecuzione di ogni richiesta. Proverà tutte le connessioni in uscita e accetterà tutte quelle in entrata. E ovviamente eseguirà le politiche del traffico in fase di esecuzione, come il routing o la registrazione. Utilizzando questo approccio, gli sviluppatori non devono preoccuparsi della connettività e concentrarsi interamente sui propri servizi e applicazioni.

Proxy sidecar : si chiama proxy sidecar perché il proxy è un altro processo in esecuzione insieme al nostro processo di servizio sullo stesso host sottostante. Ci sarà un’istanza di un proxy sidecar per ogni istanza in esecuzione dei nostri servizi e poiché tutte le richieste in entrata e in uscita – ei relativi dati – passano sempre attraverso il proxy sidecar, viene anche chiamato data-plane (DP) poiché si trova sul percorso dei dati.

Dato che avremo molte istanze per i nostri servizi, avremo anche un numero uguale di proxy sidecar: sono molti proxy! Pertanto il modello proxy sidecar richiede un control plane che consenta a un team di configurare dinamicamente il comportamento dei proxy senza doverli configurare manualmente. I piani dati inizieranno una connessione con il piano di controllo per ricevere una nuova configurazione, mentre il piano di controllo fornirà loro, in fase di esecuzione, la configurazione più aggiornata.

I team che adottano il modello proxy sidecar costruiranno un piano di controllo da zero o utilizzeranno aerei di controllo per uso generico esistenti disponibili sul mercato, come Kuma. Confronta Kuma con altri PC .

A differenza di un proxy del piano dati (DP), il piano di controllo (CP) non si trova mai sul percorso di esecuzione delle richieste che i servizi si scambiano tra loro e viene utilizzato come fonte di verità per configurare dinamicamente i proxy del piano dati sottostanti che nel frattempo abbiamo implementato insieme a ogni istanza di ogni servizio che fa parte della Mesh:

Service Mesh : un’architettura composta da proxy sidecar distribuiti accanto ai nostri servizi (i data-plan o DP) e un piano di controllo (CP) che controlla tali DP, è chiamata Service Mesh. Di solito, Service Mesh appare nel contesto di Kubernetes, ma chiunque può creare Service Mesh su qualsiasi piattaforma (incluse VM e Bare Metal).

Con Kuma, il nostro obiettivo principale è ridurre il codice che deve essere scritto e mantenuto per costruire architetture affidabili. Pertanto, Kuma abbraccia il modello proxy sidecar sfruttando Envoy come tecnologia del piano dati sidecar.

Esternalizzando tutti i problemi di connettività, sicurezza e instradamento a un proxy sidecar, beneficiamo della nostra maggiore capacità di:

  • creare applicazioni più velocemente
  • concentrarsi sulle funzionalità principali dei nostri servizi per aumentare il business
  • costruire un’architettura più sicura e standardizzata riducendo la frammentazione

Riducendo il codice che i nostri team creano e mantengono, possiamo modernizzare le nostre applicazioni pezzo per pezzo senza mai dover mordere più di quanto possiamo masticare.

Scopri di più su come Kuma consente la modernizzazione all’interno delle nostre architetture esistenti.