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:

Por analogía al caso anterior, el sufijo (V3 en este caso) significa que es la tercera versión de infraestructura que se ha puesto a disposición para correr Azure Functions, obviamente si no hay el sufijo estamos hablando de la versión 1, la cual hasta la fecha no ha sido deprecada, y si… hay circunstancias de gasto que pueden hacer mas conveniente usar la versión 2 (que no se ven en esta captura).

Un caso análogo ocurre con los clásicos Azure Web Apps, que como podemos ver también cuentan con 3 versiones disponibles, las cuales hasta ahora no han sido deprecadas:

Como se habrán dado cuenta, los PaaS solo han  tenido tres versiones de infraestructura, mientras que las Maquinas Virtuales (que vimos anteriormente) ya van por la quinta generación, así que si bien en ambos casos hay infraestructura, sus ciclos no van a la par.

Versiones de Software “interno”

Aquí las cosas se pueden poner un poco confusas, pero para aterrizar el concepto nos enfocaremos nuevamente en Azure Functions, pues es el servicio que mas ha pasado por este tipo de cambios.

El funcionamiento de este servicio se basa en un “runtime” que simplificando mucho permite que se ejecuten las aplicaciones escritas en diversos lenguajes y se puedan establecer los enlaces (“bindings”) entre la función y el recurso que dispara el evento, cuando se lanzo Azure Functions se soportaba .Net Framework 4.x (si, el que solo corría en Windows) y otros lenguajes, esto funcionaba, pero Microsoft seguía evolucionando en su soporte multiplataforma.

Es así que el 2018 se anuncia el runtime V2 que introduce el soporte a .NET Core 2.1 asi como Node 8 y 10, y el 2019 el runtime v3 soportando .NET Core 3.1 y  Node 12, aparte de el soporte a estas plataformas mas modernas cada runtime incluía funcionalidades adicionales, como la ejecución en local (muy conveniente para los devs) en Linux, integración con VS Code, mejoras en los bindings y la performance, etc. Pero había un detalle importante, ninguna de estas nuevas versiones significaba la deprecación de las versiones anteriores, claro que se recomendaba la migración, pero no era obligatorio… de momento.

La situación cambio con el runtime V4, anunciado en septiembre del 2021, el cual incluía el soporte de .Net Core 6, Node 14 entre otros lenguajes, pero introducia dos modelos de ejecución el “in process” (o sea el clásico) y el nuevo modelo “isolated”, que en corto permitía la ejecución de frameworks o lenguajes no soportados de manera “nativa”, lo cual ¡habilita la ejecución de .Net Framework 4.8 en la nueva versión del runtime y así aprovechar sus ventajas!

Este cambio resulto de veras importante, ya que las versiones 2 y 3 del runtime no soportaban a .NET Framework 4.x (de ahí el periodo de convivencia entre las 3 primeras versiones), es por eso que ya tocaba una reorganización, así que Azure nos estuvo alertando buena parte del 2022 de que las versiones 2 y 3 dejarían de ser soportadas a partir del 13 de diciembre del 2022, dándonos los enlaces para efectuar los respectivos updates a nuestro código.

Y bueno, ¿qué pasaba si no hacías el respectivo update?, pues obtendrías una hermosa advertencia como esta en el portal de Azure:

Vamos que te has quedado sin soporte, si pasa algo ya eres responsable pleno de lo que pase ahí, por lo que si no te ha quedado claro: migra ya a la V4.

Y por otro lado ¿qué pasa con el runtime V1? Eso es lo mas interesante del asunto, cuando recopilaba información para este post me di cuenta de que la V1 esta en modo de mantenimiento pero que solo será deprecada el 14 de septiembre del 2026 (recién!), lo cual a poco de pensar vemos que tiene sentido debido a la gran base extendida de .NET Framework (y sus ciclos de soporte mas largos), pese a lo cual Microsoft recomienda migrar al runtime v4.

Ahh y si, como pueden ver en el gráfico, Azure te alerta si estas usando un lenguaje deprecado o a punto de ser deprecado, así que no está demás seguir las recomendaciones teniendo en cuenta que los ciclos de actualización de los diversos lenguajes de programación cada vez son mas cortos.

Bueno, es todo por ahora pero aprovecho para comentarles que el próximo 27 de Noviembre, gracias a Microsoft Reactor estaremos conversando en vivo sobre estos temas, donde responderé las preguntas que puedan tener sobre estos temas, los espero!

(1) Lo hago desde el Portal, porque la Calculadora de Azure no te ofrece todas las opciones disponibles durante la creación de este tipo de recursos.