Cos'è una service mesh?

Una service mesh, ad esempio il progetto open source Istio, consente di controllare in che modo le diverse componenti di un'applicazione condividono i dati. A differenza di altri sistemi per la gestione della comunicazione tra i servizi, una service mesh costituisce un livello infrastrutturale integrato direttamente nell'app. Tale livello visibile è in grado di documentare la qualità dell'interazione tra le sue varie componenti, ottimizzando la comunicazione ed evitando i tempi di fermo dovuti all'espansione dell'app stessa.

Ogni parte o "servizio" di un'applicazione si affida ad altri servizi per offrire agli utenti ciò che desiderano. Ad esempio, se un utente di un'app di ecommerce vuole acquistare un prodotto, i servizi devono sapere se quell'articolo è disponibile in magazzino. Il servizio che comunica con il database dell'inventario dell'azienda deve quindi interagire con la pagina web del prodotto, che a sua volta deve interagire con il carrello online dell'utente. Per incrementare il valore aziendale, il rivenditore deve creare un servizio che offre agli utenti consigli sui prodotti in app. Questo nuovo servizio comunicherà con un database di tag di prodotti al fine di fornire consigli, ma dovrà comunicare anche con lo stesso database dell'inventario di cui aveva bisogno la pagina del prodotto. Ciò crea uno scambio continuo tra le componenti.

Le applicazioni moderne sono spesso scomposte in una rete di servizi, ognuno dei quali svolge una specifica funzione. Per poter svolgere la sua funzione, un servizio potrebbe aver bisogno di richiedere dati da diversi altri servizi. Cosa accade però se alcuni servizi vengono sovraccaricati dalle richieste di dati da altri servizi, come nel caso del database dell'inventario del rivenditore? Per gestire tale sovraccarico, ci si avvale di una service mesh, che reindirizza le richieste da un servizio all'altro bilanciando il carico complessivo di tutti gli elementi.

Un'architettura a microservizi permette agli sviluppatori di apportare modifiche ai servizi di un'app senza doverla redistribuire in toto. A differenza dello sviluppo di app in altri tipi di architetture, i singoli microservizi sono creati da piccoli team che hanno la possibilità di scegliere quali strumenti e quali linguaggi di codifica usare. Sostanzialmente, i microservizi pur comunicando tra loro sono totalmente indipendenti. Ciò significa che il mancato funzionamento di uno di loro, non comporta il mancato funzionamento dell'intera applicazione.

La comunicazione service to service è indispensabile per il funzionamento dei microservizi. La logica alla base della comunicazione può essere codificata in ogni servizio senza che sia necessaria la presenza di una service mesh. Tuttavia, una service mesh diventa utile quando la comunicazione inizia a complicarsi. Per le applicazioni cloud-native integrate in un'architettura di microservizi, una service mesh consente di includere un numero elevato di servizi "piccoli" in un'applicazione funzionale.

Una service mesh non introduce nuove funzionalità nell'ambiente di runtime di un'applicazione, infatti le applicazioni di qualsiasi tipo di architettura hanno sempre avuto bisogno di regole che specifichino in che modo le richieste si muovono da un punto all'altro. Una service mesh, però, estrapola la logica che regola la comunicazione service-to-service dai singoli servizi e la astrae in un livello dell'infrastruttura.

Questo è il motivo per cui una service mesh è integrata in un'app come un serie di proxy di rete. I proxy sono un concetto familiare all'IT di livello enterprise. Se hai effettuato l'accesso a questa pagina web da un computer sul posto di lavoro, è molto probabile che tu ne abbia appena usato uno:

1. quando hai effettuato la richiesta di accesso a questa pagina, la richiesta è stata ricevuta dal web proxy della tua azienda.
2. Dopo aver superato le misure di sicurezza del proxy, è stata inviata al server che ospita questa pagina.
3. Successivamente, questa pagina è stata restituita al proxy e ricontrollata rispetto alle misure di sicurezza.
4. Infine il proxy ha provveduto a inviartela.

In una service mesh, le richieste sono indirizzate tra i microservizi attraverso proxy presenti nel livello dell'infrastruttura. Ecco perché i singoli proxy che compongono una service mesh sono a volte chiamati “sidecar”: si muovono a fianco di ogni servizio, anziché al loro interno. Tutti questi proxy "sidecar", disaccoppiati da ogni servizio, formano insieme una rete di mesh.

Un proxy sidecar affianca un microservizio e indirizza le richieste ad altri proxy. Tutti insieme, questi proxy sidecar formano una rete di mesh.

Senza una service mesh, ogni microservizio deve essere codificato mediante una logica che regoli la comunicazione service-to-service. Ciò impedisce agli sviluppatori non solo di dedicarsi gli obiettivi aziendali, ma anche di diagnosticare eventuali problemi di comunicazione, poiché la logica che regola la comunicazione tra i servizi è nascosta all'interno di ogni servizio.

Ogni nuovo servizio che viene aggiunto a un'app, oppure ogni nuova istanza di un servizio esistente eseguita in un container, rende più complesso l'ambiente in cui avviene la comunicazione e introduce nuovi possibili errori. Individuare il punto in cui si sono verificati dei problemi all'interno di un'architettura di microservizi complessa può diventare pressoché impossibile senza la presenza di una service mesh.

La service mesh, infatti, è in grado di catturare ogni aspetto della comunicazione da servizio a servizio sotto forma di parametri prestazionali. Nel tempo, i dati messi a disposizione dalla service mesh possono essere applicati alle regole che governano la comunicazione tra i servizi, migliorando l'efficienza e l'affidabilità delle richieste di servizio.

Ad esempio, nel caso in cui un servizio non funzioni correttamente, una service mesh può raccogliere i dati sul tempo intercorso prima che un altro tentativo vada a buon fine. Grazie all'aggregazione dei dati sui tempi di errore di un determinato servizio, è possibile scrivere regole che determinino i tempi di attesa ottimali prima di ritentare quel servizio, assicurandosi che il sistema non sia sovraccaricato da tentativi inutili.

Se stai creando dei microservizi, probabilmente hai riscontrato delle esigenze specifiche durante la progettazione, tra cui sfruttare una scalabilità in tempi rapidi e aggiungere nuove funzioni per soddisfare le esigenze aziendali. È probabile che, dal lancio, la tua architettura a microservizi sia cambiata notevolmente. All'inizio, le librerie integrate nei microservizi potrebbero riuscire a gestire la comunicazione da servizio a servizio con un'interruzione minima delle operazioni. Ma nel lungo periodo questo scenario non può rimanere invariato, in particolar modo se si sta sfruttando una sempre maggiore scalabilità e si stanno aggiungendo altre funzioni. I servizi risultano sovraccaricati dalle numerose richieste e gli sviluppatori dedicano sempre più tempo a decodificare la logica di richiesta per ogni servizio, cosa che porterà a dover gestire nuove criticità.

Con una service mesh:

• Gli sviluppatori possono dedicarsi a incrementare il valore aziendale, anziché a connettere i servizi.
• Il tracciamento distribuito delle richieste tramite Jaeger costituisce un livello di infrastruttura visibile a fianco dei servizi, semplificando l'individuazione e la diagnosi di eventuali criticità.
• Le app resistono meglio ai tempi di fermo, poiché una service mesh è in grado di reindirizzare le richieste allontanandole dai servizi non funzionanti.
• I parametri prestazionali possono suggerire modi per ottimizzare la comunicazione nell'ambiente di runtime.

Inizia a pianificare il futuro: sperimenta una service mesh su Red Hat® OpenShift® Service Mesh. Prova una modalità omogenea per connettere, gestire e osservare le applicazioni basate su microservizi con informazioni comportamentali e forme di controllo sui microservizi in rete nella service mesh. OpenShift Service Mesh è disponibile gratuitamente per Red Hat OpenShift.

Il componente Automation Mesh di Red Hat Ansible Automation Platform fornisce un framework service mesh semplice e affidabile per la scalabilità dell'automazione. Con un livello di comunicazione flessibile e multidirezionale, l'Automation Mesh migliora la capacità di un'organizzazione di operare su scala globale. Grazie a una minore sensibilità alla latenza e alle interruzioni della connessione e a funzionalità di peering native, è possibile conseguire maggiori risultati con una affidabilità superiore rispetto a qualsiasi altra piattaforma di automazione sul mercato oggi. Funzionalità di sicurezza come l'autenticazione e la crittografia TLS, e controlli di accesso aggiuntivi, fanno di Red Hat Ansible Automation Platform una soluzione su cui fare affidamento per espandere le potenzialità dell'intero patrimonio di risorse IT aziendale.