Bienvenidos a otro episodio de Píldoras de Conocimiento de Microsoft aquí en M365FM. Soy su anfitrión Mircopit. Han estado desplegando recursos de Azure haciendo clic por todo el portal. Funciona bien hasta que deja de hacerlo. Luego tienes que hacerlo de nuevo, pero no recuerdas exactamente qué elegiste. Necesitas pasárselo a un compañero de equipo y no puedes seguir tus pasos. ¿Control de versiones? Nena, que confirma. Es el problema que vamos a resolver hoy. Al final de este episodio, entenderás qué es la infraestructura como código, por qué existe VCEP y cómo hace que los despliegues en Azure sean más sencillos y fiables, sean más sencillos y fiables. Empezaremos con el problema, luego la solución. Y después un ejemplo práctico que puedes seguir. Toma tu café y empecemos. Próximo el portal. La trampa de hacer clic para desplegar, parece. Inicia sesión, rellenas un formulario, pulsas crear y listo.

Pero, ¿qué pasa cuando necesitas hacerlo de nuevo con la misma configuración, región y convención de nombres? Tienes que recordar cada una de las cosas que elegiste y ahí es donde todo se complica. El desplegue manual significa resultados inconsistentes, error humano y sin rastro de auditoría. Aquí hay un ejemplo del mundo real. Alguien de tu equipo crea un recurso con una configuración ligeramente diferente. Ahora tienes dos entornos que no coinciden. Uno funciona, el otro no hay buena suerte. Averiguando por qué. Luego está el problema de la documentación. Infraestructura en un documento de Word. O peor, un video de YouTube grabado hace seis meses cuando el portal se veía completamente diferente. Las funciones se mueven, los menús cambian, aparecen nuevas opciones. Me senté con un gerente del producto del equipo del portal Dashware y dijo que lanza nuevas funciones dos veces al día. Dos veces al día.

Tu documento de Word está obsoleto antes de que termines de escribir. Aquí está la web. Hacer clic funciona para aprender. Falla producción. Entonces, ¿cuál es la alternativa? Escribes un archivo que describe lo que quieres, luego le dice a Azure que lo construya. ¿Qué es la infraestructura como código? Infraestructura como código significa gestionar tu configuración en la nube con código en lugar de hacer clic a través de un portal. Esta es la idea central. Escribes un archivo que describe tu infraestructura, ese archivo, vive en tu repositorio y puedes controlar sus versiones, revisarlo en una solicitud de extracción y ejecutarlo de nuevo mañana para obtener el mismo resultado. Hay un término clave aquí, declarativo. Eso significa que describes lo que quieres, no cómo construirlo. No le dices a Azure que primero crea un grupo de recursos, luego añade una cuenta de almacenamiento y luego configure la red.

En su lugar, dices que eres un grupo de recursos con una cuenta de almacenamiento y red configurados así y Azure determina el orden. El resultado es algo llamado y da potencia. Ejecútalo una vez, ejecútalo 100 veces y obtendrás el mismo resultado. Esa es la potencia. Piénsalo como un plano frente a construir a mano. Plano es repetible, compartible y revisable. Trégalo a alguien más y construirán exactamente lo mismo. Ahora bien, varias herramientas. Plantillas ARM en Bicep, Terraform. Todas implementan el mismo concepto de diferentes maneras. Esa es una distinción importante. La infraestructura como código es el concepto. Bicep es solo una herramienta que lo implementa. Pero aquí está el detalle. Azure ha tenido un lenguaje de I hace por años llamado plantillas ARM. Y hay una razón por la que Microsoft creó uno nuevo. El problema es las plantillas ARM. Las plantillas ARM son el formato original de Azure.

Son archivos JSON y tienen muchas ventajas. Cobertura total de cada recurso de Azure. Y el mismo motor de despliegue que se usa internamente. Si puedes crearlo en el portal, puedes definirlo en una plantilla ARM. Entonces, ¿cuál es el mismo? JSON es excelente para las máquinas, pero terrible para los humanos. Déjame mostrarte que merfe. Una cuenta al almacenamiento en una plantilla ARM toma unas 20 líneas de código. La misma cuenta al almacenamiento en Bicep, unas 10 líneas. La versión JSON es aproximadamente el doble de W. Esos son un recurso sencillo. Imagina un despliegue completo con red, cómputo, bases de datos y reglas de seguridad. La plantilla ARM se convierte en texto. Los puntos conflictivos comunes son previsibles. Coma faltantes, corchetes, desparejados, anidación verbosa que dificulta saber dónde termina un recurso y empieza otro, empieza otro. Pasan más tiempo luchando con la sintaxis JSON que definiendo realmente tu infraestructura.

Y luego están las dependencias. En ARM tienes que declarar manualmente Depensan. Si el recurso A necesita que el recurso B exista primero, tienes que escribir eso explícitamente. Si olvidas uno, tu despliegue falla. Buena suerte descubriendo cuál olvidaste. Si alguna vez has intentado escribir un archivo JSON de 200 líneas a mano, no es divertido. Ni un poquito. La curva aprendizaje pronunció. Los nuevos miembros del equipo luchan por entender las plantillas ARM. La barrera de entrada es alta. ¿Y qué sucede en la práctica? Muchos equipos terminan con una sola persona que conoce la plantilla ARM. Esa persona se convierte en un punto único de falla. Es el único que puede modificar el despliegue y el único que puede depurarlo cuando algo falla. Eso no es sostenible. Microsoft escuchó los comentarios y creó Bicep para resolver exactamente tus problemas. ¿Qué es Bicep? Entonces, ¿qué es exactamente Bicep?

Es un lenguaje diseñado para implementar recursos de Azure y, en esencia, es un transpilador. Escribes en Bicep y se compila JSON de ARM. El mismo motor por debajo, pero una forma mucho más limpia de escribir. Y el nombre Bicep es en realidad ARM del letreado al revés Bicep. ARM. Una pequeña broma interna, Microsoft. Pero una vez que lo ves en acción, tiene sentido. Bicep se sitúa sobre ARM en lugar de reemplazarlo. Obtienes el mismo poder con una sintaxis en sí. Bicep no reemplaza ARM y se construye sobre él. Todo lo que puedes hacer con ARM puedes hacerlo con Bicep. Cada tipo de recurso, cada versión de API, cada opción de configuración está allí. La única diferencia es cómo lo escribes. La sintaxis es mucho más limpia. Sin comillas en los nombres de propiedades, sin comas, entre propiedades, sin corchetes que rastrear. Simplemente demasiado. Compara las dos versiones lado a lado. La versión JSON de ARM de una cuenta de almacenamiento está llena de ruido.

Comillas, comas, corchetes, anidamiento. La versión de Bicep tiene la misma información, pero es legible. Puedes mirarlo e inmediatamente entender qué está haciendo sin tener que pasar por capas de sintaxis JSON. Una gran mejora es la inferencia automática de dependencias. En ARM tienes que declarar manualmente Dependson. Pero en Bicep, si el recurso A hace referencia al recurso B, el sistema determina la dependencia automáticamente. No necesitas escribir. Implemente función. Y eso por sí solo ahorra horas de depuración. Los módulos son otra pieza importante. Puedes dividir tu infraestructura en piezas más pequeñas y reutilizables y compartirlas entre proyectos. Un equipo construye un módulo de red y otro equipo lo utiliza. No hay necesidad de reinventar la rueda cada vez. Los parámetros y variables te permiten definir tus entradas una vez y reutilizarlas en todas partes. Se acabó el buscar y reemplazar valores codificados.

Y la interpolación de cadenas significa que puedes escribir el prefijo de almacenamiento en lugar de complejas funciones de concatenación. Las herramientas son otra razón por la que es tan agradable trabajar con Bicep. La extensión de Westcode te brinda IntelliSense, resaltada de sintaxis y verificación de errores en tiempo real. Honestamente, es una de las mejores extensiones del lenguaje en Westcode. Empiezas a escribir y sugiere lo que viene después. Cometes un error y te lo indica de inmediato. Ya no hay que esperar que una implementación falle para descubrir que olvidaste una coma. Entonces, ¿cómo se ve esto realmente en la práctica? Veamos en qué se diferencia Bicep de ARM. Bicep frente a ARM, ¿qué es realmente diferente? Hablemos de lo que realmente cambia al escribir Bicep en lugar de ARM JSON. El tamaño del archivo es una diferencia. Los archivos Bicep son casi la mitad del tamaño de las plantillas ARM equivalentes.

No hay ninguna exageración. Eliminas todas las comillas, comas, corchetes y código repetitivo. Y lo que queda es solo la definición de la infraestructura. La mitad del código el mismo resulta. La elegibilidad mejora naturalmente. Menos líneas, estructura más limpia, más fácil de entender a simple vista. Cuando abres un archivo Bicep puedes escanearlo y entender que se está implementando. Con ARM JSON tienes que atravesar capas de anidamiento antes de encontrar la configuración real del recurso. Las dependencias ahorran muchísimo tiempo. En ARM declaras manualmente los depends. Si omites uno, tu implementación falle. En Bicep, si el recurso A hace referencia al recurso B, el sistema lo maneja automáticamente. Añade la dependencia cuando se compila ARM JSON. No tienes que pensarlo, simplemente funciona. Y eso por sí solo ahorra horas de depuración. Los módulos son una de referencia importante.

ARM tenía plantillas anidadas, pero eran tediosas de manejar. Archivo separado, vinculación compleja, difíciles de versión. Bicep tiene módulos que son más limpios, versionables y reutilizables. Defines un módulo una vez, lo publicas en un registro y lo referencias desde cualquier lugar. El mismo módulo, la misma configuración siempre. El proceso de implementación en sí es idéntico. Bicep se compila a ARM JSON y luego a Azure's Manager lo despliega. El mismo botón, la misma tuve. No necesitas cambiar tu proceso de implementación, solo cambias cómo escribes las plantillas. What if es una función que ARM tiene técnicamente, pero Bicep hace mucho más accesible. Puedes previsualizar los cambios antes de desplegar y ver exactamente qué se creará, modificará o eliminará. Sin sorpresa, sin eliminación es accidental. Ejecutas what if, revisas el resultado y si todo parece correcto, implementa. La curva de aprendizaje es un área donde Bicep destaca.

ARM JSON asume que sabes lo que estás haciendo. Está diseñado para máquinas, no para humanos. Bicep está diseñado para principiantes. Sintaxis intuitiva y herramientas que te guían. Puedes aprenderlo una tarde y ser productivo al final de la semana. Microsoft ha convertido a Bicep en la experiencia de creación recomendada. Todas las nuevas funciones y mejoras se dirigen primero a Bicep. Las plantillas ARM siguen funcionando y no desaparecerán, pero probablemente no deberías escribir nuevas. Si empiezas un proyecto nuevo, Bicep es la mejor opción. Tres líneas de Bicep para desplegar un grupo de recursos. Tengo tres líneas. El ARM JSON equivalente tiene cerca de 15 líneas. Mismo resultado, misma implementación. Pero uno es legible y el otro es ruido. Ahora quizás te preguntes qué pasa con Terraform. Debo aprender Bicep o Terraform. Bicep frente a Terraform, ¿cuál deberías usar? Bienvenidos de nuevo a Microsoft Knowledge Nugget.

Soy Mirko Peters y hoy abordamos una pregunta que surge constantemente. Bicep o Terraform. Analicemos. Terraform funciona en múltiples nubes. Puedes usarlo para Azure, AWS, GCP o incluso las tres a la vez. Bicep, por otro lado, está creado solo para Azure y nada más. Se diferencia fundamental afecta a todo demás. Ahora bien, si trabajas con múltiples nubes, Terraform es la opción ideal. Prendes un lenguaje, una herramienta, un flujo de trabajo y funciona en todas partes. Pero si te enfocas principalmente en Azure, Bicep tiene ventajas reales. Y tienes app. No hay archivo de estado que gestione. Terraform tiene un archivo de estado que rastrea lo que implementa. Ese archivo es crítico. Si se corrompe o se desincroniza, tienes un problema serio. Debes almacenarlo de forma segura, hacer copias de seguridad y gestionar el acceso. Bicep se comunica directamente con Azure Resource Manager. Verifica lo existente y calcula las diferencias.

Sin archivo de estado, no hay problemas de sincronización ni riesgo de corrupción. Segunda ventaja, soporte desde Azure. Cuando Microsoft lanza una nueva función de Azure, Bicep la admite de inmediato, el mismo día. Terraform debe esperar una actualización del proveedor, que a veces es rápida y otras lleva semanas. Si necesitas usar una función nueva al instante, Bicep es la única opción. Tercero está creado por el equipo de Azure. Las herramientas, el IntelliSense y los mensajes de error están diseñados según cómo funciona Azure realmente. Al escribir Bicep, usas un lenguaje que entiende los recursos de Azure de forma nativa. Sabe qué propiedades son obligatorias, qué valores son válidos y qué dependencias existen. Es integración profunda y difícil de replicar con una herramienta de terceros. También puedes usar ambos. Muchas organizaciones usan Bicep para plataformas y zonas de aterrizaje y Terraform para cargas multinube.

No son mutuamente excluyente. Puedes elegir la herramienta correcta para cada tal. La respuesta honesta es, para aprender Azure específicamente, Bicep tiene menos pieza móvil. Es un camino más sencillo cuando estás empezando. No necesitas aprender sobre archivos de estado, proveedores o configuración de backend. Talas Azure CLI, abres VS Code y empiezas a escribir. Ya basta de teoría. Hablemos de lo que realmente necesitas para comenzar. Comenzar. Lo que realmente necesitas. Necesitas dos cosas para empezar. Azure CLI y la extensión de Bicep para VS Code. Eso es todo. No hay CLI de Bicep por separado que instalar ni herramientas adicionales que configuran. Azure CLI ya incluye Bicep. Instalar Azure CLI es bastante sencillo. Ve Microsoft Docs. Busca la página de instalación para tu sistema operativo. Si usas Mac, es solo un comando. Bro, instala Azure CLI. En Windows hay un instalador MSI.

Descárgalo, ejecutalo y listo. También funciona en Linux a través de tu gestor de paquete. Una vez instalado, ejecuta AssetAversion para confirmar que todo funciona. Deberías ver listadas tanto la versión de Azure CLI como la de Bicep. Ahora abre VS Code, ve al panel de extensiones a la izquierda y busca Bicep. Instala la de Microsoft, no una a terceros, la oficial. ¿Realmente necesitas esta extensión? Te ofrece IntelliSense que sugiere propiedades de recursos mientras escribes. Resalta la sintaxis para detectar errores al instante y verifica fallos en tiempo real. Verás líneas onduladas rojas bajo cualquier error antes incluso de intentar desplegar. Sinceramente, es una de las mejores extensiones del lenguaje en VS Code y gran parte de por qué Bicep es tan agradable de usar. Ahora, crea un archivo nuevo y llámalo main.bicep. La extensión de Bicep le indica a VS Code que se active. Sin ella, solo estarías escribiendo texto plan.

Con ella, obtienes la experiencia completa de herramientas. Aquí tienes un ejemplo real. Un despliegue de grupo de recursos en tres líneas de Code. Primero, estableces el ámbito objetivo en suscripción. Luego, defines el recurso, un grupo de recursos con un nombre y una ubicación. Eso es todo, Trisni. Comparalo con el equivalente en RMJSON, que son las 15 líneas de corchetes y comillas. Para desplegarlo, usas Azure CLI. Cuando estás desplegando en el ámbito de suscripción, el comando es azdeployment.subcreate. Pasas una ubicación para los metadatos del despliegue y apuntas a tu archivo Bicep. Esa es la forma de línea de comandos, pero también hay una experiencia guiada. En WS Code, haz clic derecho en el archivo Bicep y selecciona Deploy Bicep File. Te guía a través de todo el proceso. Te pide un nombre de despliegue, que selecciones tu suscripción, que crees o selecciones un grupo de recursos.

Y si tienes un archivo de parámetros, dices que no y se despliega. El resultado aparece en tu portal de Azure. Hay que hacer clic en el portal, pero ahora tienes un archivo que puedes reutilizar. Puedes enviarlo a tu repositorio, compartirlo con tu equipo y ejecutarlo de nuevo mañana. Y aquí viene la parte mágica. Ejecuta el mismo despliegue de nuevo y observa lo que sucede. Poder de ley en potencia. Esto es lo importante sobre ejecutar despliegues. ¿Quieres poder ejecutarlos una y otra vez sin romper nada? Eso es exactamente lo que te ofrece la ley en potencia. La primera vez que ejecutas el archivo Bicep quiere el grupo de recursos, pero la segunda vez que lo ejecutas, no pasa nada. Sin errores, sin duplicados, nada. Bicep comprueba lo que ya existe en Azure, lo compara con lo que pediste y dice que no hay nada que cambiar. No intentó crear un nuevo grupo de recursos y no dio error diciendo que ya existe uno.

Simplemente confirmó que el estado actual coincide con el estado deseado. Piénsalo como ejecutar git status en un repositorio limpio. No hay nada que hacer. Todo está ya exactamente como debería estar. Este es el poder de la infraestructura como code. Puedes ejecutar tu despliegue una y otra vez y obtener el mismo resultado siempre. Sin sorpresas, sin desviaciones. Sabes exactamente que hay desplegado porque el archivo lo indica. El archivo se convierte en tu única fuente de verdad. Nunca tienes que preguntarte si recordaste un ajuste, lidiar con el problema de función en mi equipo o buscar en el portal de Azure si alguien cambió algo. El archivo te dice lo que hay ahí. Si quieres cambiar algo, cambias el archivo y vuelves a desplegar. Si quieres verificar, ejecutas el despliegue de nuevo y confirma que todo coincide. Así es como generas confianza en tu infraestructura. El archivo es la fuente de verdad.

No tu memoria, no un documento de Word, no un video de YouTube de hace 6 meses, el archivo. Entonces, ¿dónde encaja VCEP en el panorama general de Azure? El panorama general. ¿Dónde encaja VCEP? VCEP vive dentro del ecosistema de Azure Resource Manager. Es una herramienta independiente. Mucha gente piensa que lo es, pero en realidad es solo una mejor forma de escribir plantillas ARM. Por debajo sigue siendo ARM. El mismo motor de despliegue, la misma API, todo igual. La única diferencia es cómo lo escribes. Y debido a que VCEP compila ARM, todo lo que funciona con ARM funciona con VCEP. Azure Policy aplica el cumplimiento en tus despliegues. R va a controlar a quién puede desplegar qué. Cost Management rastra los gastos de tus recursos. Azure DevOps y GitHub Actions despliegan tus archivos VCEP mediante pipelines. Todo funciona perfectamente porque VCEP genera JSON estándar de ARM. No pierdes nada al cambiar.

De hecho, ganas claridad. Microsoft ha construido todo un ecosistema alrededor de VCEP. Azure Verified Modules o ABM es una biblioteca seleccionada. Módulos de VCEP y Terraform que siguen las mejores prácticas. No tienes que escribir todo desde cero. Puedes usar módulos preconstruidos para patrones comunes como redes virtuales, cuentas de almacenamiento y servicios de aplicaciones. Están probados, mantenidos y alineados con el marco Word Architect Framework. El Cloud Option Framework incluye implementaciones de referencia en VCEP para arquitecturas empresariales estandarizadas. Si estás construyendo una zona de aterrizaje y landing zone, hiciste una plantilla de VCEP. Los deployment stacks te brindan gestión del ciclo de vida para grupos de recursos. Puedes implementar un stack y si eliminas un recurso de tu archivo VCEP, el stack puede limpiarlo por ti o por ti. O protégelo contra eliminaciones accidental.

Tú decides. El ecosistema sigue creciendo con más módulos, mejores herramientas y una integración más profunda con EA y GitHub Copilot. Puedes describir lo que quieres en lenguaje sencillo y Copilot genera el código de VCEP por ti. Microsoft sigue invirtiendo en VCEP como la experiencia de creación principal para Azure. Por lo tanto, las nuevas funciones se dirigen primero a VCEP. Las plantillas ARM siguen funcionando, pero la innovación ocurre en VCEP. Entonces, esta es la conclusión. Si trabajas en Azure, VCEP es el siguiente paso natural. Más allá de hacer clic en el portal, no tienes que aprender Terraform ni dominar el JSON de Arlen. Instalas dos cosas, escribes unas pocas líneas de código y estás implementando infraestructura repetible, controlada por versiones y confiable. Déjame dejarte algo práctico que puedes hacer hoy mismo. Así que ahora sabes que la infraestructura como código, por qué existe VCEP y cómo simplifica las implementaciones en Azure.

Este es el punto principal. VCEP no es un sistema de implementación diferente. Es una mejor forma de escribir las mismas plantillas ARM que escribirías de todos modos, usando el mismo motor y Azure Resource Manager, solo que en un lenguaje que los humanos realmente pueden leer y escribir y escribir. Y tienes un desafío para ti. Crea un archivo main.vCEP, implementa un grupo de recursos y ejecuta la implementación dos veces. Observa cómo funciona ambas veces. La primera vez crea el recurso y la segunda confirma que nada ha cambiado. Ese es el momento en que todo encaja, cuando te das cuenta de que nunca volverás a hacer clic en el portal. Es la base. Desde aquí puedes agregar cuentas de almacenamiento, redes virtuales y servicios de aplicaciones usando el mismo patrón. Escribe un archivo, implementalo y ejecutalo. Ese archivo se convierte en tu fuente de verdad y todo lo demás surge a partir de él.

Si esto te resultó útil, compártelo con alguien que todavía esté haciendo clic en el portal. Te lo agradecerán. Suscríbete en tu plataforma de podcast favorita y en el próximo episodio iremos más allá con VCEP implementando recursos reales con propiedades reales.