Llevamos años diciéndole a los equipos de desarrollo que la infraestructura es código. Y luego les pedimos que aprendan HCL. Hay algo contradictorio en eso. Pulumi rompe ese contrato tácito: si ya sabes TypeScript, Python o Go, puedes escribir infraestructura sin aprender un nuevo lenguaje. La pregunta no es si Pulumi es mejor que Terraform. La pregunta es si es mejor para tu equipo, en tu contexto, hoy.
En los últimos dos años hemos migrado tres proyectos de Terraform a Pulumi y hemos mantenido otros cinco en Terraform. No somos evangelistas de ninguna herramienta. Somos ingenieros que han usado las dos en producción y que tienen opiniones basadas en cicatrices, no en benchmarks de blog.
Qué es Pulumi y en qué se diferencia realmente de Terraform
Pulumi y Terraform hacen lo mismo a alto nivel: te permiten declarar el estado deseado de tu infraestructura y se encargan de reconciliar la realidad con ese estado. Ambos tienen state management, ambos tienen providers para los principales clouds, ambos soportan modularización.
La diferencia fundamental es el lenguaje en el que expresas ese estado deseado. Terraform usa HCL, un DSL diseñado específicamente para infraestructura. Pulumi usa TypeScript, Python, Go, Java o .NET — los lenguajes que tu equipo ya conoce.
Las ventajas reales de Pulumi (no las del marketing)
1. Abstracciones de verdad
En Terraform, la reutilización de lógica se hace mediante módulos. Los módulos son potentes, pero tienen limitaciones: no puedes hacer bucles complejos con condiciones dinámicas, las abstracciones tienen un techo y el HCL se vuelve ilegible rápidamente cuando intentas hacer algo no trivial.
En Pulumi, puedes escribir una función en TypeScript que genere cincuenta recursos con lógica condicional compleja, la testees con Jest y la publiques en npm. Eso no es posible en Terraform sin workarounds feos.
2. Tests unitarios reales
Este es el argumento que más convence a los equipos de desarrollo. En Terraform, testear infraestructura antes de desplegarla es complicado: tienes terraform validate, tienes Terratest que levanta recursos reales en AWS y tienes checkov para análisis estático. Ninguno es lo que un developer entiende por "unit test".
En Pulumi puedes escribir tests unitarios con mocks que verifican que tu código de infraestructura genera los recursos correctos sin tocar ningún cloud. El ciclo de feedback pasa de minutos a segundos.
3. Curva de aprendizaje para equipos de desarrollo
Si tienes un equipo de backend que sabe TypeScript y quieres que gestionen su propia infraestructura, la curva de Terraform es real: hay que aprender HCL, entender el modelo mental del state, los workspaces, los módulos. No es insuperable, pero es fricción.
Con Pulumi, el onboarding de un developer de TypeScript a infraestructura es significativamente más rápido. No tienen que aprender un nuevo lenguaje, solo los conceptos de infraestructura como código.
Las desventajas que nadie te cuenta
Pulumi no es perfecto. Aquí las cosas que nos han generado problemas en proyectos reales:
- El ecosistema de módulos es menor: el Terraform Registry tiene miles de módulos probados en producción por millones de usuarios. Pulumi tiene un ecosistema más pequeño. Vas a escribir más código desde cero.
- La depuración es más compleja: cuando algo falla en un módulo de Terraform, el error suele ser claro. Cuando algo falla en Pulumi, a veces estás depurando TypeScript y runtime de Pulumi al mismo tiempo.
- El state tiene las mismas complejidades: Pulumi tiene state management igual que Terraform. No te libras de los problemas de state corruption, locking o drift por usar Pulumi. Solo cambia dónde guardas el state (Pulumi Cloud, S3, etc.).
- La flexibilidad puede ser una trampa: con un lenguaje completo, es tentador escribir lógica demasiado compleja en el código de infraestructura. Hemos visto proyectos de Pulumi donde el código era tan imperativo que nadie sabía qué recursos iba a crear sin ejecutarlo.
Pulumi vs Terraform: la comparativa honesta
¿Cuándo usar cada uno?
Cómo adoptarlo en un equipo que ya usa Terraform
La pregunta que nos hacen siempre es: "¿migramos todo o empezamos desde cero en nuevos proyectos?" La respuesta depende del tamaño de tu Terraform existente y del apetito del equipo para el cambio.
- Empieza con un proyecto nuevo. No migres infraestructura existente como primera experiencia con Pulumi. El riesgo es innecesario y la fricción del aprendizaje se multiplica cuando también estás migrando.
- Elige TypeScript si tienes dudas. Es el lenguaje con mejor soporte en Pulumi, el ecosistema de tipos es muy completo y los errores en tiempo de compilación te salvan de muchos problemas en runtime.
- Define una política sobre abstracciones. Decide antes de empezar qué nivel de abstracción es aceptable en el código de infraestructura. Sin esa política, cada engineer lo hace diferente.
- Mantén el Terraform existente. No hay urgencia en migrar infraestructura que funciona. Pulumi y Terraform pueden coexistir perfectamente si gestionan recursos diferentes.
- Invierte en el state backend desde el principio. Pulumi Cloud es la opción más cómoda. Si tienes restricciones de datos, S3 con locking en DynamoDB funciona igual que con Terraform.
Un ejemplo concreto: lo que cambió en un proyecto real
En uno de los proyectos que migramos, teníamos un módulo de Terraform que creaba entornos de Kubernetes con variaciones por cliente. Cada cliente tenía configuraciones ligeramente diferentes: distintos node pools, diferentes políticas de autoescalado, namespaces personalizados.
En Terraform, esto requería un módulo con 40 variables, muchos bloques condicionales con count y for_each y una documentación extensa para que nadie lo rompiese. El módulo era correcto pero difícil de mantener.
En Pulumi, lo reescribimos como una clase en TypeScript con un constructor que recibía la configuración del cliente. La lógica condicional era código TypeScript normal, los tests verificaban que cada tipo de cliente generaba los recursos correctos y añadir un nuevo tipo de entorno era extender la clase, no editar un módulo con 40 variables.
El resultado no fue "mejor infraestructura". Fue infraestructura igual de correcta que el equipo de desarrollo podía mantener sin ayuda del equipo de operaciones.
Conclusión
Pulumi no va a reemplazar a Terraform en los próximos años. El ecosistema de Terraform es demasiado amplio y el conocimiento acumulado en los equipos es demasiado grande. Pero tampoco necesita reemplazarlo para ser la herramienta correcta en muchos contextos.
Si tu equipo de desarrollo quiere gestionar su propia infraestructura y la curva de HCL es una barrera real, Pulumi elimina esa barrera. Si necesitas abstracciones complejas que HCL no puede expresar limpiamente, Pulumi las hace posibles. Si quieres tests unitarios de infraestructura que corran en segundos, Pulumi es la respuesta.
Si tienes un equipo de operaciones dedicado con años de experiencia en Terraform y un registry de módulos bien construido, cambia por cambiar no tiene sentido.
¿Terraform o Pulumi para tu proyecto?
Te ayudamos a evaluar cuál encaja mejor con tu equipo y tu infraestructura actual. Sin dogmas, con criterio.
Hablar con un experto →