Bicep es la herramienta de Azure pensada para reemplazar las plantillas ARM y desplegar recursos en la nube con menos fricción. Si ya trabajas con infraestructura como código y buscas una sintaxis más limpia que JSON, esta guía te muestra cómo crear tu primer archivo .bicep desde Visual Studio Code y desplegarlo en un grupo de recursos.

Por qué elegir Bicep frente a ARM, CLI o Terraform

Dentro del ecosistema de Azure tienes varias rutas para desplegar recursos: plantillas ARM, línea de comandos con scripts batch, Cloud Shell, el portal y Terraform. Bicep entra en escena como una alternativa que simplifica la sintaxis de las plantillas ARM y mantiene un registro de los recursos ya publicados.

Esa última parte es la que marca la diferencia. Si descargas un archivo batch de la CLI, lo ejecutas dos veces seguidas, la terminal no sabe qué hacer con los recursos que ya existen y se llena de errores. Bicep y Terraform sí controlan ese estado, lo que reduce muchísimo los errores de despliegue.

¿Qué es Bicep en Azure? Es un lenguaje declarativo de Microsoft diseñado para reemplazar las plantillas ARM. Te permite definir recursos de Azure con una sintaxis más limpia que JSON y mantener el control del estado de tu infraestructura.

Cómo instalar la extensión de Bicep en Visual Studio Code

Antes de escribir una sola línea, abre Visual Studio Code y entra a la sección de extensiones. Busca Bicep, la extensión oficial de Microsoft, e instálala [2:00]. No es indispensable, pero le da formato al código y hace el trabajo mucho más cómodo.

Una vez instalada, crea una carpeta nueva en tu repositorio llamada Bicep y dentro un archivo main.bicep. Esa extensión activa el soporte del lenguaje y verás aparecer el ícono del robot que confirma que la extensión está funcionando.

Qué parámetros lleva un recurso de Storage Account en Bicep

El recurso Storage Account necesita varios parámetros entre llaves:

• Nombre de la cuenta de almacenamiento.
• Ubicación o región donde se desplegará.
• Tipo de almacenamiento (sku).
• Nivel o kind del almacenamiento.

Son prácticamente los mismos parámetros que usarías desde la CLI de Azure, con la ventaja de que aquí los declaras una sola vez y los reutilizas. La documentación oficial de cada recurso de Azure te muestra tres formas de desplegarlo: con Bicep, con plantilla ARM o con Terraform.

¿Bicep reemplaza a Terraform? No. Bicep es nativo de Azure y reemplaza a las plantillas ARM. Terraform sigue siendo la herramienta de infraestructura como código multinube por excelencia y ambos pueden coexistir según tu caso.

Cómo desplegar un archivo Bicep en un grupo de recursos

Con tu archivo main.bicep listo, abre la terminal y ubícate en la carpeta donde guardaste el archivo. Bicep puede desplegar a nivel suscripción o a nivel grupo de recursos. En este flujo se trabaja a nivel grupo, así que primero crea el grupo de recursos y luego ejecuta el comando de despliegue [5:30]:

bash az deployment group create --resource-group <nombre-grupo> --template-file main.bicep

La primera vez que lo ejecutes, la terminal te pedirá instalar una extensión adicional para Bicep. Acepta con Yes y la instalación corre automáticamente.

Cómo interpretar los errores que devuelve Bicep

Aquí pasa algo interesante. Al ejecutar el comando aparecieron errores reales que vale la pena entender:

1. Nombre con mayúsculas: la cuenta de almacenamiento tenía bicepStorageAccount con mayúsculas, lo cual rompe la regla de nombres de Storage Account en Azure.
2. Nombre ya tomado: al corregirlo, alguien más en Azure ya tenía bicepstorage registrado. Los nombres de Storage Account son globales.
3. Nombre único: agregando un sufijo numérico como 1253, el despliegue se completó sin problemas.

Lo valioso es que Bicep te marca estos errores antes y después del despliegue, igual que la CLI de Azure, sin tener que abrir el portal para validar.

Cómo verificar el recurso desplegado en el portal de Azure

Una vez que el comando termina con éxito, entra al portal de Azure y busca el grupo de recursos que creaste. Ahí verás tu Storage Account con el mismo aspecto que tendría si lo hubieras creado por la CLI o desde la interfaz gráfica. Para Azure no hay diferencia en el resultado final, solo en el camino que tomaste para llegar.

La ventaja de mantener este flujo en archivos .bicep es que tu infraestructura queda versionada, replicable y lista para integrarse en pipelines de CI/CD. En el siguiente paso del aprendizaje viene lo más potente: agregar parámetros y variables para que un mismo script despliegue distintos ambientes solo cambiando valores, sin reescribir el archivo completo.

¿Ya probaste Bicep en tu suscripción de Azure? Cuéntame en los comentarios qué recurso fue el primero que desplegaste y si te topaste con el clásico error de nombre duplicado.