La infraestructura como código (IaC), especialmente con Terraform, es una pieza clave de nuestra Azure Foundation y un elemento esencial en toda transformación hacia la nube. Lo hemos visto una y otra vez: un uso estructurado de IaC no solo acelera la adopción de servicios en la nube, sino que también impulsa el desarrollo de nuevos productos. Y aquí surge la pregunta inevitable: ¿cuál es el mejor punto de partida?

Next Level Azure IaC: Azure Verified Modules

Módulo Verificado de Azure – IaC según las mejores prácticas de Microsoft

Microsoft se propuso enfrentar este desafío y lanzó losAzure Verified Modules (AVM): un marco diseñado para desplegar recursos en Azure siguiendo las mejores prácticas.

Los AVM vienen en tres variantes bien definidas:

  • Resource Modules – Implementación de un recurso específico en la nube.
  • Pattern Modules – Implementación de una carga de trabajo predefinida.
  • Utility Modules – Módulos auxiliares utilizados por Resource o Pattern Modules.

Para garantizar un estándar común, Microsoft estableció requisitos que todo nuevo recurso AVM debe cumplir. Esto aplica tanto a Terraform como a Bicep, el propio lenguaje IaC de Microsoft Azure.

Cada AVM tiene un responsable designado dentro de Microsoft que se encarga de su creación, mantenimiento y resolución de problemas.

Y, en un giro muy característico de la cultura open source, todos los módulos están disponibles bajo licencia MIT en los repositorios públicos de la Azure GitHub Organisation. ¿Un módulo falla? ¿Falta un parámetro crítico? Cualquiera puede abrir un issue o contribuir directamente al desarrollo.

¿Cómo empezar con AVM?

Los AVM funcionan igual que cualquier otro módulo en Terraform o Bicep: se invocan de forma independiente y reciben los parámetros necesarios. Las directrices de AVM reducen estos parámetros al mínimo, allanando el camino para una adopción sin fricciones.

Ejemplo con Terraform: Para desplegar una máquina virtual con un disco de datos adicional, normalmente necesitas al menos estos recursos de Azure:

  • azurerm_windows_virtual_machine oder azurerm_linux_virtual_machine
  • azurerm_network_interface
  • azurerm_managed_disk
  • azurerm_virtual_machine_data_disk_attachment<

Cada uno de estos recursos exige parámetros recurrentes como el nombre del grupo de recursos, la región de destino o la propia denominación de los recursos.

Con AVM, todo ese entramado se reduce a una única llamada con los parámetros esenciales. El módulo se encarga del resto. Además, como los AVM ya integran las mejores prácticas de Microsoft, muchos valores vienen preconfigurados: TLS 1.2 habilitado por defecto o el bloqueo del acceso público son solo dos ejemplos claros.

¿Qué hacer si no existe un AVM para mi recurso?

La licencia open source de AVM ofrece un camino claro: cualquiera puede iniciar su propio desarrollo basándose en este marco. Y si más adelante Microsoft decide crear un módulo oficial para ese recurso, tu trabajo previo puede convertirse en una contribución valiosa para toda la comunidad.

GKVM - glueckkanja ❤️ Open Source

En glueckkanja seguimos exactamente este enfoque y apoyamos a nuestros clientes en el desarrollo de módulos basados en el framework AVM, los cuales posteriormente ponemos a disposición del público.

A estos módulos los llamamos GKVM (GlueckKanja Verified Modules), porque no solo cumplen con los lineamientos de AVM, sino que también incorporan el conocimiento que hemos acumulado en numerosos proyectos reales.

GKVM Resouce Modules:

GKVM Pattern Modules:

¡Agradecemos cualquier issue que ayude a ampliar los módulos con nuevas funcionalidades!

Recursos adicionales