Nota di traduzione.: Il service mesh è un fenomeno che non ha ancora una traduzione consolidata in italiano (oltre 2 anni fa abbiamo proposto l'alternativa "rete dei servizi", e successivamente alcuni colleghi hanno iniziato a promuovere attivamente la combinazione "setaccio dei servizi"). Le continue discussioni su questa tecnologia hanno portato a una situazione in cui le componenti di marketing e quelle tecniche si intrecciano strettamente. Questo materiale straordinario di uno degli autori del termine originale mira a fare chiarezza per gli ingegneri e non solo.
Fumetto di
Introduzione
Se sei un ingegnere del software che lavora nel campo dei sistemi backend, il termine "service mesh" è probabilmente già saldamente ancorato nella tua mente da un paio d'anni. Grazie a un curioso intreccio di circostanze, questa locuzione sta conquistando sempre più l'industria, mentre il clamore e le proposte pubblicitarie collegate si accumulano a dismisura, come una palla di neve che rotola giù per la collina e non mostra alcun segno di rallentamento.
Il service mesh è nato nelle acque torbide e parziali dell'ecosistema cloud native. Sfortunatamente, ciò significa che gran parte del dibattito associato varia da "chiacchiere leggere" a — per usare un termine tecnico — assoluta sciocchezza. Ma se si filtra tutto il rumore, si può scoprire che il service mesh ha una funzione 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 "A cosa serve?", e inoltre "Perché proprio ora?". Infine, cercherò di delineare perché (secondo me) questa tecnologia abbia generato un tale entusiasmo, che da sola è una storia interessante.
Chi sono?
Ciao a tutti! Mi chiamo . Sono uno dei creatori di — il primo progetto di service mesh e il progetto responsabile dell'introduzione del termine service mesh in quanto tale (scusate, ragazzi!). (Traduzione dei fumetti.: A proposito, all'inizio di questo termine, oltre 2,5 anni fa, abbiamo già tradotto un materiale precedente dello stesso autore intitolato "».) Inoltre, sono il fondatore di — una startup che sta creando fantastiche soluzioni di service mesh, come Linkerd e .
Probabilmente avete già intuito che ho un'opinione piuttosto parziale e soggettiva su questo argomento. Tuttavia, cercherò di ridurre al minimo il mio bias (eccetto in un capitolo: «Perché ci sono così tante discussioni sul service mesh?», — nel quale condividerò comunque le mie idee parziali). Mi impegnerò anche a fare in modo che questa guida sia il più obiettiva possibile. Negli esempi specifici mi baserò prevalentemente sull'esperienza di Linkerd, evidenziando le differenze che conosco (se ci sono) nell'implementazione di altri tipi di service mesh.
Ok, è tempo di passare alle cose interessanti.
Che cos'è un service mesh?
Nonostante tutto il clamore, strutturalmente un service mesh è piuttosto semplice. Non è altro che un insieme di proxy userspace dislocati "vicino" ai servizi (parleremo un po' più avanti di cosa significhi "vicino"), insieme a un insieme di processi di gestione. I proxy sono collettivamente denominati data plane, mentre i processi di gestione sono chiamati control plane. Il data plane intercetta le chiamate tra i servizi e ne gestisce "varie cose"; il control plane, di conseguenza, coordina il comportamento dei proxy e fornisce l'accesso a voi, cioè all'operatore, tramite l'API, permettendo di manipolare la rete e misurarla come un insieme.
Che tipi di proxy sono? Sono proxy TCP di categoria "Layer 7-aware" (cioè "consapevoli" del settimo livello del modello OSI) , come HAProxy e NGINX. È possibile scegliere il proxy che si preferisce; Linkerd utilizza un proxy scritto in Rust, chiamato semplicemente . Lo abbiamo creato appositamente per il service mesh. Altri mesh preferiscono proxy diversi (Envoy è una scelta comune). Tuttavia, la scelta del proxy è semplicemente una questione di implementazione.
Cosa fanno questi server proxy? Ovviamente, fanno da proxy per le chiamate ai servizi e da essi (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 che si concentrano sulle chiamate tra i servizi. Questo focus sul traffico tra i servizi distingue i proxy di service mesh da, ad esempio, i gateway API o i proxy ingress (quest'ultimi si concentrano sulle chiamate provenienti dall'esterno del cluster). (Nota di traduzione.: confrontando i controller Ingress esistenti per Kubernetes, molti dei quali utilizzano già l'Envoy menzionato, vedere .)
Quindi, abbiamo capito il data plane. Il control plane è organizzato in modo più semplice: è un insieme di componenti che forniscono tutta la meccanica necessaria affinché il data plane funzioni in modo coordinato, inclusi il rilevamento dei servizi, l'emissione dei certificati TLS, l'aggregazione delle metriche, ecc. Il data plane informa il control plane sul suo comportamento; a sua volta, il control plane fornisce un'API che consente di modificare e monitorare il comportamento del data plane come un'unità unica.
Di seguito è riportato uno schema del control plane e del data plane in Linkerd. Come si può vedere, il control plane comprende diversi componenti, tra cui un'istanza di Prometheus che raccoglie le metriche dai proxy, nonché 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 è rappresentato da un semplice linkerd-proxy affianco all'istanza dell'applicazione. Questa è solo una rappresentazione logica; in scenari reali, durante il deployment, puoi avere tre repliche di ogni componente del control plane e centinaia o migliaia di proxy nel data plane.
(I rettangoli blu in questo schema simboleggiano i confini dei pod di Kubernetes. È evidente che i container con linkerd-proxy si trovano nello stesso pod dei container dell'applicazione. Questa configurazione è nota come container sidecar..)
L'architettura del service mesh ha alcune importanti conseguenze. Prima di tutto, dal momento che il compito del proxy è intercettare le chiamate tra i servizi, il service mesh ha senso solo se la tua applicazione è stata sviluppata come un insieme di servizi. Il mesh è possibile può essere utilizzato con monoliti, ma è chiaramente eccessivo per un singolo proxy, e la sua funzionalità sarà difficilmente richiesta.
Un'altra importante conseguenza è che il service mesh richiede un'enorme quantità di proxy. Infatti, Linkerd collega il linkerd-proxy a ogni istanza di ogni servizio (altre implementazioni aggiungono proxy a ogni nodo/host/macchina virtuale. In ogni caso, non sono pochi). Tale utilizzo intensivo di proxy comporta una serie di complicazioni aggiuntive:
- I proxy nel data plane devono essere veloci,poiché su ogni chiamata ci sono due richieste al proxy: una dal lato client, una dal lato server.
- Inoltre, i proxy devono essere piccoli e leggeri.Ogni istanza consumerà risorse di memoria e CPU, e questo consumo aumenterà linearmente con l'applicazione.
- Avrai bisogno di un meccanismo per implementare e aggiornare un gran numero di proxy. Farlo manualmente non è un'opzione.
In generale, la service mesh si presenta così (perlomeno dall'alto): implementi un sacco di proxy nello user space che "fanno qualcosa" con il traffico interno tra i servizi e utilizzi il control plane per monitorarli e gestirli.
È giunto il momento di porsi la domanda 'Perché?'
A cosa serve una service mesh?
Chi si imbatte per la prima volta nell'idea di una service mesh può provare un certo brivido. La struttura della service mesh significa che essa non solo aumenterà le latenze nell'applicazione, ma consumerà risorse e aggiungerà un sacco di nuovi meccanismi all'infrastruttura. Prima installi la service mesh, poi all'improvviso ti trovi a dover gestire centinaia (se non migliaia) di proxy. La domanda è: chi andrà volontariamente a fare questo?
La risposta a questa domanda è composta da due parti. Innanzitutto, i costi operativi associati all'implementazione di questi proxy possono essere significativamente ridotti grazie ad alcuni cambiamenti che avvengono nell'ecosistema (ne parleremo più tardi).
In secondo luogo, un tale dispositivo è in realtà un ottimo modo per introdurre ulteriore logica nel sistema. E non solo perché con la service mesh puoi aggiungere molte nuove funzionalità, ma anche perché questo può essere fatto senza interferire con l'ecosistema. Infatti, l'intero modello della service mesh si basa su questo postulato: in un sistema multi-servizio, indipendentemente da cosa facciano i singoli servizi, il traffico tra di essi rappresenta il punto ideale per aggiungere funzionalità.
Ad esempio, in Linkerd (come nella maggior parte delle mesh) la funzionalità è principalmente focalizzata sulle chiamate HTTP, inclusi HTTP/2 e gRPC*. La funzionalità è piuttosto ricca e può essere suddivisa in tre classi:
- Funzioni relative a affidabilità.Richieste ripetute, timeout, approccio canarino (partizionamento/reindirizzamento del traffico) ecc.
- Funzioni relative a monitoraggio.Aggregazione delle metriche di successo, latenze e volumi di richieste per ciascun servizio o per specifiche direzioni; costruzione di mappe topologiche dei servizi ecc.
- Funzioni relative a sicurezza.Mutual TLS, controllo degli accessi ecc.
* Dal punto di vista di Linkerd, gRPC non si differenzia praticamente da HTTP/2: si utilizza semplicemente protobuf nel payload. Dal punto di vista dello sviluppatore, queste due cose, ovviamente, si differenziano.
Molti di questi meccanismi operano a livello di richiesta (da qui il termine "L7-proxy"). Ad esempio, se il servizio Foo effettua una chiamata HTTP al servizio Bar, il linkerd-proxy lato Foo può eseguire un bilanciamento del carico intelligente e instradare 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, e così via. Analogamente, il linkerd-proxy lato Bar può rifiutare la richiesta se non è autorizzata o se è stato superato il limite di richieste; può registrare la latenza dal proprio lato, e così via.
I proxy possono "fare qualcosa" anche a livello di connessione. Ad esempio, il linkerd-proxy lato Foo può iniziare una connessione TLS, mentre il linkerd-proxy lato Bar può interromperla, e entrambe le parti possono controllare i certificati TLS l'una dell'altra*. Questo non solo garantisce la crittografia tra i servizi, ma fornisce anche un modo crittograficamente sicuro per identificare i servizi: Foo e Bar possono "dimostrare" di essere ciò che affermano di essere.
* "L'uno con l'altro" significa che il certificato del client viene anch'esso verificato (mutual TLS). Nel "classico" TLS, ad esempio, tra un browser e un server, viene solitamente verificato solo il certificato di una parte (del server).
Indipendentemente dal fatto che essi operino a livello di richieste o di connessioni, è importante sottolineare che tutte le funzionalità del service mesh hanno un carattere operativo. Linkerd non è in grado di trasformare la semantica del payload — ad esempio, aggiungere campi a un frammento JSON o apportare modifiche al protobuf. Parleremo di questa importante caratteristica più avanti, quando discuteremo di ESB e middleware. Ecco l'insieme delle funzionalità offerte dal service mesh. Sorge la domanda: perché non implementarle direttamente nell'applicazione? E perché mai avere a che fare con un proxy?
Perché il service mesh è una buona idea
Sebbene le capacità del service mesh catturino l'immaginazione, il suo reale valore non risiede nelle funzionalità. In fondo, noi
possiamo possiamo realizzarli direttamente nell'applicazione (in seguito vedremo che questa è stata l'origine del service mesh). Se dovessimo esprimere questo concetto in una frase, il valore del service mesh consiste nel seguente punto: fornisce funzionalità critiche per il funzionamento del software server moderno in modo uniforme per tutto lo stack e indipendentemente dal codice dell'applicazione.
Analizziamo questa frase.
«Funzionalità critiche per il funzionamento del software server moderno». Se stai creando un'applicazione server transazionale legata a Internet pubblico, che accetta richieste dal mondo esterno e risponde in tempi brevi — ad esempio, un'app web, un server API, e la stragrande maggioranza delle altre applicazioni moderne — e se lo implementi come un insieme di servizi che interagiscono tra loro in modo sincrono, e se aggiorni costantemente questo software, aggiungendo nuove funzionalità, e se sei costretto a mantenere questo sistema operativo durante il processo di modifica — in tal caso, ti congratulo, stai creando un software server moderno. E tutte queste meravigliose funzionalità, elencate sopra, si rivelano realmente critiche per te. L'applicazione deve essere affidabile, sicura e devi poter monitorare ciò che fa. Proprio queste questioni aiutano a risolvere il service mesh.
(Ok, nel paragrafo precedente si è insinuata la mia convinzione che questo approccio sia un modo moderno di creare software server. Altri preferiscono sviluppare monoliti, "microservizi reattivi" e altre cose che non rientrano nella definizione sopra. Queste persone hanno sicuramente il loro punto di vista, diverso dal mio. Da parte mia, ritengo che non abbiano "ragione" — anche se in ogni caso per loro il service mesh non è molto utile).
«Uniforme per tutto lo stack». Le funzionalità fornite dal service mesh non sono solo critiche. Si applicano a tutti i servizi nell'applicazione, indipendentemente dal linguaggio con cui sono scritti, dal framework utilizzato, da chi li ha scritti, da come sono stati distribuiti e da tutte le altre complessità relative al loro sviluppo e utilizzo.
«Indipendente dal codice dell'applicazioneInfine, il service mesh non solo offre funzionalità uniformi per l'intero stack, ma lo fa in un modo che non richiede modifiche all'applicazione. La base fondamentale delle funzionalità del service mesh, comprese le attività di configurazione, aggiornamento, operatività, manutenzione, ecc., è esclusivamente a livello di piattaforma e indipendente dall'applicazione. L'applicazione può cambiare senza influenzare il service mesh. A sua volta, il service mesh può cambiare senza richiedere alcun intervento dell'applicazione.
In breve, il service mesh non solo fornisce funzioni vitali, ma lo fa in modo globale, uniforme e indipendente dall'applicazione. E quindi, sebbene la funzionalità del service mesh possa essere implementata nel codice del servizio (ad esempio, come libreria inclusa in ogni servizio), questo approccio non garantirà l'omogeneità e l'indipendenza, così preziose nel caso del service mesh.
E tutto ciò di cui hai bisogno è aggiungere un sacco di proxy! Prometto, molto presto esamineremo i costi operativi legati all'aggiunta di questi proxy. Ma prima, fermiamoci un attimo e diamo un'occhiata a questa idea di indipendenza dal punto di vista di diversi persone.
A chi è utile il service mesh?
Per quanto possa essere scomodo, affinché una certa 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 immaginare il tuo team come un gruppo di proprietari di servizi, che insieme progettano e implementano la logica aziendale, e proprietari di piattaforme, che si occupano dello sviluppo della piattaforma interna su cui questi servizi operano. Nelle piccole organizzazioni, potrebbero essere le stesse persone, ma con la crescita dell'azienda questi ruoli di solito diventano più distinti e si suddividono anche in sottoruoli... (Si potrebbe dire molto sulla natura in cambiamento del devops, sull'impatto organizzativo dei microservizi, ecc. Ma per ora accettiamo queste descrizioni come dati di fatto.)
Da questo punto di vista, i principali beneficiari del service mesh sono i proprietari della piattaforma. Infatti, alla fine, l'obiettivo del team della piattaforma è creare una piattaforma interna in cui i proprietari dei servizi possono implementare la logica di business e farlo in un modo che garantisca la massima indipendenza dai dettagli complessi 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 ne traggono vantaggio, sebbene in modo più indiretto. L'obiettivo del proprietario del servizio è essere il più produttivo possibile nell'implementazione della logica dei processi aziendali, e meno deve occuparsi delle questioni operative, meglio è. Invece di dedicarsi all'implementazione di politiche di retry o TLS, possono concentrarsi esclusivamente sulle attività di business e sperare che la piattaforma si occupi del resto. Per loro, questo è un grande vantaggio.
È difficile sovrastimare il valore organizzativo di questa separazione tra i proprietari della piattaforma e dei servizi. Penso che contribuisca il 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: i ragazzi di una grande azienda hanno migrato la loro piattaforma su Kubernetes. Poiché l'applicazione gestiva informazioni riservate, volevano crittografare tutte le comunicazioni nei cluster. Tuttavia, la situazione era complicata dalla presenza di centinaia di servizi e centinaia di team di sviluppatori. La prospettiva di contattare tutti e convincerli a includere il supporto TLS nei loro piani non era affatto allettante. Installando Linkerd, hanno trasferito la responsabilità dagli sviluppatori (per i quali era un onere in più) ai professionisti della piattaforma, per i quali era una priorità di alto livello. In altre parole, Linkerd risolveva per loro non tanto un problema tecnico, quanto un problema organizzativo.
In breve, il service mesh è più una soluzione a un problema non tecnico ma socio-tecnico. (Grazie Cindy Sridharan Il service mesh risolverà tutti i miei problemi?
Il service mesh risolverà tutti i miei problemi?
Sì. Nel senso, no!
Se guardiamo ai tre classi di funzioni menzionate sopra: affidabilità, sicurezza e osservabilità, è chiaro che il service mesh non è una soluzione completa per nessuno di questi problemi. Anche se Linkerd può inviare richieste ripetute (se sa che sono idempotenti), non è in grado di decidere cosa restituire all'utente se il servizio è completamente andato in perdita: tali decisioni devono essere prese dall'applicazione. Linkerd può tenere traccia delle richieste riuscite, ma non è in grado di controllare il servizio e fornire le sue metriche interne: tali strumenti devono essere parte dell'applicazione. E anche se Linkerd è in grado di gestire il mTLS, le soluzioni complete nel garantire la sicurezza richiedono molto di più.
Una sottoclasse di funzioni in questi ambiti, offerte dal service mesh, riguarda le funzionalità della piattaforma. Con questo intendo le funzionalità che:
- Sono indipendenti dalla logica di business. Il modo in cui vengono costruite le istogrammi di chiamata tra Foo e Bar non dipende affatto da perché Foo che chiama Bar.
- È difficile implementare correttamente. In Linkerd, i tentativi ripetuti sono parametrizzati da varie cose elaborate come i budget per i tentativi (retry budgets), poiché un approccio diretto nella realizzazione di tali cose porterà certamente alla cosiddetta "valanga di richieste" (retry storm) e ad altri problemi caratteristici dei sistemi distribuiti.
- Sono più efficaci quando applicate in modo uniforme. Il meccanismo TLS ha senso solo se applicato ovunque.
Poiché queste funzioni sono implementate a livello di proxy (e non a livello dell'applicazione), il service mesh le fornisce a livello piattaforma, non dell'applicazione. Quindi, non importa in quale linguaggio siano scritti i servizi, quale framework utilizzano, chi li ha scritti e perché. I proxy funzionano aldilà di tutti questi dettagli, e la base fondamentale di questa funzionalità, comprese le attività di configurazione, aggiornamento, gestione, manutenzione, ecc., risiede 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 implica la necessaria partecipazione dei proprietari dei servizi, dei team Ops/SRE e di altri soggetti all'interno dell'azienda. Il service mesh offre solo un "coup de grâce" a livello di piattaforma per ciascuna di queste aree.
Perché il service mesh è diventato popolare proprio adesso?
Probabilmente in questo momento ti stai chiedendo: ok, se il service mesh è così buono, perché non abbiamo iniziato a distribuire milioni di proxy nello stack dieci anni fa?
C'è una risposta banale a questa domanda: dieci anni fa tutti costruivano monoliti e il service mesh non era necessario per nessuno. È vero, ma secondo me questa risposta perde di vista l'essenza. Anche dieci anni fa, il concetto di microservizi come un modo promettente per costruire sistemi su larga scala era ampiamente discusso e applicato in aziende come Twitter, Facebook, Google e Netflix. La percezione generale — almeno nelle parti dell'industria con cui ho interagito — era che i microservizi fossero il "modo giusto" di costruire grandi sistemi, anche se era dannatamente difficile.
Certo, sebbene dieci anni fa ci fossero aziende che utilizzavano microservizi, non stavano certo inserendo proxy ovunque per formare un service mesh. Tuttavia, se ci pensi, stavano facendo qualcosa di simile: in molte di queste aziende si richiedeva di utilizzare una particolare libreria interna per l'interazione di rete (a volte chiamata libreria del client grasso, fat client library).
Netflix aveva Hysterix, Google aveva Stubby, Twitter aveva la libreria Finagle. Finagle, ad esempio, era obbligatoria per ogni nuovo servizio in Twitter. Gestiva sia la parte client sia quella server delle connessioni, consentiva 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 faceva il servizio. Certo, 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 pressoché simili a quelle di un service mesh. (In realtà, la prima versione di Linkerd era semplicemente Finagle avvolto in una forma di proxy.)
Pertanto, dieci anni fa esistevano non solo microservizi, ma anche librerie prototipo di service mesh, che affrontavano gli stessi problemi che oggi risolve il service mesh. Tuttavia, il service mesh in sé non esisteva allora. Ci doveva essere un altro cambiamento prima che apparisse.
Ed è proprio qui che risiede la risposta più profonda, nascosta in un altro cambiamento avvenuto negli ultimi 10 anni: c'è stata una netta riduzione dei costi di implementazione dei microservizi. Le aziende menzionate sopra, che utilizzavano microservizi dieci anni fa: Twitter, Netflix, Facebook, Google, erano aziende di enormi dimensioni e risorse. Avevano non solo il bisogno, ma anche la possibilità di creare, implementare e gestire grandi applicazioni basate su microservizi. L'energia e gli sforzi impiegati dagli ingegneri di Twitter nel passaggio da un approccio monolitico a uno microserviziale sono veramente sbalorditivi. (A dire il vero, così come il fatto che ci siano riusciti.) Tali manovre infrastrutturali allora erano impossibili per aziende di dimensioni più piccole.
Torniamo al presente. Oggi ci sono startup in cui il rapporto tra microservizi e sviluppatori è di 5:1 (o addirittura ), e inoltre, stanno gestendo con successo questa situazione! Se una startup di 5 persone riesce a gestire 50 microservizi senza sforzi, significa che qualcosa ha chiaramente ridotto il costo della loro implementazione.
1500 microservizi in Monzo; ogni riga è una regola di rete prescritta che consente il traffico
La netta riduzione dei costi di operazione dei microservizi è il risultato di un unico processo: l'aumento della popolarità dei contenitori e degli orchestratori. È qui che risiede la risposta profonda alla domanda su cosa abbia contribuito all'emergere 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: quello dell'imballaggio. Imballando un'applicazione e le sue dipendenze runtime (non di rete) in un contenitore, Docker trasforma l'applicazione in un'unità intercambiabile che può essere posizionata e avviata ovunque. Allo stesso tempo, semplifica notevolmente l'operatività multilingue stack: poiché il contenitore è un'unità atomica di esecuzione, per le finalità di distribuzione e operatività non importa cosa ci sia dentro, sia esso un'applicazione su JVM, Node, Go, Python o Ruby. Lo avvii semplicemente e via.
Kubernetes porta tutto a un nuovo livello. Ora, con un sacco di "cose eseguibili" e un gran numero di macchine su cui eseguirle, c'è bisogno di uno strumento in grado di abbinarle tra loro. In termini generali, fornisci a Kubernetes un gran numero di contenitori e un gran numero di macchine, e lui li abbina l'uno all'altro (ovviamente, questo è un processo dinamico e in continua evoluzione: i nuovi contenitori si spostano nel sistema, le macchine vengono avviate e spente, ecc. Tuttavia, Kubernetes tiene conto di tutto ciò).
Dopo aver configurato Kubernetes, i tempi di distribuzione e operatività di un servizio sono solo leggermente diversi rispetto ai costi di distribuzione e operatività di dieci servizi (in realtà, sono praticamente simili anche per 100 servizi). Aggiungi a questo i contenitori come meccanismo di impacchettamento, che favoriscono l'implementazione multilingue, e ottieni un'enorme quantità di nuove applicazioni realizzate sotto forma di microservizi scritti in vari linguaggi: l'ambiente ideale per cui il service mesh è così adatto.
Quindi, siamo arrivati alla risposta alla domanda sul perché l'idea del service mesh abbia guadagnato popolarità proprio ora: quell'omogeneità che Kubernetes garantisce ai servizi è applicabile direttamente alle sfide operative che affronta il service mesh. Imballi un proxy nei contenitori, dai a Kubernetes il compito di attaccarli dove può, ed ecco! Alla fine ottieni un service mesh, con tutta la meccanica della sua distribuzione gestita da Kubernetes. (Almeno, dall'alto. Certamente ci sono molte sfumature in questo processo.)
In sintesi: il motivo per cui il service mesh è diventato popolare proprio ora, e non dieci anni fa, è che Kubernetes e Docker hanno non solo aumentato significativamente la domanda nei suoi confronti, semplificando l'implementazione delle applicazioni come insiemi di microservizi multilingue, ma hanno anche ridotto notevolmente i costi per la sua operatività, fornendo meccanismi di distribuzione e supporto per i parchi di proxy sidecar.
Perché si parla così tanto di service mesh?
Attenzione: in questa sezione mi affido a varie supposizioni, congetture, fantasie e informazioni interne.
Cercando l'espressione «service mesh», ti imbatterai in una miriade di contenuti rielaborati a basso contenuto calorico, progetti strani e un caleidoscopio di distorsioni degne di una camera d'eco. Questo è un problema tipico di qualsiasi nuova tecnologia di tendenza, ma nel caso della service mesh la questione è particolarmente rilevante. Perché?
Beh, in parte è colpa mia. Ho fatto di tutto per promuovere Linkerd e la service mesh in ogni occasione possibile, con innumerevoli pubblicazioni sul blog e articoli come questo. Ma non sono così potente. Per rispondere realmente a questa domanda, è necessario parlare un po' della situazione generale. E non si può farlo senza menzionare un progetto: — una service mesh open source, sviluppata congiuntamente da Google, IBM e Lyft.
(Queste tre aziende hanno ruoli completamente diversi: il coinvolgimento di Lyft sembra ridursi a un semplice nome; sono gli autori di Envoy, ma non utilizzano Istio né partecipano al suo sviluppo. IBM partecipa allo sviluppo di Istio e lo utilizza. Google è attivamente coinvolta nello sviluppo di Istio, ma, per quanto ne so, in realtà non lo sta utilizzando.)
Il progetto Istio si distingue per due aspetti. In primo luogo, per l'enorme sforzo di marketing che Google, in particolare, sta dedicando alla sua promozione. A mio parere, la maggior parte delle persone a conoscenza del concetto di service mesh al momento lo ha scoperto grazie a Istio. Il secondo aspetto è quanto male sia stato accolto Istio. In questa questione sono, ovviamente, una parte interessata, ma cercando di rimanere il più obiettivo possibile, non posso non , non molto caratteristico (anche se non unico: mi viene in mente systemd, …) per un progetto open source.
(In pratica, sembra che Istio abbia problemi non solo con la complessità e l'UX, ma anche con le prestazioni. Ad esempio, durante , condotta da terzi, gli esperti hanno scoperto situazioni in cui i tempi di attesa finali (tail latency) di Istio superavano di 100 volte quelli corrispondenti di Linkerd, oltre a situazioni di carenza di risorse, in cui Linkerd continuava a funzionare con successo mentre Istio smetteva completamente di funzionare.)
Lasciando da parte le mie teorie sul perché sia successo, credo che il grande clamore attorno a service mesh sia spiegato proprio dalla partecipazione di Google. In particolare, dalla combinazione dei seguenti tre fattori:
- la promozione insistente di Istio da parte di Google;
- un corrispondente atteggiamento critico e di disapprovazione nei confronti del progetto;
- il recente e rapido aumento della popolarità di Kubernetes, i cui ricordi sono ancora freschi.
Insieme, questi fattori si uniscono in un certo ambiente stordente e privo di ossigeno, in cui la capacità di giudizio razionale si indebolisce, e rimane solo una meravigliosa sorta di .
Dal punto di vista di Linkerd, questo… lo definirei come un bene ambiguo. Voglio dire, è fantastico che service mesh sia entrata nel mainstream — cosa che non accadeva nel 2016, quando Linkerd è appena apparso e era davvero difficile attirare l'attenzione sul progetto. Ora questo problema non esiste più! Ma il problema è che la situazione con service mesh oggi è così confusa che è praticamente impossibile capire quali progetti appartengano davvero alla categoria service mesh (per non parlare di capire quale di essi sia il più adatto per uno specifico caso d'uso). Questo sicuramente ostacola tutti (e, in alcuni casi, Istio o un altro progetto possono adattarsi meglio di Linkerd, poiché quest'ultimo non è ancora una soluzione universale).
Da parte nostra, la strategia di Linkerd è stata quella di ignorare il trambusto, continuare a concentrarci sulla risoluzione dei problemi reali della comunità e, sostanzialmente, aspettare che il clamore si affievolisse. Alla fine, l'hype diminuirà, e potremo continuare a lavorare tranquillamente.
Fino ad allora, tutti noi dovremo avere un po' di pazienza.
Mi servirà service mesh, umile software engineer?
A rispondere a questa domanda ci aiuterà il seguente questionario:
Ti occupi esclusivamente dell'implementazione della logica di business? In tal caso, service mesh non ti sarà utile. Cioè, certo, puoi esserne interessato, ma idealmente service mesh non dovrebbe influenzare direttamente nulla nel tuo ambiente. Continua a lavorare su ciò per cui sei pagato.
Supporti una piattaforma in un'azienda che utilizza Kubernetes? Sì, in questo caso hai bisogno di un service mesh (naturalmente, se non stai usando K8s solo per eseguire un monolito o per l'elaborazione batch — ma a quel punto mi piacerebbe sapere perché hai bisogno di K8s). Probabilmente ti troverai in una situazione con molti microservizi, scritti da diverse persone. Tutti interagiscono tra loro e sono legati in un groviglio di dipendenze runtime, e hai bisogno di trovare un modo per gestire tutto questo. L'uso di Kubernetes ti consente di scegliere un service mesh
Sei responsabile per la piattaforma in un'azienda che NON utilizza Kubernetes, ma utilizza microservizi? In questo caso, un service mesh ti sarà utile, tuttavia il suo utilizzo sarà non triviale. Certo che puoi simulare il funzionamento del service mesh, posizionando un mucchio di proxy, ma un grande vantaggio di Kubernetes è proprio il modello di distribuzione: gestire manualmente questi proxy richiederà molto più tempo, sforzi e spese.
Sei responsabile per la piattaforma in un'azienda che lavora con monoliti? In questo caso, probabilmente non hai bisogno di un service mesh. Se lavori con monoliti (o anche con set di monoliti) che hanno schemi di interazione ben definiti e che cambiano raramente, un service mesh ti offrirà poco. Quindi puoi semplicemente ignorarlo e sperare che svanisca come un brutto sogno...
Conclusione
Probabilmente, non dovremmo chiamare il service mesh "la tecnologia più hype del mondo" — questo onore discutibile appartiene probabilmente a Bitcoin o all'IA. Potrebbe rientrare nella top five. Ma se riesci a farti strada attraverso i rumori e le distrazioni, diventa chiaro che un service mesh porta reali benefici a chi sviluppa applicazioni in Kubernetes.
Vorrei che provassi Linkerd — la sua installazione in un cluster Kubernetes (o anche in Minikube su un laptop) , e potrai vedere di persona di cosa sto parlando.
FAQ
— Se ignoro il service mesh, sparirà?
— Deve rattristarti: il service mesh è con noi a lungo.
— Ma NON VOGLIO usare il service mesh!
— Allora non farlo! Ma leggi il mio questionario qui sopra per capire se dovresti almeno familiarizzare con le sue basi.
— Non è un vecchio e buon ESB/middleware condito in un nuovo modo?
— Il service mesh si occupa della logica operativa, non di quella significativa. del bus di servizio aziendale (). Mantenere questa separazione aiuta il service mesh a evitare la stessa sorte.
— In cosa si differenzia il service mesh dagli API gateway?
— Ci sono milioni di articoli su questo tema. Basta cercare su Google.
— Envoy è un service mesh?
— No, Envoy non è un service mesh, è un server proxy. Può essere usato per organizzare un service mesh (e molto altro — è un proxy di uso generale). Ma di per sé non è un service mesh.
— Network Service Mesh è un service mesh?
— No. Nonostante il nome, non è un service mesh (che cosa meravigliosa il marketing!).
— Il service mesh aiuterà il mio sistema reattivo asincrono basato su code di messaggi?
— No, il service mesh non ti aiuterà.
— Quale service mesh dovrei usare?
— , è ovvio.
— L'articolo è una schifezza! / L'autore a nastro!
— Per favore, condividi il link con tutti i tuoi amici, così possono esserne convinti!
Ringraziamenti
Come puoi intuire dal titolo, questo articolo è stato ispirato dal fantastico trattato di Jay Kreps «». Ho incontrato Jay dieci anni fa durante un colloquio in LinkedIn, e da allora è una fonte di ispirazione per me.
Anche se mi piace definirmi «sviluppatore di Linkerd», la realtà è che sono più un manutentore del file README.md nel progetto. Su Linkerd lavorano oggi , , persone, e questo progetto non sarebbe esistito senza il contributo di una straordinaria comunità di collaboratori e utenti.
E per concludere, un ringraziamento speciale al creatore di Linkerd, (primus inter pares), che insieme a me molti anni fa si è immerso in tutto questo trambusto del service mesh.
P.S. dal traduttore
Leggi anche nel nostro blog:
- «»;
- «»;
- «»;
- «»;
- «».
Fonte: habr.com
