I gateway API e le service mesh hanno nel tempo assunto una notevole importanza per la gestione di complessi processi di comunicazione legati alle applicazioni all’interno di un sistema distribuito. Entrambi, a loro modo, giocano un ruolo fondamentale nel supportare applicazioni ad alte prestazioni che siano il più scalabili possibile. Per esempio, architetti e sviluppatori li usano per:
- semplificare le comunicazioni tra risorse software diverse;
- esporre i dati richiesti per monitorare e osservare le transazioni all’interno delle applicazioni;
- evitare di codificare la logica basata sulla comunicazione direttamente in un singolo servizio o applicazione.
Cosa ha quindi bisogno di implementare un team di sviluppo, un gateway API o una service mesh?
In molti casi – in particolare nello sviluppo di applicazioni a livello aziendale – si ha bisogno di entrambi ma sviluppatori e architetti è importante che capiscano le differenze tra questi due approcci alla comunicazione software come anche le loro somiglianze. Solo così i team possono essere in grado di prendere decisioni affidabili ed efficaci sul ruolo che questi due diversi approcci di comunicazione potrebbero giocare nel loro sistema applicativo valutando se sarebbero in grado di gestire efficacemente un gateway API o una service mesh.
Rivediamo le basi di questi approcci di comunicazione applicativa per poi esaminare alcune delle principali e più significative differenze per comprendere quando una service mesh può essere più o meno adeguata da implementare rispetto a un gateway API.
Cos’è un gateway API?
Un gateway API è un servizio che accetta richieste API in entrata dai client, le indirizza al servizio applicativo appropriato, ne elabora la risposta e la inoltra al client richiedente.
Per capire come funziona un gateway API, consideriamo un’applicazione bancaria che contiene una collezione di vari microservizi. Un microservizio potrebbe cercare i dati del conto bancario e un altro formattare i dati del conto per visualizzarli su una pagina web. La richiesta di un utente di visualizzare i dettagli del proprio conto bancario attiverà le chiamate a entrambi questi microservizi che necessiteranno di un intermediario in grado di gestire la richiesta correttamente e nel giusto ordine.
In questo caso, il gateway API diventa il fulcro centrale che accetta le richieste, le inoltra ai due microservizi e rimanda le informazioni all’applicazione in modo che possa mostrare i risultati all’utente.
Tecnicamente, un gateway API non è necessario: gli sviluppatori potrebbero semplicemente incorporare del codice all’interno dell’applicazione che indica come gestire le richieste (cioè dove inviare le richieste e come formattare i dati restituiti). Questo approccio richiederebbe però una quantità non indifferente di lavoro di sviluppo extra e porterebbe ad un aumento dei rischi per la sicurezza, perché qualsiasi errore di codifica potrebbe esporre un’API ad accessi non autorizzati e a potenziali abusi.
Gestendo le richieste API da sistemi esterni attraverso un gateway centrale al di fuori dell’applicazione, gli sviluppatori possono creare un’applicazione più sicura e allo stesso tempo semplificare la gestione della comunicazione. I gateway API rendono anche più facile monitorare le richieste API, bilanciare le richieste su più istanze di un microservizio e spostare i microservizi da un endpoint all’altro senza interrompere il modo in cui le richieste API vengono gestite.
Cos’è una service mesh?
Una service mesh è un componente dell’infrastruttura IT che gestisce le comunicazioni tra microservizi e componenti interni e li aiuta a condividere i dati che alimentano le funzionalità dell’applicazione. Per esempio, nell’applicazione bancaria descritta sopra, il microservizio che recupera i dati del conto potrebbe aver bisogno di emettere un’altra richiesta a un microservizio che convalida le identità degli utenti. Il service mesh aiuterebbe questi due microservizi a comunicare tra loro e a fornire in modo efficiente i giusti risultati.
Come i gateway API, la service mesh non è strettamente necessaria: si potrebbe incorporare il codice che supervisiona queste transazioni in ogni microservizio. Si tratterebbe però di un lavoro di codifica difficile, soprattutto perché gli indirizzi di rete assegnati ai singoli microservizi tendono a cambiare frequentemente.
Per stare al passo, gli sviluppatori dovrebbero aggiornare il codice dell’applicazione ogni volta che un microservizio cambia o implementare meccanismi basati sul codice che aiutino i microservizi ad eseguire l’auto-rilevamento automatico e a tenere costantemente traccia dei cambiamenti degli indirizzi di rete, o di qualsiasi altra modifica delle qualità identificative.
Una service mesh risolve questo problema tenendo automaticamente traccia della posizione e dell’identificazione di ogni microservizio e spostando i dati tra di loro. Se un certo microservizio, che chiameremo Servizio A, vuole condividere dati con un altro microservizio, il Servizio B, il primo semplicemente incanala quei dati all’implementazione della service mesh, che poi inoltrerà i dati al Servizio B e la service mesh alla fine otterrà una risposta dal Servizio B che restituirà al Servizio A.
Service mesh vs. gateway API: 5 differenze chiave
Una volta definiti sia i gateway API che le service mesh, diamo un’occhiata alle principali differenze tra questi due approcci alle comunicazioni tra componenti applicativi:
Comunicazione esterna vs. interna
I gateway API gestiscono le richieste che hanno origine esternamente, come la richiesta di un utente di un’applicazione per visualizzare una certa pagina mentre le service mesh gestiscono le richieste che i microservizi fanno ad altri microservizi all’interno di un’applicazione. In termini tecnici, i gateway API supervisionano la comunicazione client-to-server, mentre le service mesh si occupano della comunicazione service-to-service.
Posizionamento all’interno di un’architettura
I gateway API e le service mesh operano all’interno di diversi livelli di un’architettura software, i primi sono tipicamente componenti dell’infrastruttura rivolti al pubblico, tra il bordo di una rete e il back end di un’applicazione – inclusa la service mesh. Come componenti esterni e i sistemi, mandano richieste all’applicazione che sono ricevute e validate dal gateway API. La service mesh probabilmente aiuterà a portare le richieste che un gateway API approva e passa al back end. Tuttavia, tutto inizia dal gateway API.
Distribuzione e gestione
Rispetto alla service mesh, i gateway API sono spesso più semplici da gestire per lo sviluppatore medio che ha bisogno di distribuire un gateway all’interno del suo stack software solo una volta, e sono anche più facili da monitorare con un approccio centralizzato.
Una service mesh deve invece integrarsi e adattarsi ad ogni servizio applicativo che aiuta a gestire. Il metodo di implementazione più comune è quello di eseguire le service mesh in un contenitore proxy – spesso chiamato sidecar – che opera a fianco di ogni istanza di un microservizio containerizzato e astrae la logica centrata sulla comunicazione da quel microservizio. In questo modo, una service mesh introduce una grande quantità di elementi mobili e una complessità esponenziale per l’implementazione e il monitoraggio.
Monitoraggio e osservabilità
Le metriche del gateway API forniscono il massimo valore quando si traccia la salute generale di un’applicazione, come ad esempio quanto tempo ci vuole per rispondere a specifiche richieste API o quanto le prestazioni sono influenzate dal traffico elevato. Le metriche del gateway API possono aiutare a identificare i problemi con API specifiche, in particolare quando questi problemi non possono essere attribuiti a un’interruzione della rete, a un crash dell’applicazione o a qualche altra causa comune.
Diversamente, le metriche delle service mesh aiutano i team a identificare i problemi relativi ai singoli microservizi e alle componenti che abitano il back end di un’applicazione, piuttosto che quelli dell’applicazione nel suo complesso. Il monitoraggio della service mesh è utile per individuare l’origine di alcuni problemi di performance dell’applicazione ma probabilmente non fornirà alcuna indicazione dell’impatto di quegli specifici problemi da un punto di vista esterno e generale, ad esempio stimando come la presenza di criticità sul tempo di risposta di uno specifico microservizio impatta sulla user experience dell’utente finale.
Strumenti e supporto
È meno probabile che gli strumenti o le piattaforme dei gateway API siano open source ma la maggior parte dei gateway API funziona con qualsiasi tipo di applicazione o architettura.
Al contrario, ci sono molte opzioni open source per il supporto di service mesh, come Istio, Linkerd e Envoy ma alcuni strumenti di service mesh sono progettati per funzionare solo in determinati tipi di ambienti: AWS App Mesh funziona solo all’interno del cloud AWS, per esempio, e altre opzioni di service mesh, come Linkerd, sono costruite per supportare i microservizi che vengono distribuiti tramite Kubernetes.
Di quale avete bisogno?
La maggior parte delle applicazioni può trarre vantaggio dall’utilizzo contemporaneo di gateway API e service mesh. Mentre un gateway API può semplificare il modo in cui l’applicazione gestisce le richieste esterne, la service mesh gioca un ruolo cruciale nell’ottimizzare la comunicazione interna. Un gateway API può inoltrare una richiesta a uno specifico microservizio, ma quel microservizio ha bisogno di comunicare con un altro microservizio, ed è qui che entra in gioco la service mesh.
È anche possibile utilizzare un gateway API senza una service mesh, e viceversa ma è sempre più raro che lo si faccia perché, se si vuole massimizzare l’agilità di una applicazione e minimizzare lo sforzo degli sviluppatori nella gestione delle comunicazioni, è necessario usarli entrambi.
