Perchè Adottare gli Ambienti Effimeri?

L’uso di ambienti containerizzati ha migliorato in modo significativo il ciclo di delivery del software. Di conseguenza, la maggior parte dei team che utilizzano questi ambienti possono avere più varianti, come l’ambiente locale o di sviluppo, l’ambiente sandbox, l’ambiente di staging o di test, l’ambiente di produzione e così via, a seconda delle esigenze degli stakeholder o del software stesso. Ogni ambiente ha uno scopo unico e aiuta il team a realizzare un prodotto solido. 

Tradizionalmente, un’organizzazione IT funziona in questo modo: gli sviluppatori svolgono il loro lavoro su macchine locali (indipendentemente dal fatto che l’ambiente sia containerizzato o meno), mentre per i test e gli showcase si dispone tipicamente di un ambiente di test per la Quality Assurance (QA) interna, di un ambiente di staging per le dimostrazioni delle funzionalità o per l’UAT dei clienti e di un ambiente di produzione che spesso è containerizzato e distribuito (ad esempio, utilizzando Kubernetes).

Per scalare questo approccio, almeno gli ambienti di staging e di test devono essere replicati per ogni team che sviluppa nuove funzionalità e risolve i bug. Questo aiuta a mitigare il rischio di problemi di dipendenza nel processo di sviluppo (ad esempio, il team A che sviluppa la caratteristica A non può distribuirla e testarla nello stesso ambiente in cui il team B sta testando la caratteristica B senza causare potenziali conflitti). Tuttavia, questo processo è lento e comporta costi elevati per la gestione di questi ambienti a standard.

La soluzione a queste limitazioni è l’utilizzo di ambienti effimeri. Integrando le pratiche di Platform Engineering (PE) e gli ambienti effimeri, il platform team può preparare immagini container standard con tutte le dipendenze necessarie (librerie e pacchetti) e può quindi sostituire gli ambienti standard con quelli effimeri. Ciò consente al team di lavorare senza problemi e di semplificare ulteriormente l’esperienza di sviluppo.

Si può quindi sostituire gli ambienti standard con quelli effimeri, impostando le pipeline di delivery come segue: Un team invia una nuova funzionalità e quando laPull Request (PR) viene aperta, viene creato un ambiente effimero. I test di integrazione e gli altri controlli necessari vengono eseguiti in questo ambiente isolato e costruito per questo specifico scopo. Una volta convalidata la funzionalità e chiusa la PR, l’ambiente effimero viene chiuso. Questo approccio accelera il ciclo di vita di sviluppo del software e riduce i costi dell’infrastruttura.

Ci sono altri modi in cui l’uso di ambienti tradizionali può influenzare il ciclo di vita dello sviluppo del software; ecco alcuni esempi.

Esempio 1 – Un membro del team rilascia una funzionalità critica che funziona perfettamente in fase di sviluppo, ma che non funziona durante la distribuzione a causa di una mancata corrispondenza delle dipendenze. La ricerca del problema ritarda il rilascio del prodotto, frustrando sviluppatori e stakeholder.

Esempio 2 – Il team ha bisogno di dimostrare rapidamente nuove funzionalità agli stakeholder o al team di Quality Assurance (QA). La creazione di ambienti demo richiede tempo e risorse.

Esempio 3 – Il team gestisce numerosi microservizi e la QA deve convalidarli in varie condizioni simili alla produzione. Ciò richiede un’impostazione manuale, che è soggetta a errori e richiede molto lavoro.

Per mitigare queste limitazioni, uno degli approcci migliori è l’utilizzo di ambienti effimeri.

Cosa sono gli ambienti effimeri e perché sono importanti?

Gli ambienti effimeri sono ambienti temporanei di breve durata, on-demand, con le configurazioni e le risorse dell’ambiente desiderato. Questi ambienti sono repliche esatte di ambienti specifici, come quelli di produzione o di test, e possono essere creati quando necessario per i test, condivisi per le revisioni e smantellati una volta completata l’attività. 

Con gli ambienti effimeri, gli sviluppatori e i team di garanzia della qualità possono testare e sperimentare le funzionalità in modo indipendente, senza i vincoli degli ambienti tradizionali. Questo approccio contribuisce a semplificare il processo e a evitare ritardi.

Se integrati in un workflow GitOps, gli sviluppatori possono creare facilmente e automaticamente questi ambienti per servire da terreno per le revisioni basate su un particolare flusso Git, branch o pul requestl. Una volta completata l’azione Git (il branch viene unito o le PR vengono chiuse o unite), l’ambiente può essere facilmente distrutto, assicurando che le risorse del cloud siano utilizzate in modo efficiente e mantenendo il processo di sviluppo agile.

Gli ambienti effimeri e GitOps sono strettamente correlati in quanto entrambi enfatizzano l’automazione e la coerenza nello sviluppo del software. GitOps utilizza i repository Git per definire lo stato desiderato dell’infrastruttura e delle applicazioni, consentendo il provisioning automatico di ambienti effimeri per testare le modifiche al codice. In questo modo si garantisce che gli ambienti siano coerenti con la produzione, si isolano le attività di sviluppo, si facilita il controllo delle versioni e i rollback e si migliora la collaborazione tra i membri del team. Insieme, semplificano la pipeline CI/CD, promuovendo rilasci più rapidi e affidabili.

Gli ambienti effimeri si inseriscono nella Continuous Integration e Continuous Delivery (CI/CD) fornendo ambienti temporanei e isolati per testare le modifiche al codice.

In un workflow CI ideale, si potrebbe generare un ambiente effimero per le PR. Tuttavia, poiché questa operazione può richiedere molte risorse, molti team adottano una strategia mista, creando ambienti effimeri in modo selettivo, ad esempio per i feature branch o solo per le merge, bilanciando le esigenze di feedback con la capacità dell’infrastruttura.

In CD, consentono ai team di distribuire e testare le funzionalità in un ambiente simile a quello di produzione prima di fare merge o rilasciare in produzione. Questa integrazione aumenta la velocità, riduce i conflitti e garantisce processi di deploy coerenti e affidabili.

L’utilizzo di ambienti effimeri offre diversi vantaggi al vostro team. Esploriamone alcuni.

Vantaggi tecnici degli ambienti effimeri

L’utilizzo di ambienti effimeri durante il processo di sviluppo consente al team di lavorare in modo più efficiente. Ecco alcuni dei principali vantaggi che offrono:

Efficienza economica e ambientale: Poiché gli ambienti effimeri esistono solo per un periodo di tempo limitato, come un test, una build o un deploy, non consumano risorse quando non sono in uso, con conseguenti risparmi sui costi e vantaggi ambientali. Poiché i fornitori di cloud spesso fatturano in base all’utilizzo, gli ambienti effimeri possono contribuire a ottimizzare i costi dell’infrastruttura. Inoltre, riducendo il consumo di risorse, gli ambienti effimeri contribuiscono a ridurre l’impatto ambientale, allineandosi ai principi GreenOps per creare operazioni cloud più sostenibili.

Risoluzione dei problemi e debug potenziati: Grazie alla possibilità di replicare facilmente gli ambienti di produzione, le configurazioni effimere rendono più efficiente il debugging. Gli sviluppatori possono ricreare un ambiente con l’esatta configurazione in cui si è verificato un bug, consentendo una risoluzione dei problemi più accurata senza interrompere il flusso di lavoro principale dello sviluppo.

“Quando si sviluppa software, i bug sono un’eventualità. Utilizziamo ambienti effimeri per isolare il loro raggio d’azione.”
David Aronchick –  Co-founder at Hack

Supportare sviluppi in parallelo: Più team di sviluppo e operativi possono lavorare contemporaneamente su funzionalità o branch diversi, ciascuno all’interno del proprio ambiente isolato. In questo modo si riducono i colli di bottiglia e si possono creare flussi di lavoro paralleli senza il timore di conflitti ambientali, garantendo cicli di delivery più rapidi.

Sperimentazione e prototipazione: Mentre le pipeline CI/CD consentono l’integrazione e il deployment continui del codice, gli ambienti effimeri fanno un ulteriore passo avanti fornendo spazi isolati e temporanei per la sperimentazione rapida, l’A/B testing e la prototipazione di nuove funzionalità. Questi ambienti possono essere avviati per testare idee, convalidare ipotesi o integrare nuovi strumenti senza impattare i principali flussi CI/CD o i sistemi live. Se un esperimento fallisce, gli ambienti effimeri possono essere eliminati in modo sicuro, garantendo il recupero delle risorse senza interrompere il processo di sviluppo.

Secondo Stu Cairns, Head of Engineering in ambito Health e Disability, “la natura effimera degli ambienti crea enormi possibilità per la ricerca sugli utenti. Invece di avere prototipi isolati, ora possiamo modificare un percorso dell’utente, metterlo in un ambiente non di produzione e condurre ricerche sull’utente”.

Coerenza tra gli ambienti: Essendo creati dinamicamente a partire da configurazioni predefinite dell’infrastruttura e dell’applicazione, gli ambienti effimeri aiutano a garantire la coerenza tra le fasi di sviluppo, test e produzione. Grazie al provisioning automatico degli ambienti per ogni attività (come il test o la distribuzione), si riducono i problemi del tipo “funziona sulla mia macchina”, fornendo ambienti coerenti senza impostazioni manuali o discrepanze di configurazione.

Test avanzati di sicurezza e performance: Gli ambienti effimeri possono essere utilizzati per condurre test delle prestazioni e test di sicurezza avanzati, come i penetration test e la scansione delle vulnerabilità, in una configurazione controllata e isolata. Creando ambienti che rispecchiano la produzione, i team della piattaforma possono simulare attacchi e identificare i punti deboli senza rischiare l’integrità del sistema reale. Questa configurazione consente di effettuare valutazioni complete della sicurezza e delle prestazioni e di testare immediatamente le misure di correzione. Una volta completati i test, è possibile smantellare rapidamente gli ambienti effimeri, eliminando potenziali vulnerabilità persistenti e garantendo che le risorse vengano utilizzate solo quando necessario, mantenendo un ciclo di vita di sviluppo sicuro e ottimizzato.

Ci sono molti altri vantaggi che si possono ottenere in base al tipo di ambiente effimero che si desidera integrare nel proprio flusso di lavoro. Vediamo alcuni tipi comuni di ambienti effimeri.

Ambienti effimeri basati sull’ambiente vs. ambienti effimeri basati sui branch

Gli ambienti effimeri sono progettati per essere veloci, usa e getta e utili per flussi di lavoro specifici. Due tipi comuni sono gli ambienti effimeri Environment-Based e quelli Branch-Based. Sebbene entrambi servano a creare rapidamente ambienti di test, la differenza sta nel modo e nel momento in cui vengono utilizzati.

Ambienti effimeri Environment-Based

Con questo approccio, gli ambienti vengono creati in base a fasi specifiche del ciclo di vita dello sviluppo del software, come sviluppo, staging o produzione. L’idea è quella di replicare il più possibile gli ambienti di queste fasi, fornendo un banco di prova affidabile con tutte le sue dipendenze per eseguire il codice.

Perchè funzionano: L’obiettivo principale è quello di mantenere l’ambiente in sincronia con la fase di produzione su cui si sta lavorando. Quindi, se si sta sviluppando una funzionalità per la produzione, è possibile testarla in un ambiente che abbia l’aspetto e il comportamento della produzione. Questi ambienti sono solitamente riutilizzabili, il che significa che diversi team o sviluppatori possono testare il loro lavoro senza dover creare ambienti separati per ogni attività.

Fattori chiave

• Parità ambientale: Si ottiene una replica quasi perfetta dello stage su cui si sta lavorando, riducendo le sorprese in fase di produzione.
• Utilizzo condiviso: Questi ambienti possono gestire test per diverse funzionalità o modifiche, in modo che più team possano utilizzarli senza pestarsi i piedi a vicenda.
• Configurazioni con versione: Abbinati a Infrastructure as Code (IaC), questi ambienti vengono creati utilizzando modelli predefiniti, per mantenere la coerenza.

Quando usarli: Questa configurazione è ideale per i test QA, per i test di carico o per la convalida delle modifiche prima di un rilascio importante. Se il vostro team ha bisogno di un ambiente di test affidabile che rispecchi la produzione, questa è la strada da seguire.

Ambienti effimeri Branch-Based

Questo approccio lega gli ambienti direttamente ai branch in version control. Ogni volta che viene creato un nuovo branch o una pull request (PR), viene creato un ambiente che include le modifiche in quel branch. Una volta che la PR viene unita o chiusa, l’ambiente viene automaticamente distrutto.

Perchè funzionano: Ogni branch o funzionalità ha un proprio ambiente isolato, in modo da poter testare le modifiche senza preoccuparsi di interferire con il lavoro degli altri sviluppatori. Questi ambienti vengono creati automaticamente e scompaiono una volta terminato il branch, il che li rende ideali per test rapidi e feedback più veloci. Questi ambienti richiedono molte risorse in progetti di grandi dimensioni e possono diventare difficili da gestire se non sono ben controllati. L’approccio più utilizzato è quello degli ambienti effimeri PR.

Fattori chiave

• Isolamento delle feature: Ogni branch ha il proprio ambiente, il che significa che si possono fare test senza influenzare la codebase principale.
• Automazion: Strumenti come Jenkins o GitHub Actions è in grado di attivare e disattivare ambienti specificamente attivati dalla creazione e dalla chiusura di branch o pull request.
• Feedback immediato: Gli sviluppatori e i revisori hanno a disposizione un ambiente live con cui giocare, accelerando i test e l’approvazione.

Quando usarli: Un ambiente effimero basato su un branch dovrebbe essere usato quando si vogliono testare nuove funzionalità, correzioni di bug o altre modifiche in isolamento prima di unirle alla base di codice principale. Ciò consente di garantire che le modifiche funzionino come previsto e non introducano nuovi problemi. È particolarmente utile per i flussi di lavoro di integrazione e distribuzione continua, in quanto fornisce un ambiente coerente e riproducibile per ogni ramo.

Creare ambienti effimeri su Kubernetes (K8s)

Gli ambienti effimeri funzionano meglio con i flussi di lavoro basati su container, poiché questi flussi di lavoro consentono di raggruppare le applicazioni con le loro dipendenze. Strumenti di orchestrazione dei container come Kubernetes sono diventati popolari per la gestione dei container di applicazioni, offrendo soluzioni per scaling, distribuzione e manutenzione. Kubernetes consente la creazione di ambienti effimeri grazie al suo funzionamento sottostante.

Grazie al suo approccio dichiarativo, è possibile utilizzarlo insieme al flusso di lavoro GitOps, utilizzando strumenti come Argo CD e GitHub Actions per automatizzare la creazione e la cancellazione degli ambienti, assicurando che gli ambienti siano coerenti e facilmente riproducibili direttamente dal repository Git.

Vediamo brevemente il processo di configurazione degli ambienti effimeri in Kubernetes e come automatizzare il processo utilizzando GitOps con GitHub.

Impostare ambienti effimeri su Kubernetes

Per impostare gli ambienti effimeri, si deve iniziare a preparare il cluster Kubernetes e a definire il modo in cui l’applicazione deve essere distribuita. Ogni pull request o branch può innescare la creazione di un nuovo ambiente, isolato nel proprio namespace.

Una volta che il deployment ha raggiunto il suo scopo, Kubernetes consente di ripulire automaticamente l’ambiente, assicurando che non vengano sprecate risorse.

Ecco come fare:

• Preparare il cluster Kubernetes: È necessario un cluster Kubernetes, sia su un provider cloud (es. GKE, EKS, AKS) sia localmente (es. Minikube, Kind). Assicuratevi di configurare l’accesso con un file kubeconfig, perché è quello che il vostro sistema di automazione userà per interagire con il cluster.
• Creare la configurazione dell’applicazione: Definire l’infrastruttura e le impostazioni di deploy dell’applicazione in file manifest YAML di Kubernetes. Questi file descrivono risorse quali deploy, servizi e ingress. Includere placeholder per valori dinamici, come namespce o application name, per personalizzare l’ambiente per ogni pull request.
• Definire la gestione dei namespace: i namespaces su Kubernetes permettono di isolare le risorse per ambienti diversi. Per gli ambienti effimeri, si creerà uno spazio dei nomi dinamicamente per ogni pull request. In questo modo si evitano i conflitti tra gli ambienti e si garantisce un isolamento completo.
• Impostare sistemi CI/CD: Per automatizzare la creazione e la cancellazione di questi ambienti, si utilizzerà un sistema CI/CD come GitHub Actions. Il sistema attiverà i flussi di lavoro quando si apre o si aggiorna una richiesta di pull.

Come impostare ambienti effimeri su GitHub (GitOps)

È possibile automatizzare la creazione e lo smantellamento di questi ambienti utilizzando GitOps. Per farlo, è necessario combinare ArgoCD e GitHub Actions. 

Argo CD assicura che il cluster Kubernetes rimanga sincronizzato con lo stato desiderato definito nel repository Git (il repository che ospita le configurazioni Kubernetes), distribuendo e aggiornando automaticamente le risorse per l’ambiente effimero. GitHub Actions gestisce l’automazione guidata dagli eventi, attivando i workflow quando una pull request viene aperta, unita o chiusa. Gestisce dinamicamente attività come la creazione di namespace, l’iniezione di configurazioni specifiche per la PR e la pulizia delle risorse.

Ecco il flusso di lavoro complessivo:

1. Monitorare il repository GitHub: Argo CD è configurato per tenere traccia delle modifiche nel vostro repository GitHub. Applica automaticamente le modifiche quando viene aperta una nuova pull request (PR).
2. La PR innesca il Deploy: Una GitHub Action viene eseguita ogni volta che viene aperta una PR. Crea un namespace in Kubernetes specifico per la PR e distribuisce l’applicazione e le relative configurazioni in questo namespace.
3. Smantellamento: Quando la PR è unita o chiusa, l’ambiente e il suo namespace vengono ripuliti.

Ogni volta che si apre una PR, vengono creati un nuovo spazio dei nomi e un ambiente effimero su Kubernetes. Questo assicura ambienti isolati per ogni feature branch. Quando la PR viene unita o chiusa, l’ambiente viene automaticamente chiuso.

Sfide comuni nella transizione da ambienti tradizionali ad ambienti effimeri

Quando si passa da ambienti tradizionali ad ambienti effimeri, si possono incontrare le seguenti problematiche:

• Complessità del setup: Il passaggio da un’infrastruttura tradizionale ad ambienti effimeri richiede spesso cambiamenti significativi in termini di strumenti, flussi di lavoro e competenze. La configurazione iniziale può essere complessa, con una curva di apprendimento ripida per i team che non hanno familiarità con gli strumenti necessari.
• Gestione delle risorse: Gli ambienti effimeri possono essere ad alta intensità di risorse e richiedono solide strategie di provisioning del cloud per evitare l’uso eccessivo o i costi.
• Persistenza dello stato: Gestione della persistenza dei dati in ambienti di breve durata, soprattutto per i test che richiedono database o servizi statici, che possono essere impegnativi.
• Compatibilità con sistemi legacy: L’integrazione di ambienti effimeri nei flussi di lavoro esistenti può essere difficile quando si ha a che fare con sistemi legacy che potrebbero non supportare la containerizzazione moderna o gli approcci cloud-native.
• Costi di transizione: La migrazione ad ambienti effimeri comporta non solo adeguamenti tecnici, ma anche potenziali interruzioni degli attuali flussi di lavoro e della produttività del team, aumentando il costo complessivo della transizione.

Come mitigare queste sfide

Per ridurre l’impatto di queste problematiche, è possibile utilizzare strumenti e servizi quali:

• Strumenti di automazione: L’utilizzo di strumenti Infrastructure as Code (IaC) come Terraform o Kubernetes può aiutare ad automatizzare e semplificare il processo di configurazione dell’ambiente. 
• Monitoraggio dei costi: Implementare un adeguato monitoraggio delle risorse per tenere traccia dell’utilizzo delle risorse e dei costi associati.
• Polivy di Auto-scaling: Impostazione di politiche di autoscaling per gestire le risorse in modo efficiente e ridurre i costi.
• Servizi Stateless: Utilizzo di servizi mock, database pre-seminati o snapshot di dati versionati per risolvere i problemi di persistenza dello stato.

• Internal Developer Portals possono essere una valida soluzione; si tratta di interfacce di facile utilizzo che collegano gli sviluppatori alle piattaforme interne, consentendo loro di accedere agli strumenti in modo semplificato, riducendo il carico cognitivo e consentendo l’autonomia del self-service. Gli ambienti effimeri possono essere integrati in questi portali attraverso:
  • • • Attivazione diretta di configurazioni di ambienti con impostazioni preconfigurate 
      • Monitoraggio degli ambienti per regolare le risorse in base alla domanda, riducendo al minimo gli sprechi.
      • Integrazione con pipeline CI/CD per test e deploy automatici. 
      • Gestione degli accessi per garantire che solo gli utenti autorizzati possano creare o interagire con gli ambienti, mantenendo gli standard di sicurezza e governance

Takeaways

Gli ambienti sono essenziali per il ciclo di vita dello sviluppo, in quanto forniscono spazi per il test, lo staging e il deploy del software. Tuttavia, affidarsi agli ambienti tradizionali spesso introduce dei colli di bottiglia, rallentando i progressi e aumentando i costi a causa della scarsità di risorse. Gli ambienti effimeri, invece, offrono una soluzione dinamica, scalabile ed economica, che consente di eseguire test efficienti, cicli di sviluppo e distribuzione rapidi, integrandosi perfettamente nelle pipeline CI/CD.

Consentendo al team di sviluppo di creare e smantellare ambienti su richiesta, questo approccio garantisce la coerenza tra le varie fasi di sviluppo, riduce i costi dell’infrastruttura e accelera il ritmo di delivery. Mia-Platform offre un approccio semplificato all’implementazione di questi ambienti effimeri.

Per vedere quanto sia facile implementare gli ambienti effimeri nel vostro flusso di lavoro, consultate la documentazione completa di Mia-Platform che vi guida attraverso il processo.