Terraform o Pulumi: el lenguaje familiar cambia pruebas y rendimiento

Terraform suele ser la opción más sencilla de mantener para un equipo que ya trabaja con HCL y módulos propios. Pulumi resulta atractivo si el equipo desarrolla en Python o TypeScript y quiere probar la lógica de infraestructura con las herramientas de esos lenguajes. La elección del lenguaje cambia también lo que debe ejecutarse al planificar una actualización, aunque por sí sola no permite predecir qué herramienta tardará menos.

La comparación debe incluir el recurso y proveedor que se van a usar, el tratamiento del estado y los ciclos de integración continua. Una prueba unitaria rápida puede ahorrar trabajo durante el desarrollo; una aplicación real seguirá dependiendo del proveedor y de la infraestructura solicitada. Para decidir por velocidad hacen falta operaciones equivalentes, ejecutadas en el entorno del equipo.

Lenguaje conocido, lógica que mantener

Terraform expresa recursos mediante HCL y organiza la reutilización en módulos. La comparación de Pulumi documenta que su plataforma admite Python, TypeScript, JavaScript, Go, .NET, Java, YAML y HCL, y que puede adaptar proveedores de Terraform y consumir módulos de ese ecosistema. Por tanto, adoptar Pulumi no exige elegir un lenguaje general ni desechar automáticamente todos los módulos existentes.

En HCL, la estructura declarativa acota la lógica que aparece junto a los recursos. En Python o TypeScript se pueden reutilizar funciones, paquetes y herramientas de análisis ya conocidas, pero también hay que mantener dependencias y evitar que una función oculte cambios de infraestructura difíciles de revisar. La familiaridad ayuda cuando el equipo comparte convenciones de código; aporta menos si quienes operan la pila deben aprender a la vez el lenguaje, sus paquetes y las abstracciones creadas para el proyecto.

Las pruebas no dependen solo de Python o TypeScript

Terraform tiene un mecanismo de pruebas propio. La guía de pruebas de HashiCorp utiliza archivos .tftest.hcl para ejecutar comprobaciones sobre una planificación o una aplicación; el estado de esas pruebas permanece en memoria y separado del estado habitual. También muestra proveedores simulados para evitar crear algunos recursos reales. Una prueba que sí aplica infraestructura necesita credenciales, consume tiempo del proveedor y requiere comprobar que la limpieza se complete.

En Pulumi, la guía de pruebas unitarias sustituye las llamadas al motor por simulaciones dentro del proceso del lenguaje. Así se pueden comprobar propiedades calculadas y decisiones del programa sin desplegar recursos; una prueba de integración sigue siendo necesaria cuando importa la respuesta real del proveedor. Esta ventaja de las pruebas unitarias corresponde a los programas escritos en lenguajes generales: un proyecto Pulumi en HCL o YAML no obtiene por ese hecho el marco de pruebas de Python o TypeScript.

La pregunta útil es qué fallo se quiere detectar. Una etiqueta calculada incorrectamente puede verificarse con simulaciones en cualquiera de los dos enfoques. Si importa que el proveedor acepte la configuración o devuelva un atributo concreto, la simulación no sustituye una ejecución contra ese proveedor. El equipo debe contar tanto el tiempo de esas pruebas como el esfuerzo de mantener datos simulados que representen los casos relevantes.

El proveedor concreto decide cuánto se reutiliza

La posibilidad de adaptar un proveedor de Terraform o consumir un módulo HCL reduce una barrera de entrada a Pulumi, pero no equivale a migrar una pila sin trabajo. Hay que comprobar que estén disponibles el recurso, sus argumentos, las funciones de consulta y las salidas que usa la configuración. Una dependencia de un proveedor poco habitual pesa más en la elección que el tamaño total de cualquiera de los catálogos.

También cambia la forma de mantener componentes compartidos. Si distintos equipos ya revisan y publican módulos HCL, conservar esa interfaz puede resultar más simple que introducir otra implementación. Si los componentes de infraestructura se desarrollarán junto a servicios en un lenguaje común, Pulumi permite compartir herramientas de empaquetado y pruebas. En ambos casos, la unidad de comparación es el componente que el equipo tendrá que actualizar, no una declaración general sobre cuál ecosistema es mayor.

El estado exige una decisión de seguridad

Las dos herramientas necesitan registrar qué recursos administran. En Terraform, un valor marcado como sensible puede seguir presente en el estado: la documentación de HashiCorp sobre datos sensibles advierte que el estado local se guarda en texto legible y que el cifrado del almacenamiento remoto depende del backend. Ocultar un valor en la salida del terminal no equivale a retirarlo del archivo de estado.

La elección operativa abarca quién puede leer ese estado, dónde se conserva, cómo se impiden escrituras simultáneas y cómo se recupera una actualización interrumpida. Pulumi también requiere escoger y administrar un backend para sus pilas, ya sea gestionado o propio. Esas decisiones afectan a permisos y mantenimiento con independencia de que la configuración esté escrita en HCL, Python o TypeScript.

Los tiempos publicados describen una configuración

La tabla de Shattered presenta para Terraform 1.9.0 y Pulumi con Python 3.12 medias de planificación de 1.240 frente a 1.560 ms, medias de aplicación de 2.890 frente a 3.120 ms y tiempos de detección de deriva de 11 frente a 6 minutos, respectivamente. En esa tabla, Pulumi con Python tarda más en planificar y aplicar, pero menos en detectar deriva. La publicación no aporta suficiente detalle del entorno, los recursos y las repeticiones para convertir esas cifras en una previsión para otra pila.

El runtime forma parte del trabajo que ejecuta Pulumi y puede influir en una operación breve; también influyen la carga de dependencias, las llamadas al proveedor, el backend y el número de recursos. Una aplicación que espera respuestas de la nube puede estar dominada por tiempos distintos de los que pesan en una planificación pequeña. Por eso, un resultado obtenido con Python no establece el rendimiento de Pulumi con Go o TypeScript, ni el de una pila mayor.

Tres perfiles, una pila equivalente

Para un equipo de plataforma con módulos HCL establecidos y revisores habituados a ellos, Terraform ofrece continuidad en código, pruebas y operación. Para un equipo que ya mantiene servicios en Python o TypeScript y necesita comprobar lógica de generación de recursos, Pulumi puede aprovechar conocimientos y herramientas existentes. Si la prioridad es reducir la duración de los ciclos de CI, ninguno de esos perfiles reemplaza una medición con el proveedor, el lenguaje y el backend que se usarán de verdad.

Una comparación acotada puede definir en ambas herramientas un bucket de Amazon S3 con el mismo versionado, las mismas etiquetas y una salida con su identificador. Es una pila propuesta para evaluar la elección, no un despliegue ni una medición realizados aquí. La región, los permisos, las versiones de proveedor y la configuración del estado deben coincidir; de lo contrario, una diferencia de resultado podría provenir del entorno.

Con esa base, tiene sentido distinguir el tiempo de preparar dependencias del de planificar sin cambios, y medir aparte una modificación de etiqueta y su aplicación. Las pruebas pueden comprobar la misma etiqueta errónea, primero con simulaciones y luego, si el equipo necesita validar al proveedor, contra recursos temporales. El resultado permite valorar conjuntamente la revisión del código, la cobertura de pruebas y el coste de cada ciclo: las tres consecuencias que acompañarán a la herramienta después de la primera instalación.

Lee también:

• Passkeys o contraseñas: el riesgo cambia al proveedor que las sincroniza
• YouTube Premium sube a 15,99 € en España: la familia pagará 29,99 €
• Docker o Podman: rootless no decide por sí solo el rendimiento