API Gateway fantastici e dove trovarli – Guarda il video!

Saluti iniziali

Salve a tutti e benvenuti in questo video. Oggi esploreremo il mondo di questi fantastici strumenti, gli API gateway. Vedremo cosa sono, il loro utilizzo e, infine, arriveremo a comparare alcuni dei più diffusi strumenti disponibili nella comunità open source. Ma prima permettetemi di presentarmi.

Il mio nome è Giorgia Fiscaletti: sono una Computer Science Engineer e un’amante dei gatti, come potete intuire da questa GIF, e al momento sto lavorando in Mia‑Platform come Cloud Engineer Specialist. Mia‑Platform è una delle primissime soluzioni sul mercato per creare e sviluppare applicazioni Kubernetes. È un prodotto che è stato creato dagli sviluppatori per gli sviluppatori, per aiutare le aziende nella loro fase di trasformazione digitale. In quanto Cloud Engineer Specialist lavoro nel team Operations, dove collaboriamo col reparto R&D sia per l’infrastruttura, sia per il prodotto, occupandoci della manutenzione, del monitoraggio, e altre operazioni di questo tipo.

Se avete qualsiasi dubbio o domanda non esitate a scriverli nella sezione commenti, e proveremo a rispondere il prima possibile. Inoltre, ricordate di seguirci sui social media e di iscrivervi al canale per ricevere le ultime novità.

Agenda

Torniamo all’argomento principale di questa presentazione. Cominceremo con una breve introduzione sugli API gateway: vedremo cosa sono, per cosa possono essere utilizzati, e perché sono così importanti per le nostre applicazioni. In seguito esploreremo alcune delle funzionalità più interessanti che possiamo trovare in questi strumenti. Infine, arriveremo alla parte più importante di questo video, dove analizzeremo alcuni degli strumenti più popolari presenti nel Cloud Native Computing Foundation landscape.

Introduzione sugli API gateway

Partiamo dalle basi: cos’è un API gateway? La risposta di per sé è piuttosto semplice: come suggerisce il nome stesso, un API gateway è una porta di ingresso collocata tra la nostra applicazione e il mondo esterno. Dunque, quando un client prova a fare una richiesta alla nostra applicazione, l’API gateway prende in carico la richiesta ed esegue alcuni controlli di sicurezza. Ad esempio, controlla l’autenticazione e le autorizzazioni insieme ad altre operazioni, a seconda delle funzionalità abilitate sul nostro tool. Infine, quando si è assicurato che la richiesta sia autenticata e autorizzata, e che il client abbia tutti i permessi per accedere alla risorsa, l’API gateway inoltra la chiamata, ossia inoltra in modo univoco la richiesta al corretto servizio sottostante.

Scopo del video

Quindi perché oggi parliamo di API gateway? Per rispondere a questa domanda dobbiamo tornare a qualche mese fa, quando per lavoro mi era stato chiesto di cercare nuovi API gateway per il nostro prodotto. Stavamo cercando qualcosa che fosse ancora più performante rispetto all’API gateway che stavamo già utilizzando. Era la prima volta che affrontavamo una ricerca di questo tipo, per prodotti di questo genere. Quindi, adesso che sono passati alcuni mesi, ho iniziato a pensare ad alcuni suggerimenti che sarebbero stati utili per la Giorgia di qualche mese fa per eseguire una ricerca più formale su questo argomento.

Torniamo nuovamente indietro nel tempo. Mi era stato chiesto di guardare gli strumenti disponibili all’interno del Cloud Native Computing Foundation landscape, di compararli, di comparare le funzionalità e infine di scegliere il migliore per il nostro prodotto. Quella è stata probabilmente la prima volta che ho visitato la pagina del Cloud Native Computing Foundation landscape: ho cercato la pagina e questo è stato quello che mi sono trovata di fronte. Come primo impatto è stato piuttosto scioccante, e chiaramente la mia prima reazione è stata questa.

Non appena mi sono messa gli occhiali, ho realizzato che non dovevo guardare tutti questi strumenti, ma che ero interessata solo a queste due categorie: Service Proxies e API gateway. Se però guardate meglio, potete notare che sono comunque 38 tool, li ho contati, e in azienda non sempre si ha a disposizione il tempo per fare una ricerca approfondita su un così alto numero di strumenti. È necessario un primo filtro, una selezione preliminare.

Nel video di oggi spero di lasciarvi con alcuni spunti, alcuni suggerimenti nel caso vi doveste trovare in una situazione simile, nella quale dovete scegliere un nuovo API gateway per la vostra applicazione, o se dovete costruirne una nuova e dovete selezionare il primo API gateway per il vostro prodotto.

Perché gli API gateway sono importanti?

Ma perché gli API gateway sono così importanti? Prima di tutto sono sicuramente uno degli elementi cardine della nostra applicazione, in quanto sono collocati tra i nostri servizi e il mondo esterno, e aiutano a gestire il traffico che arriva dai client esterni.

Inoltre aiutano a ottimizzare la performance, in quanto un API gateway performante è in grado di ridurre la latenza della richiesta e, di conseguenza, di ridurre la latenza percepita dall’utente finale. Aiutano anche a garantire l’affidabilità dei nostri servizi grazie a dei set di funzionalità: per fare un esempio che approfondiremo in seguito, il rate limit service.

Ancora, gli API gateway aiutano la scalabilità della nostra applicazione: in quanto sono responsabili di mappare in modo trasparente la richiesta al corretto servizio sottostante, in modo che il client esterno sia completamente ignaro del numero dei servizi con cui l’API gateway comunica.

Infine, ultimo ma non meno importante, aiutano a migliorare la sicurezza, grazie ai dei controlli che vengono eseguiti non appena la richiesta viene ricevuta dall’API gateway. Controlli che possono essere, ad esempio, sull’autorizzazione grazie ad un servizio di autorizzazione esterno, oppure controlli di autenticazione.

Le principali funzionalità di un API gateway

Scendiamo ora più in profondità ed esploriamo alcune delle funzionalità più interessanti che si possono trovare in questi tool. Solo una piccola precisazione prima di proseguire. Le funzionalità dipendono strettamente dal nostro scenario, dal nostro caso d’uso. Presenteremo le funzionalità che sono essenziali per il nostro caso, ma per altre situazioni possono essere necessarie funzionalità diverse, meno funzionalità o più funzionalità. Questo va tenuto a mente.

Mappatura e riscrittura delle URL

Cominciamo da quella più semplice, ossia la mappatura delle URL. È essenziale che un API gateway sia in grado di mappare la URL della richiesta, in modo che riceva in modo univoco il corretto servizio sottostante. Allo stesso tempo, l’API gateway deve anche essere in grado di riscrivere la URL che riceve. Questo perché non sempre vogliamo esporre la rotta del nostro servizio sottostante.

Questo tipo di funzionalità genera un layer di sicurezza addizionale che protegge i nostri servizi da potenziali attacchi. Quindi, quello che un API gateway fa non appena riceve una richiesta da un client esterno è mappare la URL del corretto servizio sottostante, e la riscrive con un altro percorso che è accettato e compatibile con le rotte esposte dal servizio sottostante.

Rate limit

Una funzionalità che abbiamo già anticipato è il rate limit. Un servizio di rate limit si occupa di limitare il numero delle richieste che possono essere eseguite in un’unità di tempo sulla nostra applicazione. Per esempio, può limitare il numero di volte che un singolo utente può ricaricare la pagina di login. Questo aiuta la nostra applicazione ad assicurare la disponibilità dei nostri servizi e anche ad evitare potenziali attacchi automatizzati (per esempio, gli attacchi DoS ‑ Denial of Service).

Gestione delle API key

Addentriamoci ora nell’ambito della sicurezza parlando della gestione delle API Key. Un API gateway deve essere in grado di gestire la risoluzione delle chiavi segrete estraendole da un header o da un cookie, a seconda di come è sviluppata la nostra applicazione, e risolverle in modo da applicarle alle rotte secretate, e verificare l’informazione corretta.

Servizio di autorizzazione

Arriviamo ora a una delle più importanti funzionalità di un API gateway, cioè la capacità di comunicare con un servizio di autorizzazione esterno. Questa funzionalità è essenziale per verificare che i permessi dei client e per essere sicuri che l’agente esterno sia autorizzato ad eseguire quelle richieste e ad accedere a quella specifica risorsa.

Cache HTTP

Vediamo ora una funzionalità più avanzata, ossia la cache HTTP. La cache HTTP migliora le performance della nostra applicazione, in quanto permette di salvare alcune informazioni dalla richiesta e riutilizzarle in caso una richiesta simile sia ripetuta dopo poco tempo.

Service Proxy vs API gateway

Ora che abbiamo analizzato alcune delle funzionalità fondamentali degli API gateway, possiamo arrivare alla parte più importante di questo video, nella quale confronteremo le funzionalità e le loro implementazioni di alcuni dei più famosi strumenti presenti nel Cloud Native Computing Foundation landscape. Cominciamo elencando le differenze tra le due principali categorie che andremo ad esplorare, cioè i Service Proxy e gli API gateway.

Service Proxy

Per definizione, i Service Proxy non sono API gateway: sono strumenti più generici che possono essere implementati in molti modi diversi (per esempio, per costruire un security proxy, un canary o molti altri strumenti). Quindi, un API gateway è solo una delle tante implementazioni di un Service Proxy. Questo permette di costruire API gateway da zero, lasciando molte opzioni che possono non essere essenziali per un API gateway, ma che possono essere un’evoluzione interessante del nostro tool.

Generalmente sono molto estensibili, ma questo grado di estensibilità spesso implica una maggiore complessità sottostante, che si traduce in una curva di apprendimento più lenta. Quindi, avendo a che fare con i Service Proxy, secondo la mia esperienza sarà sicuramente necessario più tempo per studiare la documentazione, lo strumento, e infine per l’implementazione.

Alcuni esempi di Service Proxy disponibili all’interno della Cloud Native Computing Foundation sono: Envoy, Traefik, Contour e Nginx. 

API gateway

Dall’altra parte abbiamo gli API gateway. Gli API gateway sono strumenti che sono stati costruiti con l’unico scopo di lavorare come API gateway, quindi hanno un’implementazione mirata.

Di conseguenza, sono meno complessi e generalmente meno estensibili, ma questo non è necessariamente un difetto. Significa solo che gli API gateway hanno una serie di limiti ben definiti, entro i quali ci si può muovere liberamente rimanendo sicuri che il risultato finale funzionerà perfettamente come un API gateway, ed entro i quali saremo sicuri di avere tutte le funzionalità essenziali per il nostro strumento finale.

Alcuni esempi di API gateway disponibili all’interno della Cloud Native Computing Foundation sono: Emissary Ingress, Gloo Edge, Kong e Tyk.

Confronto tra gli strumenti

Ho selezionato quattro strumenti tra tutti quelli disponibili: due Service Proxy e due API gateway. Cominciamo il confronto analizzando Envoy.

Service Proxy ‑ Envoy

Envoy è un Service Proxy ad alte prestazioni sviluppato in C++, ed è lo strumento che mi piace definire “il boss finale dei Service Proxy”, dal momento che molti altri strumenti della Cloud Native Computing Foundation sono basati e costruiti su di esso.

Innanzitutto è un servizio esterno al processo, ossia è completamente agnostico rispetto all’ambiente in cui è inserito: come conseguenza, è completamente indipendente da ogni altra tecnologia che si trova nella nostra applicazione.

Fornisce supporto sia per gRPC, sia per HTTP/2, fornendo quindi molte opzioni per implementare la comunicazione tra l’API gateway e i servizi sottostanti.

Inoltre è estremamente estensibile grazie ai filtri, che sono i blocchi di costruzione della configurazione di Envoy, e fornisce tutte le funzionalità che possano essere necessarie. Grazie a questa estensibilità possono esserci molte funzionalità che non sono essenziali per il nostro API gateway, ma che possono essere utili per interessanti evoluzioni future del nostro strumento.

Service Proxy ‑ Traefik

Vediamo il secondo strumento che analizzeremo oggi: Traefik, un altro Service Proxy che personalmente sceglierei soltanto per il suo logo. Traefik è un HTTP reverse proxy e load balancer, ed è anche lo strumento famoso per il suo stack tecnologico. È in grado di integrarsi facilmente con altri componenti della nostra applicazione, come, ad esempio: Docker, containerd, Kubernetes e così via. 

Fornisce anche un service discovery automatico, ossia si può scegliere di scrivere manualmente tutte le rotte ai nostri servizi sottostanti, oppure possiamo lasciare che sia Traefik a farlo in modo automatico.

Inoltre, possiede un HTTPS automatico, grazie alla sua integrazione con Let’s Encrypt. Naturalmente si può decidere di implementare l’HTTPS con qualsiasi altro servizio di terze parti, ma avere Let’s Encrypt già incluso nel pacchetto è sicuramente utile.

Infine, anche se gli sviluppatori sono molto gelosi dei loro terminali e IDE, vi assicuro che avere una UI pulita è un grande vantaggio quando si ha a che fare con API gateway e route manager.

API gateway ‑ Emissary Ingress

Passiamo ora alla seconda categoria di strumenti che analizzeremo oggi, ossia gli API gateway, cominciando con il primo che ho selezionato: Emissary Ingress. 

Emissary ingress è un control plane specializzato per Envoy Proxy. Ciò significa che è costruito su Envoy Proxy e fornisce molte delle caratteristiche stabili disponibili sul service proxy di Envoy. Essere su Envoy è anche un vantaggio, perché Emissary Ingress fornisce un livello di semplificazione per scrivere le configurazioni di Envoy. È anche Kubernetes native, cosa che fornisce tutti i vantaggi di lavorare in un ambiente Kubernetes (ad esempio, la possibilità di scrivere la configurazione di Envoy tramite custom resource definitions).

Infine, ha un’architettura stateless, ossia non è necessario costruirlo come un singolo elemento centralizzato che deve garantire la disponibilità e la sicurezza del sistema, ma può essere distribuito su più istanze.

API gateway ‑ Gloo Edge

Vediamo ora l’ultimo strumento di questa introduzione, ossia Gloo Edge, un altro API gateway e un altro tool che personalmente sceglierei solo per la sua icona. Come loro stessi si definiscono, Gloo Edge è un API gateway Kubernetes‑native di nuova generazione.

Anche questo è costruito su Envoy, cosa che porta tutti i vantaggi di esporre le API di Envoy e quindi usare molte delle funzionalità stabili di Envoy. Anche Gloo Edge è Kubernetes native, quindi anche in questo caso è possibile scrivere le configurazioni usando le custom resource definition (CRD) di Kubernetes.

Inoltre fornisce supporto per applicazioni ibride, nel senso che può essere integrato facilmente in applicazioni che usano diverse tecnologie: orchestrazione, vitrualizzazione, containerizzazione, e così via.

Infine, fornisce un discovery service completamente automatizzato, simile a quello di Traefik. Questo significa che si può scegliere se scrivere manualmente tutte le rotte ai servizi sottostanti, oppure si può lasciare che Gloo lo faccia in automatico.

Confronto tra le funzionalità

Ora che abbiamo introdotto questi due Service Proxy e questi due API gateway, possiamo finalmente confrontare come le funzionalità presentate in precedenza sono implementate in questi quattro strumenti.

Mappatura e riscrittura delle URL

In Envoy la mappatura e la riscrittura sono configurate all’interno della configurazione della rotta, che è una proprietà tipica dell’HTTP connection manager. La configurazione della rotta fornisce una lista di corrispondenze dove è possibile specificare l’URL della richiesta, il corrispondente servizio sottostante ed eventualmente una riscrittura della URL, per renderla compatibile con quelle accettate dal servizio sottostante

In Traefik la mappatura è configurata all’interno del router, cioè l’elemento responsabile di indirizzare le richieste ai servizi sottostanti. Dall’altra parte, le riscritture sono definite all’interno di un middleware dedicato.

In Emissary sia la mappatura sia la riscrittura hanno una custom resource definition dedicata, chiamata Mapping, all’interno della quale si può specificare una lista di corrispondenze tra l’URL della richiesta e il corrispondente servizio sottostante, e l’eventuale riscrittura. Si può fare una cosa molto simile in Gloo, grazie al servizio virtuale di custom resource definition, dove, anche in questo caso, si può specificare una lista di corrispondenze tra le URL, il servizio corrispondente e l’eventuale riscrittura.

Rate limit

Envoy ha la configurazione di rate limiting più completa, in quanto fornisce filtri sia per il global rate, sia per il local rate. Il global rate limit filter comunica con una sorgente esterna tramite gRPC, quindi richiede la configurazione di un servizio client esterno, la configurazione dei parametri di rate limit, che è la quantità di richieste, l’unità di tempo, e la chiave su cui il rate limit deve essere eseguito. Ad esempio, l’indirizzo IP del client esterno si può trovare all’interno della configurazione del servizio di rate limit esterno. Dall’altra parte, il local rate è interno e fornisce una configurazione per proteggere i servizi di rate limit esterni da possibili picchi di traffico.

In Traefik c’è un altro middleware dedicato al rate limit, nel quale possiamo specificare tutti i parametri che abbiamo già menzionato, ossia il numero di richieste, l’unità di tempo, la chiave sulla quale deve essere applicato il rate limit e le interruzioni per i picchi di traffico.

Emissary e Gloo hanno una configurazione simile tra loro. In Emissary c’è una custom resource definition, chiamata Rate limit service, che espone le API di Envoy per il global rate limit service, nel quale è possibile specificare un rate limit service esterno che comunica con l’API gateway tramite gRPC. In Gloo è possibile fare lo stesso tramite il virtual service custom resource definition, il quale a sua volta espone allo stesso modo le API di Envoy per il global rate limit.

Gestione delle API key

Riguardo alla gestione delle API key, la maggior parte degli strumenti che ho potuto analizzare non forniscono un supporto esplicito, ma è possibile implementarla combinando funzionalità diverse attraverso due passaggi principali.

Il primo può essere implementato attraverso la manipolazione degli header, dal momento che è sufficiente estrarre il secret dall’header o da un cookie, a seconda di come è strutturata la nostra applicazione.

Il secondo passaggio è la vera risoluzione del secret, e può essere implementato con un alcune logiche nelle quali è sufficiente estrarre le informazioni dal secret e applicare i permessi sulle rotte secretate.

Tra questi quattro strumenti Gloo è l’unico che fornisce un API per gestire le API key, ossia la Secret custom resource definition. Grazie a questa CRD siamo in grado di definire i secrets e applicarli alle rotte secretate, e in automatico Gloo si occuperà di risolverli e gestire i permessi.

Servizio di autorizzazione

Dal momento che, come abbiamo già anticipato, il servizio di autorizzazione è una funzionalità essenziale, è implementato in modo simile in tutti gli strumenti analizzati. L’API gateway deve comunicare con un servizio di autorizzazione esterno e deve essere in grado di scambiare informazioni con questo servizio esterno.

In Envoy è implementato con il filtro ExtAuthz, in Traefik con il middleware ForwardAuth, in Emissary con il plugin AuthService, e in Gloo con il custom auth server. Come si può notare, hanno tutti configurazioni simili.

Cache HTTP

Infine c’è la cache HTTP. Questa funzionalità non è ancora stata implementata in molti degli strumenti che abbiamo analizzato.

In Envoy c’è un filtro cache, ma è ancora in fase di costruzione. Se guardiamo nella documentazione c’è un avvertimento importante che dice: “Non usare in ambienti di produzione” – e personalmente mi fido.

In Traefik è una funzionalità enterprise, quindi non la prenderemo in considerazione.

Infine in Emissary e Gloo, siccome sono entrambi control plane per Envoy, la cache HTTP non è ancora supportata, dal momento che non è una una funzionalità stabile nello stesso Envoy Proxy.

Questo conclude il confronto tra questi quattro famosi strumenti del Cloud Native Computing Foundation landscape. 

Riepilogo

A questo punto facciamo un riepilogo di quanto abbiamo visto oggi in questo video.

Abbiamo esplorato gli API gateway, che sono alcuni dei più importanti strumenti per le nostre applicazioni in quanto sono collocati tra i nostri servizi e il mondo esterno, e aiutano a gestire il traffico che arriva da client esterni in modo sicuro.

Quindi abbiamo esplorato alcune delle loro funzionalità e siamo arrivati a confrontare alcuni degli strumenti più famosi presenti all’interno del Cloud Native Computing Foundation landscape. Da un lato abbiamo analizzato i Service Proxy, che sono strumenti generici e molto estensibili e permettono di costruire da zero gli API gateway. Dall’altro lato, abbiamo visto gli API gateway, che sono strumenti con un’implementazione mirata che funziona alla perfezione all’interno di un ben definito set di confini.

Qual è la scelta migliore per la vostra applicazione?

Torniamo quindi alla questione principale: qual è la scelta migliore per la vostra applicazione? La risposta dipende strettamente dal vostro scenario e dalle esigenze della vostra applicazione.

Se avete il tempo di esplorare la documentazione, di studiare come costruire un API gateway da zero, e se volete avere a disposizione diverse opzioni per possibili evoluzioni del vostro strumento, probabilmente un Service Proxy è quello che fa per voi.

D’altra parte, se non avete molto tempo e volete uno strumento che funzioni correttamente con l’unico scopo di fare da API gateway, e che offra tutte le funzionalità essenziali di API gateway, probabilmente vi conviene sceglierne uno dalla categoria degli API gateway.

La scelta sta a voi.

Conclusioni

Questo conclude il video di oggi. Se avete domande o dubbi sentitevi liberi di aggiungerli nella sezione dei commenti, e vi risponderemo quanto prima. Inoltre, scannerizzate questo QR code se volete lasciare un feedback.

Questo è tutto per oggi. Grazie per averci seguito, ci vediamo al prossimo video!