Modifica

Condividi tramite

Soluzioni multicloud con Serverless Framework

Funzioni di Azure

Questo articolo descrive un'iniziativa di collaborazione tra il team Microsoft Commercial Software Engineering (CSE) con un rivenditore globale per distribuire una soluzione serverless a disponibilità elevata su piattaforme cloud Azure e Amazon Web Services (AWS), tramite Serverless Framework.

Architettura

Diagramma che mostra l'architettura serverless multicloud.

Scaricare un file di Visio di questa architettura.

Flusso di dati

  • L'app utente può provengono da qualsiasi origine in grado di accedere al cloud. In questa implementazione l'utente accede a un'app gateway che bilancia il carico delle richieste 50-50 tra i cloud Azure e AWS.
  • Qualsiasi risposta viene anche instradata tramite il gateway di Gestione API, che quindi la invia all'app richiedente.

Componenti

Serverless Framework

Questa soluzione usa Serverless Framework, disponibile da Serverless, Inc. La versione gratuita di Serverless Framework include un'interfaccia della riga di comando, plug-in aggiuntivi e servizi di monitoraggio limitati. L'edizione Pro include funzionalità operative tra cloud, ad esempio monitoraggio avanzato e avvisi. Il framework supporta i linguaggi Node.js e Python, oltre agli host cloud sia AWS che Azure.

Per usare Azure con Serverless Framework, è necessario:

  • Node.js, per creare pacchetti di microservizi
  • Funzioni di Azure, per fornire funzionalità paragonabili a quelle di altre piattaforme cloud
  • Serverless Framework, per supportare la distribuzione e il monitoraggio multicloud
  • Libreria Serverless Multicloud, per fornire API di runtime normalizzate per gli sviluppatori
  • Plug-in serverless di Funzioni di Azure, per supportare la distribuzione multicloud. Questo plug-in inizialmente non era all'altezza del plug-in AWS Lambda equivalente ed è stato esteso per questo progetto.

La figura seguente illustra la pipeline di elaborazione. I livelli del middleware rappresentano le funzionalità intermedie necessarie prima di raggiungere il gestore.

Diagramma che illustra una pipeline di elaborazione multicloud.

API indipendenti dal cloud

L'implementazione serverless in ogni piattaforma supporta singole funzioni come microservizi, una per ogni nodo di macchina virtuale funzionale, ed esegue l'elaborazione in base alle esigenze. Ogni funzione AWS Lambda ha una funzione di Funzioni di Azure corrispondente. La libreria Serverless Multicloud crea microservizi analoghi da entrambi i cloud in un'API REST normalizzata indipendente dal cloud che le app client possono usare per interfacciarsi con entrambe le piattaforme. Poiché il livello API astratto fornisce codice per i microservizi corrispondenti per ogni piattaforma, le transazioni non necessitano di conversione. L'interfaccia indipendente dal cloud consente alle app utente di interagire con il cloud senza conoscere o curarsi della piattaforma cloud a cui accedono.

Il diagramma seguente illustra questo concetto:

Diagramma che illustra un'API indipendente dal cloud.

CI/CD con GitOps

Una delle principali funzioni di Serverless Framework è rimuovere tutti i potenziali problemi a livello di infrastruttura associati alla distribuzione di un'app nel cloud. Usando un approccio basato su manifesto, Serverless Framework può gestire tutti i problemi di distribuzione, consentendo di automatizzare la distribuzione in base alle esigenze per supportare GitOps.

Anche se questo progetto iniziale usa distribuzioni manuali, è realistico implementare compilazioni, test e distribuzioni serverless basate su manifesto all'interno o tra cloud. Questo processo può usare un flusso di lavoro per sviluppatori GitOps: compilazione da Git, uso di controlli qualità per test e valutazione ed esecuzione del push di soluzioni serverless in entrambi i provider di servizi cloud. L'esecuzione di tutte le distribuzioni tramite Serverless Framework dall'inizio del progetto è il modo più efficiente per procedere.

Gestione API

L'applicazione di gestione API può essere una esistente o personalizzata. Apigee™ API Manager in questa implementazione funge solo da router per il bilanciamento del carico 50-50 delle transazioni tra le due piattaforme cloud e viene sottoutilizzata rispetto alle sue funzionalità.

L'applicazione di gestione API deve essere in grado di:

  • Essere distribuita all'interno o all'esterno di una piattaforma cloud in base alle esigenze
  • Instradare i messaggi da e verso entrambe le piattaforme cloud
  • Registrare le richieste di traffico per coordinare il traffico asincrono dei messaggi
  • Inoltrare richieste e risposte usando l'API REST comune da e verso l'applicazione utente
  • Monitorare l'integrità di entrambe le distribuzioni del framework serverless cloud per verificarne la capacità di ricevere richieste
  • Eseguire controlli automatizzati di integrità e disponibilità in ogni piattaforma cloud per supportare il routing e la disponibilità elevata

Alternative

  • Altri linguaggi come Python potrebbero implementare la soluzione, purché siano supportati dalle implementazioni serverless delle piattaforme cloud, in questo caso AWS Lambda e Funzioni di Azure. In questo progetto è stato usato Node.js per creare pacchetti di microservizi, perché il cliente conosce Node.js e le piattaforme AWS e Azure lo supportano.

  • La soluzione può usare qualsiasi piattaforma cloud che supporti Serverless Framework, non solo Azure e AWS. Attualmente, Serverless Framework è compatibile con otto diversi provider di servizi cloud. L'unica avvertenza è assicurarsi che gli elementi che supportano l'architettura multicloud o il relativo equivalente siano disponibili nelle piattaforme cloud di destinazione.

  • L'applicazione di gestione API in questa implementazione iniziale funge solo da router per il bilanciamento del carico 50-50 delle transazioni tra le due piattaforme cloud. Potrebbe tuttavia incorporare altra logica di business per specifici scenari.

Dettagli dello scenario

Nell'elaborazione serverless il provider di servizi cloud alloca dinamicamente le risorse di microservizi per eseguire il codice e addebita i costi solo per le risorse usate. L'elaborazione serverless astrae il codice dell'app dall'implementazione dell'infrastruttura, dalla distribuzione del codice e da aspetti operativi come la pianificazione e la manutenzione.

Come per altri servizi, ogni provider di servizi cloud ha una propria implementazione serverless ed è difficile per i clienti usare un provider diverso senza incorrere in costi ed effetti operativi considerevoli. I potenziali clienti possono vedere questa situazione come un indebolimento della loro posizione e agilità di negoziazione. Il vincolo al fornitore rappresenta uno dei principali ostacoli all'adozione del cloud aziendale.

Serverless Framework open source è un'interfaccia cloud universale per lo sviluppo e la distribuzione di soluzioni di elaborazione serverless tra provider di servizi cloud. L'open sourcing e le API comuni per le funzioni serverless consentono a provider, clienti e partner di creare soluzioni tra cloud per servizi di qualità ottimale. Serverless Framework riduce le barriere all'adozione del cloud risolvendo i problemi di vincolo al fornitore e della ridondanza di provider tra cloud. I clienti possono ottimizzare le soluzioni in base a costi, agilità e altre considerazioni.

Il team CSE e il team di prodotto di Azure hanno collaborato alla riscrittura dell'interfaccia della riga di comando serverless per supportare nuove funzionalità di Funzioni di Azure come Funzioni Premium, Gestione API e KeyVault. L'interfaccia della riga di comando serverless offre ora un'interfaccia standard per la distribuzione di GitOps sia in Azure che in AWS. Il team ha anche sviluppato la libreria Serverless Multicloud, che fornisce un'API di runtime normalizzata per distribuire app serverless sia in AWS che in Azure.

Questa soluzione offre disponibilità elevata con failover attivo-attivo tra più piattaforme cloud, diversamente dal failover attivo-passivo. Se il servizio di un provider di servizi cloud diventa non integro o non disponibile, questa soluzione può reindirizzare le richieste a un'altra piattaforma cloud.

Questo progetto ha soddisfatto gli obiettivi tecnici seguenti:

  • Creare una soluzione multi-settoriale.
  • Usare la libreria Multicloud Serverless per supportare un'API indipendente dal cloud che si interfaccia con i microservizi ovunque vengano distribuiti.
  • Supportare un flusso di lavoro di processo CI/CD GitOps per lo sviluppo, il test e la distribuzione in tutte le piattaforme cloud supportate.
  • Usare l'accesso basato su API tramite un gateway cloud autenticato e bilanciare il carico tra piattaforme cloud usando il gateway come router.

Altri potenziali vantaggi dell'uso di Serverless Framework includono:

  • Prevenzione o riduzione del vincolo al fornitore
  • Riduzione di oltre il 40-60% del codice durante lo sviluppo tramite libreria Multicloud Serverless
  • Sviluppo di soluzioni avanzate che combinano servizi di provider di servizi cloud diversi
  • Eliminazione della maggior parte della complessità e dei requisiti di manutenzione dell'infrastruttura
  • Condivisione dei dati semplificata, confronti di prestazioni e costi e la possibilità di usufruire di offerte speciali
  • Disponibilità elevata attiva-attiva

Potenziali casi d'uso

  • Scrivere applicazioni lato client per più piattaforme usando un'API indipendente dal cloud della libreria Serverless Multicloud.
  • Distribuire una raccolta di microservizi funzionali in un framework serverless in più piattaforme cloud.
  • Usare un'app indipendente dal cloud tra piattaforme cloud senza conoscere o curarsi della piattaforma che la ospita.

Considerazioni

  • Questo articolo non descrive le soluzioni di sicurezza, anche se sono incluse nella distribuzione iniziale. Esistono molte possibili soluzioni di sicurezza, alcune dipendenti dalla piattaforma, e questo framework dovrebbe supportare qualsiasi soluzione ragionevole. L'autenticazione utente è la sicurezza minima presunta.

  • Poiché è difficile articolare le differenze tra le offerte funzionali serverless di AWS e di Azure, il lavoro iniziale dovrebbe concentrarsi sul mapping delle funzioni disponibili in ogni piattaforma cloud e sull'identificazione dei requisiti di trasformazione necessari. È possibile sviluppare un'API indipendente dalla piattaforma da queste informazioni.

  • L'uso di una soluzione open source può introdurre rischi, a causa di problemi di manutenzione e supporto a lungo termine con qualsiasi software open source.

  • Nella versione gratuita di Serverless Framework, il monitoraggio è limitato principalmente al dashboard amministrativo. Il monitoraggio è disponibile nell'offerta Enterprise a pagamento. Attualmente, il plug-in serverless di Funzioni di Azure non include funzionalità per l'osservabilità o il monitoraggio e potrebbe essere necessario apportare modifiche per implementarle.

  • Questa soluzione potrebbe usare le metriche per confrontare le prestazioni e i costi tra le piattaforme cloud, consentendo ai clienti di ottimizzare facilmente l'utilizzo tra piattaforme cloud.

Distribuire lo scenario

Una distribuzione blu-verde tradizionale sviluppa e distribuisce un'app in due ambienti separati ma identici, blu e verde, aumentando la disponibilità e riducendo i rischi. L'ambiente blu è in genere l'ambiente di produzione che in genere gestisce il traffico in tempo reale, mentre l'ambiente verde è una distribuzione di failover, se necessaria. In genere, la pipeline CI/CD distribuisce automaticamente entrambi gli ambienti blu e verde all'interno della stessa piattaforma cloud. Questa configurazione è considerata attiva-passiva.

Nella soluzione multicloud la distribuzione blu-verde viene implementata in entrambe le piattaforme cloud. Nel caso serverless, vengono distribuiti due set duplicati di microservizi per ogni piattaforma cloud, uno come ambiente di produzione e l'altro come ambiente di failover. Questa configurazione attiva-passiva all'interno di ogni piattaforma cloud riduce il rischio che questa piattaforma non sia disponibile, aumentandone la disponibilità e abilitando la disponibilità elevata attiva-attiva multicloud.

Diagramma che mostra una distribuzione blu-verde attiva-attiva.

Un vantaggio secondario della distribuzione blu-verde è la possibilità di usare la distribuzione di failover in ogni piattaforma cloud come ambiente di test per gli aggiornamenti dei microservizi, prima di rilasciarli nella distribuzione in produzione.

Passaggi successivi