Se non è descritto non esiste
Nel mondo dell’infrastruttura, la realtà è ciò che può essere dichiarato. Il resto è rumore, è emergenza, è dimenticanza.
Terraform non è solo uno strumento: è un modo di vedere. Una grammatica del controllo, della ripetibilità, della chiarezza.
Ho cominciato a riscrivere tutto — ambienti di sviluppo, staging, servizi dei clienti — partendo da un principio: se non posso versionarlo, non posso comprenderlo.
Questa è la mia terraformazione. Un processo tecnico, sì, ma anche esistenziale. Un atto di ordine contro l’entropia digitale.
Il problema: ambienti disallineati, conoscenza distribuita, caos.
Per anni ho lavorato in ambienti dove l’infrastruttura era tramandata oralmente, come una leggenda.
Quel server? “È lì da sempre.”
Quella variabile d’ambiente? “Non toccarla.”
Quel container? “Funziona solo se lo lanci da quella directory, con quel profilo e se hai spento quell’applicativo.”
Lo chiamavamo infrastruttura, ma era più simile a un rituale.
Nei casi più fortuiti ogni progetto aveva il suo readme.md a metà, qualche script di provisioning con nomi molto eloquenti tipo “deploy_ver4_db_temp.sh”, e molta, moltissima memoria umana indispensabile per far girare le cose.
Un manifesto della fragilità
La natura del mio lavoro è mettere in ordine cose che nessuno voleva sistemare.
Ho visto molte aziende, diverse dimensioni e in questo senso, anche in quelle più strutturate, la tendenza a non documentare regna sovrana; inizialmente ho pensato di mettermi io a documentare il tutto, volevo colmare un vuoto. Poi ho capito.
Documentare a posteriori è come cercare l’acqua con la bacchetta da rabdomante.
Ogni dettaglio sfugge, ogni eccezione apre un nuovo capitolo, ogni modifica rende la documentazione vecchia ancora prima di essere salvata.
Citando altri: Docker ha risolto il problema del “Sul mio computer funziona”.
L’impatto che Docker ha avuto nel mio lavoro è stato devastante, ha dato un senso a molte cose, ha reso più semplice la gestione di ambienti e requisiti differenti, ha reso possibile lavorare su molti progetti senza dover impazzire più di tanto, ha ridotto notevolmente il margine di errore.
Ma lo ha fatto a modo suo: incapsulando, congelando, separando.
Non ha reso l’ambiente più semplice, lo ha reso trasportabile!
Docker mi ha insegnato a pensare in termini di ambiente contenuto, mi ha mostrato un percorso di isolamento tra componenti, un Container per il webserver, uno per il Key-value store, uno per l’applicativo, uno per il Database.
Terraform mi ha insegnato a pensare in termini di sistema descritto.
Prima impari a contenere. Poi impari a descrivere.
Capiamoci: Terraform non è magia, è chiarezza.
Tutto quello che prima funzionava perché “qualcuno sapeva farlo andare” ora funziona perché “ne é stato descritto il suo funzionamento”.
Analizzando un caso specifico mi sono trovato con questa infra gestita con Portainer, non ne sono un grande fan ma questo c’era.
Lungi dal voler togliere lo strumento dalle mani del cliente, possiamo però integrarci? Facciamolo.
Al cliente spesso non interessa il cosa o il come, gli interessa che funzioni e, in molti casi, vuole “vedere” che funzioni.
Terraform definisce lo stato, Portainer lo rende osservabile e gestibile, anche in ambienti complessi o condivisi.
Approccio Modulare:
Git, Docker, ECR, Portainer, Terraform, S3
Ho creato un repository dedicato sull’account Github del cliente, così ha sia i sorgenti dell’applicazione che quelli dell’infrastruttura nello stesso contenitore.
L’applicazione è stata Containerizzata e la build veniva salvata in AWS Elastic Container Registry (ECR).
Inizialmente il rilascio andava fatto manualmente da Portainer ma avendo integrato l’uso di Terraform basta rilasciare una nuova immagine e procedere al rilascio con un banalissimo:
terraform apply
Poiché stiamo cercando di formare qualcuno presso il cliente per portare avanti la “baracca” AWS S3 gioca un ruolo fondamentale diventando la fonte assoluta di verità per gli stati di Terraform.
In un contesto dove la responsabilità si deve trasmettere, non solo eseguire, avere una fonte di verità condivisa è essenziale.
AWS S3, in questo caso, non è solo uno storage, ma diventa il pilastro centrale del coordinamento: è lì che Terraform salva e legge il proprio stato, ed è da lì che ogni modifica parte e torna.
Questo ci permette di:
evitare sovrapposizioni e conflitti tra chi applica i cambiamenti;
versionare ogni variazione dell’infrastruttura, mantenendo una cronologia leggibile;
dare a chi subentrerà una base oggettiva e accessibile da cui partire, senza dipendere dalla memoria di chi c’era prima.
In altre parole: se la descrizione è codice, lo stato è conoscenza viva.
E tenerla in S3 significa renderla consultabile, condivisa, e durevole — anche quando le persone cambiano.
Terraform non è la destinazione, è la grammatica con cui possiamo iniziare a raccontare davvero il nostro sistema.
Perché solo ciò che è descritto può evolvere. Tutto il resto è folklore.
Per chi vuole iniziare
Se stai pensando di introdurre Terraform nel tuo flusso di lavoro, inizia da qui:
Containerizza tutto il possibile.
Descrivi prima ciò che cambia più spesso.
Usa un backend remoto fin da subito.
Non aspettare di “avere tempo”: la terraformazione è un processo, non un progetto.