Infrastructure as Code: il confine sottile tra automazione virtuosa e debito tecnico fuori controllo

L'Infrastructure as Code — IaC per chi lavora nel settore da un po' — è diventata una delle pratiche più citate nei piani di trasformazione digitale delle aziende italiane. L'idea di fondo è elegante: descrivere l'intera infrastruttura attraverso file di configurazione versionati, applicabili in modo deterministico su qualsiasi ambiente. Niente più configurazioni manuali, niente più "funzionava sul server di staging", niente più notti insonni prima dei rilasci.

Eppure, nelle realtà operative di molte organizzazioni, la promessa si scontra con una realtà meno rosea. Repository IaC che crescono senza criteri, stati Terraform corrotti, moduli Ansible scritti da chi non lavora più in azienda, stack CloudFormation impossibili da aggiornare senza rischiare un rollback catastrofico. Il problema non è lo strumento in sé: è l'approccio con cui viene adottato.

Scegliere lo strumento giusto non è una questione religiosa

Il primo errore che commettono molti team è affrontare la scelta tra Terraform, Ansible e CloudFormation come se fosse una disputa ideologica. In realtà, questi strumenti rispondono a esigenze diverse e spesso si integrano in modo complementare.

Terraform, sviluppato da HashiCorp e ora sotto la licenza BSL, eccelle nella gestione dichiarativa delle risorse cloud. Il suo modello a stato — il famoso terraform.tfstate — consente di tracciare la configurazione desiderata e riconciliarla con quella effettiva. È la scelta naturale per chi deve orchestrare risorse su AWS, Azure, Google Cloud o ambienti ibridi. Il limite? Lo stato deve essere gestito con cura: un file di stato corrotto o non aggiornato può portare a duplicazioni di risorse o, peggio, alla distruzione di infrastruttura in produzione.

Ansible si posiziona invece come strumento di configuration management e orchestrazione procedurale. Non mantiene uno stato centralizzato — il che lo rende più semplice da adottare inizialmente — ma proprio questa caratteristica può diventare un problema in infrastrutture complesse: senza uno stato, è difficile sapere con certezza cosa è stato applicato e dove. Ansible brilla nella gestione della configurazione a livello di sistema operativo, nell'automazione di task ripetitivi e nell'integrazione con sistemi legacy.

AWS CloudFormation (e il suo equivalente Azure Resource Manager) è la scelta obbligata per chi lavora in ambienti fortemente vincolati a un singolo cloud provider. Offre integrazione nativa con i servizi AWS e gestione degli stack con rollback automatico. Il rovescio della medaglia è la verbosità del formato YAML/JSON e la limitata portabilità verso altri provider.

La risposta alla domanda "quale strumento scegliere" è quasi sempre: dipende. Dipende dall'infrastruttura esistente, dalle competenze del team, dai vincoli normativi e dalla strategia cloud dell'organizzazione. Quello che non dipende da niente è la necessità di una scelta consapevole, documentata e condivisa.

Gli errori di versionamento che costano più caro

Una volta scelto lo strumento, il secondo punto critico riguarda il versionamento. Trattare i file IaC come semplici script da tenere su una cartella condivisa — o peggio, su un desktop locale — è ancora più pericoloso che non avere IaC affatto. Perché crea una falsa sensazione di controllo.

I pattern problematici più comuni che si osservano nelle organizzazioni italiane di medie dimensioni includono:

• Branch di lunga durata: feature branch IaC che divergono dal main per settimane, accumulando modifiche difficili da riconciliare. Una regola pratica efficace è imporre merge entro 48-72 ore o, in alternativa, adottare trunk-based development anche per il codice infrastrutturale.

• Assenza di tagging semantico: senza tag di versione espliciti sui moduli Terraform o sui ruoli Ansible, ogni aggiornamento diventa potenzialmente distruttivo. Il versioning semantico (MAJOR.MINOR.PATCH) dovrebbe essere obbligatorio per qualsiasi modulo riutilizzabile.

• Segreti nel repository: credenziali, chiavi API e certificati che finiscono — per distrazione o fretta — nei file di configurazione. Uno strumento come HashiCorp Vault, AWS Secrets Manager o Azure Key Vault non è un optional: è un prerequisito.

• Mancanza di code review per le modifiche IaC: molte organizzazioni applicano processi rigorosi di revisione al codice applicativo ma trattano le modifiche infrastrutturali come operazioni di routine. Un errore in un file .tf può avere conseguenze molto più gravi di un bug applicativo.

Governance: la componente che nessuno vuole progettare

Il vero discrimine tra un'implementazione IaC virtuosa e un debito tecnico in crescita esponenziale non è tecnico: è organizzativo. La governance dell'infrastruttura codificata richiede decisioni esplicite su chi può approvare modifiche, come vengono gestiti gli ambienti (sviluppo, staging, produzione), quale processo autorizza un terraform apply in produzione.

Un modello che funziona in contesti aziendali strutturati prevede:

1. Repository separati per ambienti diversi oppure workspace dedicati con variabili di ambiente isolate. La promiscuità tra configurazioni di test e produzione è una delle cause più frequenti di incidenti.

2. Pipeline CI/CD per la validazione e l'applicazione: ogni modifica al codice IaC dovrebbe passare attraverso una pipeline automatizzata che esegue terraform validate, terraform plan e — dopo approvazione umana — terraform apply. Strumenti come Atlantis o Spacelift offrono workflow specifici per questo scopo.

3. Policy as Code: soluzioni come Open Policy Agent (OPA) o Sentinel di HashiCorp permettono di codificare i vincoli di compliance direttamente nella pipeline, bloccando configurazioni non conformi prima che raggiungano l'ambiente di produzione.

4. Documentazione automatica: i moduli IaC ben strutturati dovrebbero generare documentazione leggibile automaticamente. Strumenti come terraform-docs riducono il carico cognitivo per chi deve manutenere il codice mesi dopo averlo scritto.

Quando l'IaC diventa un incubo: i segnali da non ignorare

Esistono indicatori precisi che segnalano un'implementazione IaC in difficoltà. Se il team teme di eseguire terraform plan perché "non si sa mai cosa potrebbe cambiare", se i moduli non vengono aggiornati da oltre sei mesi, se esistono risorse cloud non tracciate dallo stato IaC (le cosiddette risorse "orfane"), se la documentazione è assente o obsoleta: sono tutti segnali che il debito tecnico ha già superato un livello critico.

In questi casi, la soluzione non è abbandonare l'IaC — sarebbe come eliminare il sistema di controllo versione perché il repository è disordinato. La soluzione è un audit strutturato: riconciliare lo stato effettivo dell'infrastruttura con quello codificato, eliminare le risorse orfane, refactoring dei moduli più critici, e — soprattutto — stabilire un processo di governance che impedisca al problema di ripresentarsi.

Costruire un workflow IaC che scala con l'organizzazione

L'obiettivo finale non è avere "dell'IaC" — è avere un'infrastruttura governabile, riproducibile e comprensibile da chiunque nel team. Questo richiede investimento iniziale in progettazione, formazione e strumenti. Richiede la volontà di rallentare nella fase di setup per accelerare in modo sostenibile nelle fasi successive.

Le organizzazioni che ottengono i risultati migliori dall'Infrastructure as Code sono quelle che la trattano con lo stesso rigore del software applicativo: code review, test automatizzati, documentazione, versionamento semantico, e una cultura in cui "funziona" non è sufficiente se non è anche comprensibile, manutenibile e sicuro.

L'automazione dell'infrastruttura è uno degli investimenti più redditizi che un'azienda IT possa fare. Ma come ogni investimento, il rendimento dipende dalla qualità dell'esecuzione — non dalla sola intenzione.