Che cos'è Apigee hybrid?

Immagine stilizzata del deployment

Apigee hybrid ti consente di gestire le API on-premise, su Google Cloud o in una combinazione di entrambi:

Gestisci tutte le API in un unico posto

Apigee hybrid ti aiuta a gestire le API interne ed esterne con Google Cloud.

Con la gestione unificata delle API, puoi fornire a sviluppatori, partner e clienti un'esperienza coerente del programma API.

Risolvi i problemi di sicurezza e conformità

Se le tue considerazioni in materia di conformità e sicurezza rendono il deployment on-premise un must per le tue applicazioni, con un gateway ibrido di livello enterprise, puoi ospitare e gestire il piano di runtime ibrido Apigee on-premise.

Sarai tu a gestire e controllare il runtime, in modo da sfruttare l'infrastruttura esistente di conformità, governance e sicurezza.

Sostieni la tua strategia multi-cloud

L'equilibrio tra costi e prestazioni può portare a una strategia ibrida.

Che tu stia semplicemente esplorando diversi cloud provider o che tu abbia già scelto una strategia ibrida, la tua piattaforma di gestione delle API dovrebbe offrirti la flessibilità di cui hai bisogno. Ospita e gestisci gateway ibridi di livello aziendale nel tuo data center, su Google Cloud o in entrambi.

 

Per scoprire di più sulla modalità ibrida:

Continua a leggere

 

 

Se è tutto pronto per l'installazione ibrida:

Inizia da qui

 

Programmi API in un mondo ibrido

Apigee hybrid è costituito da un piano di gestione gestito da Google e da un piano di runtime che puoi installare in Kubernetes on-premise o su Google Cloud. Entrambi gli aerei utilizzano i servizi della piattaforma Google Cloud, come mostrato nell'immagine seguente:

Una visione generale della piattaforma ibrida, inclusi piano di gestione, piano di runtime e servizi Google Cloud

Come puoi vedere, il modello ibrido è costituito dai seguenti componenti principali:

  • Piano di gestione Apigee-run: un insieme di servizi ospitati nel cloud e gestiti da Google. Questi servizi includono la UI, l'API di gestione e l'analisi.
  • Piano di runtime gestito dal cliente: un insieme di servizi di runtime containerizzati che configuri e gestisci nel tuo cluster Kubernetes. Tutto il traffico delle API passa attraverso il piano di runtime e viene elaborato.

    Puoi gestire il runtime containerizzato sul tuo cluster Kubernetes per una maggiore agilità con implementazioni graduali, scalabilità automatica e altri vantaggi operativi dei container.

  • Google Cloud: una suite di servizi cloud ospitata da Google.

Una cosa fondamentale da sapere sull'ibrido è che tutto il traffico delle API viene elaborato all'interno dei confini della rete e sotto il tuo controllo, mentre i servizi di gestione come l'analisi dell'interfaccia utente e delle API vengono eseguiti nel cloud e sono gestiti da Google. Per ulteriori informazioni, vedi Dove vengono archiviati i dati?

Il seguente video fornisce un'analisi approfondita dell'architettura ibrida:

Informazioni sul piano di runtime

Il piano di runtime è un insieme di servizi di runtime containerizzati che configuri e gestisci nel tuo cluster Kubernetes. Tutto il traffico API passa attraverso il piano di runtime e viene elaborato all'interno del piano di runtime. Il piano di runtime include i seguenti componenti principali:

Il piano di runtime viene eseguito in un cluster Kubernetes di tua proprietà e che gestisci.

La seguente immagine mostra i servizi principali in esecuzione sul piano di runtime:

Servizi principali in esecuzione sul piano di runtime ibrido

Per informazioni generali sui componenti di runtime, consulta le sezioni seguenti. Inoltre, consulta Panoramica della configurazione del servizio di runtime.

Le seguenti sezioni descrivono in modo più dettagliato ciascuno di questi servizi principali del piano di runtime.

processore di messaggi

I processori di messaggi ibridi (MP) forniscono l'elaborazione delle richieste API e l'esecuzione dei criteri sul piano di runtime. Gli MP caricano tutti i proxy di cui è stato eseguito il deployment, le risorse, i server di destinazione, i certificati e gli archivi chiavi dallo spazio di archiviazione locale. Puoi configurare un controller Istio Ingress per esporre i MP alle richieste provenienti dall'esterno del cluster.

Sincronizzatore

Il programma di sincronizzazione recupera i dati di configurazione relativi a un ambiente API dal piano di gestione e li propaga sul piano di runtime. Questi dati scaricati sono chiamati anche contratto e vengono archiviati nel file system locale.

Il programma di sincronizzazione esegue periodicamente il polling del server di gestione per individuare eventuali modifiche e scarica una nuova configurazione ogni volta che vengono rilevate modifiche. I dati di configurazione vengono recuperati e archiviati localmente come file JSON nel file system locale, a cui possono accedere i processori di messaggi.

I dati di configurazione scaricati consentono al piano di runtime di funzionare indipendentemente dal piano di gestione. Con il contratto, gli elaboratori di messaggi sul piano di runtime utilizzano i dati archiviati localmente come configurazione. Se la connessione tra il piano di gestione e quello di runtime non è disponibile, i servizi sul piano di runtime continueranno a funzionare.

I dati di configurazione scaricati dal programma di sincronizzazione includono:

Datastore Cassandra

Apache Cassandra è il datastore di runtime che fornisce persistenza dei dati per il piano di runtime.

Cassandra è un sistema di dati distribuito che fornisce persistenza dei dati sul piano di runtime. Puoi eseguire il deployment del database Cassandra come pool di nodi StatefulSet sul tuo cluster Kubernetes. Localizzare queste entità vicino ai servizi di elaborazione di runtime consente di supportare i requisiti di sicurezza e alta scalabilità.

Il database Cassandra archivia informazioni sulle seguenti entità:

  • Sistema di gestione delle chiavi (KMS)
  • Mappa chiave-valore (KVM)
  • Cache risposte
  • OAuth
  • Quote

API di gestione per i dati di runtime (MART)

I dati che appartengono alla tua organizzazione e a cui si accede durante le chiamate API di runtime vengono archiviati da Cassandra nel piano di runtime.

Questi dati includono:

  • Configurazioni delle applicazioni
  • Dati del sistema di gestione delle chiavi (KMS)
  • Cache
  • Mappe chiave-valore (KVM)
  • Prodotti basati su API
  • App sviluppatore

Per accedere a questi dati e aggiornarli, ad esempio per aggiungere un nuovo KVM o per rimuovere un ambiente, puoi utilizzare l'interfaccia utente ibrida Apigee o le API Apigee. Il server MART (API di gestione per i dati di runtime) elabora le chiamate API rispetto al datastore di runtime.

Questa sezione descrive il ruolo che MART svolge quando chiami le API Apigee per accedere al datastore di runtime.

 
Che cos'è MART

Per chiamare un'API Apigee, devi inviare una richiesta autenticata al server di gestione (MS) sul piano di gestione. MS autentica e autorizza la richiesta, quindi inoltra la richiesta a MART sul piano di runtime. A questa richiesta è associato un token generato da MS utilizzando un account di servizio preconfigurato.

MART riceve la richiesta, la autentica e la autorizza, quindi ne esegue la convalida aziendale. Ad esempio, se l'app fa parte di un prodotto API, MART garantisce che si tratti di una richiesta valida. Dopo aver stabilito che una richiesta è valida, MART la elabora.

Cassandra archivia i dati di runtime elaborati da MART (si tratta, dopotutto, di un datastore di runtime). MART potrebbe leggere i dati da Cassandra o aggiornarli, a seconda del tipo di richiesta.

Come la maggior parte dei servizi ibridi, MART è stateless: non conserva il proprio stato in fase di runtime.

Che cosa non è MART

Anche se MART espone una porta nel cloud pubblico, non chiami direttamente MART. (La porta deve essere esposta in modo che MART possa ricevere chiamate da MS tramite un account di servizio).

Inoltre, MART non riceve chiamate di runtime dai tuoi clienti ai loro proxy API; queste chiamate vengono gestite dal controller in entrata e instradate ai processori di messaggi del tuo cluster.

 

Vale la pena sottolineare che sia il MART sia i processori di messaggi hanno accesso allo stesso datastore di runtime (Cassandra), ovvero il modo in cui vengono condivisi dati come KMS, KVM e cache.

L'immagine seguente mostra il flusso di una chiamata API Apigee:

Flusso di chiamate API in modalità ibrida

UDCA

Universal Data Collection Agent (UDCA) è un servizio in esecuzione all'interno del pod di raccolta dati nel piano di runtime che estrae i dati di analisi, debug e stato del deployment e li invia all'UAP.

Per ulteriori informazioni, consulta Raccolta dei dati di debug, analisi e stato del deployment.

Informazioni sul piano di gestione

Il piano di gestione viene eseguito su Google Cloud. Comprende servizi amministrativi come:

  • UI ibrida di Apigee: fornisce agli sviluppatori un'interfaccia utente per creare ed eseguire il deployment di proxy API, configurare criteri, creare prodotti API e creare app per sviluppatori. Gli amministratori possono utilizzare l'interfaccia utente ibrida di Apigee per monitorare lo stato del deployment.
  • API Apigee: fornisci un'interfaccia programmatica per la gestione della tua organizzazione e degli ambienti.
  • Unified Analytics Platform (UAP): riceve ed elabora i dati di analisi e sullo stato del deployment dal piano di runtime.

La seguente immagine mostra i servizi principali in esecuzione sul piano di gestione:

Servizi in esecuzione sul piano di gestione ibrida Apigee

Informazioni sui servizi Google Cloud

La tabella seguente descrive i servizi principali di Google Cloud utilizzati da ibridi:

Servizio Google Cloud Descrizione
Identità L'autenticazione degli account utente utilizza gli account Google Cloud. L'autorizzazione utilizza gli account di servizio Google Cloud.
Ruoli La gestione degli accessi per gli ambienti ibridi utilizza il motore dei ruoli di Google, IAM, e supporta i ruoli Apigee predefiniti.
Gerarchia delle risorse Le risorse sono organizzate in progetti Google Cloud (collegati a organizzazioni Apigee).
Stackdriver Fornisce l'analisi dei dati di logging e delle metriche.
 

Tipi di utenti

Apigee ha identificato i seguenti tipi principali di utenti ibridi:

Ruolo Responsabilità tipiche Aree di interesse
Amministratori di sistema/operatori
  • Installa e configura i servizi sul piano di runtime di ibrido
  • Configura gli account Google Cloud, Apigee e di servizio
  • Creare servizi e progetti Google Cloud
  • Gestisci il cluster Kubernetes
  • Mantieni tutte le impostazioni precedenti
  • Risolvere i problemi relativi ai proxy API
Sviluppatori
  • Crea proxy API utilizzando l'UI ibrida di Apigee o le API Apigee
  • Esegui il deployment dei proxy API nel piano di runtime
  • Risolvere i problemi relativi ai proxy API
  • Testare i proxy API
 

Vantaggi

Apigee hybrid offre i seguenti vantaggi:

Maggiore agilità
Poiché l'ambiente ibrido viene distribuito e viene eseguito in container, puoi ottenere implementazioni graduali, scalabilità automatica e altri vantaggi operativi di un sistema containerizzato.
Latenza ridotta
Tutte le comunicazioni con il piano di gestione ibrido sono asincrone e non avvengono nell'ambito dell'elaborazione delle richieste API client.
Maggiore adozione delle API
Sebbene sia possibile elaborare le API interne utilizzando Apigee, la latenza e l'efficienza ridotte che si possono ottenere con l'ambiente ibrido rendono l'elaborazione di API interne con ibrido un'opzione interessante. Parte di questa efficienza viene raggiunta perché il gateway API viene eseguito on-premise, in prossimità dei servizi di backend. Inoltre, se utilizzi Apigee, puoi aumentare l'adozione di Apigee elaborando le API interne tramite un modello ibrido.
Maggiore controllo
Molte aziende stanno adottando una strategia ibrida. La capacità di gestire i runtime delle API distribuiti in data center privati è un requisito chiave per le grandi aziende. Attualmente, è possibile eseguire il deployment del piano di runtime ibrido in Google Cloud o nel tuo data center.

Passaggio successivo

Consulta il quadro generale: una panoramica del processo di installazione ibrida.