La Infraestructura como Código es uno de esos grandes avances de la tecnología que pasan desapercibidos en nuestro día a día.  Uno de los objetivos es definir nuestra infraestructura en código que nos permita hacer repetible la ejecución en diferentes entornos o recuperar toda la infraestructura en caso de desastres. Si estáis en algún tipo de cloud, debería de ser un requisito imprescindible.

Si hablamos de Azure, el propio cloud de Microsoft está basado en Azure Resource Manager (ARM), el servicio de implementación y administración de Azure. ARM permite definir nuestra infraestructura usando un sistema de plantillas con una sintaxis declarativa que podemos clasificar como IaC,

Cómo crear recursos con una plantilla ARM

Pongamos un ejemplo para entender cómo crear nuestra infraestructura usando ARM. Nuestra aplicación necesita una máquina virtual, un App Service y un SQL Azure.

Hablemos de la plantilla necesaria para crear la máquina virtual.

En la plantilla podemos ver cómo se definen los recursos necesarios para crear una máquina virtual:

• Un almacenamiento de diagnóstico Microsoft.Storage/storageAccounts
• Un disco administrado Microsoft.Compute/disks
• Una red virtual Microsoft.Network/virtualNetworks
• Una interfaz de red conectada a la red virtual Microsoft.Network/networkInterfaces
• La máquina virtual (por fin) Microsoft.Compute/virtualMachines con los recursos anteriores asociados

Fácil pero complejo de leer y mantener, ¿no os parece?

Azure Bicep al rescate

Las plantillas de IaC no son sencillas. Fijaos en la complejidad del json que simplemente crea una máquina virtual. Las plantillas ARM son muy potentes, incluso en la última versión podemos ejecutar scripts PowerShell o de Az Cli, pero la complejidad que esto implica no ayuda en la adopción de IaC.

Para ayudar con esta complejidad, Microsoft ha desarrollado un lenguaje de dominio (DSL) llamado Azure Bicep. Bicep nos ayuda a desarrollar plantillas ARM con un lenguaje sencillo que nos ayuda a quitar complejidad de las plantillas ARM, pero no nos resuelve el que necesitamos tener conocimiento de ellas para poder aplicar las configuraciones.

Como podemos ver en la imagen, podemos generar el fichero .json de una plantilla ARM usando un comando de compilación Bicep que compila nuestro fichero .bicep o directamente realizar el despliegue con Az Cli o con PowerShell con el fichero .bicep.

En el fragmento de código anterior, tenemos la misma implementación de los recursos necesarios para crear una máquina virtual usando Bicep. ¿Qué os parece? Bastante más simple de leer y, os invito a probarlo, más simple de desarrollar.

Aunque existen otras opciones como Terraform, una herramienta que usa ficheros de configuración declarativos para implementar la infraestructura en un entorno multi-cloud, Pulumi o Farmer, Azure Bicep puede ofrecer las siguientes ventajas:

• Soporte a nuevos recursos de ARM desde el primer día, algo que en otros productos como Terraform no es aplicable, tenemos que esperar a que se haga la implementación adecuada.
• El modelo de despliegue de Bicep está soportado en Azure que es quien controla el estado de los recursos y el flujo de despliegue, en otros, como Terraform, el estado se mantiene en local, con el riesgo de pérdida o sobreescritura.

Por su puesto, Azure Bicep es sólo para Azure, si tenéis un entorno multi-cloud y queréis mantener un único lenguaje o framework de despliegue, Bicep no encaja.