La conversación empezó como tantas otras en un canal de Slack entre ingenieros de plataformas. Un administrador, normalmente tranquilo según sus propias palabras, confesaba estar al borde de la desesperación cada vez que actualizaba el provider de Cloudflare para Terraform: cambios incompatibles en versiones menores, necesidad de tocar el state a mano y horas perdidas resolviendo incidencias que, en teoría, no deberían existir en 2025.
El comentario se hizo viral cuando Matt Gowie, CEO y CTO de la consultora Masterpoint, decidió compartir la captura en LinkedIn para abrir un debate más amplio sobre la calidad de los providers de Terraform y OpenTofu. Su reflexión es directa: no todos los providers están al mismo nivel y, en un mundo donde la Infraestructura como Código (IaC) es la base de muchas operaciones críticas, eso se ha convertido en un problema serio.
El problema: cambios “rompedores” en versiones menores
En la captura compartida por Gowie, el ingeniero Oliver Mulelid-Tynes relata su experiencia al actualizar el provider de Cloudflare desde la versión 5.4.0 a la 5.13.0. Sobre el papel, se trata de una actualización menor. En la práctica, describe “cambios rompederos” que le obligaron a editar el state de Terraform a mano para arreglar routes y workers huérfanos.
En su mensaje, Mulelid-Tynes llega a calificar el provider de “increíblemente malo”, y se muestra sorprendido de que un producto de una compañía tan avanzada en otros ámbitos presente un comportamiento tan frágil en algo tan básico como el ciclo de versiones. También critica el tono de algunas respuestas en GitHub, que según él rozan la arrogancia y parecen culpar al usuario por esperar que una actualización menor no rompa nada.
Más allá del desahogo, el caso ilustra un riesgo real: cuando el provider que la organización utiliza para gestionar su infraestructura falla, no solo se pierde tiempo. Pueden quedar recursos huérfanos, configuraciones inconsistentes y, en el peor de los casos, interrupciones de servicio.
No es solo Cloudflare: la importancia estratégica del provider
En su texto, Matt Gowie evita convertir el asunto en un ataque personal a un proveedor concreto, pero sí lanza un mensaje claro a toda la industria: las empresas deberían tratar su provider de Terraform con el mismo nivel de importancia que sus APIs.
Para muchas organizaciones, el provider es la forma de interactuar con el servicio. Es la capa que permite a equipos de plataforma y DevOps automatizar despliegues, reproducir entornos y aplicar cambios de manera segura y repetible. Si esa pieza es frágil, todo el modelo de IaC se resiente.
Gowie pone ejemplos positivos: los providers de Datadog, GitHub o Spacelift, desarrollados y mantenidos directamente por las propias empresas, que describe como “maduros y bien construidos”. No dan problemas serios en el día a día y permiten a su equipo ejecutar proyectos complejos para clientes sin que la herramienta se convierta en un obstáculo.
El mensaje de fondo es sencillo: si una compañía quiere que se construyan plataformas serias sobre su producto, debe invertir en que su provider sea robusto, bien documentado y con una experiencia de uso cuidada.
UX e infraestructura: cuando la experiencia del desarrollador lo es todo
Durante mucho tiempo, la discusión en torno a servicios cloud y APIs se centraba en rendimiento, funcionalidades y precio. Pero el auge de Terraform, OpenTofu y otros motores de IaC ha desplazado parte del foco hacia la experiencia del desarrollador.
Un buen provider no solo expone todos los recursos y parámetros necesarios. También:
- Mantiene una política de versiones predecible, donde las actualizaciones menores no introducen cambios incompatibles.
- Proporciona mensajes de error claros y documentación actualizada.
- Ofrece herramientas y guías de migración para saltos de versión complejos.
- Responde con rapidez y respeto en issues y pull requests abiertos por la comunidad.
Cuando estas piezas fallan, el coste para los equipos DevOps se multiplica: horas invertidas en “cirugía de estado”, dudas sobre si actualizar o no y, en muchos casos, la necesidad de mantener versiones antiguas por miedo a romper producción.
La respuesta de Cloudflare: mejoras en camino
En la publicación de LinkedIn, Gowie actualiza su mensaje para añadir la respuesta de una responsable de producto de Cloudflare, que asegura que el equipo está trabajando en mejoras importantes para el provider y reconoce parte del malestar generado. Aunque los detalles técnicos de esos cambios todavía no son públicos, el gesto apunta a que el fabricante es consciente del problema.
Para las empresas que dependen intensivamente del provider de Cloudflare, este tipo de reacciones es clave. La transparencia sobre la hoja de ruta y el reconocimiento de los fallos son, a menudo, el primer paso para recuperar la confianza de una comunidad que, por naturaleza, es muy sensible a la estabilidad y la calidad del software.
Qué pueden hacer los equipos de plataforma hoy
Mientras llegan las mejoras, los equipos de infraestructura y DevOps pueden tomar algunas medidas prácticas para reducir riesgos asociados a cualquier provider problemático, no solo el de Cloudflare:
- Revisar la política interna de actualizaciones
Evitar actualizar automáticamente a la última versión de un provider en entornos críticos. Mantener entornos de staging o sandbox donde probar primero los cambios. - Anclar versiones en los modules
Es buena práctica fijar versiones concretas (version = "~> 5.12") en lugar de permitir saltos mayores sin control. Así se evitan sorpresas con cambios incompatibles. - Automatizar copias de seguridad del state
Antes de grandes actualizaciones, disponer de copias del state almacenadas de forma segura permite deshacer cambios si algo sale mal. - Participar en la comunidad
Reportar bugs, compartir workarounds y votar los issues más críticos ayuda a priorizar el trabajo de los equipos que mantienen los providers. - Evaluar alternativas cuando sea posible
Si un provider acumula problemas graves de forma recurrente, puede ser el momento de estudiar alternativas de diseño: desde servicios equivalentes hasta capas de abstracción propias que reduzcan el impacto de un cambio.
Un síntoma de madurez del ecosistema IaC
El debate generado por la publicación de Matt Gowie también se puede leer en clave positiva: demuestra que la comunidad de IaC ha madurado. Los equipos ya no se conforman con que un provider “funcione más o menos”, sino que exigen estándares elevados de calidad, soporte y experiencia de uso.
Para los proveedores de servicios, el mensaje está claro. En 2025, ofrecer una buena API ya no es suficiente. Quien quiera ser relevante en el mundo de la nube y la automatización debe cuidar también la capa donde los equipos de plataforma pasan más horas: el provider de Terraform u OpenTofu.
La infraestructura como código se ha convertido en la “lengua franca” de la automatización en muchas empresas. Cuidar esa lengua —sus herramientas, sus providers, sus ciclos de versiones— es, en definitiva, cuidar la relación con los clientes más avanzados y con los proyectos que generan más valor.
Preguntas frecuentes
¿Por qué es tan importante la calidad de un provider de Terraform u OpenTofu?
Porque es la pieza que traduce el código de infraestructura a llamadas reales contra las APIs del servicio. Si el provider introduce errores, cambios incompatibles o comportamientos inesperados, toda la cadena de automatización se vuelve frágil.
¿Qué son los “breaking changes” en un provider y por qué preocupan tanto?
Son cambios que hacen que configuraciones válidas en una versión dejen de funcionar en la siguiente. Cuando aparecen en versiones menores, obligan a los equipos a revisar código, modificar state y asumir riesgos adicionales, lo que va contra la filosofía de actualizaciones seguras y predecibles.
¿Cómo puede una organización evaluar si un provider es fiable antes de adoptarlo masivamente?
Algunos indicadores útiles son: número de issues abiertos y cerrados en GitHub, frecuencia de lanzamientos, calidad de la documentación, presencia de ejemplos actualizados, y si el provider está mantenido oficialmente por la propia empresa dueña del servicio.
¿Qué buenas prácticas deberían seguir las empresas que desarrollan sus propios providers?
Mantener un calendario de versiones claro, documentar todos los cambios, evitar introducir incompatibilidades en versiones menores, acompañar cada versión mayor de guías de migración, responder con rapidez en los canales de soporte y probar exhaustivamente los cambios con baterías de pruebas automatizadas antes de lanzar nuevas versiones.
