Pulumi vs Terraform 2026: Infrastructure as Code con TypeScript e Domande per Colloqui

Pulumi vs Terraform rappresenta la decisione centrale sull'Infrastructure as Code per i team DevOps nel 2026. Entrambi gli strumenti provisionano risorse cloud in modo dichiarativo, ma differiscono nel supporto linguistico, nella gestione dello state e nella maturità dell'ecosistema. Questo confronto copre i compromessi tecnici, esempi di codice in TypeScript e HCL, e le domande da colloquio che emergono quando i candidati discutono scelte IaC.

Architettura di Base: Engine di Pulumi vs Ciclo Plan-Apply di Terraform

Terraform utilizza un linguaggio specifico di dominio (HCL) e un workflow a due fasi: terraform plan genera un piano di esecuzione, terraform apply lo esegue. Il file di state traccia i metadati delle risorse e viene memorizzato localmente o in backend remoti come S3 o Terraform Cloud.

Pulumi incorpora il suo engine in runtime general-purpose. I programmi scritti in TypeScript, Python, Go o C# vengono eseguiti direttamente contro le API cloud attraverso i provider di Pulumi. Lo state viene memorizzato in Pulumi Cloud per default, con opzioni per backend autogestiti inclusi S3, Azure Blob Storage e file locali.

La differenza architetturale si manifesta immediatamente nel modo in cui ogni strumento gestisce cicli, condizionali e astrazioni. Il for_each e count di Terraform operano entro i vincoli di HCL. I programmi Pulumi utilizzano costrutti nativi del linguaggio: for...of in TypeScript, list comprehension in Python, range in Go.

import * as aws from "@pulumi/aws";
import * as pulumi from "@pulumi/pulumi";

// Native TypeScript array methods work directly
const environments = ["dev", "staging", "prod"];

const buckets = environments.map(env => 
  new aws.s3.BucketV2(`data-${env}`, {
    bucket: `myapp-data-${env}-${pulumi.getStack()}`,
    tags: {
      Environment: env,
      ManagedBy: "pulumi",
    },
  })
);

// Export bucket ARNs as stack outputs
export const bucketArns = buckets.map(b => b.arn);

La configurazione Terraform equivalente richiede la sintassi HCL per l'iterazione:

# main.tf - Terraform HCL example
variable "environments" {
  type    = list(string)
  default = ["dev", "staging", "prod"]
}

resource "aws_s3_bucket" "data" {
  for_each = toset(var.environments)

  bucket = "myapp-data-${each.key}-${terraform.workspace}"

  tags = {
    Environment = each.key
    ManagedBy   = "terraform"
  }
}

output "bucket_arns" {
  value = [for b in aws_s3_bucket.data : b.arn]
}

Entrambi gli snippet creano tre bucket S3. La versione Terraform è concisa e leggibile per chiunque abbia familiarità con HCL. La versione Pulumi utilizza TypeScript standard, il che significa autocompletamento IDE, type checking e integrazione con codebase esistenti senza imparare un nuovo linguaggio.

Supporto TypeScript: Linguaggio Nativo vs CDKTF (Deprecato)

Pulumi ha supportato TypeScript fin dalla sua prima release pubblica. L'SDK espone classi di risorse tipizzate, e pulumi.Output<T> avvolge valori asincroni che si risolvono durante il deployment. Strumenti di refactoring, linter e framework di test dall'ecosistema TypeScript si applicano direttamente.

La risposta di Terraform al supporto di linguaggi general-purpose era CDKTF (Cloud Development Kit for Terraform). CDKTF permetteva ai team di scrivere TypeScript o Python che si compilava in Terraform JSON. HashiCorp ha deprecato CDKTF a dicembre 2025 e archiviato il repository. I progetti CDKTF esistenti continuano a funzionare, ma non vengono rilasciati aggiornamenti per nuove versioni di Terraform o modifiche dei provider.

Per i team che vogliono TypeScript IaC nel 2026, Pulumi è l'opzione mantenuta attivamente. I team già investiti in CDKTF possono continuare a eseguire i loro stack, ma la migrazione a HCL o Pulumi è la strada da seguire per nuovi sviluppi.

import * as aws from "@pulumi/aws";
import * as pulumi from "@pulumi/pulumi";

// Custom component encapsulating VPC, subnets, and routing
export class StandardVpc extends pulumi.ComponentResource {
  public readonly vpcId: pulumi.Output<string>;
  public readonly publicSubnetIds: pulumi.Output<string>[];

  constructor(name: string, args: { cidr: string; azCount: number }, opts?: pulumi.ComponentResourceOptions) {
    super("mycompany:network:StandardVpc", name, {}, opts);

    const vpc = new aws.ec2.Vpc(`${name}-vpc`, {
      cidrBlock: args.cidr,
      enableDnsHostnames: true,
      tags: { Name: name },
    }, { parent: this });

    this.vpcId = vpc.id;

    // Create public subnets across availability zones
    const azs = aws.getAvailabilityZones({ state: "available" });
    this.publicSubnetIds = [];

    for (let i = 0; i < args.azCount; i++) {
      const subnet = new aws.ec2.Subnet(`${name}-public-${i}`, {
        vpcId: vpc.id,
        cidrBlock: `10.0.${i}.0/24`,
        availabilityZone: azs.then(az => az.names[i]),
        mapPublicIpOnLaunch: true,
        tags: { Name: `${name}-public-${i}` },
      }, { parent: this });
      this.publicSubnetIds.push(subnet.id);
    }

    this.registerOutputs({ vpcId: this.vpcId });
  }
}

Questo componente Pulumi crea un'astrazione VPC riutilizzabile. I consumatori lo istanziano con new StandardVpc("prod", { cidr: "10.0.0.0/16", azCount: 3 }). L'equivalente in Terraform è una directory di modulo con variabili, output e file HCL. Entrambi gli approcci abilitano il riuso; la versione Pulumi eredita il tooling di TypeScript per documentazione, testing e versionamento.

Gestione dello State e Opzioni Backend

La gestione dello state è dove emergono le differenze operative. Lo state di Terraform contiene ID delle risorse, metadati del provider e valori sensibili. I team devono configurare backend remoti per abilitare la collaborazione e implementare il locking per prevenire modifiche concorrenti.

La configurazione del backend Terraform supporta S3, Azure Blob, Google Cloud Storage, Terraform Cloud e altri. Ogni backend richiede la propria configurazione di autenticazione. Il locking dello state utilizza DynamoDB per backend S3, blob lease per Azure, o locking nativo in Terraform Cloud.

Pulumi Cloud gestisce memorizzazione dello state, locking e cronologia per default. I team creano un account gratuito, eseguono pulumi login, e la gestione dello state è configurata. Per i team che richiedono state autogestito, Pulumi supporta backend S3, Azure Blob, GCS e file locali con il comando pulumi login.

# Pulumi: login to self-managed S3 backend
pulumi login s3://my-pulumi-state-bucket

# Terraform: configure S3 backend in HCL
# backend.tf
terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

Pulumi Cloud fornisce una UI web per cronologia degli stack, visualizzazione delle risorse e permessi del team. Terraform Cloud offre funzionalità simili con policy enforcement attraverso Sentinel. Opzioni self-hosted esistono per entrambi: backend self-hosted di Pulumi e Terraform Enterprise.

Ecosistema dei Provider e Supporto Multi-Cloud

L'ecosistema di provider Terraform è il più grande nell'IaC. Il Terraform Registry elenca oltre 4.000 provider che coprono AWS, Azure, GCP, Kubernetes e centinaia di piattaforme SaaS. La qualità dei provider varia: i provider ufficiali HashiCorp e dei vendor cloud ricevono aggiornamenti regolari, mentre i provider della community potrebbero restare indietro rispetto ai cambiamenti delle API.

I provider Pulumi avvolgono i provider Terraform usando un bridge che genera SDK tipizzati. Il Pulumi Registry espone provider per i principali cloud, Kubernetes, database e servizi di monitoraggio. Poiché Pulumi fa bridge dei provider Terraform, la copertura dell'ecosistema è comparabile, sebbene le nuove versioni dei provider Terraform richiedano aggiornamenti del bridge prima che gli SDK Pulumi riflettano i cambiamenti.

Pulumi offre anche provider nativi scritti direttamente contro le API cloud. I provider nativi per AWS, Azure e Kubernetes forniscono supporto same-day per nuove funzionalità API. Il compromesso è che i provider nativi esistono solo per i cloud principali; i servizi meno comuni usano provider bridged.

// Using Pulumi's native AWS provider for Lambda
import * as aws from "@pulumi/aws";
import * as pulumi from "@pulumi/pulumi";

const role = new aws.iam.Role("lambda-role", {
  assumeRolePolicy: aws.iam.assumeRolePolicyForPrincipal({
    Service: "lambda.amazonaws.com",
  }),
});

const lambdaFunction = new aws.lambda.Function("api-handler", {
  runtime: aws.lambda.Runtime.NodeJS20dX,
  handler: "index.handler",
  role: role.arn,
  code: new pulumi.asset.AssetArchive({
    "index.js": new pulumi.asset.StringAsset(
      `exports.handler = async () => ({ statusCode: 200, body: "OK" });`
    ),
  }),
});

export const functionArn = lambdaFunction.arn;

Testing del Codice Infrastrutturale

Il testing è dove la scelta del linguaggio crea divergenza. I programmi Pulumi sono codice standard, quindi gli unit test usano framework familiari. Il modulo @pulumi/pulumi/runtime fornisce mocking per la creazione di risorse, permettendo ai test di verificare la configurazione senza deployare risorse.

import { describe, it, expect, beforeAll } from "vitest";
import * as pulumi from "@pulumi/pulumi";

// Mock Pulumi runtime
pulumi.runtime.setMocks({
  newResource: (args: pulumi.runtime.MockResourceArgs) => {
    return { id: `${args.name}-id`, state: args.inputs };
  },
  call: (args: pulumi.runtime.MockCallArgs) => {
    return args.inputs;
  },
});

describe("S3 Bucket Configuration", () => {
  let bucketTags: Record<string, string>;

  beforeAll(async () => {
    // Import the Pulumi program after mocks are set
    const infra = await import("../infra/index");
    // Extract outputs for testing
    bucketTags = await new Promise(resolve => {
      infra.buckets[0].tags.apply(tags => resolve(tags as Record<string, string>));
    });
  });

  it("should tag buckets with Environment", () => {
    expect(bucketTags).toHaveProperty("Environment");
  });

  it("should tag buckets with ManagedBy", () => {
    expect(bucketTags.ManagedBy).toBe("pulumi");
  });
});

Il testing Terraform usa terraform test (introdotto in Terraform 1.6) o strumenti esterni come Terratest. terraform test esegue file di test HCL che creano risorse reali in configurazioni isolate. Terratest è una libreria Go che avvolge i comandi Terraform e fornisce assertion.

# tests/bucket.tftest.hcl - Terraform native test
run "bucket_tags" {
  command = plan

  assert {
    condition     = aws_s3_bucket.data["dev"].tags["Environment"] == "dev"
    error_message = "Bucket must be tagged with Environment"
  }

  assert {
    condition     = aws_s3_bucket.data["dev"].tags["ManagedBy"] == "terraform"
    error_message = "Bucket must be tagged with ManagedBy"
  }
}

Entrambi gli approcci validano la configurazione dell'infrastruttura. Il vantaggio di Pulumi è l'integrazione con test runner TypeScript e strumenti di coverage. I test nativi di Terraform funzionano senza dipendenze esterne ma richiedono sintassi HCL.

Domande per Colloqui: Pulumi vs Terraform

I colloqui DevOps nel 2026 includono frequentemente confronti di strumenti IaC. Ecco domande che distinguono i candidati che hanno usato entrambi gli strumenti in produzione.

"Cosa succede quando lo state Terraform diverge dall'infrastruttura reale?"

Risposta attesa: terraform plan rileva il drift confrontando lo state con l'infrastruttura reale. Il piano mostra le risorse da aggiornare, creare o distruggere. Il drift si verifica quando vengono apportate modifiche al di fuori di Terraform (console, CLI, altri strumenti). Le opzioni includono terraform refresh per aggiornare lo state, terraform import per portare le risorse sotto gestione, o accettare il piano per ripristinare lo stato desiderato.

"Come gestisce Pulumi i secret in modo diverso da Terraform?"

Risposta attesa: Pulumi cripta i secret nello state per default usando una passphrase o cloud KMS. La funzione pulumi.secret() marca i valori come sensibili, e rimangono criptati at rest. Terraform memorizza i secret in plaintext nei file di state; i team si affidano alla crittografia del backend (crittografia server-side S3) e ai controlli di accesso. Terraform 1.4 ha aggiunto il marking delle variabili sensitive, ma i valori appaiono comunque non criptati nello state.

"Perché HashiCorp ha deprecato CDKTF, e quali sono le opzioni di migrazione?"

Risposta attesa: CDKTF aggiungeva overhead di manutenzione senza corrispondere alla cadenza di aggiornamento di Terraform. Nuove versioni dei provider e funzionalità Terraform richiedevano aggiornamenti manuali ai binding CDK. HashiCorp ha scelto di concentrarsi su HCL e Terraform Cloud. Le opzioni di migrazione sono: convertire a HCL usando cdktf convert, riscrivere in Pulumi se TypeScript è richiesto, o continuare a eseguire stack CDKTF esistenti senza aggiornamenti.

"Quando sceglieresti Pulumi rispetto a Terraform per un nuovo progetto?"

Risposta attesa: Scegliere Pulumi quando il team usa già TypeScript/Python/Go e vuole IaC nello stesso linguaggio del codice applicativo, quando astrazioni complesse richiedono costrutti di programmazione reali (generics, interfacce, framework di test), o quando la crittografia dei secret integrata è un requisito. Scegliere Terraform quando il team conosce HCL, quando l'ecosistema dei provider deve includere provider di nicchia o della community, o quando il tooling organizzativo (Atlantis, Spacelift) si integra con Terraform.

Strategie di Migrazione: da Terraform a Pulumi

Pulumi fornisce pulumi import per portare risorse cloud esistenti sotto gestione senza ricrearle. Per i team con state Terraform, pulumi convert traduce HCL in programmi Pulumi. La conversione non è perfetta: moduli complessi e blocchi dinamici richiedono aggiustamenti manuali.

# Convert Terraform HCL to Pulumi TypeScript
pulumi convert --from terraform --language typescript

# Import existing AWS resources into Pulumi state
pulumi import aws:s3/bucketV2:BucketV2 my-bucket my-existing-bucket-name

Una migrazione graduale permette ai team di eseguire entrambi gli strumenti durante la transizione. Terraform gestisce gli stack esistenti mentre Pulumi provisiona nuova infrastruttura. Una volta che i team acquisiscono esperienza con Pulumi, convertono gli stack Terraform in modo incrementale. Lo state non è condiviso tra gli strumenti, quindi la gestione delle risorse deve essere chiaramente divisa per evitare conflitti.

Framework Decisionale per il 2026

Punti Chiave per Infrastructure as Code nel 2026

• Terraform 1.16 è la scelta stabile per IaC basato su HCL con il più grande ecosistema di provider e tooling maturo (Atlantis, Spacelift, env0).
• Pulumi v3.263 offre TypeScript, Python, Go e C# con testing nativo del linguaggio, integrazione IDE e crittografia dei secret integrata.
• CDKTF è deprecato da dicembre 2025. I team che vogliono TypeScript IaC dovrebbero valutare Pulumi piuttosto che iniziare nuovi progetti CDKTF.
• Entrambi gli strumenti supportano deployment multi-cloud, backend di state remoti e collaborazione di team. La scelta dipende dalla preferenza linguistica e dall'expertise esistente del team.
• Le discussioni nei colloqui dovrebbero dimostrare comprensione della gestione dello state, rilevamento del drift, ecosistemi dei provider e i compromessi tra semplicità DSL e potenza del linguaggio general-purpose.
• La migrazione da Terraform a Pulumi è possibile usando pulumi convert e pulumi import, ma richiede pianificazione attenta e rollout graduale.