Infraestructura como código: Terraform vs Pulumi vs CDK

La decisión que define tu operaciones

La herramienta de Infrastructure as Code (IaC) que elijas condiciona como tu equipo piensa sobre infraestructura durante los próximos 3-5 años. No es una decisión trivial. Terraform, Pulumi y AWS CDK representan tres filosofías diferentes sobre cómo definir y gestionar recursos cloud, y cada una tiene implicaciones profundas en la productividad del equipo, la portabilidad entre proveedores y la capacidad de testing.

Hemos usado las tres en producción. Este artículo documenta lo que hemos aprendido, con datos concretos y opiniones honestas.

Terraform: el estándar de la industria

Terraform de HashiCorp lleva desde 2014 y tiene una posición dominante. Según la encuesta de CNCF 2024, el 64% de las organizaciones que usan IaC eligen Terraform. Esa masa crítica importa: más documentación, más módulos comunitarios, más ingenieros que lo conocen.

El lenguaje: HCL

Terraform usa HCL (HashiCorp Configuration Language), un lenguaje declarativo diseñado específicamente para definir infraestructura. No es un lenguaje de programación de propósito general. Es un lenguaje de configuración con esteroides.

resource "aws_lambda_function" "api" {
  function_name = "api-handler"
  runtime       = "nodejs20.x"
  handler       = "index.handler"
  memory_size   = 256
  timeout       = 30

  environment {
    variables = {
      DB_HOST = aws_rds_cluster.main.endpoint
    }
  }
}

Lo bueno de HCL: es legible por cualquiera que haya visto un archivo de configuración. No necesitas saber programar para entender qué hace un plan de Terraform. La barrera de entrada es genuinamente baja. Los juniors lo aprenden en días, no en semanas.

Lo malo de HCL: cuando necesitas lógica compleja (bucles condicionales, transformaciones de datos, composición dinámica), HCL se vuelve dolorosamente limitado. Los for_each, count, dynamic blocks y funciones built-in cubren muchos casos, pero a veces terminas luchando contra el lenguaje en lugar de expresar tu intención.

Un ejemplo real: generar reglas de seguridad para 15 microservicios donde cada uno tiene puertos y CIDRs diferentes. En Python, es un bucle con un diccionario. En HCL, es un for_each anidado con flatten y lookup que requiere tres lecturas para entender.

Estado y plan

El modelo de Terraform se basa en un archivo de estado (state) que representa la realidad de la infraestructura y un plan que muestra los cambios antes de aplicarlos. terraform plan es probablemente la feature más valiosa de toda la herramienta: ver exactamente qué va a cambiar antes de que cambie.

El estado es también la mayor fuente de dolor. Conflictos de estado cuando dos personas modifican infraestructura simultáneamente, drift entre el estado y la realidad, operaciones de state mv y state rm que requieren precisión quirúrgica. Terraform Cloud y backends remotos con locking mitigan el problema, pero no lo eliminan.

Ecosistema

Terraform tiene providers para prácticamente todo: AWS, Azure, GCP, Cloudflare, Datadog, PagerDuty, GitHub, Kubernetes, y cientos más. El Terraform Registry aloja más de 3.500 providers y 15.000 módulos. Para cualquier servicio cloud mainstream, hay un provider maduro y bien mantenido.

Los módulos de la comunidad son un arma de doble filo. Los módulos oficiales (como terraform-aws-modules/vpc) son excelentes. Los módulos random de terceros varían enormemente en calidad. Nuestra regla: usar módulos oficiales o de organizaciones verificadas; para todo lo demás, escribir módulos propios.

La cuestión de la licencia

En agosto de 2023, HashiCorp cambió Terraform de MPL a BSL (Business Source License). Esto provocó la creación de OpenTofu, un fork mantenido por la Linux Foundation. A efectos prácticos, la funcionalidad es idéntica y la transición entre ambos es trivial. Pero si la licencia es una preocupación para tu organización, OpenTofu es la alternativa directa.

Pulumi: IaC en tu lenguaje

Pulumi tomó una decisión de diseño radical: en lugar de inventar un nuevo lenguaje, permite definir infraestructura en lenguajes de programación existentes. TypeScript, Python, Go, C#, Java. La infraestructura es código, literalmente.

const api = new aws.lambda.Function("api", {
  runtime: "nodejs20.x",
  handler: "index.handler",
  memorySize: 256,
  timeout: 30,
  environment: {
    variables: {
      DB_HOST: cluster.endpoint,
    },
  },
});

La promesa y la realidad

La promesa: usa las herramientas que ya conoces. IDEs con autocompletado, type checking, debugging, testing frameworks nativos. Lógica compleja con bucles, funciones, clases. Reutilización de código con los mecanismos del lenguaje en lugar de módulos específicos.

La realidad: la promesa se cumple, pero con matices. El autocompletado funciona y es genuinamente útil. Los tipos previenen errores que en Terraform solo descubrirías en apply. Pero la curva de aprendizaje es más pronunciada. Un ingeniero que sabe Python necesita aprender el modelo de recursos de Pulumi, el concepto de stacks, la diferencia entre inputs y outputs, y como funciona la resolución asíncrona de dependencias. No es trivial.

Dónde Pulumi brilla

Lógica compleja: cuando la infraestructura tiene lógica condicional significativa, Pulumi es claramente superior. Generar recursos basados en configuración dinámica, aplicar políticas condicionalmente, transformar datos de entrada; todo esto es natural en un lenguaje de programación y forzado en HCL.

Testing: Pulumi permite unit testing real de infraestructura con frameworks estándar (Jest, pytest, Go testing). Puedes mockear los providers y verificar que tu lógica genera los recursos correctos sin necesidad de aplicar nada. En Terraform, el testing nativo (terraform test) es funcional pero más limitado.

Component resources: Pulumi permite crear abstracciones de alto nivel que encapsulan múltiples recursos. Un DatabaseCluster que internamente crea la instancia RDS, los security groups, los parameter groups y las alertas de CloudWatch. El mecanismo de componentes es más natural que los módulos de Terraform porque usa herencia y composición del lenguaje.

Dónde Pulumi sufre

Menor ecosistema: menos providers, menos ejemplos, menos ingenieros que lo conocen. Encontrar un ingeniero con experiencia en Pulumi es significativamente más difícil que encontrar uno con experiencia en Terraform.

Complejidad accidental: la libertad de usar un lenguaje de propósito general es también una invitación a sobreingenierar. Hemos visto proyectos Pulumi donde alguien construyó un framework de abstracción de tres niveles sobre los recursos básicos. El resultado era más difícil de entender que el HCL equivalente.

Estado: Pulumi tiene su propio sistema de estado, similar al de Terraform pero con Pulumi Cloud como backend por defecto. Puedes usar backends locales o S3, pero la experiencia está optimizada para el servicio cloud de Pulumi. Dependencia de vendor en la herramienta de gestión de infraestructura: irónico.

AWS CDK: la apuesta de Amazon

AWS Cloud Development Kit (CDK) usa el mismo principio que Pulumi (IaC en lenguajes reales) pero con un giro: genera CloudFormation templates como paso intermedio. Defines infraestructura en TypeScript, Python, Java, C# o Go, y CDK la sintetiza en CloudFormation JSON/YAML que AWS despliega.

const fn = new lambda.Function(this, 'ApiHandler', {
  runtime: lambda.Runtime.NODEJS_20_X,
  handler: 'index.handler',
  memorySize: 256,
  timeout: Duration.seconds(30),
  environment: {
    DB_HOST: cluster.clusterEndpoint.hostname,
  },
});

Los constructs: la killer feature

CDK organiza los recursos en tres niveles de abstracción llamados constructs:

L1 (Cfn resources): mapeo 1:1 con recursos de CloudFormation. Verboso pero completo.

L2 (curated constructs): abstracciones de alto nivel con defaults inteligentes. Un Function de L2 configura automáticamente el IAM role, los logs en CloudWatch y la política de retry. Reduce el boilerplate dramáticamente.

L3 (patterns): combinaciones predefinidas de recursos. LambdaRestApi crea una Lambda, un API Gateway, los permisos necesarios y los stages de deployment en una única línea.

Los L2 y L3 son la razón por la que CDK es tan productivo para equipos que trabajan exclusivamente en AWS. Un desarrollador puede levantar una arquitectura serverless completa en 50 líneas de TypeScript. El equivalente en Terraform sería 200+ líneas de HCL.

La limitación fundamental

CDK es solo para AWS. No hay soporte para Azure, GCP ni ningún otro proveedor. CDK for Terraform (CDKTF) existe como puente, pero en la práctica es un wrapper sobre Terraform providers con una experiencia inferior al CDK nativo.

Si tu infraestructura es 100% AWS y no tienes planes de cambiar, CDK es probablemente la opción más productiva. Si hay cualquier posibilidad de multi-cloud, CDK te ata a un proveedor.

CloudFormation como backend

Que CDK genere CloudFormation es una ventaja y una limitación. Ventaja: CloudFormation es un servicio gestionado de AWS con rollback automático, drift detection y stack policies. No hay estado que gestionar manualmente. Limitación: CloudFormation tiene límites (500 recursos por stack, velocidad de despliegue dependiente del servicio) y los errores de CloudFormation son notoriamente críticos de diagnosticar. Cuando CDK falla, tienes que leer errores de CloudFormation y mapearlos mentalmente al código TypeScript. No es divertido.

Comparativa directa

Criterio	Terraform	Pulumi	CDK
Lenguaje	HCL	TS, Python, Go, C#, Java	TS, Python, Go, C#, Java
Multi-cloud	Excelente	Bueno	Solo AWS
Curva aprendizaje	Baja	Media-alta	Media
Testing	Básico (terraform test)	Nativo (Jest, pytest)	Nativo + assertions CDK
Ecosistema	Muy grande	Medio	Grande (AWS)
Estado	Self-managed + Cloud	Pulumi Cloud + self	CloudFormation (gestionado)
Madurez	Alta (10+ años)	Media (6+ años)	Media (6+ años)
Contratación	Fácil	Difícil	Medio

Cuándo elegir cada uno

Elige Terraform si: tu equipo es operaciones-first, trabajas con múltiples clouds, la plantilla incluye personas sin background de programación fuerte, o valoras la mayor comunidad y ecosistema.

Elige Pulumi si: tu equipo es desarrollo-first, necesitas lógica de infraestructura compleja, priorizas testing y type safety, y tienes ingenieros con experiencia sólida en TypeScript o Python.

Elige CDK si: tu infraestructura es 100% AWS, quieres la máxima productividad con defaults inteligentes, y no te preocupa el vendor lock-in con Amazon.

Nuestra posición: para la mayoría de nuestros clientes (empresas medianas españolas con necesidades multi-cloud moderadas y equipos mixtos de operaciones y desarrollo), Terraform sigue siendo la recomendación por defecto. No porque sea el mejor en ningún eje individual, sino porque es el más equilibrado: suficientemente potente, ampliamente conocido, y con el ecosistema más maduro. Pulumi es nuestra segunda elección para equipos con fuerte cultura de desarrollo que priorizan type safety y testing.

La herramienta importa menos de lo que crees

Una confesión: hemos pasado más tiempo debatiendo que herramienta de IaC usar que el que habríamos ahorrado eligiendo la “perfecta”. Las tres herramientas funcionan. Las tres tienen limitaciones. Lo que realmente determina el éxito de tu IaC no es la herramienta sino las prácticas:

• Todo en código: zero recursos manuales. Si alguien crea un security group desde la consola, se borra.
• Review de infraestructura como review de código: los planes de Terraform (o equivalentes) se revisan en PR antes de aplicar.
• Módulos reutilizables: no copies y pegues. Encapsula patrones comunes en módulos o componentes.
• Entornos idénticos: staging debe ser una réplica de producción, definida con el mismo código.
• Drift detection: detectar y corregir cambios manuales periódicamente.

Elige una herramienta, aprende a usarla bien, y enfoca la energía en las prácticas, no en la siguiente herramienta.

Nuestro equipo de cloud y DevOps implementa infraestructura como código para organizaciones de todos los tamaños. Si estás considerando una migración de IaC o empezando desde cero, podemos ayudarte a elegir la herramienta adecuada y establecer las prácticas que la hacen funcionar. Para arquitecturas multi-cloud, la elección de IaC es especialmente crítica.