Cos'è la distribuzione blu-verde?

Un ambiente è attivo e serve gli utenti, etichettato come "blu" e un altro, l'ambiente "verde", viene utilizzato per la distribuzione e il test di una nuova versione. Quando la nuova versione viene approvata, il traffico viene indirizzato istantaneamente dall'ambiente blu all'ambiente verde.

La strategia è stata resa popolare e nominata da Jez Humble e David Farley nel loro fondamentale libro del 2010 Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation.

Blu-verde è una tecnica di distribuzione continua che consente l'eliminazione dei tempi di inattività, ovvero la possibilità di effettuare istantaneamente rollback verso una vecchia versione. Consente di eseguire facilmente test A/B e crea un ambiente di sviluppo sicuro, senza il rischio che gli utenti finali si imbattano in una versione non ancora pronta.

Sebbene la dicitura "blu-verde" sia la più comune, ne esistono delle varianti. Netflix usa il sistema "rosso/nero", ma il concetto rimane lo stesso. A volte, gli sviluppatori potrebbero voler avere più di due ambienti. Lo schema di denominazione dei colori è efficace per differenziare due ambienti. Tuttavia, le organizzazioni potrebbero anche utilizzare convenzioni di denominazione come numeri di versione, ID di build o titoli personalizzati, soprattutto se sono coinvolti più di due ambienti.

Sebbene il concetto sia semplice, ci sono diverse fasi e variabili all'interno di queste fasi per creare una distribuzione blu-verde stabile e sicura che utilizzi al meglio i benefici della strategia.

La creazione di ambienti identici per la distribuzione blu-verde può essere eseguita manualmente o utilizzando strumenti automatizzati. Infrastructure as Code, o IaC, è un approccio automatizzato al provisioning. IaC utilizza file di configurazione leggibili da macchina, un po' come un insieme di istruzioni o una ricetta per abilitare il provisioning e la configurazione automatica dell'infrastruttura IT secondo specifiche predefinite.

IaC consente agli sviluppatori di avviare automaticamente una copia dell'ambiente blu, già operativo, da utilizzare come ambiente verde. Gli sviluppatori possono quindi modificare questi modelli secondo le necessità, sapendo di partire da un punto di partenza affidabile. L'uso dell'IaC aiuta a garantire una replica ripetibile e precisa.

La containerizzazione, in cui codice applicativo, dipendenze e API sono tutti impacchettati insieme in un'unica "immagine container", è un altro approccio. L'uso dei container garantisce che l'intero ambiente sia identico. Kubernetes, una piattaforma di orchestrazione di container open source, è comunemente utilizzata per la containerizzazione nella distribuzione blu-verde.

Dopo la creazione degli ambienti, l'applicazione viene distribuita nell'ambiente blu (live).

Un bilanciatore di carico è un meccanismo, spesso presente davanti agli ambienti applicativi come strumento all'interno dei provider cloud o degli ambienti Kubernetes, che indirizza il traffico di produzione secondo necessità. In questo scenario, il bilanciatore del carico indirizza il traffico verso l'ambiente live e blu.

Successivamente, il nuovo codice con gli aggiornamenti di applicazione viene implementato nell'ambiente di produzione verde. Poiché il bilanciatore del carico instrada il traffico verso l'ambiente di produzione blu, il verde è uno spazio sicuro per sperimentare, testare e configurare. 

Quando il processo di implementazione nell'ambiente verde è completato, esegui tutti i passaggi di validazione necessari. Questi passaggi possono includere scansioni di sicurezza, controlli delle prestazioni, scansioni di bug e altro ancora.

Quando l'ambiente verde è convalidato e approvato da tutti gli stakeholder necessari, aggiorna il bilanciatore del carico per indirizzare il traffico dalla versione blu precedente alla nuova versione verde.

Il passaggio sarà istantaneo; gli utenti non visualizzeranno in alcun momento un messaggio di errore o qualcosa di diverso dagli ambienti blu o verdi.

Gli aggiornamenti DNS possono essere utilizzati per indirizzare gli utenti all'ambiente desiderato, ma possono verificarsi ritardi significativi quando le cache aggiornano l'indirizzo IP. A causa di queste problematiche, i bilanciatori del carico sono preferibili perché gli aggiornamenti hanno effetto immediato.

Anche se la fase di convalida dovrebbe aver individuato la maggior parte dei potenziali bug o problemi di prestazioni, è comunque importante monitorare l'ambiente verde appena avviato. Software e servizi di analytics possono aiutarti qui. Il confronto delle attività può indicare se sta succedendo qualcosa di insolito.

Se qualcosa va storto, il traffico degli utenti può essere reindirizzato all'ambiente blu mentre gli sviluppatori si occupano di risolvere il problema.

La dismissione di un ambiente blu in disuso è facoltativa; alcune organizzazioni potrebbero voler mantenere l'ambiente blu a tempo indeterminato, nel caso in cui l'ambiente verde debba essere ripristinato ad un certo punto. Tuttavia, esistono anche potenziali ragioni di costo che potrebbero giustificare lo smantellamento di un ambiente blu in qualche fase del suo ciclo di vita. In alternativa, l'ambiente blu può diventare il prossimo ambiente sperimentale, o verde.

La pipeline di integrazione continua/fornitura continua è "un workflow DevOps automatizzato che semplifica il processo di distribuzione del software". Questa pipeline facilita la distribuzione continua delle modifiche al codice nelle applicazioni.

È una pratica strettamente integrata con la distribuzione blu-verde: CI/CD consente la distribuzione blu-verde e le distribuzioni blu-verdi sono spesso integrate nelle pipeline CI/CD per aiutare a rilasciare aggiornamenti software senza tempi di inattività e con rischi ridotti.

Le pipeline CI testano e integrano automaticamente il nuovo codice prima che venga integrato nel repository centrale, riducendo il rischio che il codice difettoso raggiunga la distribuzione. Le pipeline CD utilizzano una strategia di distribuzione blu-verde per ottimizzare i rilasci rapidi senza influenzare gli utenti. La distribuzione blu-verde garantisce una disponibilità quasi continua e un rollback sicuro, il che gioca un ruolo importante nel raggiungere l'obiettivo generale CI/CD di rilasci frequenti e affidabili del codice.

Ispirate al proverbio inglese del canarino nella miniera di carbone, le implementazioni canary rappresentano un altro metodo per ridurre i rischi durante la distribuzione di nuove versioni del software.

Mentre le distribuzioni blu/verdi creano due ambienti separati, ciascuno dei quali generalmente gestisce l'intero traffico oppure nessuno, la distribuzione canary adotta un approccio diverso. Le release canary hanno un solo ambiente, che ospita più versioni.

In una distribuzione canary, le nuove versioni vengono rilasciate prima a una piccola percentuale di utenti. Successivamente, gli sviluppatori possono verificare se gli errori aumentano, le prestazioni diminuiscono o si verificano altri problemi. Quella piccola percentuale di utenti funge da "canarino nella miniera di carbone". Se non ci sono problemi, il traffico verso la nuova versione aumenta costantemente, controllando continuamente eventuali errori.

Il vantaggio principale di una distribuzione canary rispetto a una distribuzione blu/verde è nel costo dell'infrastruttura, poiché la distribuzione canary utilizza solo un ambiente, mentre le distribuzioni blu/verdi ne utilizzano due. Tuttavia, le distribuzioni canary possono anche essere più complesse e comportare maggiori rischi in caso di necessità di rollback, rispetto al semplice reindirizzamento del bilanciamento del carico tipico delle distribuzioni blu/verdi.

Il metodo di distribuzione canary può essere utile se i potenziali errori non sono un problema così significativo come far arrivare una nuova release davanti agli utenti il più rapidamente possibile, oppure se gli sviluppatori vogliono monitorare l'impatto con un feedback reale sull'esperienza utente.

Detto questo, esiste anche un approccio ibrido. I bilanciatori del carico possono indirizzare una parte del traffico degli utenti, ad esempio l'1%, verso l'ambiente verde, lasciando che il 99% vada a quello blu. Questo combina efficacemente entrambe le strategie, fornendo insight sulla distribuzione canary con la possibilità di emettere rollback in modo rapido e semplice.

La distribuzione blu-verde offre numerosi vantaggi, sia che venga utilizzata con un approccio "tutto o niente" sia con un rilascio di tipo canary.

Poiché il bilanciatore del carico sposta istantaneamente il traffico all'ambiente desiderato, gli utenti finali non subiscono mai tempo di inattività. Questo è un beneficio significativo per le istanze ad alto traffico, dove il tempo di inattività può produrre gravi problemi aziendali.

Disporre di due ambienti separati, uno dei quali noto per essere sicuro e operativo, consente agli sviluppatori di annullare immediatamente qualsiasi modifica in caso di problemi. Se l'ambiente verde presenta problemi, il traffico può semplicemente essere deviato verso l'ambiente blu.

Avere due ambienti separati semplifica l'analisi delle metriche, le analytics e i test A/B per le diverse versioni. I dati di analytics e monitoraggio possono essere chiaramente collegati sia all'ambiente blu che a quello verde, consentendo confronti e controlli di stato di salute semplici. Ciò è in contrasto con la distribuzione canary, che può essere più difficile da distinguere, poiché entrambe le versioni sono attive contemporaneamente.

Un ambiente verde e sperimentale consente il test approfondito di nuove versioni fuori dalla vista dell'utente finale. Le nuove versioni vengono implementate con un notevole grado di sicurezza che funzioneranno come previsto. Nei casi in cui ciò non avviene, il traffico può essere reindirizzato istantaneamente verso l'ambiente blu stabile.

Sebbene la distribuzione blu-verde offra molti benefici, ci sono potenziali svantaggi e casi d'uso non ottimali che i team di sviluppo dovrebbero considerare.

Con due ambienti completamente in esecuzione, i costi dell'hosting e dell'infrastruttura possono aumentare. Non è detto che questi costi siano esattamente il doppio di quelli di un ambiente singolo. In alcuni casi, l'ambiente verde avrà un'impronta più piccola o l'ambiente blu potrebbe essere rapidamente dismesso o alcune risorse potrebbero essere condivise tra i due ambienti. È probabile, tuttavia, che si verificherà un aumento dei costi.

Sebbene non sia esclusivo delle distribuzioni blu-verde, mantenere la sincronizzazione del database tra ambienti vecchi e nuovi può rappresentare una sfida. Ad esempio, in un sistema blu-verde che comporta cambiamenti frequenti o complessi nello schema, può essere complicato mantenere la compatibilità.

Per evitare di interrompere l'ambiente live, le modifiche allo schema devono essere retrocompatibili, il che significa che il nuovo sistema può funzionare con quello più vecchio. In caso contrario, gli ambienti potrebbero richiedere database separati che devono sincronizzarsi in tempo reale. Questa sincronizzazione bidirezionale presenta i propri rischi, come incoerenze e degrado delle prestazioni.

Per affrontare questo problema, gli strumenti CI/CD, come GitHub Actions, includono processi di distribuzione del database che gestiscono automaticamente gli aggiornamenti dello schema. A volte, modifiche allo schema troppo complesse possono annullare il valore della distribuzione blu-verde.

Nelle applicazioni con stato, quelle che mantengono dati persistenti tra le richieste, le implementazioni blu-verde possono presentare problemi. Le applicazioni stateful potrebbero includere carrelli che conservano i loro contenuti per più visite o registri di messaggistica. Se i database non sono condivisi e compatibili tra gli ambienti, questi dati possono andare persi.

Le applicazioni di microservizi sono spesso sistemi altamente complessi composti da molti componenti singolarmente distribuibili. Poiché gli sviluppatori di microservizi potrebbero voler distribuire decine di volte al giorno, la natura incrementale di una distribuzione canary è considerata una scelta più sicura.