Man mano che sempre più organizzazioni passano al cloud, l’abilità di sapere come eseguire il provisioning e configurare un server fisico sta diventando meno rilevante per il modo in cui viene costruito e distribuito il software moderno. Nel complesso mondo odierno guidato dal software, in cui l’infrastruttura informatica spesso non è né vista né ascoltata, essere in grado di fornire e gestire tale infrastruttura utilizzando codice dichiarativo, piuttosto che configurazioni manuali o persino script, è fondamentale per eseguire applicazioni su scala web.

Una breve storia dell’infrastructure as code

Sebbene gli amministratori di sistema utilizzino gli script per gestire la propria infrastruttura sin dagli anni ’90, la pratica di trattare l’infrastructure as code (IaC – Infrastruttura come codice) non si è completamente formata fino alla fine degli anni 2000, quando ingegneri come il pioniere devops Andrew Clay-Shafer, il cofondatore di Chef Adam Jacob e il fondatore di Puppet Luke Kanies hanno iniziato a usare questa terminologia.

In un mondo di applicazioni distribuite, i server di ottimizzazione manuale non sarebbero mai stati scalabili e lo scripting aveva i suoi limiti; essere quindi in grado di automatizzare il provisioning dell’infrastruttura è diventato un’esigenza fondamentale per molti first mover nei primi giorni del cloud.

Oggi, l’infrastruttura sottostante è più comunemente fornita come codice grazie ai primi strumenti popolari in questo ambito come Chef, Puppet, SaltStack e Ansible. Ma la tecnologia si muove velocemente e da allora le cose sono inevitabilmente cambiate. Di seguito vi spieghiamo i fondamenti dell’infrastructure as code e perché è la base delle moderne pratiche di sviluppo del software.

Definizione di infrastructure as code

In Infrastructure as Code: Dynamic Systems for the Cloud Age, Kief Morris spiega che l’infrastruttura come codice si riduce a tre pratiche fondamentali: “Definire tutto come codice, testare e distribuire continuamente tutto mentre lavorate e costruire il proprio sistema partendo da piccoli pezzi”.

In termini di definizione operativa, secondo Morris il modello IaC “è un approccio all’automazione dell’infrastruttura basato sulle pratiche dello sviluppo del software, che enfatizza routine coerenti e ripetibili per il provisioning e la modifica dei sistemi e la loro configurazione.”

All’atto pratico ciò significa che i team devops apportano modifiche a una descrizione dell’ambiente e alla versione del modello di configurazione utilizzando un linguaggio ben documentato come JSON o YAML. Una volta configurato l’ambiente, è possibile apportare modifiche all’origine, non alla destinazione, consentendo modifiche più sicure e regolari all’infrastruttura su scala molto più ampia.

Dove l’infrastructure as code e devops si incontrano

Come metodo per automatizzare la configurazione iniziale e le modifiche successive, l’infrastruttura come codice è una parte fondamentale delle moderne pratiche devops, in cui ci si aspetta che sviluppatori e operatori lavorino fianco a fianco per distribuire il software più rapidamente e più spesso. Automatizzando e verificando le versioni dell’infrastruttura, gli strumenti IaC possono aiutare gli sviluppatori di applicazioni a concentrarsi su ciò che sanno fare meglio e a liberare gli amministratori di sistema dal faticoso lavoro su processi manuali.

L’utilizzo del codice per il provisioning e la manutenzione dell’infrastruttura aiuta sia ad avvicinare gli sviluppatori e gli specialisti delle operazioni nelle prime fasi del ciclo di vita dello sviluppo software, sia a infondere la disciplina, la chiarezza e la ripetibilità dello sviluppo software nelle operazioni. Poiché l’automazione e la collaborazione sono i principi chiave delle pratiche devops, gli strumenti IaC diventano anche un hub centrale per il modo in cui quel team lavora insieme in modo efficace.

applicazioni adattive

I vantaggi dell’infrastructure as code

I principali vantaggi di questo modello sono da ricercarsi nell’abbandono dei processi manuali e nella libertà che l’automazione offre ai team devops. Ciò comporta un certo grado di risparmio sui costi e può anche aumentare la velocità con cui questi team possono apportare modifiche in modo sicuro alle loro applicazioni.

Come ha scritto il cofondatore di Simple Thread Justin Etheredge in un articolo dello scorso anno, “l’infrastruttura come codice dà la libertà di apportare modifiche senza il timore di rendere le cose irrecuperabili, oltre a fornire una migliore comprensione di come l’ambiente sia diventato così com’è; ciò consente di essere più sicuri nell’apportare i cambiamenti di cui avete bisogno”.

Nel suo libro, Morris delinea anche sette vantaggi chiave del modello IaC rispetto ai metodi di provisioning tradizionali.

  • Utilizzare l’infrastruttura IT come fattore abilitante per la fornitura rapida di valore
  • Ridurre lo sforzo e il rischio di apportare modifiche all’infrastruttura
  • Consentire agli utenti dell’infrastruttura di ottenere le risorse di cui hanno bisogno, quando ne hanno bisogno
  • Fornire strumenti comuni per lo sviluppo, le operazioni e le funzioni correlate
  • Creare sistemi affidabili, sicuri ed economici
  • Rendere visibili i controlli di governance, sicurezza e conformità
  • Migliorare la velocità per la risoluzione dei problemi

Strumenti per l’infrastructure as code

Gli strumenti necessari per implementare l’infrastructure as code interessano principalmente due ambiti: orchestrazione della configurazione e gestione della configurazione. Gli strumenti di orchestrazione più popolari sono AWS CloudFormation, Google Cloud Deployment Manager, HashiCorp Terraform, Microsoft Azure Resource Manager e Pulumi, che consentono agli sviluppatori di automatizzare la distribuzione dell’infrastruttura.

Per quanto riguarda la gestione della configurazione, strumenti di terze parti come Ansible, Chef, Puppet e SaltStack rimangono modi popolari per configurare, archiviare e automatizzare le build di ambienti server virtuali, mentre molti sviluppatori utilizzano Docker per le loro immagini dei container.

Molti di questi strumenti possono essere utilizzati in tandem, come nel caso di Ansible, Chef, Puppet e SaltStack che si concentrano sulla gestione delle configurazioni su infrastrutture già esistenti, mentre gli strumenti di provisioning come Terraform astraggono quel livello di infrastruttura.

Muovere i primi passi

In genere l’adozione dell’infrastructure as code è parte di un più ampio spostamento organizzativo verso il cloud e le pratiche di devops. Sebbene parte di questo cambiamento possa sembrare piuttosto intimidatoria, l’implementazione dell’infrastruttura come codice è la chiave per modernizzare il vostro approccio alla creazione e all’esecuzione del software.

“A volte può essere necessario un po’ più di tempo per apportare modifiche con l’infrastruttura come codice”, avverte Etheredge, “ma questa è una di quelle situazioni in cui è necessario rallentare per accelerare. Essere diligenti nell’apportare modifiche attraverso i vostri script vi farà indubbiamente risparmiare innumerevoli ore durante un’interruzione o durante la risoluzione dei problemi. E sarete molto più sicuri delle vostre modifiche perché potete testare quella modifica in un ambiente di prova invece di incrociare le dita ed eseguire l’aggiornamento direttamente in produzione. Anche in ambienti piccoli i profitti possono essere enormi”.

Oppure, come ha scritto Morris, “l’automazione della vostra infrastruttura richiede lavoro, ma farlo vi aiuterà enormemente ad apportare modifiche, inclusa la costruzione del sistema”.