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 numeri di settore descrivono un divario tra adozione ed esecuzione. Circa il 45% delle organizzazioni sta implementando l’infrastructure as code e il 74% dei leader IT la considera un abilitatore chiave della trasformazione cloud.¹ Ma solo il 14% mostra le pratiche di chi la esegue davvero bene, e chi ci riesce ha un team di platform engineering cinque volte più spesso degli altri.² Lo scarto raramente dipende dallo strumento scelto: dipende dal modello di riconciliazione che gli si costruisce attorno.

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 quando qualcuno lancia un comando o una pipeline; i backend commerciali aggiungono controlli pianificati, come gli health assessment di HCP Terraform ogni 24 ore o la drift detection di Pulumi Cloud, che restano esecuzioni a intervallo. Crossplane esegue il confronto in continuo tramite il control loop di Kubernetes. Linguaggio, sintassi e tooling vengono dopo questa scelta.

Il dibattito su HCL, TypeScript o YAML riguarda 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 node pool.

La potenza di un linguaggio general-purpose serve in una minoranza di casi, quasi sempre 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 dipende dall’intervallo di riconciliazione che impostate voi e dai rate limit dell’API del provider: da decine di secondi a diversi minuti.

• Prevedibilità del cambiamento: la pianificazione preventiva di Terraform e Pulumi vi mette davanti un diff leggibile e approvabile prima dell’applicazione; la riconciliazione continua opera in modo asincrono e 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 pipeline si limita a versionare l’intento.

C’è poi la questione di dove risiede lo stato, che per un CTO riguarda la continuità operativa prima dell’architettura. Uno state file remoto su S3 o GCS con lock introduce contesa. Nella nostra esperienza su progetti multi-cloud, uno state file monolitico condiviso da più team di prodotto è una delle cause ricorrenti di rilasci lenti: le pipeline restano in coda ad aspettare un lock acquisito mezz’ora prima da un’altra esecuzione, o rimasto appeso dopo un job interrotto.

Crossplane elimina il file separato e conserva lo stato in etcd come risorse Kubernetes. Il problema però non sparisce: si sposta 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 chi tiene il timone della riconciliazione. E da chi possiede il loop dipendono le tre variabili che contano nella pratica: dove risiede lo stato desiderato, quanto controllo resta al team applicativo e quanto lavoro operativo vi rimane in carico.

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 ma quanto controllo centralizzato serve e quanta autonomia si vuole concedere ai team applicativi.

Una precisazione tecnica: Ansible, Puppet e Chef non sono alternative a questi tre strumenti. Sono configuration management che agisce dentro le macchine, non provisioning cloud. Confonderli porta a decisioni architetturali sbagliate.

Pesa anche la licenza. Nell’agosto 2023 HashiCorp ha spostato Terraform sotto Business Source License, e da quella scelta è nato OpenTofu, fork oggi governato dalla Linux Foundation. Il core di Crossplane (progetto CNCF graduato) e la CLI di Pulumi restano invece sotto Apache 2.0.

Il caso Terraform mostra che una licenza può cambiare dopo anni di adozione, quando lo strumento è già diffuso in pipeline, moduli e competenze del team. Per questo, nel nostro approccio open source, la governance pesa quanto le funzionalità quando scegliamo uno strumento IaC per un cliente: guardiamo chi detiene il copyright, se il progetto sta in una fondazione neutrale e se la licenza è approvata OSI.

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 e raramente serve scrivere integrazioni custom. La maturità varia da provider a provider, e sui servizi più recenti o di nicchia capita di trovare risorse incomplete o in ritardo rispetto alle API.

Meno codice custom da mantenere significa meno dipendenza da una o due persone in grado di capirlo, e quando il team adotta un nuovo servizio cloud parte da una risorsa documentata invece che da due settimane di analisi esplorativa 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.

I limiti sono due, entrambi strutturali. Il primo è il rovescio della prevedibilità: tra due esecuzioni il drift resta invisibile, perché il confronto con lo stato reale avviene solo quando qualcuno lancia un piano. Il secondo è il tetto di espressività di HCL: 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. È governance del codice ottenuta con strumenti che il team già padroneggia.

Il guadagno può essere netto in contesti enterprise. Snowflake, nel case study pubblicato da Pulumi, riporta il deployment di un cluster passato da una settimana o una settimana e mezza a meno di un giorno, su AWS, Azure e Google Cloud.³

Il meccanismo vale soprattutto in contesti multi-tenant, dove decine di ambienti quasi identici vanno replicati per cliente o per stage: le topologie si generano in modo parametrico via codice, invece di duplicare file di configurazione che poi divergono tra loro.

Quel numero vale due cose. 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: 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 progetto CNCF graduato: un insieme di controller Kubernetes che mappa risorse cloud su Custom Resource Definition (CRD) fornite dai provider. Database gestiti, code, bucket e cluster diventano oggetti nativi della Kubernetes API⁴ e da lì si integrano senza adattatori aggiuntivi con gli strumenti che già leggono quella API: Argo CD e Flux per il GitOps, Prometheus per le metriche, Kyverno per le policy.

Il valore reale 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 la 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. In pratica, i team applicativi usano API interne per creare 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 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, 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 su HCP Terraform e Conftest o Checkov nelle pipeline per l’open source, CrossGuard per Pulumi, Kyverno o OPA Gatekeeper per Crossplane, insieme a scansione statica delle configurazioni, gestione centralizzata dei segreti e RBAC granulare.

Se i vincoli girano nella pipeline a ogni commit, lo sviluppatore scopre subito che un bucket è pubblico o che manca un tag di costo e corregge da solo, senza aprire un ticket al team security. L’alternativa è la revisione manuale a valle, che blocca il rilascio a codice già scritto. Le regole restano obbligatorie, ma il controllo arriva prima e in automatico, e l’audit diventa una conseguenza del processo invece di un progetto a sé.

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. Un ambiente di sviluppo riproducibile si crea in minuti invece che in ore di setup manuale per singolo sviluppatore.

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.

In pratica:

• 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 separa due layer. Il layer fondativo, cioè rete, IAM, cluster gestiti come GKE, EKS o AKS e servizi condivisi, cambia raramente e ha un alto raggio d’impatto: vuole prevedibilità e approvazione, quindi uno strumento a esecuzione controllata come Terraform o OpenTofu. Il layer applicativo, con i servizi gestiti per tenant, cambia ogni giorno: vuole self-service e autocorrezione, quindi un control plane continuo come Crossplane o componenti programmatici come Pulumi.

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à 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.

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.

Due cose restano irrisolte. La validazione preventiva nei modelli a riconciliazione continua è più debole di un piano approvabile, e la governance del codice programmatico dipende da disciplina interna prima che da tooling.

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 è la vostra automazione infrastrutturale, prenotate un primo confronto con il nostro team DevOps e platform engineering. Serve a inquadrare la situazione e a capire se una valutazione della maturità della vostra automazione, e la progettazione del layer di piattaforma che ne consegue, hanno senso nel vostro caso. Siamo Kubernetes Certified Service Provider, membri CNCF, con certificazioni AWS e Google Cloud.

Domande frequenti

Note e fonti