Terraform, Pulumi, Crossplane: tre modelli di infrastructure as code

L’infrastructure as code è la pratica di definire reti, cluster e servizi gestiti in file versionati e riproducibili invece di configurarli a mano da console. Terraform, Pulumi e Crossplane la implementano con tre modelli diversi: esecuzione a trigger con state file, codice general-purpose, control plane a riconciliazione continua.

I benchmark di settore raccontano un divario netto: circa il 45% delle organizzazioni ha adottato pratiche di infrastructure as code e il 74% dei leader IT la considera un abilitatore critico della trasformazione cloud¹, ma solo il 14% dimostra con continuità eccellenza operativa nella sua esecuzione.

Perché il vero discrimine dell’IaC non è il linguaggio, ma il modello di riconciliazione

La differenza che conta tra i tre strumenti è quando e come lo stato reale viene confrontato con quello desiderato. Terraform e Pulumi eseguono il confronto solo quando qualcuno lancia un comando o una pipeline. Crossplane lo esegue in modo continuo tramite il control loop di Kubernetes. Tutto il resto è ergonomia.

Il dibattito su HCL contro TypeScript contro YAML cambia la curva di apprendimento del team, non il profilo di rischio operativo. Nella pratica quotidiana la quasi totalità delle definizioni infrastrutturali è puramente dichiarativa: un bucket, una subnet, un nodo pool. La potenza di un linguaggio general-purpose serve in una minoranza di casi, e quasi sempre sono gli stessi: generazione dinamica di risorse a partire da un inventario esterno, logiche condizionali complesse fra ambienti. Quella complessità, però, non resta confinata: si paga in review, in debugging e in onboarding su tutto il resto del codebase.

Le tre dimensioni su cui la differenza diventa misurabile:

• Rilevamento del configuration drift: nel modello a trigger la deriva tra due esecuzioni è un incidente da scoprire, spesso durante un’emergenza; nel control loop viene intercettata e corretta al ciclo di riconciliazione successivo, senza intervento umano. La latenza effettiva non è una proprietà magica del paradigma: dipende dall’intervallo di riconciliazione che impostate voi e dai rate limit dell’API del provider, quindi potete aspettarvi da decine di secondi a diversi minuti.

• Prevedibilità del cambiamento: la pianificazione preventiva delle modifiche di Terraform e Pulumi vi mette davanti un diff leggibile e approvabile prima dell’applicazione; la riconciliazione continua opera in modo asincrono e vi rende più difficile ottenere la stessa validazione a monte.

• Dipendenza da pipeline esterne: il primo modello vive dentro la CI/CD e ne eredita i tempi morti; il secondo sposta l’intelligenza dentro il cluster, e la vostra pipeline si limita a versionare l’intento.

C’è poi la questione di dove risiede lo stato, che per un CTO è una questione di continuità operativa prima che di architettura. Uno state file remoto su S3 o GCS con lock introduce contesa: nella nostra esperienza su progetti multi-cloud, gli state file monolitici condivisi tra troppi team sono una delle cause ricorrenti di rallentamento dei rilasci, con pipeline in coda ad aspettare un lock rilasciato mezz’ora prima. Crossplane elimina il file separato e conserva tutto in etcd come risorse Kubernetes, spostando il problema su backup, disaster recovery e superficie di audit del cluster.

I principi cardine della codifica dichiarativa, dall’idempotenza alla riproducibilità degli ambienti nelle pipeline CI/CD, restano validi in tutti e tre i modelli: cambia solo chi tiene il timone della riconciliazione. Ed è proprio questo il criterio con cui conviene metterli a confronto, perché da chi possiede il loop dipendono le tre variabili che pesano davvero in esercizio: dove risiede lo stato desiderato, quanto controllo resta al team applicativo e quanto lavoro operativo vi rimane in carico. Il confronto che segue usa queste tre dimensioni come griglia di lettura.

Tre modelli a confronto: cosa cambia per l’organizzazione, non solo per il codice

Terraform e OpenTofu rappresentano il modello a esecuzione controllata con state file esterno, Pulumi il modello programmatico basato su linguaggi general-purpose, Crossplane il modello a control plane continuo dentro Kubernetes. Il criterio di scelta non è la sintassi: è quanto controllo centralizzato serve e quanta autonomia si vuole concedere ai team applicativi.

Un equivoco diffuso va sciolto prima di procedere: Ansible, Puppet e Chef operano su un livello diverso. Sono strumenti di configuration management che agiscono dentro le macchine, non alternative dirette al cloud provisioning. Confonderli con i tre modelli qui analizzati porta a decisioni architetturali sbagliate.

Va messo sul tavolo anche il contesto delle licenze. Il passaggio di Terraform alla Business Source License ha generato OpenTofu, fork governato dalla Linux Foundation, mentre il core di Crossplane (progetto graduato CNCF) e la CLI di Pulumi restano sotto Apache 2.0. Per chi ragiona in termini di vendor lock-in e sovranità sulle proprie scelte tecnologiche, non è un dettaglio legale: è un criterio di valutazione.

Terraform e OpenTofu: lo standard di governance consolidata

Il vantaggio più concreto resta l’ampiezza della copertura dei provider. I tre hyperscaler hanno provider ufficiali mantenuti nel registry, quindi per la maggior parte dei servizi che incontriamo nei progetti, dai cluster GKE su Google Cloud ai load balancer AWS, esiste già una risorsa documentata: raramente serve scrivere integrazioni custom o ripiegare su chiamate API dirette. Resta il fatto che la maturità varia da provider a provider, e sui servizi più recenti o di nicchia può capitare di trovare risorse incomplete o in ritardo rispetto alle API. Per chi decide, la traduzione è diretta: meno codice custom da mantenere significa meno dipendenza da una o due persone in grado di capirlo, e quando il team vuole adottare un nuovo servizio cloud la strada parte da una risorsa già documentata invece che da uno spike di due settimane per capire come integrarla.

Il punto di forza organizzativo è la separazione netta tra codice applicativo e infrastruttura, unita a un comportamento prevedibile: la pianificazione preventiva produce un artefatto approvabile, che si presta a percorsi autorizzativi formali e a controlli di conformità con Sentinel o Open Policy Agent.

Il limite è strutturale. Tra due esecuzioni il drift resta invisibile, e la modularizzazione ha un tetto di espressività che si sente quando si prova a costruire astrazioni di alto livello: oltre una certa complessità, i moduli diventano matrioske di variabili difficili da mantenere.

Pulumi: l’infrastruttura trattata come software a tutti gli effetti

Qui l’infrastruttura entra nella stessa toolchain dell’applicazione: tipizzazione forte, refactoring assistito dall’IDE, test unitari con i framework standard, riuso tramite i package manager aziendali già in uso. Non è una comodità estetica, è governance del codice ottenuta con strumenti che il team padroneggia.

In contesti multi-tenant, dove decine di ambienti quasi identici vanno replicati per cliente o per stage, i casi enterprise documentati riportano un salto netto: il provisioning di cluster complessi passa da 1-1,5 settimane a meno di un giorno. Il meccanismo è semplice. Le topologie si generano in modo parametrico via codice applicativo, invece di duplicare file di configurazione che poi divergono tra loro.

Per chi decide, quel numero si traduce in due voci concrete. Un nuovo ambiente smette di essere una richiesta da mettere in coda al team infrastruttura e diventa un passaggio dentro la pipeline. E si libera la capacità oggi spesa a riconciliare varianti di configurazione.

Il trade-off va esplicitato a un decision maker: la flessibilità massima richiede disciplina di ingegneria del software. Senza code review, test automatici e standard interni condivisi, si genera infrastruttura non deterministica, difficile da auditare e ancora più difficile da spiegare a un revisore esterno.

Crossplane: Kubernetes come control plane unico dell’infrastruttura

Crossplane è un Kubernetes Operator della CNCF che mappa risorse cloud su Custom Resource Definition (CRD) fornite dai provider: database gestiti, code, bucket e cluster diventano oggetti nativi della Kubernetes API². Da lì ereditano gratuitamente tutto l’ecosistema, da Argo CD e Flux per il GitOps a Prometheus per le metriche, fino a Kyverno per le policy.

Il valore reale però sta nelle Composite Resource Definition (XRD), con il modello di composizione rivisto da Crossplane v2 ad agosto 2025³: permettono di esporre API di alto livello ai team applicativi, e da questa versione una Composition può includere qualsiasi risorsa Kubernetes, non solo quelle definite da Crossplane. Il meccanismo sottostante è lo stesso dei controller che riconciliano stato desiderato e stato reale nei pattern Operator.

Il costo nascosto è un cluster di controllo da gestire e proteggere: backup di etcd, RBAC, segreti, tuning dei provider, rate limiting delle API cloud. Come Kubernetes Certified Service Provider, è il punto che vediamo sottovalutato con più frequenza nelle valutazioni iniziali.

Come l’IaC diventa la base di una Internal Developer Platform

Quanto aspettano i vostri sviluppatori per ottenere un database di staging? Se la risposta si misura in giorni, il problema non è l’automazione: è che l’automazione serve solo il team infrastruttura. L’infrastructure as code diventa base di una Internal Developer Platform (IDP) quando smette di essere provisioning gestito da chi amministra i cluster e diventa un livello di astrazione self-service: API interne con cui i team applicativi creano risorse già conformi a policy di sicurezza, naming e budget, senza aprire un ticket e senza scrivere una riga di Terraform.

Il cambio di ruolo del team di piattaforma è il vero punto strategico. Da gatekeeper autorizzativo a fornitore di golden path: moduli, policy e API riutilizzabili. L’IaC non serve a far lavorare meno i sysadmin, serve a togliere il team infrastruttura dal percorso critico di ogni rilascio.

L’astrazione è il prodotto, non lo strumento. Un modulo Terraform espone parametri; una XRD di Crossplane o un componente riutilizzabile Pulumi espongono una promessa di prodotto: “dammi un ambiente di staging completo”, “dammi un Postgres conforme alle nostre policy”. È questa differenza semantica, non il tool, che riduce il carico cognitivo e si integra con cataloghi come Backstage, secondo una logica che il platform engineering ha reso operativa nei team enterprise.

I livelli di maturità che osserviamo sul campo si susseguono in quest’ordine:

1. Provisioning automatizzato: le risorse nascono da codice versionato, non da console. È il punto di partenza, non un traguardo.
2. Moduli condivisi: il team di piattaforma pubblica componenti riutilizzabili con default sicuri.
3. API self-service con policy: i team creano risorse in autonomia dentro vincoli verificati automaticamente.
4. Piattaforma con catalogo e observability: portale sviluppatori, metriche di utilizzo e ownership tracciata.

La sicurezza si sposta a monte con il policy-as-code: Sentinel o OPA per Terraform, test nativi in Pulumi, Kyverno o OPA Gatekeeper per Crossplane, insieme a scansione statica delle configurazioni, gestione centralizzata dei segreti e RBAC granulare. Quando i vincoli sono verificati a ogni commit, l’audit diventa una conseguenza del processo e non un progetto a sé: è la differenza tra security enablement e security enforcement.

C’è infine una leva FinOps che esiste solo se l’infrastruttura è codificata: ambienti effimeri creati e distrutti on-demand, spegnimento programmato fuori orario, provisioning vincolato all’uso effettivo. Gli ambienti di sviluppo riproducibili passano da ore di setup manuale per singolo sviluppatore a pochi minuti.

Quale modello scegliere e quando conviene combinarli

La scelta dipende da due variabili: la maturità cloud native dell’organizzazione e la frequenza di cambiamento del layer da governare. Se Kubernetes non è ancora lo standard interno, Crossplane aggiunge un cluster da presidiare prima che serva. Se serve approvazione formale, Terraform o OpenTofu restano l’opzione a minor rischio.

Tradotto in condizioni verificabili:

• Scegliete Terraform o OpenTofu se il vostro team infrastruttura ha background sistemistico, i cambiamenti richiedono un percorso di approvazione esplicito e la priorità è la prevedibilità sul raggio d’impatto.

• Scegliete Pulumi se avete già una cultura di software engineering solida, con code review e test automatici, e vi serve logica dinamica per topologie multi-tenant o generazione di ambienti parametrici.

• Scegliete Crossplane se i vostri workload sono già standardizzati su Kubernetes, il GitOps con Argo CD o Flux è in produzione e l’obiettivo dichiarato è esporre API self-service ai team applicativi.

L’architettura IaC stratificata è la norma, non l’eccezione. Il pattern che vediamo funzionare: uno strumento a esecuzione controllata per il layer fondativo, cioè rete, IAM, cluster GKE, EKS o AKS e servizi condivisi; un control plane continuo o componenti programmatici per il layer applicativo e i servizi gestiti per tenant. La regola è semplice. Il layer che cambia raramente e ha alto raggio d’impatto vuole prevedibilità e approvazione. Il layer che cambia ogni giorno vuole self-service e autocorrezione.

Prima di decidere, quattro rischi vanno messi sul tavolo: il tool sprawl con pipeline impossibili da debuggare (il fallimento dell’IaC è raramente tecnologico, quasi sempre organizzativo), la validazione preventiva più complessa nei modelli asincroni, il rate limiting delle API cloud con decine di controller attivi, il presidio di competenze sul control plane. Sull’interoperabilità, invece, il rischio è più basso di quanto si tema: i provider di Pulumi e Crossplane si appoggiano in larga parte all’ecosistema Terraform, quindi la migrazione raramente è un rip-and-replace. Le stesse logiche di governance architetturale per mitigare la frammentazione degli strumenti su più provider valgono qui.

Sull’orizzonte temporale, un’indicazione realistica: primi risultati misurabili su un perimetro circoscritto in poche settimane, adozione di una piattaforma interna governata su trimestri, non su sprint.

Conclusione: la decisione da prendere non è sul tool

Il linguaggio si impara in poche settimane. Il modello operativo si cambia in anni. La scelta che un CTO deve firmare riguarda quanto controllo centralizzato mantenere, quanta autonomia concedere ai team applicativi e quanto costo operativo è disposto a internalizzare per ottenere autocorrezione del drift senza intervento umano.

Vale la pena riconoscere cosa non è ancora risolto. La validazione preventiva nei modelli a riconciliazione continua resta più debole di un piano approvabile, e la governance del codice programmatico dipende da disciplina interna prima che da tooling. Chi vende una di queste due cose come problema risolto sta semplificando.

Un criterio pratico per capire dove siete: se il vostro state file è condiviso da più di tre team e ogni deploy attende un lock, il problema non è lo strumento. È l’assenza di un layer di piattaforma che separi il layer fondativo da quello di consumo.

Se volete capire a che punto è davvero la vostra automazione infrastrutturale, prenotate una call di 30 minuti con il nostro team DevOps e platform engineering: mappiamo insieme lo stato dei vostri moduli Terraform, delle pipeline e del drift tra ambienti, e ne usciamo con una lista concreta di interventi prioritari per il layer di piattaforma. Siamo Kubernetes Certified Service Provider, membri CNCF, con certificazioni AWS e Google Cloud.

Note e fonti