Bicep o Terraform para Azure: una comparación honesta

Esta discusión suele decidirla quien habla primero en la reunión, lo que es una pena porque los compromisos son reales y fáciles de enunciar.

Donde Bicep es genuinamente mejor

No hay fichero de estado. Bicep despliega contra Azure Resource Manager, que es en sí mismo la fuente de verdad. No hay estado que guardar, bloquear, corromper ni del que derivar. Una fracción grande del trabajo operativo de Terraform —backends, bloqueos, cirugía de estado tras un apply fallido, import para recursos creados a mano— sencillamente no existe.

Soporte de recursos desde el primer día. Una función nueva de Azure está disponible en Bicep en cuanto la API de ARM la soporta, porque Bicep es una capa tipada fina sobre la API. El proveedor de Terraform va por detrás, a veces meses. Si adoptas funciones de Azure pronto, esto importa y se nota.

El what-if es exacto a nivel de API. az deployment what-if le pregunta a Azure qué cambiaría, en lugar de comparar con un estado que puede no coincidir con la realidad.

Las pilas de despliegue te dan un ciclo de vida gestionado para un conjunto de recursos, con ajustes de denegación que impiden cambios fuera de banda — una capacidad sin equivalente directo en Terraform.

Donde Terraform es genuinamente mejor

No es solo Azure. Casi todo entorno real tiene algo más: un proveedor de DNS, GitHub, Cloudflare, Datadog, un esquema de base de datos, otra nube. Una herramienta y un flujo de trabajo para todo ello es una ventaja práctica grande, y es el argumento que gana más a menudo.

El ecosistema de módulos y comunidad es mucho mayor. Para casi cualquier patrón, alguien ha publicado un módulo revisado.

Planes explícitos y legibles como artefacto de revisión. La salida de terraform plan publicada en un pull request es algo sobre lo que un revisor puede razonar, y el flujo asociado —plan, aprobar, aplicar el plan guardado— está bien establecido.

Una historia más fuerte de pruebas y políticas. checkov, tfsec, conftest, Terratest y el ecosistema de política como código están maduros. Bicep tiene linting y el kit de pruebas de plantillas ARM, pero el utillaje es más fino.

Detección de deriva. Un terraform plan programado te dice qué cambió fuera del pipeline. El modelo de Bicep, donde ARM es la verdad, significa que los cambios fuera de banda son simplemente la realidad hasta que el siguiente despliegue los sobrescriba — salvo que uses pilas de despliegue con ajustes de denegación.

Cómo elegir

Solo Azure, equipo centrado en Microsoft, equipo de plataforma que vive en Azure DevOps: Bicep. La ausencia de estado es un ahorro operativo real y el soporte desde el primer día es una capacidad real. Usa pilas de despliegue y ajustes de denegación para recuperar la protección frente a la deriva.

Multinube, o infraestructura no-Azure significativa, o un equipo que ya sabe Terraform: Terraform. El coste de una segunda herramienta y un segundo modelo mental supera las ventajas de Bicep.

Organización grande con ambos: elige uno por frontera en lugar de mezclar dentro de una capa. Bicep para los despliegues de aplicación que posee un equipo de producto, Terraform para la plataforma y la landing zone. Lo que no funciona es dos herramientas gestionando el mismo grupo de recursos — gana la última que se ejecuta y ninguna lo sabe.

Si eliges Terraform, lo específico de Azure que hay que acertar

• El bloque features {} es obligatorio en el proveedor y sus valores por defecto son opinados, en particular para el borrado suave y el purgado de Key Vault.
• Autentica la CI con credenciales federadas OIDC sobre una identidad gestionada asignada por el usuario, nunca con un secreto de cliente.
• Los bloqueos de recurso aplicados por política harán que terraform destroy falle en staging, de forma confusa, la primera vez.
• Estado en una cuenta de almacenamiento de la suscripción de gestión, con versionado y un bloqueo sobre el contenedor.
• Un estado por suscripción y capa, la misma estructura que usamos en AWS.

Si eliges Bicep

• Usa pilas de despliegue para todo lo que quieras proteger de cambios fuera de banda.
• Ejecuta what-if en el pull request y publica la salida, la misma disciplina que un plan de Terraform.
• Guarda los módulos en un registro privado de Bicep en un Azure Container Registry, versionados, en lugar de en rutas relativas entre repositorios.
• Azure Policy sigue siendo tu capa de gobernanza, no la herramienta de despliegue — mira política como código. Esto es cierto elijas lo que elijas, y es la decisión más importante de las dos.

En cualquier caso, la herramienta de despliegue importa menos que la estructura que despliega: los grupos de administración, las fronteras de suscripción y las políticas de el artículo de la landing zone. Hemos entregado ambas, y los proyectos que fueron bien no se distinguían por esta elección.

Qué hacer esta semana

Cuenta las cosas no-Azure de tu infraestructura que hoy se gestionan a mano — registros DNS, ajustes de repositorios de GitHub, configuración de monitorización. Si esa lista es larga, es el argumento para Terraform. Si está vacía, Bicep te costará menos de operar.