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 ;).

Azure Upward: Advanced DevOps Hands On Workshop (materiales I)

El día de hoy estare participando en el Azure Upward: Advanced DevOps Hands On Workshop, organizado por Microsoft, donde hablare sobre Azure DevOps, Web App for Containers y algo sobre microservicios, y para esto he preparado una demo que basicamente consiste en contenerizar un proyecto web, desarrollado en .Net Core, publicarlo en el Azure Container Registry, y desplegarlo en dos slots de Azure Web App for Containers.

Para la demo me he basado en el código fuente de la segunda edición libro Entity Framework Core in Action de Jon P. Smith, asi que he hecho un fork para que ustedes puedan replicar la demo en sus casas, siendo así los archivos que he agregado al código original son los siguientes:

.dockerignore
azure-pipelines.yml
BookApp/Dockerfile

Como mostrare en la sesión la idea es crear un pipeline en Azure Pipelines, basandonos en un repositorio GitHub, por lo que tienen dos opciones hacer un fork del código original de Jon y agregarle una copia de los tres archivos mencionados, o hacer un fork de mi fork, queda al gusto de ustedes.

Como es logico, es necesario contar con un Azure Web for Containers, un Azure Container Registry, y enlazarlos adecuadamente a nuestro Azure DevOps, pero creo que eso me da para un video corto que voy a preparar, de momento les comento que para poder usar el pipeline es necesario definir unas variables, como se indica en este grafico, pues de lo contrario el pipeline no se ejecutara.

Bueno, espero que la sesión les sea de utilidad, cualquier consulta me la dejan en los comentarios por si hay algo que falta precisar. Feliz despliegue!

 

 

 

 

Las perspectivas PaaS Linux sobre Azure

Si hace unos años me hubieran dicho que estaría comentando sobre lo que menciona el titulo, me hubiera puesto a reír, pero el contexto tecnológico cambia de manera constante y este es el escenario en que los desarrolladores debemos tener claras nuestras opciones a la hora de considerar Linux como plataforma.

De mas esta comentar sobre las oportunidades que nos ofrece .Net Core para poder llegar a escenarios en los que tradicionalmente Windows estaba vedado, pero también debemos tener en cuenta las perspectivas de poder integrarnos y trabajar con otros stacks, así que si… Linux nos va a rodear bastante a los que trabajamos con .Net.

Ahora bien,  trabajar con Máquinas Virtuales Linux siempre ha sido posible desde que los proveedores de cloud empezaron a ofrecer IaaS, pero si uno basa su estrategia cloud en depender de máquinas virtuales que básicamente replican la arquitectura que se tenía on premise, no se está sacando partido de las potencialidades de la nube (optimización de costos y escalamiento) ni  tampoco se esta asumiendo un enfoque pragmático frente a los retos (o limitaciones) inherentes a la nube, como pueden ser los niveles de servicio asegurados por el proveedor (SAL), lidiar con las latencias, etc, esto y la necesidad de brindar a nuestros equipos de desarrollo con plataformas que aceleren su productividad nos deben obligar a mirar la nube más allá del IaaS.

Es con esta mirada que debemos analizar la propuesta PaaS que nos da Azure en el entorno Linux; recordemos que tradicionalmente si queríamos implementar una Web App lo que estábamos provisionando “por detrás” era una MV Windows con un IIS especialmente configurado para permitir las ventajas como slots, escalamiento, kudu, etc… lo cual nos va bien para aplicaciones .Net pero por ejemplo no nos permite correr aplicaciones Ruby, aparte de que existen escenarios en que se requiere cierta librería PHP que ¡oh sorpresa! tiene una fuerte dependencia con el sistema operativo Linux, así que era natural que Microsoft Azure venga a ofrecer una solución de Web Apps basada en Linux como una opción para los desarrolladores, misma que en este momento esta en versión de prueba.
top-level-create
Finish Reading: Las perspectivas PaaS Linux sobre Azure

Completando el ciclo de ALM: Release Management (II)

Prosiguiendo con la entrega anterior, pasamos a los pasos 4 y 5 de este proceso que consiste en configurar cada uno de los entornos de despliegue en los que se va a desplegar la aplicación, la idea que implementaremos en esta ocasión sera la siguiente:

  • Cada vez que se efectué un cambio en el código fuente se disparara una Build (Integración Continua, esto ya lo tenemos bien sabido)
  • Si la Build es exitosa se disparara una Release
  • El primer paso de la Release sera desplegar automáticamente al entorno QA
  • Efectuado el despliegue a QA, un aprobador humano dará su conformidad, o no, al contenido desplegado
  • Si el despliegue en QA ha sido aprobado, recién entonces se efectuara el despliegue al entorno PRO

Obvio que este esquema puede extenderse para incorporar mas entornos, para añadir pruebas de carga en la nube, distintas categorías entre aprobadores, etc, pero para demostrar el concepto esta prueba sera suficiente.

De momento vamos a identificar correctamente nuestros entornos, así que nos vamos al entorno llamado por defecto “Default Environment” y le cambiamos el nombre…

Clipboard01

A QA:

Clipboard02

Finish Reading: Completando el ciclo de ALM: Release Management (II)

Completando el ciclo de ALM: Release Management (I)

Repasemos un poco lo que hemos aprendido hasta ahora: sabemos como configurar nuestro Visual Studio On… digo Visual Studio Team Services para crear un Team Project, desarrollar una aplicación en ASP.NET para finalmente compilar y desplegar dicha aplicación cada vez que efectuemos un cambio en el código fuente (Integración Continua).

Todo perfecto, pero recordemos que si queremos definir un conjunto de entornos (QA, DEV, STA, PRO…) entre los que sucesivamente vayamos escalando nuestra aplicación, hacíamos uso de la funcionalidad de Azure llamada “slots”, la cual de una manera sencilla nos permitía intercambiar contenidos entre los diversos entornos, esta técnica es muy practica y nos permite cierto grado de protección a fin de poder revisar nuestros cambios antes de que hagamos el despliegue en el entorno definitivo.

Devops-release

Ahora tenemos una opción adicional, y es que desde la gestión que hace VSTS/TFS manejemos de manera separada la forma en que nuestro “paquete” va siendo desplegado y escalado en los entornos de aprobación hasta su destino “final”: producción, y al hacerlo logramos introducir un factor que sera de gran utilidad de cara al aseguramiento de la calidad de lo entregado: la aprobación de versiones, vale decir que a una persona (o grupo de personas) se le notifica que hay una nueva versión de la aplicación en determinado entorno y que le corresponde dar su conformidad a dicha versión, lo cual derivara en que la versión en cuestión sea propagada al siguiente entorno, y así sucesivamente. Adicionalmente este cambio nos va a permitir manejar ya no solo el historial de nuestras Builds sino tambien el historial de nuestros despliegues, pudiendo ver si todos los despliegues propuestos han pasado los tests de carga y/o fueron aprobados satisfactoriamente por QA o el cliente.

Finish Reading: Completando el ciclo de ALM: Release Management (I)