Cos'è un gateway federato?

Nei sistemi centralizzati, un singolo gateway (a sua volta connesso a più API e responsabile della loro gestione) gestisce tutte le query dei client. La federazione dei gateway consente invece a un'organizzazione di utilizzare una rete distribuita di API gateway, ciascuno responsabile del proprio insieme distinto di servizi.

In un sistema gateway federato, i team possono aggiungere servizi secondo necessità senza influire sull'intero sistema, rendendo più efficienti l'utilizzo delle risorse e la gestione del traffico. Anche i singoli reparti possono utilizzare protocolli diversi per gestire i rispettivi gateway. Il framework offre ai team la libertà di gestire le proprie API, migliorando la flessibilità, la resilienza operativa e molto altro.

Questo approccio aiuta anche a evitare i rallentamenti del traffico e altri problemi associati agli API gateway e può offrire benefici implementando le funzioni del gateway più vicine agli utenti finali. Le strategie di federazione dei gateway possono essere applicate a vari stili architettonici e protocolli API, tra cui REST, gRPC e SOAP, ognuno dei quali offre benefici e svantaggi.

Dal punto di vista IT, un gateway federato è utile perché consente ai team DevOps di sviluppare e implementare le proprie API, mantenendo l'aderenza alle policy di governance, sicurezza e gestione della piattaforma API a livello aziendale. I team possono lavorare rapidamente e indipendentemente per completare i progetti nel proprio dominio (facilitando l'innovazione e accelerando il time to market) preservando gli standard a livello di organizzazione e trovando un equilibrio tra autonomia del team e supervisione centralizzata.

La federazione GraphQL è costituita da un concetto e un approccio architettonico alternativi, utilizzati per creare un'API GraphQL unificata. È basata su GraphQL, un linguaggio di query in grado di indirizzare con precisione le risorse di più servizi con una singola query API.

La federazione GraphQL collega diversi servizi (noti come sottografi), ciascuno con il proprio schema che definisce i dati che gestisce, a uno schema unificato noto come supergrafo. Un unico gateway espone questo schema supergrafo alle applicazioni client, unisce più servizi e campi sottostanti e indirizza tutte le query API. Al contrario, la federazione dei gateway collega più API gateway attraverso un piano di controllo centrale, dove ogni API gateway risponde alle proprie query.

La federazione è un approccio generale alla gestione del sistema che collega componenti autonomi attraverso un piano di controllo comune.

In un sistema gateway centralizzato, tutte le richieste dei client passano attraverso un unico gateway, che gestisce funzioni quali routing, autenticazione, autorizzazione e monitoraggio. A differenza delle architetture federate, queste responsabilità non vengono distribuite tra più istanze.

Questo approccio può semplificare il logging, la gestione del traffico, l'applicazione della sicurezza e altre attività, poiché ognuno di questi processi fluisce attraverso il gateway. Le organizzazioni possono anche avviare le implementazioni da un unico punto, eliminando la necessità di aggiornamenti delle versioni su più gateway e servizi.

Tuttavia, le aziende con framework centralizzati potrebbero avere maggiori probabilità di incontrare ostacoli, soprattutto quando scalano le loro operazioni. Essendo l'unico punto di passaggio del sistema, il gateway può facilmente congestionarsi. Inoltre, presenta un single point of failure; se si verifica un errore, questo si ripercuote sull'intero sistema.

A differenza dei sistemi centralizzati, le architetture di gateway federate sono costituite da più gateway, ciascuno responsabile di un set distinto di servizi e API associate. I gateway funzionano in modo indipendente, sebbene ciascuno di essi sia gestito da un piano di controllo centrale.

Rispetto ai framework centralizzati, i sistemi federati promuovono flessibilità e autonomia, offrendo ai team di sviluppo un maggiore livello di controllo sui rispettivi domini. Questo layout decentralizzato rende inoltre i sistemi federati più resilienti alle interruzioni e ai guasti del sistema.

Tuttavia, i sistemi federati sono più complessi dal punto di vista operativo e possono introdurre disparità di governance e problemi di comunicazione tra i team. Le implementazioni possono richiedere più tempo e la manutenzione può essere più costosa, perché ogni gateway deve essere gestito e aggiornato separatamente.

Esistono diversi motivi per cui un'azienda potrebbe scegliere un sistema di gateway federato.

Per prima cosa, la federazione dei gateway è comunemente usata nei casi di fusioni e acquisizioni, in cui un'azienda eredita diversi stack e sistemi di API management dalle società che acquisisce. Anziché gestire individualmente più architetture separate, ognuna con protocolli di sicurezza, standard tecnici e strutture di governance distinti, o di cercare di aggiornare i sistemi acquisiti con i sistemi aziendali esistenti, le aziende si rivolgono alla federazione dei gateway. Questo approccio consente alle organizzazioni di integrare gli API gateway esistenti e i sistemi sottostanti nella struttura sovrastante, fornita dal piano di controllo centrale.

Allo stesso modo, più gateway vengono spesso utilizzati in ambienti con molti microservizi costruiti da team diversi e distribuiti in diverse impostazioni. Un'azienda potrebbe anche scegliere un sistema federato per ottenere benefici a livello di prestazioni.

Ad esempio, consideriamo una società di logistica con diversi uffici in tutto il mondo, ognuno dei quali serve una particolare regione. Posizionando gateway, server, servizi e altre risorse più vicini ai client che vi accedono, l'azienda può ottimizzare la latenza e i relativi fattori delle prestazioni.

Nella federazione dei gateway, il piano di controllo centrale si occupa della gestione, dell monitoraggio e della governance, ma è generalmente inaccessibile ai client. Gli utenti delle API interagiscono direttamente con i gateway che compongono il sistema federato (interrogando l'endpoint responsabile dei servizi pertinenti), ma non interrogano il piano di controllo stesso. Il piano di controllo riceve metadati e log solo dopo che è avvenuta una chiamata API.

Sebbene questo approccio possa introdurre una certa complessità operativa, promuove anche l'indipendenza. Ad esempio, aiuta a consentire ai team della piattaforma di configurare i propri gateway e servizi per soddisfare le proprie esigenze specifiche, scegliere i propri protocolli e distribuire le implementazioni in modo autonomo. Le architetture federate sono anche più resilienti alle configurazioni errate e alle violazioni di sicurezza, perché gli errori sono isolati dal gateway da cui hanno avuto origine e non è probabile che si diffondano ad altri gateway della rete.

Nella federazione GraphQL, invece, gli schemi di più servizi indipendenti (sottografi) vengono combinati in un unico schema supergrafo unificato. Un singolo gateway, o router, presenta un unico punto di ingresso per le query client, offrendo un'esperienza API unificata.  

Il router suddivide in modo intelligente le query in richieste secondarie più piccole, recuperando le informazioni rilevanti da più sottografi e compilandole in una risposta coesa per i client.

Immaginiamo una piattaforma sanitaria con servizi separati per:

• Pazienti: gestione dei dati dei pazienti, delle informazioni di contatto e delle cartelle cliniche
  
  
• Appuntamenti: pianificazione e monitoraggio delle prossime visite
  
  
• Fatturazione: gestione delle fatture e delle notifiche di fatturazione

Anziché interrogare ciascuno di questi endpoint con una chiamata API separata, la federazione GraphQL presenta un'interfaccia unificata che consente ai clienti, in questo caso un'app o una dashboard che serve medici o pazienti, di accedere all'anamnesi di un paziente, identificare il suo prossimo appuntamento e determinare il suo saldo in sospeso con una singola chiamata API, anziché tramite tre richieste separate.

La federazione GraphQL fornisce un modo per creare un'API GraphQL scalabile in un ambiente distribuito. Il framework consente lo sviluppo e la distribuzione indipendenti dei servizi, offrendo al contempo un frontend unificato per le query dei clienti. Tuttavia, la federazione GraphQL può essere soggetta a problemi di costi e complessità, vulnerabilità di sicurezza, congestione e ridondanze.

Introdotta nel 2019, la federazione Apollo è un'implementazione della federazione GraphQL che utilizza direttive speciali (come @key o @extends) all'interno del linguaggio di definizione dello schema GraphQL, al fine di definire le relazioni tra diversi tipi di sottografi.

Sebbene Apollo sia una soluzione diffusa, non è l'unica opzione di federazione GraphQL disponibile. Le alternative più comuni includono Hive, Mesh, Indigo e WunderGraph Cosmo, che offrono diversi livelli di personalizzazione. 

Secondo la società di ricerca Gartner, mentre nel 2024 meno del 5% delle aziende disponeva di sistemi GraphQL federati, si prevede che tale cifra raggiunga il 30% entro il 2027. I principali provider di cloud come Amazon Web Services (AWS) e Microsoft Azure, oltre a repository di codice come GitHub, supportano le API GraphQL anche con strumenti di observability e convalida integrati.

La federazione GraphQL presenta diversi vantaggi distinti, soprattutto nella sua capacità di semplificare l'accesso alle API per i client. I team possono mantenere un certo grado di indipendenza implementando, gestendo e scalando i propri sottografi.

Tuttavia, come framework centralizzato, la federazione GraphQL è più vulnerabile a lacune di sicurezza, problemi di congestione e inefficienze delle prestazioni. È inoltre vincolato agli schemi GraphQL, mentre la federazione dell'API gateway è compatibile con più protocolli.

Nello sviluppo di una strategia API, le organizzazioni decidono se adottare un framework API GraphQL o utilizzare un altro stile di architettura, come REST, per le loro API.

In definitiva, le organizzazioni potrebbero scegliere di incorporare sia la federazione GraphQL che altri stili architettonici nei loro sistemi, ognuno responsabile della gestione di funzioni diverse. In una configurazione comune, un'azienda utilizza GraphQL internamente (con rigidi guardrail per mitigare i problemi di sicurezza, costi o complessità) e utilizza uno stile di architettura diverso come REST (che può fornire un livello di controllo più profondo e un'adozione più semplice) per le API esterne. In questo scenario, un API gateway federato potrebbe essere utilizzato anche per unificare questi stili architettonici eterogenei attraverso il piano di controllo centrale.

Nelle configurazioni standard dell'API gateway, un unico gateway gestisce tutto il traffico utente, il routing e l'analytics. Sebbene questo approccio aiuti a semplificare le configurazioni, può portare rapidamente a rallentamenti negli ambienti più complessi.

I gateway federati si basano su una serie di API gateway, non su uno singolo. Ogni gateway viene utilizzato per gestire le chiamate API a un set specifico di servizi e i gateway sono connessi al piano di controllo, che si occupa della gestione e della governance.

I service mesh, invece, sono considerati configurazioni est-ovest perché gestiscono le connessioni tra microservizi ma non si interfacciano con gli utenti. I mesh di servizio facilitano principalmente la comunicazione e l'observability all'interno di un singolo ambiente o cluster. Tuttavia, varianti note come mesh hybrid cloud sono ottimizzate per eseguire funzioni come crittografia, bilanciamento del carico e autenticazione su più cluster e ambienti (inclusi ambienti multicloud, hybrid cloud e on-premise). 

Le organizzazioni possono utilizzare diverse strategie per trarre vantaggio dall'architettura distribuita di un gateway federato, riducendo al contempo alcune delle complessità operative e dei costi di manutenzione associati ai sistemi federati. Queste pratiche aiutano a preservare l'autonomia dei team, mantenendo linee di comunicazione aperte e una supervisione unificata tra i team.

Le aziende dovrebbero tracciare chiare distinzioni tra i team, eliminando le ambiguità sui servizi che ciascuno è incaricato di creare e mantenere. Questa pratica promuove la responsabilità e protegge i team dal rischio di duplicare o configurare in modo errato il lavoro dei colleghi. Per estensione, questo approccio può aumentare la produttività perché i team hanno una solida comprensione dei propri obiettivi e responsabilità (e la libertà di agire su di essi).

L'implementazione incoerente dei protocolli e degli standard di sicurezza e conformità tra i gateway e le API può presentare rischi di sicurezza, legali e di reputazione. Il mantenimento di standard per la registrazione, la crittografia, l'autenticazione e altre implementazioni di sicurezza tra i gateway deve essere una priorità in un sistema distribuito. In questo modo si garantisce che il piano di gestione centrale possa essere utilizzato per rispondere in modo efficiente alle segnalazioni degli incidenti, così come per effettuare audit completi e prevenire attacchi futuri, indipendentemente dal dominio da cui proviene una minaccia.

Le lacune di observability in un sistema distribuito possono portare a rischi di sicurezza e problemi di prestazioni. È fondamentale che il piano di gestione centrale fornisca la visibilità completa necessaria ai team per visualizzare lo stato di salute e le prestazioni del sistema. Questa funzionalità aiuta a consentire una rapida correzione in caso di problemi, nonché la capacità di apportare miglioramenti proattivi in base a metriche di sicurezza e prestazioni.

I portali unificati degli sviluppatori fungono da hub centralizzati dove gli sviluppatori possono accedere e conoscere qualsiasi API del sistema, indipendentemente dal luogo in cui si trovano o dalla loro struttura. Sono particolarmente importanti nei sistemi federati perché forniscono linee guida, documentazione e esempi di codifica per offrire ai team DevOps un chiaro framework per costruire, implementare e mantenere le loro API.

Questi standard universali, insieme alle chiavi API e ad altri controlli degli accessi, aiutano a garantire che gli sviluppatori possano aggiungere facilmente API al sistema e gestire i propri gateway mantenendo sicurezza e coerenza.

Poiché ogni team agisce con un certo grado di autonomia, le linee di comunicazione aperte sono fondamentali per condividere la best practice e mantenere una rete sostenibile. Le dashboard e altri strumenti di collaborazione possono aiutare i team a sincronizzarsi su obiettivi e procedure condivisi, soprattutto quando una modifica in un dominio potrebbe influire sui servizi correlati.

Meccanismi di reporting completi consentono ai team DevOps di rilevare e risolvere rapidamente la latenza, le interruzioni del servizio e altre anomalie, contribuendo a un'esperienza utente più fluida. Le metriche delle prestazioni possono anche migliorare l'efficienza della scalabilità, identificando quali parti del sistema stanno raggiungendo la massima capacità e quali invece sono poco performanti.

I moderni approcci DevOps, come l'infrastructure as code (utilizzo del codice per automatizzare i processi IT che altrimenti richiederebbero supervisione e provisioning manuali) e AIOps (utilizzo dell'AI per semplificare le operazioni IT) possono aiutare i gateway federati a funzionare in modo più efficiente. Le tecniche di automazione contribuiscono anche a una rete più resiliente perché riducono la probabilità di errore umano e offrono ai team IT la larghezza di banda necessaria per concentrarsi su problemi più complessi.

La federazione dei gateway combina la flessibilità e la personalizzazione delle architetture decentralizzate con una struttura di governance centralizzata e può offrire diversi vantaggi rispetto alle architetture tradizionali.

La federazione conferisce ai team il controllo sui propri gateway, consentendo loro di adattare le configurazioni di runtime, gestire gli aggiornamenti e personalizzare gli ambienti di codifica per soddisfare al meglio le esigenze dei propri clienti e servizi. Ad esempio, per modificare il limite di velocità di un'API in un sistema centralizzato, un team dovrebbe inviare una richiesta tramite il gateway unico dell'organizzazione. I sistemi federati consentono ai team di effettuare la regolazione in modo indipendente e in tempo reale, senza influire sugli altri gateway della rete.

Il piano di controllo centrale aiuta a garantire che i gateway multipli, pur avendo le proprie configurazioni, si attengano a standard di compatibilità e sicurezza condivisi. I team hanno la flessibilità di regolare i parametri in modo autonomo, beneficiando al contempo del beneficio della supervisione esterna fornita dal piano di controllo.

Gli approcci federati riconoscono che i team di sviluppo spesso sanno meglio di tutti come migliorare e mantenere i propri domini. Ai team viene data l'autonomia di modificare le proprie API o servizi non appena rilevano un problema, migliorando l'adattabilità e l'agilità. 

I team possono anche lavorare su diversi linguaggi di codifica mantenendo la relazione del servizio con il piano di controllo centrale. Infine, i reparti possono implementare gli aggiornamenti in base alle necessità, anziché affidarsi a un'autorità centrale per approvare le modifiche, migliorare il time to market delle nuove funzionalità e semplificare i workflow.

I sistemi federati possono offrire un provisioning delle risorse più efficiente, consentendo ai team di monitorare le proprie prestazioni e di regolare di conseguenza i limiti di velocità e la distribuzione del traffico. Le organizzazioni possono scalare solo i servizi e le funzioni che richiedono una maggiore capacità, indirizzando risorse dai servizi o dalle regioni meno utilizzate a quelle che registrano una domanda più elevata.

Inoltre, poiché le API gateway sono indipendenti, è più difficile che le vulnerabilità passino da un API gateway all'altro. Di conseguenza, i sistemi federati sono generalmente più resistenti agli attacchi e alle interruzioni perché è probabile che i guasti influiscano solo su un singolo gateway, anziché sull'intero sistema.

Nei sistemi federati, i singoli team DevOps si occupano del funzionamento e della manutenzione dei propri gateway. Con meno responsabilità, il team centrale può concentrarsi su questioni di livello superiore, come l'applicazione delle normative di conformità, la facilitazione della comunicazione incrociata tra i team e il perfezionamento delle architetture di sistema.

I silos di dati sono molto meno probabili perché un gateway federato può analizzare le prestazioni e applicare guardrail tra i domini. Le metriche cross-gateway possono fornire una visione più olistica dell'impatto di un determinato servizio su prodotti e servizi correlati.

La proprietà e la flessibilità decentralizzate possono introdurre diverse problematiche, soprattutto in caso di interruzioni nella governance o nell'observability. Le sfide introdotte dai gateway federati includono:

Sebbene l'autonomia del team possa contribuire a promuovere l'innovazione, aggiunge anche complessità architettonica al sistema, aumentando i costi di infrastruttura ed elaborazione. I sistemi federati tendono inoltre a richiedere più risorse di manutenzione e sicurezza a causa della loro struttura decentralizzata.

Poiché le metriche e i log sono distribuiti su più API gateway, può essere più difficile per le organizzazioni costruire un quadro coeso delle prestazioni complessive del sistema. Le fonti di dati possono diventare frammentate e scollegate dalla rete più ampia, rendendo più difficile l'identificazione e la risoluzione di potenziali configurazioni errate. Le organizzazioni possono affrontare questa sfida attraverso solidi protocolli e principi di standardizzazione e con gli strumenti di observability.

Mentre i singoli team possono effettuare gli aggiornamenti a propria discrezione, le implementazioni a livello aziendale potrebbero richiedere più tempo rispetto agli ambienti centralizzati. Anziché aggiornare una singola base di codice centrale, i gateway federati devono distribuire gli aggiornamenti su più domini e ogni team è responsabile dell'approvazione e dell'integrazione di tali modifiche in modo indipendente.

Mantenere configurazioni e policy coerenti tra i gateway distribuiti può rappresentare una sfida. Se i team adottano protocolli, pianificazioni di implementazione e formati di dati che si discostano dagli standard di governance aziendale, possono emergere incompatibilità e vulnerabilità a livello di sicurezza. Al contrario, se gli standard e le policy di governance diventano troppo rigorosi, le aziende rischiano di soffocare la sperimentazione e rallentare il ritmo dell'innovazione. In un sistema federato, l'equilibrio è fondamentale.

Via via che le aziende crescono e si evolvono in un sistema federato, rischiano di introdurre nuove inefficienze, come la proliferazione incontrollata delle API, quando più team sviluppano involontariamente API ridondanti. Se questo problema si aggrava, i gateway possono diventare ingestibili, poiché il piano centrale è incapace di tenere traccia delle modifiche. Questo problema può essere mitigato attraverso una governance efficiente.