Pulumi vs Terraform en 2026: Infrastructure as Code con TypeScript y Preguntas de Entrevista

Pulumi vs Terraform representa la decisión central de infrastructure as code para equipos DevOps en 2026. Ambas herramientas aprovisionan recursos cloud de manera declarativa, pero difieren en soporte de lenguajes, gestión de estado y madurez del ecosistema. Esta comparativa cubre los compromisos técnicos, ejemplos de código en TypeScript y HCL, y las preguntas de entrevista que surgen cuando los candidatos discuten opciones de IaC.

Arquitectura Central: Motor de Pulumi vs Ciclo Plan-Apply de Terraform

Terraform utiliza un lenguaje específico de dominio (HCL) y un flujo de trabajo en dos fases: terraform plan genera un plan de ejecución, terraform apply lo ejecuta. El archivo de estado rastrea los metadatos de recursos y se almacena localmente o en backends remotos como S3 o Terraform Cloud.

Pulumi integra su motor en runtimes de propósito general. Los programas escritos en TypeScript, Python, Go o C# se ejecutan directamente contra las APIs cloud a través de los providers de Pulumi. El estado se almacena en Pulumi Cloud por defecto, con opciones para backends autogestionados incluyendo S3, Azure Blob Storage y archivos locales.

La diferencia arquitectónica aparece inmediatamente en cómo cada herramienta maneja bucles, condicionales y abstracciones. El for_each y count de Terraform funcionan dentro de las restricciones de HCL. Los programas Pulumi usan construcciones nativas del lenguaje: for...of en TypeScript, comprensiones de lista en Python, range en 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 configuración equivalente en Terraform requiere sintaxis HCL para iteración:

# 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]
}

Ambos snippets crean tres buckets S3. La versión Terraform es concisa y legible para cualquiera familiarizado con HCL. La versión Pulumi usa TypeScript estándar, lo que significa autocompletado IDE, verificación de tipos e integración con bases de código existentes sin aprender un nuevo lenguaje.

Soporte TypeScript: Lenguaje Nativo vs CDKTF (Deprecado)

Pulumi soportó TypeScript desde su primer lanzamiento público. El SDK expone clases de recursos tipadas, y pulumi.Output<T> envuelve valores asíncronos que se resuelven durante el despliegue. Las herramientas de refactoring, linters y frameworks de testing del ecosistema TypeScript se aplican directamente.

La respuesta de Terraform al soporte de lenguajes de propósito general fue CDKTF (Cloud Development Kit for Terraform). CDKTF permitía a los equipos escribir TypeScript o Python que se compilaba a JSON de Terraform. HashiCorp deprecó CDKTF en diciembre de 2025 y archivó el repositorio. Los proyectos CDKTF existentes aún funcionan, pero no se publican actualizaciones para nuevas versiones de Terraform o cambios de providers.

Para equipos que quieren TypeScript IaC en 2026, Pulumi es la opción activamente mantenida. Los equipos ya invertidos en CDKTF pueden continuar ejecutando sus stacks, pero la migración a HCL o Pulumi es el camino a seguir para nuevos desarrollos.

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 });
  }
}

Este componente Pulumi crea una abstracción VPC reutilizable. Los consumidores lo instancian con new StandardVpc("prod", { cidr: "10.0.0.0/16", azCount: 3 }). El equivalente en Terraform es un directorio de módulo con variables, outputs y archivos HCL. Ambos enfoques permiten reutilización; la versión Pulumi hereda las herramientas de TypeScript para documentación, testing y versionado.

Gestión de Estado y Opciones de Backend

La gestión de estado es donde aparecen las diferencias operacionales. El estado de Terraform contiene IDs de recursos, metadatos de providers y valores sensibles. Los equipos deben configurar backends remotos para habilitar colaboración e implementar bloqueo para prevenir modificaciones concurrentes.

La configuración de backend de Terraform soporta S3, Azure Blob, Google Cloud Storage, Terraform Cloud y otros. Cada backend requiere su propia configuración de autenticación. El bloqueo de estado usa DynamoDB para backends S3, leases de blob para Azure, o bloqueo nativo en Terraform Cloud.

Pulumi Cloud maneja almacenamiento de estado, bloqueo e historial por defecto. Los equipos crean una cuenta gratuita, ejecutan pulumi login, y la gestión de estado queda configurada. Para equipos que requieren estado autogestionado, Pulumi soporta S3, Azure Blob, GCS y backends de archivos locales con el 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 proporciona una interfaz web para historial de stacks, visualización de recursos y permisos de equipo. Terraform Cloud ofrece características similares con aplicación de políticas a través de Sentinel. Existen opciones auto-hospedadas para ambos: el backend auto-hospedado de Pulumi y Terraform Enterprise.

Ecosistema de Providers y Soporte Multi-Cloud

El ecosistema de providers de Terraform es el más grande en IaC. El Terraform Registry lista más de 4,000 providers cubriendo AWS, Azure, GCP, Kubernetes y cientos de plataformas SaaS. La calidad de los providers varía: los providers oficiales de HashiCorp y proveedores cloud reciben actualizaciones regulares, mientras que los providers comunitarios pueden quedarse atrás en cambios de API.

Los providers de Pulumi envuelven providers de Terraform usando un puente que genera SDKs tipados. El Pulumi Registry expone providers para los principales clouds, Kubernetes, bases de datos y servicios de monitoreo. Como Pulumi hace puente con providers de Terraform, la cobertura del ecosistema es comparable, aunque las nuevas versiones de providers de Terraform requieren actualizaciones del puente antes de que los SDKs de Pulumi reflejen los cambios.

Pulumi también ofrece providers nativos escritos directamente contra APIs cloud. Los providers nativos para AWS, Azure y Kubernetes entregan soporte el mismo día para nuevas características de API. El compromiso es que los providers nativos solo existen para los principales clouds; los servicios menos comunes usan providers con puente.

// 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 de Código de Infraestructura

El testing es donde la elección de lenguaje crea divergencia. Los programas Pulumi son código estándar, así que las pruebas unitarias usan frameworks familiares. El módulo @pulumi/pulumi/runtime proporciona mocking para creación de recursos, permitiendo que las pruebas verifiquen configuración sin desplegar recursos.

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");
  });
});

El testing de Terraform usa terraform test (introducido en Terraform 1.6) o herramientas externas como Terratest. terraform test ejecuta archivos de prueba HCL que crean recursos reales en configuraciones aisladas. Terratest es una biblioteca Go que envuelve comandos de Terraform y proporciona aserciones.

# 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"
  }
}

Ambos enfoques validan la configuración de infraestructura. La ventaja de Pulumi es la integración con runners de test de TypeScript y herramientas de cobertura. Las pruebas nativas de Terraform se ejecutan sin dependencias externas pero requieren sintaxis HCL.

Preguntas de Entrevista: Pulumi vs Terraform

Las entrevistas DevOps en 2026 frecuentemente incluyen comparaciones de herramientas IaC. Aquí hay preguntas que distinguen a candidatos que han usado ambas herramientas en producción.

"¿Qué sucede cuando el estado de Terraform diverge de la infraestructura real?"

Respuesta esperada: terraform plan detecta la divergencia comparando el estado con la infraestructura real. El plan muestra recursos a actualizar, crear o destruir. La divergencia ocurre cuando se hacen cambios fuera de Terraform (consola, CLI, otras herramientas). Las opciones incluyen terraform refresh para actualizar el estado, terraform import para traer recursos bajo gestión, o aceptar el plan para restaurar el estado deseado.

"¿Cómo maneja Pulumi los secretos de manera diferente a Terraform?"

Respuesta esperada: Pulumi encripta secretos en el estado por defecto usando una passphrase o KMS cloud. La función pulumi.secret() marca valores como sensibles, y permanecen encriptados en reposo. Terraform almacena secretos en texto plano en archivos de estado; los equipos dependen de encriptación del backend (encriptación del lado del servidor S3) y controles de acceso. Terraform 1.4 agregó marcado de variable sensitive, pero los valores aún aparecen sin encriptar en el estado.

"¿Por qué HashiCorp deprecó CDKTF, y cuáles son las opciones de migración?"

Respuesta esperada: CDKTF agregaba sobrecarga de mantenimiento sin igualar la cadencia de actualización de Terraform. Las nuevas versiones de providers y características de Terraform requerían actualizaciones manuales a los bindings de CDK. HashiCorp eligió enfocarse en HCL y Terraform Cloud. Las opciones de migración son: convertir a HCL usando cdktf convert, reescribir en Pulumi si se requiere TypeScript, o continuar ejecutando stacks CDKTF existentes sin actualizaciones.

"¿Cuándo elegirías Pulumi sobre Terraform para un nuevo proyecto?"

Respuesta esperada: Elegir Pulumi cuando el equipo ya usa TypeScript/Python/Go y quiere IaC en el mismo lenguaje que el código de aplicación, cuando abstracciones complejas requieren construcciones de programación reales (genéricos, interfaces, frameworks de testing), o cuando la encriptación integrada de secretos es un requisito. Elegir Terraform cuando el equipo conoce HCL, cuando el ecosistema de providers debe incluir providers de nicho o comunitarios, o cuando las herramientas organizacionales (Atlantis, Spacelift) se integran con Terraform.

Para más preparación de entrevistas sobre infrastructure as code, consulta Preguntas de Entrevista Terraform: Guía Completa Infrastructure as Code y el módulo Terraform Avanzado.

Estrategias de Migración: Terraform a Pulumi

Pulumi proporciona pulumi import para traer recursos cloud existentes bajo gestión sin recrearlos. Para equipos con estado Terraform, pulumi convert traduce HCL a programas Pulumi. La conversión no es perfecta: los módulos complejos y bloques dinámicos requieren ajuste manual.

# 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 migración por fases permite a los equipos ejecutar ambas herramientas durante la transición. Terraform gestiona stacks existentes mientras Pulumi aprovisiona nueva infraestructura. Una vez que los equipos ganan experiencia con Pulumi, convierten stacks de Terraform incrementalmente. El estado no se comparte entre herramientas, así que la gestión de recursos debe estar claramente dividida para evitar conflictos.

Marco de Decisión para 2026

Puntos Clave para Infrastructure as Code en 2026

• Terraform 1.16 es la opción estable para IaC basado en HCL con el ecosistema de providers más grande y herramientas maduras (Atlantis, Spacelift, env0).
• Pulumi v3.263 ofrece TypeScript, Python, Go y C# con testing nativo del lenguaje, integración IDE y encriptación integrada de secretos.
• CDKTF está deprecado desde diciembre 2025. Los equipos que quieran TypeScript IaC deberían evaluar Pulumi en lugar de iniciar nuevos proyectos CDKTF.
• Ambas herramientas soportan despliegues multi-cloud, backends de estado remotos y colaboración de equipo. La elección depende de la preferencia de lenguaje y experiencia existente del equipo.
• Las discusiones de entrevista deberían demostrar entendimiento de gestión de estado, detección de divergencia, ecosistemas de providers y los compromisos entre la simplicidad del DSL y el poder de lenguajes de propósito general.
• La migración de Terraform a Pulumi es posible usando pulumi convert y pulumi import, pero requiere planificación cuidadosa y despliegue por fases.