Infrastructure as Code (Evoluzione)
40 anni di evoluzione dell'IaC raccontati da DevOps & AI Toolkit come una fiaba della buonanotte. Ogni strumento era un "tinker" che veniva giù dalla strada con un fix per un problema reale. 1
La sequenza
| Strumento | Cosa risolve | Cosa introduce |
|---|---|---|
| Bash | Istruzioni manuali | Non scala, ogni motore diverge |
| CFEngine | Descrizione dello stato desiderato | 20 anni in anticipo, impopolare |
| Puppet/Chef | Stati replicabili | Agent residente + master (2 set da gestire) |
| Ansible | No agent, no master: entra, lavora, esce | YAML. Genuinamente meglio, per qualche anno |
| Terraform | Provisioning cloud, multi-provider | State file (fonte di verità), è un visitor |
| Kubernetes | Reconciliation loop continuo | No state file, tipi custom, ma solo per il workload |
| Crossplane | IaC con reconciliation K8s | Vive nel cluster, non è visitor. Ma serve un cluster |
Dettagli della storia
- CFEngine proponeva di descrivere il motore sano invece del lavoro da fare, e di riportare ogni giorno tutto a quella descrizione: aveva ragione con 20 anni di anticipo ma era "quasi impossibile da amare" 1
- Puppet e Chef hanno passato 10 anni in guerra sul linguaggio: Chef voleva un vero linguaggio (Ruby) con loop e condizioni, Puppet voleva dichiarare lo stato desiderato lasciando che l'ordine si risolvesse da solo. Il costo era un agent in ogni macchina più un master, installati a mano con uno script 1
- Ansible usava la porta che ogni macchina aveva già, si imparava in un pomeriggio e per qualche anno le cose andarono "genuinamente meglio"; nasce il titolo di DevOps engineer, "due lavori saldati in una parola" 1
- Il cloud (AWS, poi Azure e Google) affitta macchine quasi uguali ma senza ponti tra provider. Lì il limite di Ansible è la memoria: non sa cosa ha creato, e una risorsa tolta dalla descrizione non viene rimossa ma resta accesa a pagamento finché qualcuno se ne accorge 1
- Terraform introduce il plan (cosa creerà, cambierà o restituirà) e lo state, una mappa che lega ogni riga di codice a una risorsa reale; parla con decine di provider in un solo linguaggio. Pulumi è "lo stesso pensatore con una bocca diversa": TypeScript, Python o Go al posto di HCL, ma stessi plan, stesso state e stessi problemi 1
- Lo state è il suo potere e il suo punto debole: se lo perdi le risorse restano e continuano a costare ma non hai più modo di gestirle; due scritture concorrenti lo corrompono; può semplicemente essere sbagliato dopo una modifica manuale, e Terraform "corregge il mondo". Va conservato su un'altra macchina, costruita a mano 1
- Kubernetes non tiene un registro e non se ne va mai: confronta di continuo lo stato voluto con quello reale e permette di inventare tipi propri (nella fiaba, il "granaio"). Crossplane porta lo stesso modello a cloud e datacenter e consente il self-service senza passare dall'operatore, che diventa platform engineer: decide cosa sono le cose invece di costruirle 1
Il pattern ricorrente
"Cinque nomi, cinque argomenti, cinque generazioni. Stesso lavoro ogni volta: fare una pila di cose e assicurarsi che continuino a esistere." 1
Ogni pensatore era migliore del precedente. Ogni volta il regno cresceva abbastanza da mangiarsi il vantaggio. Ogni fix aveva bisogno della sua macchina da mantenere viva. 1
Le due rivoluzioni
- Dichiarativo > Imperativo: Puppet/Chef hanno reso possibile replicare motori identici 1
- Reconciliation loop > Visitor: Kubernetes/Crossplane non vanno mai a casa → il drift viene corretto continuamente, non solo quando qualcuno lancia il tool 1
Il limite non risolto
Terraform è un visitor: quando se ne va, il mondo drifta. K8s/Crossplane risolvono con il reconciliation loop, ma hanno bisogno del loro cluster — la macchina più importante del regno, che qualcuno deve mantenere viva. 1
Nel finale arrivano gli AI agent: scrivono correttamente in tutti i linguaggi IaC e si prendono la scrittura, ma l'infrastruttura continua a driftare e a rompersi, e chi viene svegliato alle 3 di notte resta l'umano. 1
Ogni tool vendeva in realtà gli anni che una persona doveva spendere per impararlo; gli agent pagano quel prezzo in pochi secondi, e nessun tool significa più ciò che significava. L'autore prevede un sesto strumento costruito per gli agent, che non avrà alcun bisogno di essere leggibile da una persona. Lascia aperta la domanda se i regni siano cresciuti malgrado gli strumenti o grazie a loro. 1
Vedi anche: AI Agent in DevOps, Infrastructure Governance, Agentic Testing, Checking vs Testing