Cos'è una service mesh?

Una service mesh è un livello di infrastruttura all'interno di un'applicazione software che gestisce la comunicazione fra diversi servizi, come quelli deputati al routing del traffico, alla sicurezza e a osservabilità e resilienza, eliminando le complessità dei singoli servizi.

Per il corretto funzionamento delle applicazioni moderne, è necessario che diversi servizi comunichino fra loro. Pensa alla tua ultima visita al sito di un rivenditore online. Probabilmente hai usato la barra di ricerca del sito per sfogliare i prodotti. La ricerca costituisce un servizio. Potresti avere anche ricevuto suggerimenti per i prodotti correlati o aver aggiunto un articolo a un carrello online. Sono entrambi altri servizi. Il servizio che comunica con il database dell'inventario deve quindi interagire con la pagina web del prodotto, che a sua volta deve interagire con il tuo carrello online. Il rivenditore potrebbe anche avere un servizio che offre consigli sui prodotti in app. Questo servizio comunicherà con un database di tag di prodotti al fine di fornire consigli e dovrà comunicare anche con lo stesso database dell'inventario di cui aveva bisogno la pagina del prodotto.

Le applicazioni moderne sono spesso scomposte in una rete di servizi, ognuno dei quali svolge una funzione specifica. Per 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? È qui che ci si avvale di una service mesh, che gestisce le comunicazioni fra un servizio e l'altro, bilanciando il carico complessivo di tutti gli elementi.

Una service mesh può essere considerata un modello per l'architettura deimicroservizi. I microservizi sono un approccio architetturale alle applicazioni in cui una raccolta di servizi indipendenti comunica tramite interfacce di programmazione delle applicazioni (API) leggere. Un'architettura di microservizi è un approccio cloud native alla realizzazione di software secondo modalità che permettono l'esistenza indipendente di ogni funzione principale di un'applicazione. A differenza dello sviluppo di app in altri tipi di architetture, i singoli microservizi possono essere creati da piccoli team che hanno la possibilità di scegliere quali strumenti e quali linguaggi di codifica usare. 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. Man mano che l'architettura dei microservizi cresce, diventa più difficile da gestire: se un'app contiene decine o centinaia di servizi che interagiscono l'uno con l'altro, infatti, potrebbero verificarsi problemi di rete, monitoraggio e tracciamento, bilanciamento dei carichi di traffico, nonché di protezione della comunicazione fra microservizi. E non basta un codice personalizzato per risolvere completamente questo tipo di problemi. Una service mesh è invece una soluzione coerente, capace di gestire sfide di questo tipo senza dover modificare il codice dei singoli servizi.

Una service mesh gestisce la comunicazione fra servizi utilizzando un piano dati e un piano di controllo. 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. Tutti sanno cosa sono i proxy: 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. Ecco come funziona:

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, ciascuna istanza di servizio è associata a un "sidecar proxy", in esecuzione insieme al servizio stesso, che intercetta tutto il traffico di rete in entrata e in uscita. Ogni sidecar proxy affianca un microservizio, indirizza le richieste da e verso altri proxy e gestisce attività relative a carico di rete, bilanciamento del carico, implementazione dei criteri di sicurezza e raccolta dei dati di telemetria. Invece di comunicare direttamente l'uno con l'altro, dunque, i servizi inviano richieste tramite sidecar, che gestiscono la comunicazione fra i servizi. E tutto questo costituisce il piano dati.

Il piano di controllo invece gestisce la configurazione e la distribuzione dei criteri nel piano dati. Distribuisce inoltre le regole di routing del traffico, gestisce le certificazioni di sicurezza fra servizi, configura i componenti di applicazione dei criteri e raccoglie dati di telemetria.

Senza una service mesh, ogni microservizio deve essere codificato mediante una logica che regoli la comunicazione service to service, complicando il rilevamento di eventuali problemi di comunicazione, poiché la logica che regola la comunicazione tra i servizi è nascosta all'interno di ogni servizio.

Scopri di più sui microservizi

Istio è una piattaforma di service mesh open source che controlla il modo in cui i microservizi condividono tra loro i dati. Regola il flusso del traffico, applica i criteri e monitora le comunicazioni in un ambiente costituito da microservizi. Include API che consentono di integrare Istio in qualsiasi piattaforma di registrazione o sistema di gestione di telemetria e criteri. Inoltre puoi eseguire Istio in ambienti on premise, cloud, containerizzati e virtuali.

L'architettura di Istio si distingue in piano dati e piano di controllo. Istio usa i proxy Envoy ad alte prestazioni, che vengono distribuiti come sidecar e gestiscono il traffico per tutti i servizi della service mesh. Nel piano dati, gli sviluppatori possono aggiungere il supporto di Istio a un servizio grazie al deployment di un proxy sidecar all'interno dell'ambiente.

La service mesh di Istio include una nuova modalità ambiente per cui i sidecar proxy della service mesh non sono più necessari, ma vengono sostituiti da proxy a livello di nodo e gateway intermedi chiamati waypoint. I proxy waypoint vengono eseguiti al di fuori dei pod delle applicazioni e sono gestiti in maniera indipendente.

Scopri di più su Istio su Red Hat Developer

Ogni nuovo servizio aggiunto a un'app, o nuova istanza di un servizio esistente eseguita in un container, complica l'ambiente di comunicazione e aggiunge ulteriori probabilità di errore. Individuare il punto in cui si sono verificati dei problemi all'interno di un'architettura di microservizi complessa può essere pressoché impossibile in assenza di una service mesh.

L'uso di una service mesh presenta alcuni vantaggi, ad esempio:

• Sicurezza avanzata. Una service mesh si avvale del protocollo mutual Transport Layer Security (mTLS) per verificare che la comunicazione fra servizi sia crittografata e sicura e che i dati sensibili degli utenti siano protetti. Aggiunge quindi un ulteriore livello di protezione, senza la necessità di implementare manualmente la crittografia su ciascun servizio. Una service mesh può migliorare il controllo degli accessi basato su ruoli (RBAC) e criteri per la protezione delle API, oltre ad automatizzare la gestione dei certificati e la rotazione delle chiavi.
• Applicazione dei criteri. Le service mesh includono funzionalità di configurazione centralizzate per i criteri dei servizi come quote, limitazioni della velocità, dell'autenticazione e delle autorizzazioni. Consente inoltre di controllare le interazioni fra servizi grazie a criteri di accesso applicati a livello di proxy, per garantire la massima coerenza.
• Gestione del traffico. Una service mesh consente alle tue app di gestire il traffico di singoli servizi in base a condizioni di carico, versioni e regole impostate dall'utente. Ad esempio, se stai presentando una nuova versione del tuo servizio di inventario, puoi usare un deployment canary (ossia un deployment di prova di dimensioni ridotte) per convogliare solo il 5% del traffico verso il nuovo servizio; se tutto procede come previsto, puoi aumentare il flusso di traffico.
• Osservabilità e controllo integrità. Osservare l'interazione dei microservizi in tempo reale può essere complicato, ma con una service mesh puoi implementare strumenti integrati come il tracciamento distribuito e la raccolta di metriche per monitorare la situazioni in ogni momento. I sidecar di una service mesh raccolgono metriche (totale delle richieste, latenza e frequenza di errore) che poi inviano al piano di controllo o agli strumenti di monitoraggio.
• Tolleranza agli errori e maggiore resilienza. Una service mesh può essere utile anche quando i microservizi non funzionano come dovrebbero, perché automatizza nuovi tentativi e fallback. Se un servizio ha un problema o non risponde più, la service mesh eseguirà un numero di tentativi pari a quello definito da regole preimpostate e reindirizzerà il traffico verso servizi alternativi. In questo modo le app possono affrontare qualsiasi difficoltà senza problemi, anche se un servizio non è disponibile, e garantire un'esperienza utente fluida. Ma la service mesh raccoglie anche dati relativi all'intervallo fra tentativo di risoluzione e ripristino, per ottimizzare il tempo di attesa e non sovraccaricare il sistema con tentativi non necessari.

Con una service mesh, i team dedicati a sviluppo e operazioni possono gestire al meglio la migrazione dalle applicazioni monolitiche a quelle cloud native, ossia raccolte di applicazioni basate su microservizi, piccole, indipendenti e a basso accoppiamento. 

Durante l'implementazione di una service mesh le aziende possono trovarsi ad affrontare diverse sfide, come ad esempio:

• Complessità e integrazione con i sistemi esistenti. Può rivelarsi complicato configurare, gestire e integrare una service mesh nei sistemi esistenti, soprattutto per quelle realtà che operano in ambienti di grandi dimensioni e distribuiti su sistemi multicloud e on premise, o che semplicemente non hanno mai utilizzato una service mesh nei propri ambienti.
• Requisiti per le risorse e sovraccarico operativo. La gestione delle applicazioni tramite una service mesh crea un sovraccarico operativo perché ciascun servizio ha un proxy sidecar, che aumenta l'utilizzo di CPU e memoria. Gestire e risolvere un problema del genere, specialmente nelle distribuzioni su larga scala, può rivelarsi complesso, complicando anche scalabilità e adeguamento delle performance.
• Lacune nelle competenze. Per comprendere al meglio funzionalità, configurazione e best practice delle service mesh i team devono essere formati. I problemi dovuti al debugging possono rivelarsi gravi, specialmente se correlati a regole di routing complesse o a errori nella configurazione mTLS. Molte aziende lamentano che i team esistenti non avevano sufficiente esperienza nella tecnologia sottostante le service mesh, necessaria per un'impostazione e un utilizzo efficaci.

Un gateway API è uno strumento di gestione delle API che si situa tra un client e una raccolta di servizi back end. In questo caso, il client è l'applicazione sul dispositivo dell'utente, mentre i servizi di back end sono quelli che si trovano sui server dell'azienda. Un gateway API ti offre un modo per disaccoppiare l'interfaccia del client dall'implementazione back end. Quando un client invia una richiesta, il gateway API la suddivide in più richieste, le indirizza dove necessario, elabora delle risposte e tiene traccia di ogni operazione.

Una service mesh protegge le comunicazioni interne fra servizi, pur consentendo il traffico esterno veicolato dal gateway API e, se utilizzata in concerto con quest'ultimo, consente un'applicazione uniforme dei criteri. 

Scopri di più su Red Hat 3scale API management

L'offerta di Red Hat include prodotti integrati per la gestione di API, service mesh e piattaforme infrastrutturali che ti permettono di creare un'architettura completa per la gestione dei servizi. Red Hat® OpenShift® Service Mesh offre un metodo unificato per la connessione, la gestione e il monitoraggio delle applicazioni basate su microservizi. Offre un controllo dei microservizi connessi alla rete all'interno della service mesh con informazioni dettagliate sul loro comportamento.

OpenShift Service Mesh coniuga le capacità di Istio alle funzionalità di altri progetti open source come Kiali (console Istio) e Jaeger (tracciamento distribuito) e supporta la collaborazione con i membri più importanti della community Istio. OpenShift Service Mesh aumenta la produttività degli sviluppatori perché integra i criteri di comunicazione, senza modificare il codice applicativo o incorporare librerie specifiche del linguaggio.

Red Hat OpenShift Service Mesh viene fornito preinstallato, testato e ottimizzato per Red Hat OpenShift. È inoltre compatibile con funzionalità specifiche di OpenShift come operatori e pipeline di integrazione e distribuzione continue (CI/CD). Dispone del supporto aziendale Red Hat e riceve regolarmente aggiornamenti e patch per garantire la sicurezza e la stabilità. OpenShift Service Mesh funziona su diversi cluster Red Hat OpenShift, per offrire coerenza in ambienti di cloud ibrido o multicloud.