Per Istio e oltre: Azure's Service Mesh Interface

Lo sviluppo di applicazioni moderne e cloud-first, almeno su Azure, è diventato quasi dipendente da Kubernetes. Tecnologie come Virtual Kubelets, AKS (Azure Kubernetes Service) e Azure Service Fabric Mesh sono fondamentali per la creazione di applicazioni distribuite scalabili su Azure, utilizzando i contenitori per distribuire e gestire i microservizi.

Guardando gli strumenti Kubernetes di Azure, è chiaro che Microsoft sta facendo molto lavoro all'interno e intorno alla Cloud Native Computing Foundation, lavorando su tutti gli aspetti del framework open source. Non dovremmo essere sorpresi; Microsoft ha assunto uno dei fondatori del progetto Kubernetes e poi ha acquisito Deis, un importante fornitore. Il team Deis è alla base di uno degli ultimi contributi di Azure all'ecosistema Kubernetes, la Service Mesh Interface (SMI).

Presentazione delle mesh di servizi

Forse è meglio prima spiegare cos'è una mesh di servizi e perché è importante per qualsiasi applicazione basata su Kubernetes.

Le moderne architetture IT sono incentrate sull'astrazione. Con i servizi cloud non dobbiamo più pensare all'hardware sottostante. Se stiamo usando IaaS definiamo macchine virtuali per ospitare il nostro codice. Con PaaS siamo ancora più lontani dall'hardware, utilizzando i servizi e le API che abbiamo scelto, scegliendo un livello di prestazioni appropriato per le nostre applicazioni e budget. Con architetture basate su container come Kubernetes, siamo a un punto a metà tra i due: utilizzando servizi come AKS possiamo definire le macchine virtuali sottostanti, che poi ospitano i nostri pod del contenitore e scalano con modifiche nel calcolo e nella memoria (e ora con KEDA (scalabilità automatica basata su eventi basata su Kubernetes), al ricevimento degli eventi).

Questo è solo un aspetto dell'astrazione. I microservizi Kubernetes sono, in fondo, senza stato; utilizzano una memoria esterna e si trovano in cima a reti fisiche o virtuali. È l'aspetto di rete dell'esecuzione di Kubernetes che è probabilmente il più complicato: con la scalabilità orizzontale e la scalabilità dei servizi, è necessario modificare la rete in modo che corrisponda alle modifiche alla tua applicazione. Ma come si mantengono i servizi connessi quando il front-end e il back-end di un'applicazione possono essere ridimensionati a velocità diverse?

È qui che entrano in gioco le mesh di servizi. Sono un nuovo livello di astrazione, che solleva il codice dalla rete sottostante sfruttando le capacità di una moderna rete definita dal software. Agendo come un insieme di proxy di rete che vengono distribuiti con il codice, una rete mesh di servizi gestisce la comunicazione da servizio a servizio senza che il codice abbia bisogno di alcuna consapevolezza della rete sottostante. Puoi pensare a una mesh di servizi come a un piano di controllo automatizzato per la rete della tua applicazione, gestendo il piano di controllo sottostante mentre Kubernetes scala il tuo codice su e giù.

Una rete definita dal software per i microservizi

Forse meglio pensato come un modo per implementare un bilanciamento del carico scalabile, sensibile alla latenza e al rilevamento del servizio, una mesh di servizi è fondamentalmente un router distribuito con regole di routing dinamico gestite come parte di una distribuzione Kubernetes. È possibile definire regole aggiuntive; ad esempio, mantenere separati i sistemi di produzione e di test o gestire la distribuzione di una nuova versione e il cambio tra le versioni del contenitore. Ogni pod in un'applicazione ha un'istanza di mesh di servizi in esecuzione come sidecar, con l'individuazione dei servizi e altri elementi con stato in esecuzione all'esterno dei servizi.

Con una mesh di servizi stai spingendo l'intelligenza in un nuovo livello di rete, quindi non devi metterla nei tuoi microservizi. Hai bisogno di crittografare una connessione? Questo è un lavoro per la tua rete di servizi. Hai bisogno di autorizzare i clienti? Un altro compito per la rete di servizi.

Troppe maglie

La combinazione di una distribuzione Kubernetes con una mesh di servizi ha molto senso. Tuttavia c'è un altro grosso problema: quale usi? Inviato? Istio? Linkerd? Aspen Mesh? Se ne scegli uno, cosa impedisce a un team di sviluppo in un'altra parte della tua attività di sceglierne un altro? Allora cosa succede se la tua azienda decide di standardizzare su una piattaforma specifica?

Questo è il problema che Microsoft sta cercando di risolvere con l'interfaccia mesh dei servizi. Invece di ogni mesh di servizi con il proprio set di API, SMI è un modo per implementare API comuni che funzionano su diverse mesh di servizi, gestendo quella nuova rete intelligente. Invece di bloccare il codice in una mesh di servizi specifica e nelle sue API, puoi scrivere codice che risolva i casi d'uso più comuni tramite un'API comune. Se è necessario sostituire una rete di servizi, se si cambia provider o se ne trova uno che funziona meglio, non è necessario modificare il codice, a condizione che la rete di servizi implementi l'SMI. Tutto quello che devi fare è modificare i sidecar della mesh di servizio e ridistribuire il codice.

SMI: API mesh di servizi comuni

Lavorando con aziende dell'ecosistema Kubernetes come Hashicorp e Buoyant, Microsoft ha definito le funzionalità chiave per SMI che supportano le richieste comuni dei suoi clienti. Nella versione iniziale si è concentrato su tre aree: politica del traffico, telemetria del traffico e gestione del traffico. Queste tre aree sono controllate dalla maggior parte delle mesh di servizi e l'intenzione è di renderla una specifica facile da implementare senza modificare l'applicazione sottostante.

Rendendo SMI un insieme di API standard, nulla impedisce ai fornitori di mesh di servizi di continuare a offrire le proprie API o funzionalità aggiuntive al di fuori di quelle specificate. In alternativa non è necessario apportare modifiche; terze parti possono creare livelli di traduzione che si trovano tra le API SMI e le API dei servizi proprietari. Non avrai nemmeno bisogno di una nuova versione di Kubernetes, poiché le API SMI sono implementate come server API di estensione e definizioni di risorse personalizzate. Puoi procedere e installarli in qualsiasi cluster, utilizzando gli strumenti di gestione esistenti. Ciò dovrebbe rendere SMI facile per Azure e altri servizi Kubernetes ospitati nel cloud per integrarli nei loro servizi Kubernetes gestiti esistenti.

Sia che tu voglia utilizzare Linkerd o Aspen Mesh o NSX Service Mesh di VMware, con SMI potrai scegliere quello che preferisci, migliorando la portabilità del codice ed evitando il lock-in a specifici servizi cloud. Quindi c'è l'opportunità di cambiare mesh di servizi senza influire sul codice. Se una nuova mesh di servizi offre prestazioni migliori, tutto ciò che devi fare è modificare la pipeline di compilazione per utilizzare la nuova mesh e quindi distribuire un'applicazione aggiornata.

È interessante vedere Microsoft assumere la guida di un progetto come questo, lavorando con un'ampia sezione trasversale della comunità Kubernetes. Adottando un approccio che non è esplicitamente incentrato sulla creazione di una mesh di servizi, Azure può offrire diverse mesh di servizi come parte della configurazione di AKS, consentendoti di scegliere lo strumento che desideri senza dover modificare alcun codice.