Nota del traduttore.: il service mesh è un fenomeno che non ha ancora una traduzione consolidata in italiano (più di 2 anni fa abbiamo proposto l'alternativa "rete per servizi", e successivamente alcuni colleghi hanno iniziato a promuovere attivamente la combinazione "setaccio per servizi"). Le continue discussioni su questa tecnologia hanno portato a una situazione in cui gli aspetti di marketing e tecnici si intrecciano troppo strettamente. Questo straordinario materiale da uno degli autori del termine originale mira a portare chiarezza per gli ingegneri e non solo.
Fumetto di
Introduzione
Se sei un ingegnere del software che lavora nell'ambito dei sistemi backend, il termine "service mesh", probabilmente, si è già stabilito saldamente nella tua mente negli ultimi due anni. Grazie a una strana concatenazione di eventi, questa espressione sta conquistando sempre più il settore, mentre il buzz e le relative offerte pubblicitarie si accumulano come una palla di neve che rotola giù per una collina, senza alcun segno di rallentamento.
Il service mesh è nato nelle acque torbide e tendenziose dell'ecosistema cloud native. Purtroppo, ciò significa che gran parte del dibattito ad esso associato varia da "chiacchiere a basso contenuto calorico" fino — per usare un termine tecnico — a pura sciocchezza. Ma se si filtra tutto il rumore, si può scoprire che il service mesh ha una funzione ben reale, definita e importante.
In questa pubblicazione cercherò di fare proprio questo: presentare una guida onesta, approfondita e orientata agli ingegneri sul service mesh. Intendo rispondere non solo alla domanda: "Che cos'è?", — ma anche "Perché?", così come "Perché proprio adesso?". Infine, cercherò di delineare perché (secondo me) questa particolare tecnologia ha suscitato un tale caos, che di per sé è una storia interessante.
Chi sono io?
Ciao a tutti! Mi chiamo . Sono uno dei creatori di — il primo progetto di service mesh e il progetto che ha dato origine al termine service mesh nel suo significato attuale (scusate, ragazzi!). (Traducendo.: A proposito, all'alba dell'emergere di questo termine, oltre 2,5 anni fa, abbiamo già tradotto un materiale preliminare dello stesso autore intitolato "».) Inoltre, io sono il responsabile di — una startup che crea fantastici strumenti per service mesh come Linkerd e .
Probabilmente immaginate che abbia un'opinione piuttosto soggettiva su questo argomento. Tuttavia, cercherò di mantenere la parzialità al minimo (eccetto per una sezione: «Perché si parla così tanto di service mesh?», — in cui condividerò alcune delle mie idee soggettive). Farò anche del mio meglio per rendere questa guida il più obiettiva possibile. Negli esempi specifici mi baserò principalmente sull'esperienza di Linkerd, evidenziando anche le differenze che conosco (se presenti) nell'implementazione di altri tipi di service mesh.
Ok, è il momento di passare ai contenuti interessanti.
Che cos'è un service mesh?
Nonostante tutto il clamore, strutturalmente un service mesh è piuttosto semplice. È solo un insieme di proxy userspace collocati "vicino" ai servizi (ne parleremo un po' dopo riguardo a cosa significhi "vicino"), insieme a un insieme di processi di gestione. I proxy nel loro complesso sono chiamati data plane, mentre i processi di gestione sono denominati control plane. Il piano dati intercetta le chiamate tra i servizi e si occupa di ''diverse cose''; il piano di controllo, di conseguenza, coordina il comportamento dei proxy e fornisce accesso a te, ovvero l'operatore, all'API, consentendo di manipolare la rete e misurarla come un'unità.
Che cos'è questo proxy? È un proxy TCP di categoria ''Layer 7-aware'' (ossia ''consapevoli'' del settimo livello del modello OSI) come HAProxy e NGINX. Puoi scegliere un proxy secondo le tue preferenze; Linkerd utilizza un proxy in Rust, semplicemente chiamato . L'abbiamo creato appositamente per il service mesh. Gli altri mesh preferiscono proxy diversi (Envoy è una scelta comune). Tuttavia, la scelta del proxy è solo una questione di implementazione.
Cosa fanno questi server proxy? Ovviamente, fanno da proxy per le chiamate ai servizi e viceversa (strictly speaking, svolgono la funzione di proxy e reverse proxy, gestendo sia le chiamate in entrata che quelle in uscita). E implementano un insieme di funzioni focalizzate sulle chiamate tra i servizi. Questa attenzione al traffico tra i servizi differenzia il proxy del service mesh da, ad esempio, le API gateway o i proxy ingress (questi ultimi si concentrano sulle chiamate che arrivano nel cluster dal mondo esterno). (Nota del traduttore.: confronto dei controller Ingress esistenti per Kubernetes, molti dei quali utilizzano il già menzionato Envoy, vedi in .)
Quindi, abbiamo chiarito il data plane. Il control plane è più semplice: si tratta di un insieme di componenti che forniscono tutta la meccanica necessaria affinché il data plane funzioni in modo coordinato, inclusi rilevamento dei servizi, rilascio di certificati TLS, aggregazione delle metriche e così via. Il data plane informa il control plane sul proprio comportamento; a sua volta, il control plane fornisce un'API per modificare e monitorare il comportamento del data plane come un insieme unico.
Di seguito è riportato uno schema del control plane e del data plane in Linkerd. Come si può vedere, il control plane include diversi componenti, tra cui un'istanza di Prometheus che raccoglie metriche dai proxy, oltre ad altri componenti come destination (rilevamento dei servizi), identity (centro di certificazione, CA) e public-api (endpoint per web e CLI). Al contrario, il data plane consiste in un semplice linkerd-proxy accanto all'istanza dell'applicazione. Questa è solo una rappresentazione logica; in condizioni reali di distribuzione, potresti avere tre repliche di ciascun componente del control plane e centinaia o migliaia di proxy nel data plane.
(I rettangoli blu in questo diagramma simboleggiano i confini dei pod di Kubernetes. Si può vedere che i contenitori con linkerd-proxy si trovano nello stesso pod dei contenitori dell’applicazione. Questo tipo di schema è conosciuto come container sidecar.)
L'architettura del service mesh ha diverse implicazioni importanti. In primo luogo, poiché il compito del proxy è quello di intercettare le chiamate tra i servizi, il service mesh ha senso solo se la tua applicazione è costruita su un insieme di servizi. Il mesh è possibile può essere utilizzato con i monoliti, ma è chiaramente ridondante per un singolo proxy, e le sue funzionalità potrebbero non essere richieste.
Un'altra importante implicazione è che il service mesh richiede un'enorme quantità di proxy. In effetti, Linkerd associa linkerd-proxy a ogni istanza di ogni servizio (altre implementazioni aggiungono proxy a ogni nodo/host/macchina virtuale. In ogni caso, non sono pochi). Un uso così attivo dei proxy porta con sé una serie di ulteriori complicazioni:
- I proxy nel data plane devono essere rapidi, poiché per ogni chiamata ci sono due richieste ai proxy: una dal lato client, una dal lato server.
- Inoltre, i proxy devono essere piccole e leggere. Ognuna consumerà risorse di memoria e CPU, e questo consumo crescerà linearmente con l'applicazione.
- Avrete bisogno di un meccanismo per distribuire e aggiornare un gran numero di proxy. Farlo manualmente non è un'opzione.
In generale, un service mesh appare così (almeno dall'alto): distribuite una serie di proxy userspace che "fanno qualcosa" con il traffico interno tra i servizi e utilizzate il control plane per monitorarli e gestirli.
È giunto il momento di porsi la domanda "Perché?"
A cosa serve un service mesh?
A chi si imbatte per la prima volta nell'idea di un service mesh è lecito provare un certo timore. La struttura di un service mesh significa che non solo aumenterà la latenza nell'applicazione, ma porterà anche a consumare risorse e aggiungerà un sacco di nuovi meccanismi nell'infrastruttura. Prima installate il service mesh e poi improvvisamente vi rendete conto di dover gestire centinaia (se non migliaia) di proxy. Chi si offrirà volontario per farlo?
La risposta a questa domanda si compone di due parti. Innanzitutto, i costi operativi legati al dispiegamento di questi proxy possono essere significativamente ridotti grazie ad alcuni cambiamenti che avvengono nell'ecosistema (ne parleremo più avanti).
In secondo luogo, un dispositivo simile è in realtà un ottimo modo per introdurre logiche aggiuntive nel sistema. E non solo perché con il service mesh si possono aggiungere molte nuove funzionalità, ma anche perché si può fare senza interferire con l'ecosistema. Infatti, l'intero modello del service mesh si basa su questo postulato: in un sistema a servizi multipli, indipendentemente da ciò che fanno i singoli servizi, il traffico tra di essi è il punto ideale per aggiungere funzionalità.
Ad esempio, in Linkerd (come nella maggior parte dei mesh) le funzionalità sono principalmente focalizzate sulle chiamate HTTP, inclusi HTTP/2 e gRPC*. Le funzionalità sono piuttosto ricche e possono essere suddivise in tre classi:
- Funzionalità relative all'affidabilità. Richieste ripetute, timeout, approccio canary (divisione/reindirizzamento del traffico), ecc.
- Funzionalità relative monitoraggio.. Aggregazione delle metriche di prestazione, latenze e volumi delle richieste per ciascun servizio o singoli ambiti; costruzione di mappe topologiche dei servizi, ecc.
- Funzionalità relative sicurezza. Mutual TLS, controllo degli accessi, ecc.
* Dal punto di vista di Linkerd, gRPC non si distingue praticamente da HTTP/2: si utilizza semplicemente protobuf nel payload. Dal punto di vista dello sviluppatore, queste due cose differiscono, ovviamente.
Molti di questi meccanismi operano a livello di richieste (da cui il termine «L7-proxy»). Ad esempio, se il servizio Foo invia una chiamata HTTP al servizio Bar, il linkerd-proxy dal lato di Foo può effettuare un bilanciamento del carico intelligente e indirizzare le chiamate da Foo alle istanze di Bar in base alla latenza osservata; può ripetere la richiesta se necessario (e se è idempotente); può registrare il codice di risposta e il tempo di attesa, ecc. In modo simile, il linkerd-proxy dal lato di Bar può rifiutare la richiesta se non è autorizzata o se è stato superato il limite delle richieste; può registrare la latenza dal proprio lato, ecc.
I proxy possono "fare qualcosa" anche a livello di connessione. Ad esempio, il linkerd-proxy sul lato Foo può avviare una connessione TLS, mentre il linkerd-proxy sul lato Bar può interromperla, e entrambe le parti possono verificare i certificati TLS l'uno dell'altro*. Questo non solo garantisce la crittografia tra i servizi, ma offre anche un modo crittograficamente sicuro per identificare i servizi: Foo e Bar possono "provare" di essere ciò che affermano di essere.
* "L'uno dell'altro" significa che anche il certificato del cliente viene verificato (mutual TLS). Nel TLS "classico", ad esempio, tra browser e server, di solito viene verificato il certificato solo di una parte (del server).
Indipendentemente dal fatto che operino a livello di richieste o di connessioni, è importante sottolineare che tutte le funzioni di service mesh sono di operatività pratica. Linkerd non è in grado di trasformare la semantica del payload — ad esempio, aggiungere campi a un frammento JSON o apportare modifiche a protobuf. In questa importante caratteristica parleremo più tardi, quando discuteremo di ESB e middleware.
Ecco quali funzionalità offre un service mesh. Nasce quindi la domanda: perché non implementarle direttamente nell'applicazione? E perché mai doversi affidare a un proxy?
Perché il service mesh è una buona idea
Sebbene le capacità del service mesh siano affascinanti, il suo valore principale non risiede realmente nelle funzionalità. Alla fine, noi possiamo implementarle direttamente nell'applicazione (più avanti vedremo che questa è stata l'origine del service mesh). Se dovessimo esprimere questo pensiero in una sola frase, il valore del service mesh è il seguente: fornisce funzionalità essenziali per il funzionamento del software server moderno in modo uniforme per tutto lo stack e indipendentemente dal codice dell'applicazione..
Analizziamo questa affermazione.
«Funzionalità essenziali per il funzionamento del software server moderno.». Se stai creando un'applicazione server transazionale legata a Internet pubblico, che riceve richieste dall'esterno e risponde a esse in breve tempo — ad esempio, un'app web, un server API, e la stragrande maggioranza delle altre applicazioni moderne — e se la realizzi come un insieme di servizi che interagiscono tra loro in modo sincrono, e se stai costantemente aggiornando questo software, aggiungendo nuove funzionalità, e sei costretto a mantenere questo sistema operativo durante le modifiche — in questo caso, congratulazioni, stai sviluppando software server moderno. E tutte queste straordinarie funzionalità, elencate sopra, si rivelano realmente critiche per te. L'applicazione deve essere affidabile, sicura, e devi essere in grado di monitorare ciò che fa. Proprio queste problematiche vengono affrontate da un service mesh.
(Ok, anche se nel paragrafo precedente si è insinuata la mia convinzione che questo approccio sia un modo moderno per sviluppare software server. Altri preferiscono sviluppare monoliti, "microservizi reattivi" e altre cose che non rientrano nella definizione fornita sopra. Queste persone hanno sicuramente un'opinione diversa dalla mia. D'altra parte, credo che non abbiano "ragione" — anche se, in ogni caso, il service mesh non è molto utile per loro).
«Uniforme per l'intero stackLe funzioni fornite dal service mesh non sono solo cruciali. Si applicano a tutti i servizi nell'applicazione indipendentemente dal linguaggio in cui sono scritti, dal framework utilizzato, da chi li ha scritti, da come sono stati distribuiti e da tutte le altre sottigliezze del loro sviluppo e utilizzo.
«Indipendente dal codice dell'applicazioneInfine, il service mesh offre non solo funzionalità uniformi per l'intero stack, ma lo fa in modo che non richiede modifiche all'applicazione. La base fondamentale della funzionalità del service mesh, comprese le attività di configurazione, aggiornamento, gestione, manutenzione, ecc., si trova esclusivamente a livello di piattaforma ed è indipendente dall'applicazione. L'applicazione può cambiare senza influenzare il service mesh. Allo stesso modo, il service mesh può evolversi senza alcun coinvolgimento dell'applicazione.
In breve, il service mesh non solo fornisce funzioni vitali, ma lo fa in un modo globale, uniforme e indipendente dall'applicazione. Pertanto, sebbene la funzionalità del service mesh possa essere implementata nel codice del servizio (ad esempio, sotto forma di libreria inclusa in ogni servizio), questo approccio non garantirà l'omogeneità e l'indipendenza, così preziose nel contesto del service mesh.
E tutto ciò di cui hai bisogno è aggiungere un sacco di proxy! Prometto, molto presto esamineremo i costi operativi associati all'aggiunta di questi proxy. Ma prima, fermiamoci e diamo un'occhiata a quest'idea di indipendenza da diverse prospettive. persone.
A chi è utile il service mesh?
Per quanto possa sembrare scomodo, affinché una tecnologia diventi una parte importante dell'ecosistema, deve essere accettata dalle persone. Quindi, chi è interessato al service mesh? Chi trae vantaggio dal suo utilizzo?
Se stai sviluppando software server moderno, puoi pensare alla tua squadra come a un gruppo di proprietari di servizi, che collaborano per sviluppare e implementare la logica di business, e proprietari della piattaforma, che si occupano dello sviluppo della piattaforma interna su cui questi servizi operano. Nelle piccole organizzazioni, queste potrebbero essere le stesse persone, ma con la crescita dell'azienda, questi ruoli di solito diventano più definiti e possono anche dividersi in sotto-ruoli... (C'è molto da dire sulla natura in evoluzione del devops, sull'impatto organizzativo dei microservizi, ecc. Ma per ora, consideriamo queste descrizioni come un dato di fatto).
Da questo punto di vista, i beneficiari più evidenti del service mesh sono i proprietari della piattaforma. Infatti, l'obiettivo finale del team della piattaforma è quello di creare una piattaforma interna, sulla quale i proprietari dei servizi possano implementare la logica aziendale, facendo questo in un modo che garantisca la massima indipendenza dai dettagli opachi della sua gestione. Il service mesh non solo offre funzionalità critiche per raggiungere questo obiettivo, ma lo fa in un modo che, a sua volta, non impone dipendenze ai proprietari dei servizi.
Anche i proprietari dei servizi traggono vantaggio, sebbene in modo più indiretto. L'obiettivo del proprietario del servizio è essere il più produttivo possibile nell'implementazione della logica del processo aziendale, e meno deve preoccuparsi delle questioni operative, meglio è. Invece di doversi occupare dell'implementazione, ad esempio, di politiche di retry o di TLS, possono concentrarsi esclusivamente sulle attività aziendali e sperare che la piattaforma si occupi del resto. Questo rappresenta un grande vantaggio per loro.
Il valore organizzativo di tale separazione tra i proprietari delle piattaforme e dei servizi è difficile da sovrastimare. Penso che contribuisca principale al valore del service mesh.
Abbiamo appreso questa lezione quando uno dei primi sostenitori di Linkerd ci ha raccontato perché hanno scelto il service mesh: perché ha permesso loro di 'ridurre al minimo le chiacchiere'. Ecco alcuni dettagli: un grande gruppo aziendale ha migrato la propria piattaforma in Kubernetes. Poiché l'applicazione gestiva informazioni riservate, volevano crittografare tutte le comunicazioni nei cluster. Tuttavia, la situazione si complicava a causa di centinaia di servizi e di centinaia di team di sviluppo. La prospettiva di contattare tutti e convincerli a integrare il supporto TLS nei loro piani non era affatto allettante. Installando Linkerd, hanno trasferito la responsabilità dagli sviluppatori (per i quali si trattava di un fastidio in più) ai platform engineer, per i quali era una priorità di alto livello. In altre parole, Linkerd risolveva per loro non solo un problema tecnico, ma anche organizzativo.
In sintesi, il service mesh è più una soluzione a una problema socio-tecnico. rispetto a un problema tecnico. (Grazie per averci presentato questo termine.)
Il service mesh risolverà tutti i miei problemi?
Sì. Insomma, no!
Se si considerano le tre categorie di funzioni sopra menzionate: affidabilità, sicurezza e osservabilità, diventa chiaro che il service mesh non è una soluzione completa per nessuno di questi problemi. Anche se Linkerd può effettuare richieste ripetute (se sa che sono idempotenti), non è in grado di decidere cosa restituire all'utente se il servizio è completamente andato a fuoco: tali decisioni devono essere prese dall'applicazione. Linkerd può tenere traccia delle richieste riuscite, ma non può entrare nel servizio e fornire le sue metriche interne: strumenti del genere devono essere a carico dell'applicazione. Anche se Linkerd è in grado di organizzare l'mTLS, soluzioni complete per la sicurezza richiedono molto di più.
Una sottoclasse delle funzionalità in questi ambiti, offerte dal service mesh, riguarda le funzionalità della piattaforma. Con questo intendo funzioni che:
- sono indipendenti dalla logica di business. Il modo in cui si costruiscono gli istogrammi delle chiamate tra Foo e Bar è del tutto indipendente da perché Foo chiama Bar.
- È difficile implementare correttamente. In Linkerd, i tentativi di ripetizione sono parametrizzati da varie funzionalità avanzate come i budget dei tentativi di ripetizione (retry budgets), poiché un approccio diretto all'implementazione di queste cose porterà sicuramente a quella che viene chiamata "valanga di richieste" (retry storm) e ad altri problemi tipici dei sistemi distribuiti.
- Sono più efficaci quando vengono applicati in modo uniforme. Il meccanismo TLS ha senso solo se viene applicato ovunque.
Poiché queste funzionalità sono implementate a livello di proxy (e non a livello di applicazione), il service mesh le fornisce a livello di piattaforma, e non di applicazione. Quindi, non importa in quale linguaggio siano scritti i servizi, quale framework utilizzano, chi li ha scritti e perché. I proxy operano al di fuori di tutti questi dettagli, e la base fondamentale di questa funzionalità, comprese le attività di configurazione, aggiornamento, gestione, manutenzione, ecc., si trova esclusivamente a livello di piattaforma.
Esempi delle capacità del service mesh
In sintesi, voglio dire che il service mesh non è una soluzione completa per garantire affidabilità, osservabilità o sicurezza. L'ampiezza di queste aree richiede la partecipazione attiva dei possessori dei servizi, dei team Ops/SRE e di altri soggetti all'interno dell'azienda. Il service mesh offre solo un "istantanea" a livello di piattaforma per ciascuna di queste aree.
Perché il service mesh è diventato così popolare proprio adesso?
Probabilmente, in questo momento ti starai chiedendo: ok, se il service mesh è così valido, perché non abbiamo iniziato a distribuire milioni di proxy nel nostro stack dieci anni fa?
C'è una risposta banale a questa domanda: dieci anni fa tutti costruivano monoliti, e il service mesh non era necessario a nessuno. È vero, ma, a mio avviso, in una tale risposta si perde il senso. Anche dieci anni fa, il concetto di microservizi come modo promettente per creare sistemi su larga scala era ampiamente discusso e applicato in aziende come Twitter, Facebook, Google e Netflix. La visione generale — almeno nelle parti dell'industria con cui ho avuto contatti — era che i microservizi fossero il «modo corretto» di costruire grandi sistemi, anche se era dannatamente difficile.
Certo, anche se dieci anni fa c'erano aziende che utilizzavano microservizi, non infilavano affatto proxy ovunque per formare un service mesh. Tuttavia, se si guarda da vicino, facevano qualcosa di simile: in molte di queste aziende era previsto l'uso di una particolare libreria interna per la comunicazione di rete (a volte chiamata libreria del client pesante, fat client library).
Netflix aveva Hysterix, Google aveva Stubby e Twitter usava la libreria Finagle. Ad esempio, Finagle era obbligatorio per ogni nuovo servizio in Twitter. Gestiva sia la parte client che quella server delle connessioni, permetteva di effettuare richieste ripetute, supportava il routing delle richieste, il bilanciamento del carico e le misurazioni. Forniva uno strato coerente di affidabilità e osservabilità per l'intero stack di Twitter, indipendentemente da ciò che il servizio stesse facendo. Naturalmente, funzionava solo per i linguaggi JVM e si basava sul modello di programmazione che doveva essere utilizzato per l'intera applicazione. Tuttavia, le sue funzionalità erano quasi le stesse di un service mesh. (In realtà, la prima versione di Linkerd era semplicemente Finagle avvolto in forma di proxy.)
Pertanto, dieci anni fa esistevano non solo microservizi, ma anche librerie proto-service-mesh specializzate che affrontavano gli stessi problemi che un service mesh risolve oggi. Tuttavia, il service mesh stesso non esisteva ancora. Doveva avvenire un ulteriore cambiamento prima che apparisse.
Ed è qui che risiede una risposta più profonda, nascosta in un'altra trasformazione avvenuta negli ultimi 10 anni: c'è stata una drastica riduzione dei costi per l'implementazione dei microservizi. Le aziende menzionate sopra, come Twitter, Netflix, Facebook e Google, che utilizzavano i microservizi dieci anni fa, erano aziende di enorme scala e risorse. Non solo avevano bisogno, ma anche la possibilità di creare, distribuire e gestire grandi applicazioni basate su microservizi. L'energia e gli sforzi investiti dagli ingegneri di Twitter per passare da un approccio monolitico a uno a microservizi sono davvero straordinari. (A dirla tutta, come anche il fatto che ce l'abbiano fatta.) Manovre infrastrutturali di questo tipo erano impossibili per le aziende più piccole all'epoca.
Torniamo al presente. Oggi esistono startup in cui il rapporto microservizi-sviluppatori è di 5:1 (o anche ), e inoltre, se la startup composta da 5 persone riesce a gestire senza sforzo 50 microservizi, significa che qualcosa ha chiaramente ridotto i costi di implementazione.
1500 microservizi in Monzo; ogni riga rappresenta una regola di rete predefinita che consente il traffico
Una drastica riduzione dei costi operativi dei microservizi è il risultato di un singolo processo: l'aumento della popolarità dei container e degli orchestratori. Questo è il profondo motivo che ha contribuito alla nascita del service mesh. La stessa tecnologia ha reso attraenti sia il service mesh che i microservizi: Kubernetes e Docker.
Perché? Beh, Docker risolve un grande problema: il problema dell'imballaggio. Imballando l'applicazione e le sue dipendenze runtime (non di rete) in un container, Docker trasforma l'applicazione in un'unità intercambiabile, che può essere collocata e eseguita ovunque. Allo stesso tempo, semplifica notevolmente la gestione di stack multi-lingua: poiché il container è un'unità atomica di esecuzione, ai fini del deployment e della gestione non importa cosa c'è dentro, che si tratti di un'applicazione su JVM, Node, Go, Python o Ruby. Lo esegui e basta. stack: poiché il container è un'unità atomica di esecuzione, per scopi di distribuzione e operazione non importa cosa contenga, sia esso un'applicazione su JVM, Node, Go, Python o Ruby. Lo esegui semplicemente, e basta.
Kubernetes porta tutto a un nuovo livello. Ora che ci sono molte "cose eseguibili" e molte macchine per eseguirle, nasce la necessità di uno strumento in grado di abbinarle tra loro. In linea generale, si forniscono a Kubernetes numerosi contenitori e macchine, e lui li abbina fra loro (ovviamente, si tratta di un processo dinamico e in continua evoluzione: nuovi contenitori si spostano nel sistema, le macchine vengono avviate e fermate, ecc. Tuttavia, Kubernetes tiene conto di tutto questo).
Dopo aver configurato Kubernetes, il tempo necessario per il deployment e la gestione di un servizio è poco diverso da quello necessario per dieci servizi (in realtà, sono praticamente equivalenti anche per cento servizi). A questo si aggiunga il fatto che i contenitori fungono da meccanismo di imballaggio, incoraggiando implementazioni multilingue, e si ottiene una serie di nuove applicazioni realizzate sotto forma di microservizi, scritte in vari linguaggi — proprio l'ambiente per cui il service mesh è così adatto.
Quindi, siamo arrivati alla risposta alla domanda sul perché l'idea del service mesh sia diventata popolare proprio ora: l'uniformità che Kubernetes fornisce ai servizi è direttamente applicabile alle sfide operative che affronta il service mesh. Imballi i proxy nei contenitori, dai a Kubernetes il compito di attaccarli ovunque sia possibile, e voilà! A fine corsa ottieni un service mesh, con Kubernetes che gestisce l'intera meccanica della sua distribuzione. (Almeno, dal punto di vista globale. Certo, in questo processo ci sono molte sfumature.)
Per riassumere: il motivo per cui il service mesh è diventato popolare proprio adesso, e non dieci anni fa, è che Kubernetes e Docker non solo hanno aumentato significativamente la domanda per esso, semplificando l'implementazione delle applicazioni come insieme di microservizi multilingue, ma hanno anche ridotto notevolmente i costi per la sua gestione, fornendo meccanismi di distribuzione e supporto per fleet di proxy sidecar.
Perché si parla così tanto di service mesh?
Avviso: in questa sezione faccio uso di tutte le ipotesi, congetture, speculazioni e informazioni interne.
Cercando la frase «service mesh», ti imbatterai in un sacco di contenuti riprocessati a basso contenuto calorico, progetti strani e un caleidoscopio di distorsioni degne di una camera d'eco. Qualsiasi tecnologia alla moda presenta questo problema, ma nel caso del service mesh la questione è particolarmente acuta. Perché?
Beh, in parte è colpa mia. Ho fatto del mio meglio per promuovere Linkerd e il service mesh ogni volta che ho avuto l'opportunità, attraverso innumerevoli post sul blog e articoli come questo. Ma non sono così potente. Per rispondere veramente a questa domanda, è necessario discutere brevemente la situazione generale. E non possiamo parlare di essa senza menzionare un progetto: — un service mesh open source sviluppato congiuntamente da Google, IBM e Lyft.
(Le tre aziende hanno ruoli molto diversi: il coinvolgimento di Lyft sembra limitarsi al solo nome; sono i creatori di Envoy, ma non usano Istio né partecipano al suo sviluppo. IBM è coinvolta nello sviluppo di Istio e lo utilizza. Google partecipa attivamente allo sviluppo di Istio, ma da quanto posso vedere, in realtà non lo usa.)
Il progetto Istio si distingue per due aspetti. In primo luogo, ci sono i notevoli sforzi di marketing che Google, in particolare, sta mettendo nel suo lancio. A mio avviso, la maggior parte delle persone che sono a conoscenza del concetto di service mesh lo ha scoperto per la prima volta grazie a Istio. Il secondo aspetto è quanto sia stata ricevuta male Istio. In questa questione, sono ovviamente parte interessata, ma cercando di rimanere il più obiettivo possibile, non posso fare a meno di , non molto caratteristico (anche se non unico: viene in mente systemd, …) per un progetto Open Source.
(In pratica, sembra che Istio abbia problemi non solo con la complessità e l'esperienza utente, ma anche con le prestazioni. Ad esempio, durante , condotta da una terza parte, gli esperti hanno scoperto situazioni in cui la latenza finale (tail latency) di Istio superava di 100 volte quella di Linkerd, così come situazioni di mancanza di risorse, in cui Linkerd continuava a funzionare correttamente, mentre Istio si bloccava completamente.)
Lasciando da parte le mie teorie su perché sia successo, credo che l'enorme fervore attorno al service mesh sia spiegato proprio dalla partecipazione di Google. In particolare, dalla combinazione dei seguenti tre fattori:
- la promozione invadente di Istio da parte di Google;
- l'atteggiamento critico e di disapprovazione nei confronti del progetto;
- l'improvvisa e rapida ascesa della popolarità di Kubernetes, i cui ricordi sono ancora freschi.
Insieme, questi fattori si uniscono in un ambiente nebuloso e privo di ossigeno, in cui la capacità di giudizio razionale si affievolisce, e rimane solo una meravigliosa forma di .
Dal punto di vista di Linkerd, lo descriverei come un bene ambiguo. Voglio dire, è fantastico che il service mesh sia entrato nel mainstream — cosa che non accadeva nel 2016, quando Linkerd è stato lanciato e attirare l'attenzione verso il progetto era veramente difficile. Ora non ci sono più problemi! Ma è un peccato che la situazione del service mesh sia così confusa oggi, che è praticamente impossibile capire quali progetti rientrino realmente nella categoria service mesh (per non parlare del fatto di capire quale sia il più adatto per un particolare caso d'uso). Questo, senza dubbio, crea difficoltà a tutti (e, certamente, in alcuni casi Istio o un altro progetto potrebbero essere più adatti di Linkerd, poiché quest'ultimo non è ancora una soluzione universale).
Dal punto di vista di Linkerd, la nostra strategia è stata quella di ignorare il rumore, continuare a concentrarci sulla risoluzione di veri problemi della comunità e, in sostanza, aspettare che l'hype si acquietasse. Alla fine, il clamore si placherà e potremo continuare a lavorare tranquillamente.
Per ora, tutti noi dovremo avere un po' di pazienza.
Mi servirà un service mesh, io, umile software engineer?
Il questionario seguente può aiutarti a trovare una risposta a questa domanda:
Ti occupi esclusivamente dell'implementazione della logica di business? In tal caso, il service mesh non ti sarà utile. Certo, puoi essere interessato, ma idealmente il service mesh non dovrebbe influenzare direttamente nulla nel tuo ambiente. Continua a lavorare su ciò per cui sei pagato.
Gestisci una piattaforma in un'azienda che utilizza Kubernetes? Sì, in questo caso il service mesh è necessario (ovviamente, se non utilizzi K8s solo per eseguire un monolite o per l'elaborazione batch — ma in tal caso mi piacerebbe sapere perché hai bisogno di K8s). Probabilmente ti troverai in una situazione con molti microservizi scritti da persone diverse. Tutti interagiscono tra loro e sono intrecciati in un groviglio di dipendenze runtime, e hai bisogno di un modo per gestire tutto questo. L'uso di Kubernetes ti consente di scegliere un service mesh "su misura". A tale scopo, esplora le loro funzionalità e peculiarità e rispondi alla domanda se uno dei progetti disponibili ti si addice (ti consiglio di iniziare la ricerca con Linkerd).
Sei responsabile della piattaforma in un'azienda che NON utilizza Kubernetes ma impiega microservizi? In tal caso, il service mesh ti sarà utile, ma il suo utilizzo non sarà banale. Naturalmente, puoi simulare il funzionamento del service mesh utilizzando un certo numero di proxy, ma un importante vantaggio di Kubernetes è proprio il modello di deployment: gestire manualmente questi proxy richiederà molto più tempo, sforzo e risorse.
Sei responsabile della piattaforma in un'azienda che lavora con monoliti? In tal caso, probabilmente non hai bisogno di un service mesh. Se lavori con monoliti (o persino con insieme di monoliti) che hanno pattern di interazione ben definiti e raramente cambiano, un service mesh non potrà offrirti molto. Puoi quindi semplicemente ignorarlo e sperare che svanisca come un brutto sogno...
Conclusione
Probabilmente, non si dovrebbe definire il service mesh come "la tecnologia più hype del mondo" — questo onore discutibile spetta probabilmente al bitcoin o all'IA. Potrebbe essere tra le prime cinque. Ma se si riesce a oltrepassare i livelli di rumore e confusione, diventa chiaro che il service mesh offre reali vantaggi a chi crea applicazioni in Kubernetes.
Vorrei che provaste Linkerd — la sua installazione in un cluster Kubernetes (o anche in Minikube su un laptop) , e potrete vedere voi stessi di cosa sto parlando.
FAQ
— Se ignorerò il service mesh, scomparirà?
— Mi dispiace deluderti: il service mesh è qui per restare.
— MA IO NON VOGLIO usare il service mesh!
— E non c'è bisogno! Basta leggere il mio questionario sopra per capire se vale la pena conoscere almeno le basi.
— Non è solo un vecchio buon ESB/middleware in una nuova veste?
— Il service mesh si occupa della logica operativa, non del significato. del bus di servizio aziendale (). Mantenere questa separazione aiuta il service mesh ad evitare la stessa sorte.
— In cosa si differenzia il service mesh dagli API gateway?
— Ci sono un milione di articoli su questo tema. Basta cercare su Google.
— Envoy è un service mesh?
— No, Envoy non è un service mesh, è un server proxy. Può essere utilizzato per organizzare un service mesh (e molto altro — è un proxy generico). Ma di per sé non è un service mesh.
— Network Service Mesh è un service mesh?
— No. Nonostante il nome, non è un service mesh (com'è strano il marketing?).
— Può un service mesh aiutarmi con il mio sistema reattivo e asincrono basato su code di messaggi?
— No, il service mesh non ti aiuterà.
— Quale service mesh dovrei usare?
— , è chiaro come il sole.
— L'articolo è pessimo! / L'autore al rogo!
— Per favore, condividi il link con tutti i tuoi amici, così possono rendersi conto!
Ringraziamenti
Come puoi intuire dal titolo, questo articolo è stato ispirato dal fantastico saggio di Jay Kreps «». Ho incontrato Jay dieci anni fa mentre facevo un colloquio su LinkedIn, e da allora è una fonte di ispirazione per me.
Anche se mi piace definirmi «sviluppatore di Linkerd», la realtà è che sono più un mantenitore del file README.md nel progetto. Oggi su Linkerd lavorano , , persone, e questo progetto non sarebbe stato possibile senza il contributo della straordinaria comunità di collaboratori e utenti.
E per concludere, un ringraziamento speciale al creatore di Linkerd, (primus inter pares), che insieme a me diversi anni fa ha immerso completamente in tutto questo trambusto con il service mesh.
P.S. dal traduttore
Leggete anche nel nostro blog:
- «»;
- «»;
- «»;
- «»;
- «».
Fonte: habr.com
