Gestire l'infrastruttura tecnologica di un'applicazione moderna è un'impresa che va ben oltre la semplice configurazione di qualche server. Si tratta di orchestrare un ecosistema complesso fatto di bilanciatori di carico, firewall, database, cluster di container e una serie di strumenti che supportano l'intero ciclo di vita del software, dallo sviluppo al rilascio in produzione. Con l'accelerazione impressa dai modelli DevOps, la gestione manuale di tutto questo è diventata insostenibile, aprendo la strada a un paradigma che ha rivoluzionato il settore: l'Infrastructure as Code, comunemente abbreviato in IaC.
Il concetto alla base è semplice: invece di configurare manualmente server e risorse attraverso interfacce grafiche o procedure operative standard, si scrive codice che descrive e gestisce l'infrastruttura in modo automatico e riproducibile. Questo approccio consente di trattare l'infrastruttura esattamente come si tratta il codice applicativo, con tutto ciò che ne consegue in termini di versionamento, tracciabilità e automazione. Vale la pena chiarire subito un equivoco frequente: IaC non è la stessa cosa dell'Infrastructure as a Service (IaaS), ovvero i servizi cloud come AWS o Azure. Lo IaC, al contrario, si applica tanto agli ambienti cloud quanto a quelli on-premise, ovvero alle infrastrutture fisiche gestite direttamente dalle aziende.
Dal punto di vista tecnico, esistono due grandi famiglie di infrastrutture codificate: quelle mutevoli e quelle immutabili. Le prime ammettono modifiche e aggiornamenti progressivi sui componenti esistenti, un approccio flessibile ma che nel tempo può portare a configurazioni disallineate tra ambienti diversi. Le seconde, invece, seguono una logica più rigida e più moderna: quando un componente deve cambiare, non viene modificato ma sostituito integralmente con uno nuovo, costruito secondo le specifiche aggiornate. Questo garantisce uniformità assoluta e riduce drasticamente i margini di errore legati alle cosiddette derive di configurazione, quei piccoli disallineamenti che si accumulano nel tempo e che possono causare comportamenti imprevedibili in produzione.
Due tipi di approccio
La scelta tra questi due modelli si intreccia con un'altra distinzione fondamentale: quella tra approccio dichiarativo e approccio imperativo nella scrittura del codice IaC. Chi adotta un approccio imperativo deve specificare passo dopo passo le operazioni che il sistema deve compiere per raggiungere la configurazione desiderata, un po' come scrivere una ricetta dove ogni istruzione deve essere seguita nell'ordine esatto. Chi invece sceglie l'approccio dichiarativo si limita a descrivere il risultato finale che vuole ottenere, lasciando allo strumento il compito di capire come arrivarci.
Entrambi gli approcci hanno pregi e difetti concreti. Il modello dichiarativo è più adatto alla gestione di infrastrutture complesse perché è intrinsecamente idempotente: si possono eseguire gli stessi comandi più volte ottenendo sempre il medesimo risultato. Gestisce bene anche la deriva di configurazione, poiché non definisce passi espliciti ma stati desiderati. Il rovescio della medaglia è una minore granularità nel controllo del processo di provisioning e una certa complessità eccessiva per interventi piccoli e mirati che potrebbero essere risolti con un semplice script da riga di comando.
L'approccio imperativo, al contrario, restituisce al team pieno controllo su ogni fase del processo ed è particolarmente indicato per ottimizzazioni specifiche o piccole correzioni. Tuttavia richiede competenze di scripting elevate e presenta un rischio significativo: un errore in un singolo passaggio può compromettere l'intera sequenza operativa. Per team alle prime armi con DevOps, questa curva di apprendimento può rappresentare un ostacolo concreto. La maggior parte delle organizzazioni che puntano a un'automazione completa dell'infrastruttura finisce per preferire il modello dichiarativo, riservando quello imperativo a scenari più circoscritti.
I vantaggi pratici dell'adozione di IaC sono molteplici e toccano aspetti diversi del ciclo di sviluppo. Sul piano della velocità, il provisioning automatico è semplicemente più rapido di qualsiasi procedura manuale, e questo vale per server, database, reti e gestione degli account utente. Sul piano della consistenza, eliminare l'intervento umano nelle fasi di configurazione significa ridurre drasticamente le variabilità tra ambienti diversi. Un ambiente di test che replica fedelmente la produzione non è più un obiettivo ambizioso ma una conseguenza naturale del processo.
C'è poi l'integrazione con le pipeline CI/CD, le catene di integrazione e distribuzione continua che rappresentano la spina dorsale di qualsiasi processo DevOps moderno. Poiché l'infrastruttura è codice a tutti gli effetti, può essere sottoposta agli stessi controlli di versione, test automatici e processi di revisione del codice applicativo. Questo allineamento tra sviluppo e operations è uno degli obiettivi centrali della filosofia DevOps e IaC ne è uno degli abilitatori più potenti.
Un esempio pratico
Un esempio concreto aiuta a capire come tutto questo si traduca nella pratica quotidiana: uno sviluppatore che sta lavorando a una nuova funzionalità. Prima di rilasciarla in produzione, deve verificare che il codice funzioni in un ambiente identico a quello live. Grazie a IaC, lo sviluppatore può automaticamente generare un ambiente di test virtuale che replica fedelmente la produzione, con le stesse versioni dei servizi, gli stessi dati e la stessa configurazione. Se il codice funziona lì, funzionerà anche in produzione. Quello che in passato richiedeva ore di lavoro coordinato tra sviluppatori, amministratori di sistema, amministratori di database e tester, oggi può essere gestito in autonomia da una singola persona attraverso istruzioni codificate che si attivano automaticamente.
Naturalmente, IaC non è privo di complessità. L'adozione di questi strumenti richiede formazione, e una configurazione errata può propagarsi rapidamente attraverso l'intera infrastruttura proprio perché l'automazione amplifica ogni intervento, nel bene e nel male. Il monitoraggio del versionamento e i test pre-rilascio diventano quindi componenti essenziali di qualsiasi strategia IaC matura.
Sul mercato esistono strumenti pensati per esigenze diverse. Per la gestione dell'infrastruttura in senso ampio, i riferimenti principali sono
- Terraform di HashiCorp
- Pulumi
- AWS CloudFormation
- Azure Resource Templates
Per la gestione della configurazione con capacità infrastrutturali più limitate si ricorre invece ad Ansible, Chef o Puppet. Raramente uno strumento solo basta: nella pratica è comune combinare Terraform per il provisioning multi-cloud con Ansible per le configurazioni applicative più granulari, integrando il tutto nelle pipeline CI/CD secondo i requisiti specifici del progetto.
Terraform
Con Terraform scrivi configurazioni dichiarative in file leggibili, definendo provider e risorse; i provider collegano Terraform ai servizi cloud e i moduli servono a riusare configurazioni comuni. Terraform mantiene anche uno state file, cioè una fotografia delle risorse gestite, che usa per tracciare i cambiamenti e capire cosa creare, modificare o eliminare nei deploy successivi.
È molto usato quando vuoi un solo workflow per più cloud, ambienti ibridi o anche servizi SaaS, mantenendo tutto versionabile e collaborativo.
Pulumi
Pulumi segue lo stesso obiettivo dell’IaC, ma ti permette di definire l’infrastruttura usando TypeScript, Python, Go, .NET, Java o YAML invece di un linguaggio dedicato come HCL. Il motore di deployment interpreta il codice, confronta lo stato desiderato con quello corrente e interagisce con le API del cloud per creare, aggiornare o rimuovere le risorse. È comodo per team molto orientati allo sviluppo software, perché si integra bene con test, CI/CD e pratiche tipiche del codice applicativo.
AWS CloudFormation
CloudFormation usa template JSON o YAML come blueprint delle risorse AWS e gestisce l’insieme come uno stack, cioè un’unità logica di deployment.
Quando crei uno stack puoi passare parametri per personalizzare il deployment, e prima di aggiornare puoi usare i change set per vedere quali modifiche verranno applicate. Funziona bene se lavori soprattutto in AWS e vuoi restare dentro l’ecosistema nativo della piattaforma.
Azure Resource Templates
Nel mondo Azure, con “Azure Resource Templates” di solito si intendono gli ARM templates, file JSON dichiarativi gestiti da Azure Resource Manager.
Un template può contenere parametri, variabili, funzioni, risorse e output, così puoi riusare lo stesso schema in ambienti diversi e ottenere in uscita i valori generati dal deploy. Sono utili quando vuoi automazione nativa su Azure e una struttura modulare, perché i template possono essere suddivisi in componenti più piccoli e collegati o annidati tra loro.
Schema mentale
Terraform è ideale per standardizzare su più provider, Pulumi per chi preferisce programmare l’infrastruttura, CloudFormation per ambienti centrati su AWS e ARM templates per ambienti centrati su Azure. Un esempio semplice è questo: per creare una VM con rete e storage, in tutti i casi descrivi il risultato desiderato in un progetto; poi il tool confronta quella descrizione con lo stato reale e applica le modifiche necessarie.
Gli strumenti IaC si differenziano anche per il meccanismo con cui applicano le configurazioni. Nel modello push, un server centralizzato invia attivamente le istruzioni ai sistemi target. Nel modello pull, sono i sistemi stessi a interrogare periodicamente il server centrale per ricevere aggiornamenti. Quasi tutti gli strumenti supportano entrambe le modalità, anche se ognuno ha una preferenza di default. Sul piano dei linguaggi, alcuni strumenti usano un Domain Specific Language proprietario, altri si appoggiano a formati standard come YAML o JSON, più familiari a chi ha già esperienza con ambienti cloud. La scelta dello strumento giusto dipende quindi non solo dall'infrastruttura target, ma anche dalle competenze del team e dall'ecosistema tecnologico già in uso.
