¡Mas poder para las Azure Functions!

Para nadie es un secreto que soy un fanático del modelo serverless en general y de Azure Functions en particular, habiendo dedicado unos cuantos artículos a cubrir este servicio de Azure, es que es simplemente un modelo de trabajo muy conveniente para varios casos de uso, y que hoy con motivo del Microsoft Build 2024 tiene uno de sus cambios mas trascendentes desde su lanzamiento y es el nuevo plan Azure Functions Flex.

No nos entretendremos explicando cómo funciona el servicio, solo debemos recordar Azure Functions se basa en proporcionar una abstracción al desarrollador, donde no tenemos que interactuar con una máquina virtual, por mas que por detrás haya una, y que su modelo de trabajo se orienta esencialmente a los eventos, donde un evento puede ser una invocación HTTP, un timer, la inserción de un elemento en una cola, etc. Y con esos pilares se pueden construir aplicaciones cloud native muy interesantes.

El caso es que a pesar de todo su poder Azure Functions tiene algunas limitaciones que siempre deben tenerse en cuenta al momento de diseñar una aplicación:

  • El cold start: un modelo serverless “puro” (llamado modo Consumo en Azure) en teoría se basa en que el recurso de computo no esta asignado de manera dedicada al cliente, sino que solo se asigna cuando haya necesidad (o sea cuando el Functions es invocado), pero esto implica que haya un tiempo de espera mientras el recurso se inicializa y se asigna para su uso, dicho tiempo de espera se conoce como “cold start” y puede ser inconveniente en los casos de uso en que se requiera inmediatez, esta situación ha llevado a que se tenga que recurrir a planes como:
  • App Service o Premium: esto consiste básicamente en tener el recurso de computo permanentemente asociado al cliente, evitando el cold start, aunque teniendo el inconveniente de tener que pagar por el recurso de forma permanente, aun cuando no se haga uso de el, en todo caso esto puede ser aceptado ya que nos permite hacer uso de una funcionalidad muy interesante y necesaria:
  • VNET Integration: ha sido inevitable y totalmente lógico, que las organizaciones hayan ido ordenando sus diversos recursos en la nube mediante redes privadas (VNETs y subnets), lo cual permite el desarrollo de infraestructuras hibridas que comuniquen el mundo on premise con el mundo cloud, y obviamente no exponer a Internet recursos sensibles. El problema es que los Azure Functions de modo Consumo no pueden vincularse a una VNET, por lo que si se quiere trabajar en un modelo orientado a eventos, se hace necesario usar los planes App Service o Premium.
  • Pocas opciones de dimensionamiento: cuando se usa el modo Consumo NO se puede dimensionar el recurso de cómputo que nos atendera cuando sea invocado, si queremos precisar que tan potente será este necesariamente debemos recurrir a los modo App Service o Premium.

Y bueno, dirán, ¿por qué tanto repaso? Es que el día de hoy en el Microsoft Build se ha anunciado el Public Preview del nuevo plan Azure Functions Flex Consumption, que básicamente nos ofrece un modelo basado en el modo Consumo, pero con las siguientes ventajas: Finish Reading: ¡Mas poder para las Azure Functions!

¡Actualiza tus Azure Functions! ¡Ya!

Este articulo puede ser considerado una continuación de los anteriores, pero en este caso vamos a tratar de ir al grano respecto a una situación que algunos todavía podemos estar pasando y sobre la cual no se ha tomado acción, asi que vamos a ello.

Recordemos, desde diciembre del 2022 los runtime V2 y V3 de Azure Functions ya no están soportados, pero ¿eso significa que ya dejaron de funcionar las Functions que tenemos en producción? Pues no, ahí siguen operando a menos que Microsoft anuncie su apagado definitivo (como ya paso con otros servicios que comentamos aquí y aquí) peroooo…. sin garantías de que sigan funcionando como se espere, una razón (simplificando mucho) es que Microsoft puede «meter mano» en la infraestructura compartida pero teniendo en mira solo los parámetros de operación de la versión V4 (la soportada actualmente) y las versiones de los lenguajes soportados por V4. Por ejemplo si tu Function fue hecho en una versión de Node antigua (pero entonces soportada por la V3) y aun no has migrado a la V4, no hay garantías ni soporte del funcionamiento esperado de tu aplicación, si pues no hay «Pero si ayer funcionaba», es que simplemente no se ha sido diligente en seguir los ciclos de vida de la tecnología que estamos usando.

Reiterando lo que ya conversamos anteriormente, esto deriva del principio de Responsabilidad Compartida, al elegir trabajar con un servicio IaaS, PaaS o un SaaS, estamos aceptando el nivel de intervención que el proveedor ha definido para ese tipo de servicio, así que un PaaS (como Azure Functions) va a implicar que el proveedor tome un rol muy proactivo respecto al ciclo de vida y mantenimiento del servicio que esta ofreciendo, así que si uno quiere que Azure lo «deje en paz» por mucho tiempo respecto al mantenimiento, pues… no queda sino optar por un servicio IaaS como las Máquinas Virtuales, con todo lo que eso implica.

Bueno, discusiones de obsolescencia aparte, queda claro que ya estamos tarde, si tenemos Functions de versión 3 o 4 nuestras aplicaciones ya no están bajo soporte, por lo que toca efectuar la migración respectiva (lo cual puede implicar cambios de código para alinearnos a versiones modernas de los lenguajes/frameworks), así que el primer paso sería averiguar que Functions requieren actualización.

Para este problema la solución mas «sencilla» seria revisar cada Functions y ver si hay alguna alerta, como la que vimos anteriormente:

El problema es que esto solo tiene sentido si en nuestras subscripciones tenemos pocas Functions, por lo que el paseito seria sencillo, pero… si tenemos varias subscripciones y Functions desplegados ¿Como hacemos? Si, lo suyo seria algún query o script para lograrlo, así que usando Azure Copilot conseguí este query para ejecutar en Azure Graph:

resources 
| where type == 'microsoft.web/sites'
| where properties.kind == 'functionapp'
| extend runtimeVersion = tostring(properties.siteConfig.netFrameworkVersion)
| where isnotnull(runtimeVersion) and runtimeVersion contains '4.'
| project id

La mala noticia es que este query no funciona, el valor «runtimeVersion» siempre retorna una cadena vacia, por lo que hacer comparaciones alrededor de este valor no tiene mucho sentido.

Asi que conversando con algunos MVPs me entere que el camino era el uso de PowerShell, y luego de unas pruebas vi que la solución que me brindo Brett Miller era la adecuada:

PS /home/brett> $query = "resources
| where type == 'microsoft.web/sites'
| where properties.kind == 'functionapp'
| extend runtimeVersion = tostring(properties.siteConfig.netFrameworkVersion) "
$functions = Search-azGraph -Query $query

PS /home/brett> $functions | foreach-object { 
$appSettings = Get-AzFunctionAppSetting -Name $_.name -ResourceGroupName $_.resourceGroup            
    [pscustomobject]@{
       functionname = $_.Name  
       runtimeVersion = $appSettings.FUNCTIONS_EXTENSION_VERSION
    }
}

Claro que para que esto funcione debemos ejecutarlo en el lugar correcto: el Cloud Shell que nos da el Portal de Azure o el propio Cloud Shell de Windows, y para que el query se efectue correctamente hay que instalar el paquete respectivo, por lo que solo hay que ejecutar previamente esta linea dentro del Cloud Shell:

Install-Module -Name Az.ResourceGraph

Y como pueden ver, ahora si conseguí la información que estaba buscando:

Upps… pensé que ya había migrado todos los Functions que uso para mis demos, a cualquiera le puede pasar, pero lo importante es que ya tenemos la información necesaria para ubicar nuestros Functions obsoletos y empezar la migración.

No puedo dejar de mencionar que Stefano Demiliani, otro fellow MVP, también encontró una solución para este problema, la cual esta detallada aquí.

Así que… ¡no hay excusas! ubica tus Functions a actualizar y ¡migra ya!

Todo lo que querías saber sobre las “versiones” en Azure y no te atrevías a preguntar (2)

Bueno, esto tardo un poco mas de la cuenta, pero aquí continuamos con lo ya empezado, tratar de entender los ciclos de vida y «versiones» de los diversos servicios de Azure, así que vamos a ello y hoy veremos algunos datos que nos servirán para planear bien la provisión de nuestros servicios, y si en la ocasión anterior conocimos los casos vinculados a las deprecación de servicios y a las generaciones de computo (máquinas virtuales), por lo que hoy toca continuar con los…

Servicios PaaS, en este caso empezaremos enfocándonos en nuestros queridos Azure Functions, como todos sabemos si uno opera en el modo Consumo no tiene margen de maniobra para elegir la infraestructura base sobre la que va a correr nuestro código, pero eso cambia si se opta por los modos Premium o App Service, en ese sentido, al provisionar un nuevo Function desde el Portal (1), podemos ver diversas opciones para desplegar nuestro Function: Finish Reading: Todo lo que querías saber sobre las “versiones” en Azure y no te atrevías a preguntar (2)

Todo lo que querías saber sobre las “versiones” en Azure y no te atrevías a preguntar (1)

Hace unas semanas alguien me pregunto sobre las “versiones recomendadas” de los recursos de Azure que debían provisionar para una solución, esa pregunta de tanto en tanto aflora y suele ser común entre quienes tienen experiencia en TI on premise, y que por lo general suelen estar acostumbrado a que los software tengan años o versiones, por ejemplo, Windows Server 2003, Windows Server 2019, Oracle 8i, etc.

Súmale el hecho de que en este mundo es usual seguir políticas de “no usar la última versión, hasta que salgan los primeros parches o usar solo la penúltima que ya está probada” “usar las versiones de manera intercalada para ahorrar en licencias (perpetuas)”, paradigmas que tenían sentido en el mundo on premise cambian de valor cuando las organizaciones migran hacia la nube y especialmente a esquemas de pago por suscripción/uso como por ejemplo en el caso de Office, antes era usual que una organización comprara las licencias perpetuas de Office 2010, ignorara el lanzamiento de Office 2013, para solo actualizar hacia Office 2016.

Como sabemos con Office 365 (ahora Microsoft 365), el modelo cambio a un pago por subscripción periódica, donde Microsoft se hace cargo de actualizar constantemente con las últimas versiones que vayan liberando, liberándonos de problemas de desplegar nuevas versiones, nuestra responsabilidad obviamente es elegir el plan correcto para las necesidades y presupuesto de nuestra organización: E1, Pequeña Empresa, A3, etc.

Con esta premisa respecto al modelo de compra basado en uso, podemos ir profundizando en el concepto, y plantearnos la pregunta “¿Existen versiones (incrementales) de los servicios PaaS en la nube?”, y la respuesta corta seria “En la mayoría de los casos no debemos preocuparnos, porque como parte de la responsabilidad compartida, Azure se hace cargo de ir actualizando las plataformas base de los servicios PaaS que vayamos utilizando”. Finish Reading: Todo lo que querías saber sobre las “versiones” en Azure y no te atrevías a preguntar (1)

¿Cuales son las diferencias entre Azure Container Instances, Azure Container Apps y Azure Kubernetes Services? (y ii)

El articulo anterior dejo las bases respecto a como ha ido la evolución de las tecnologías de contenedores, y el contexto en que se ubican los Azure Container Apps (ACA), pero creo que falta precisar un poco respecto a los casos de uso en que se puede aplicar esta tecnología o sus “hermanos” en Azure.

Empezare con algo que puede que ahora luzca menos glamoroso, pero que si que causo impacto en el momento de su lanzamiento: los Azure Container Instances, como mencionamos en su momento, esta tecnología surge para evitar el tener que lanzar los contenedores dentro de un cluster o de una MV, en ese sentido, que se puede hacer ahora con ellos:

  • Lanzar servicios de “servidor” basados en contenedores, que no requieran una orquestación ni escalamiento, como puede ser un servidor SFTP en la nube
  • Experimentación individual, en desarrollo, de un contenedor que luego se integrara como parte de una plataforma de microservicios.
  • ML, si, esto es algo que aprendí mientras preparaba mi certificación en Azure AI, resulta que algunos modelos sencillos de ML se pueden desplegar en Azure Container Instances, interesante la verdad.
  • Dar soporte a un escalamiento sencillo a los clusters AKS, creando virtual nodes en escenarios en que no es conveniente escalar el cluster hacia nodos “reales”, ojo este modelo tiene algunas limitaciones por lo que toca revisar si es la solución para nuestra necesidad en concreto.

Como se puede ver, los ACI aun dan mucho juego, pero de nuevo vamos a la pregunta respecto a los casos de uso que corresponden a AKS y ACA, y esto ya entra en los terrenos del mal llamado “juicio de experto” que son tan subjetivos, pero trataremos de delimitar la cancha: Finish Reading: ¿Cuales son las diferencias entre Azure Container Instances, Azure Container Apps y Azure Kubernetes Services? (y ii)

¿Cuales son las diferencias entre Azure Container Instances, Azure Container Apps y Azure Kubernetes Services?

Aquí de vuelta, y me complace comentar que he sido renovado por séptima vez como Microsoft MVP para Developer Technologies y Microsoft Azure, reconocimiento que es a la vez un reto que motiva a seguir compartiendo conocimiento, así que vamos a ello.

Hace unas semanas tuve una conversación respecto a las diferencias entre ACA, ACI y AKS, lo cual me hizo pensar que si, puede haber cierta confusión ya que los servicios no nacieron en el mismo tiempo, así que para entender su contexto repasemos un poco de historia.

Muchos recordamos el boom de Docker y los Contenedores durante 2015 y 2016, y si, en ese momento significo toda una revolución respecto a como se desarrollaban y desplegaban las aplicaciones, no nos detendremos en eso, pues ya se ha escrito mucho al respecto, pero si anotaremos las consecuencias inmediatas de ese boom para entonces:

  • Impulso para el uso de Linux, ya que era el único Sistema Operativo que permitía ejecutar Docker
  • Se abrió el camino para el crecimiento de un patrón de arquitectura llamado “microservicios”
  • Lo cual derivo en la necesidad de ejecutar mas de un contenedor a la vez

Si pues, yo un usuario clásico de Windows de toda la vida tuve que desempolvar mis oxidados conocimientos de Linux (¡en una MV sobre Azure!)  a fin de poder practicar con Docker y así hacer mis primeras demos al respecto. Y claro, eso me dejo con la inquietud de “¿es conveniente desplegar una MV para tan solo un contenedor?”, claro eso me llevo a conocer y probar lo que era Docker Composer, y leer sobre algo llamado Docker Swarm.

Tiempos acelerados, y en ese momento los objetivos de Microsoft iban por dos frentes: integrar a Windows (Server) en el mundo de los contenedores y por otro lado ofrecer alternativas para simplificar el despliegue y la orquestación de los contenedores en la nube. Finish Reading: ¿Cuales son las diferencias entre Azure Container Instances, Azure Container Apps y Azure Kubernetes Services?

Y… ¿para que se usa DevOps? (o ¿como empezar en DevOps?)

Estas conversaciones siempre terminan aflorando, pero casi siempre coinciden por la misma temporada, y en esta ocasión lo que me llevo a escribir esta nota fue la siguiente imagen que me paso mi enamorada:

La vi y dije «Upss ¿aun siguen con eso?», y es que si no es raro encontrar estas «guias» o recomendaciones para el que quiera iniciar su «carrera como DevOps», lo cual ya de por si esta mal porque recordemos que DevOps es una practica/filosofía/enfoque y no un rol, pero esta vez no ahondaremos en ello, sino nos centraremos en el entendimiento de DevOps y de lo que queremos lograr con su adopción.

Empecemos viendo el gráfico, y listemos las categorías:

  1. Lenguajes de Programación
  2. Administración de Servidores
  3. Redes y Seguridad
  4. Infraestructura como Código
  5. CI/CD
  6. Logs y Monitoreo
  7. Nube

Si, lo mas obvio es que (como de costumbre) la lista es de herramientas, y nada de practicas, pero es que aun tratándose de herramientas, faltan categorías relevantes, por ejemplo… donde ¿están Selenium, Cypress, PlayWright y otros? (Testing) ¿Se ha considerado la relevancia de herramientas como LaunchDarkly, Optimizely o App Configuration? (feature flags).

Con esto entendemos el problema en su verdadera magnitud, no solo es que al hablar de DevOps se piense solo en Automatización y Herramientas, sino que el dialogo DevOps ha sido monopolizado por un enfoque IT Pro, en el cual las practicas quedan acotadas a el funcionamiento de la infra (importantisimo, ojo, no se malentienda), donde es mas fácil conseguir hablar de estrategias de ruteo en redes que de experiencias en Feature Flags o el impacto del branching en tu estrategia. Finish Reading: Y… ¿para que se usa DevOps? (o ¿como empezar en DevOps?)

Lo que nos trae el Microsoft Ignite 2022

Pues si, hoy empezó el Microsoft Ignite, y como es usual es la ocasión para que Microsoft anuncie nuevos productos y mejoras sobre los existentes, así que aquí resumiremos los que considero mas importantes.

Microsoft Defender for Cloud recargado, la gestión de la seguridad en la nube es un gran reto para las organizaciones, por lo que se refuerza a Microsoft Defender dandole nuevas capacidades como el nuevo Microsoft Defender Cloud Security Posture Management (CSPM) y sus nuevos benchmarks de seguridad, pero el que me ha llamado particularmente la atención es que ahora es posible escanear y detectar vulnerabilidades en los Elastic Container Registry de AWS, todo un avance en la seguridad multi-cloud.

Kubernetes Fleet, la gestión de clusters es una de las tareas que ha ido creciendo en importancia en los departamentos de Operaciones de las empresas, así que hoy se introduce Azure Kubernetes Fleet Manager, un nuevo servicio en preview, el cual simplifica la administración de varios clústeres al permitir la administración centralizada de todos los clústeres a escala. Los clientes pueden agrupar cualquier combinación de clústeres de Azure Kubernetes Service (AKS) para simplificar las operaciones de varios clústeres, simplificando el reparto de cargas de trabajo y gestión de redes.

Escalamiento vertical en los clusters de AKS, al tradicional soporte de Horizontal Pod Autoscaling, se nos plantea ahora opción de que los pods en nuestros clusters puedan escalar de forma vertical, lo cual definitivamente abre mayor flexibilidad en la forma en que configuramos nuestras aplicaciones.

Azure Cosmos DB for PostgreSQL, con este lanzamiento Cosmos DB amplia su alcance hacia las bases de datos relacionales, Construido sobre el motor Hyperscale (Citus), el nuevo Azure Cosmos DB for PostgreSQL trae todo lo que los desarrolladores aman de PostgreSQL a la base de datos rápida y escalable de Microsoft para el desarrollo de aplicaciones cloud-native, definitivamente un salto muy atrevido de Microsoft luego del exito de Cosmos DB en el muno NO SQL.

Microsoft Defender for DevOps, esta nueva solución proporcionará visibilidad en múltiples entornos DevOps para administrar de forma centralizada la seguridad de DevOps, fortalecer las configuraciones de recursos en la nube en el código y ayudar a priorizar la corrección de problemas críticos en el código en entornos multi-pipeline y multicloud. En esta versión preliminar, se introduce compatibilidad con GitHub y Azure DevOps son compatibles y otras plataformas importantes de DevOps se admitirán en breve.

Esto solo es una parte de las novedades, para conocer mas visitar el Book of News! Y a ti cual te parece que es la novedad mas importante de hoy?

Agregando HTTPS a tus Azure Web Apps… gratis!

Siempre es bueno revisitar uno de los servicios mas queridos de Azure para mi: Azure Web Apps, con ellos (y SQL Database) empecé mi camino hacia la nube, fue blanco de mis primeros experimentos en lo que ahora se conoce como DevOps, y además… es el servicio donde tengo este blog, así que vamos a compartir experiencia que espero les sea de utilidad para configurar los sites que tenemos en este servicio.

Contextualizando, originalmente yo tenia este site en Blogger, el cual mude a WordPress con Azure Web Apps ya hace 8 años, cambiando su base de datos MySQL de clearDB hacia Azure hace 4, lo que no mencione es que originalmente este site solo uso el protocolo «http» por un buen tiempo, por lo que, como es sabido, terminaría siendo penalizado a nivel de SEO en los buscadores y generando desconfianza del lector, lo cual seria todo un problema de cara a los objetivos de divulgación de este sitio.

En ese sentido a poco de ingresar al programa MVP empecé a utilizar el beneficio de los certificados digitales de prueba que Digicert ofrece a la comunidad MVP, de esta manera ya tenia un certificado digital que podía vincular a mi site, indicando que la comunicación y el usuario viaja de manera segura, y… todo ha ido bien, pero este año decidí hacer una prueba cuyos resultados estoy probando y compartiendo ahora.

Top 10 Standard (DV) SSL Hosting Companies

El detalle es que el proceso de generación de un certificado SSL en DigiCert es tedioso y poco claro,al menos hasta hace dos años se apoyaba en herramientas de apariencia casi 90era y no generaban de manera directa los archivos PFX que son los que acepta Azure Web Apps para instalar un certificado, así que este año cuando mi ultimo certificado de DigiCert cumplió sus dos años de vigencia, decidí probar una funcionalidad que Microsoft anuncio el 2019: los certificados SSL gratuitos para Azure Web Apps, funcionalidad que brinda un gran beneficio para sites sencillos como este pues existen algunas limitaciones, como por ejemplo el no poder usar wildcards (*), pero de todas maneras es una gran ayuda para el que tiene su dominio y quiere brindar seguridad a sus sites.

Ok, el caso es que yo usaba previamente un certificado wildcard de DigiCert, y todo estaba configurado alrededor de este esquema, tanto en Azure como en mi registro de dominios (en este caso Network Solutions) por lo que contare mas o menos como lo fui solucionando, esperando que le sirva tanto al que va a migrar como el que va a aprovechar esta funcionalidad por primera vez. Ojo, estoy dando por sobreentendido que ya se tiene la titularidad de un dominio, ya sea en GoDaddy, RCP, NetSol, etc, así como acceso a su respectiva consola y obviamente una subscripción en Azure.

Finish Reading: Agregando HTTPS a tus Azure Web Apps… gratis!

Lo que se trajo el Microsoft Build 2022: ACA, gRPC, GraphQL y mas…

Y si, llego otra edición del Build, el evento de Microsoft orientado a los desarrolladores donde anuncia sus novedades tecnológicas de la temporada, en esta ocasión ya se nota un regreso progresivo a lo presencial pues en Simultaneo se están realizando eventos en diversas ciudades del mundo, siendo la mas cercana a nosotros Buenos Aires.

Ah, y este servidor también estuvo presente con estos #TableTopic, que espero les sean de interés:

Como decía, aparte de la visión de liderazgo que nos dan lideres como Satya Nadella, Donovan Brown o Scott Scott Hanselman, el plato fuerte es conocer los nuevos servicios o funcionalidades que se encuentran disponibles a partir de hoy, y claro, cada uno tiene sus preferencias pero las mías son:

  • Disponibilidad (GA) de los Azure Container Apps, esta era la noticia que mas estaba esperando desde el pasado #MSIgnite, donde conocimos a este nuevo servicio que viene a representar una alternativa mas sencilla de administrar la orquestación de contenedores que la proveida por Kubernetes, que seamos francos, con toda su potencia no siempre es lo que hace falta cuando tienes aplicaciones pequeñas o medianas, sumale un soporte directo a KEDA y escalamiento mas sencillo y ya tenemos una herramienta destinada a tomar un lugar relevante en nuestras arquitecturas.
  • Mejoras en Azure Kubernetes Service (AKS), de todas maneras K8s seguira siendo la opción de referencia para varios despliegues, y en ese sentido AKS ahora incluye soporte a Draft 2 para el despliegue de aplicaciones contenerizadas a Kubernetes. De igual manera se estan incluyendo dos nuevos add-in uno para facilitar el ruteo de aplicaciones Web hacia internet, y otro para KEDA, sera motivo para probar ese ruteador.
  • Mejoras a Azure App Service, ok, se ha anunciado el preview de nuevas capacidades de migración entre SKUs  y un nuevo Landing Zone (documentación y automatización) para AppService 3, pero la verdad es que lo mas esperado era el soporte para gRPC, el cual finalmente esta en preview, lo cual nos permitirá usar el protocolo HTTP/2 para facilitar y mejorar la performance de la comunicación entre el frontend y el backend.
  • Novedades en Azure API Management, Azure API Management es un servicio que usualmente damos por sentado, pero cubre un rol muy importante en las organizaciones al exponer nuestras APIs, las cuales tradicionalmente han sido de tipo RESTful, pero en los últimos años ha ido creciendo el uso de APIs basadas en GraphQL, en escenarios que requieren flexibilidad en el conjunto de datos que se recuperan de las consultas, por lo que era cuestión de tiempo que Azure API Management le diera soporte, el cual hoy pasa del modo preview a la disponibilidad general (GA).
  • Novedades en Azure SQL Database, si esta vez se han anunciado varias cosas incluyendo su conexión con Synapse, pero en este caso lo que nos interesan son las novedades para desarrolladores siendo la mas importante el anuncio de actualizaciones en el soporte a Azure Functions, lo que permitirá (en adición a C#) que lenguajes como Python o JavaScript se conecten a SQL Database reduciendo la complejidad en el acceso a la base de datos; de igual manera ahora contamos con un entorno local de desarrollo contenerizado que nos da a los desarrolladores una experiencia de trabajo lo mas cercana posible a la versión en la nube, en un entorno que nos brinda Visual Studio Code y extensiones de Azure Data Studio que nos permite generar un workflow completo de diseño, desarrollo, test y despliegue de nuestra base de datos.

Si, hay muchas otras novedades como las que trae Cosmos DB en sus mejoras para el modo serverless, o el cambio de nombre de Azure Spring Cloud a Azure Spring Apps, el nuevo MySQL Flexible Server Business Critical, etc, pero con esto tenemos lo esencial para ir aprendiendo en los próximos meses viendo las diversas sesiones ¿Cual es tu novedad mas importante? Espero tus comentarios en español, que de eso se trata este blog ;).

GitHub Copilot ahora es un nuevo miembro (asíncrono) de tu equipo

Una de las novedades mas interesantes que se acaban de anunciar hoy en el Microsoft Build 2025, son GitHub Copilot coding agent, y las mejoras en la gestión de modelos sin salir de GitHub, amén de otras novedades como el soporte en la modernización de aplicaciones, y los Agentes SRE. Iremos revisando las diversas novedades en las próximas entregas, pero hoy nos centraremos en el Coding Agent.

Para empezar, veamos la definición que ha sacado Microsoft al respecto: GitHub Copilot evolucionará de un asistente en el editor a un socio de IA con un agente de desarrollo autónomo y asíncrono, el primero de su tipo, integrado en la plataforma GitHub. GitHub Copilot podrá probar, iterar y refinar el código en GitHub como un agente de IA que los desarrolladores pueden delegar tareas rutinarias y especializadas para avanzar en los proyectos. Copilot es un compañero de equipo de IA, no solo una herramienta.

Luego de haber probado esta nueva funcionalidad, podemos entender mejor la descripción y quedarnos con las siguientes ideas fuerzas que vienen con ello:

  • Agente autónomo y asíncrono. Aquí lo asíncrono es clave, ya hemos trabajado con GitHub Copilot y como su nombre lo dice, es tu copiloto, programa a tu lado, conforme vas avanzando en tu desarrollo. El cambio aquí es que este agente opera tras bastidores, una vez que le dejas una tarea, pudiendo tu continuar con otra parte del proyecto de desarrollo
  • Compañero de equipo de IA, si pues, quienes hemos trabajado en desarrollo de software conocemos bien a herramientas como JIRA o Azure Boards, donde esencialmente registramos tareas o actividades a ser desarrolladas, y muy frecuentemente ya asignando quien lo va a hacer, y ahora ese miembro de tu equipo que hará la tarea será… GitHub Copilot.

Ya con la parte teórica definida, pasemos a la acción para que tu mismo puedas empezar a probarlo, y también para entender sus límites.

Primero lo primero validemos que tenemos la funcionalidad activada, así que (estando logueado a nuestra cuenta de GitHub) vamos a https://github.com/settings/profile
Opciones de Copilot
Validamos que podemos hacer uso de la funcionalidad de acuerdo a los términos del preview del servicio, y tomemos una decisión muy importante, definir el alcance a nivel de nuestros repositorios:
Niveles de acceso
Esto nos permitirá definir si todos los repositorios de nuestra cuenta podrán usar la funcionalidad o solo algunos repos selectos, esta decisión es importante especialmente si varias personas trabajan en nuestros repos, ya que el uso de esta funcionalidad esta sujeto a unas tarifas premium extras, por lo que puede que nos interese regular en donde podamos hacer uso de esta funcionalidad. En mi caso, como soy el único que usa el repo, lo he habilitado en todos mis repos.

Nota adicional, de momento esto solo puede activarse en los repos privados, lo comprobé directamente porque no pude usar la funcionalidad en uno de mis repos públicos, por lo que tuve que volver dicho repo en privado para hacer ciertos experimentos que necesitaba hacer.

Ahora si, manos a la obra ¿Cómo hago uso de la funcionalidad? En corto: creando una tarea razonablemente detallada en un Issue de GitHub, y en lugar de asignar la tarea a un humano, se lo asignamos a …. GitHub Copilot, como lo vemos en esta pantalla:
Asignando la tarea

Como podemos ver tenia dos opciones respecto a quien asignar el Issue: yo mismo y Github Copilot, como es obvio se lo asigne a Copilot, y ahí empezó a trabajar por su cuenta para crearme los unit test solicitados:
Opened Now

Y en ese momento empezó a explicar lo que estaba haciendo, su plan, su descomposición del entendimiento del problema y los siguientes pasos a seguir:
Trabajo en progreso

Esta fue una captura de pantalla cuando Copilot aún estaba “pensando”, nótese los mensajes de que esta “In progress”, esto es muy importante ya que luego de proponerte cambios, va a intentar de ejecutar unos pipelines/workflows en GitHub Actions, para lo cual te presenta el botón de “Aprove and run workflows” que ya aparece desde que empieza a procesar la tarea, y aquí mi primera recomendación, no lanzar ese botón hasta que Copilot haya terminado la tarea. Y si, el proceso de solución no es instantáneo y el tiempo de duración de la resolución variara según la complejidad, recordemos, este agente es asíncrono por lo que aprovechemos estos 10 minutos para tomarnos un té o ir pensando que otro issue asignarle.

Concluida su tarea, y luego de haber ejecutado los workflows respectivos ya podríamos aceptar el Pull Request que nos ofrece, el cual es muy detallado respecto a los cambios propuestos
Detalle de Unit Tests

Esto del Pull Request es muy importante tenerlo en cuenta, ya que Copilot no aplica los cambios directamente sobre la rama master/main sino que crea una rama “copilot/fix-xxx” cada vez que atiende uno de los issues que vamos creando. Por lo que si, no era necesario aclararle que cree un PR.

Ok, esta fue la versión rápida de como funciona este Agente, vayamos un poco mas allá, para empezar, debo comentar que la aplicación con la que estuve trabajando es una sencilla aplicación Blazor desplegada en Static Web Apps, la cual muestra una tabla con fabricantes y modelos de autos, la aplicación Frontend no consume directamente los datos sino que los consulta a un API hecho en .NET, API que es quien consume los datos de un Table Storage de Azure. Si les interesa pueden ver como hacer dicha aplicación aquí.

Siendo una aplicación tan básica, era ideal para ir evolucionándola usando Copilot, como han podido ver, lo primero que hice fue pedirle que agregara las necesarias pruebas unitarias, y así sucesivamente le fui solicitando cosas como:

  • Que mostrara data hardcodeada en caso de que el frontend no pudiera conectarse con la fuente
  • Mejorar la claridad del código y actualizar las librerías
  • Mejorar la gestión de la configuración centralizando en un único punto del código el lugar donde al frontend se le pasa la URI de la API. En ese momento empecé a escribir todas las tareas en español, aunque de todas formas Copilot detallara todo su razonamiento en inglés.

Luego decidid agregarle un buscador al sistema, originalmente la aplicación solo mostraba el contenido total de la tabla, pero luego de los cambios que hizo Copilot, la pantalla quedo así:
Aplicacion solo con buscador
Lo importante aquí ya no es tan solo el resultado obtenido, sino el ver el proceso detrás, como convirtió mi pedido original:
Soporte para Consultas
En este análisis y plan detallado ya orientado al código:

Por cierto ¿se fijaron como Copilot para definir su tarea/PR utiliza un nombre mas prolijo que el original de mi issue?

Ya en este momento estaba emocionado con lo que estaba logrando, por lo que decidí pedirle que me permitiera editar y agregar nuevos registros, lo cual me llevo a esto (con la inclusión de nuevas pruebas unitarias, por supuesto):
Aplicacion con opción de edición
Nada mal, pero en ese momento me percate de que la aplicación no podía editar bien un registro existente, así que estuvimos iterando mediante 7 issues, y en cada etapa me indicaba posibles soluciones, que involucraban la gestión de cadenas, manejo de excepciones, pero no funcionaba, hasta que me di cuenta que había un tema respecto a cómo había definido los datos en la tabla del Azure Storage, que siempre iba a generar errores si trataba de modificar cierto registro, eso no lo tenia Copilot en su contexto, por lo que por mas que volviera a razonar no iba a ser capaz de resolver el problema.

Así que si, esta nueva herramienta es muy útil, sumara mucho para poder avanzar en nuestros trabajos, siempre que tengamos unas consideraciones importantes:

  • La decisión final esta en nosotros, durante este proceso rechace dos PR porque en las pruebas en ambientes efímeros no obtenía la respuesta deseada.
  • Debemos revisar bien el “proceso de razonamiento” mediante el cual Copilot va armando su plan y la solución respectiva.
  • Reducir la ambigüedad cuando detallemos la tarea a pedir, una de las razones del éxito que tuve cuando agrego en el buscador fue que mi pedido era razonablemente explicito y detallado.
  • Debemos ser conscientes de que el sistema no tiene acceso a todo el contexto, en este caso Copilot no puede acceder a mi Azure y por ende no podía “ver” la forma en que su solución no estaba funcionando.

¿Qué les parece? ¿Se animan a probarla? Yo de momento tengo algunos experimentos en mente que probar, ya les ire contando y mil disculpas por la ausencia de estos meses.