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”.

Por ejemplo, en el caso de uno de mis servicios favoritos: Service Bus, hace varios meses escribí unos artículos respecto a cómo se le agregaron nuevas capacidades respecto al uso de Managed Identities, la incorporación de estas características fue totalmente transparente para el usuario final, simplemente ya están para usar y listo.

Antes de proseguir, quiero aclarar que queda fuera del contenido de este post todo lo referente a niveles o “tiers” que pueda tener un servicio (los clásicos free, standard, premium, etc) o los modelos de cómputo (vCore vs DTU p. ej.) que uno tiene para elegir recursos como bases de datos.

Bueno, prosigamos.

Como dije líneas arriba “en la mayoría de los casos”, no deberíamos preocuparnos por las actualizaciones, pero eso obviamente implica que hay casos que deberemos mirar con atención para garantizar la continuidad de nuestra plataforma cloud:

Deprecación. Y en esta situación debemos entender tres casos distintos:

1. Cuando el servicio es retirado completamente, ese fue el caso de Azure Scheduler, servicio que fue retirado el 2022 por lo que los usuarios tuvieron que migrar hacia Logic Apps. Otro caso podría ser Azure Service Fabric Mesh, pero en este caso no hubo mucho problema pues el servicio no paso de la etapa de preview.

Justo cuando redactaba este post me entere que Azure Database for Maria DB seria deprecado el 19 de septiembre del 2025, recomendándose su migración a MySQL, pues pasada esa fecha todas las instancias existentes serian borradas, de momento no se ha anulado la posibilidad de crear nuevas instancias, pero sera cuestion de tiempo que esta opción ya no este disponible.

2. Cuando un “sabor” de un servicio es deprecado, ese fue el caso de las versiones Web y Business de Azure SQL Database, en ese caso los usuarios fueron avisados desde el 2014 de ese retiro, recomendando migrar hacia las versiones actuales Basic, Standard y Enterprise, además se facilitó un mecanismo sencillo desde el portal para lograr el objetivo. Este también es el caso que se ha dado con la deprecación de Azure Database for MySQL Single Server y su requerimiento de migración hacia Flexible Server, que fue anunciado en septiembre del 2022 y será efectivo en septiembre del 2024, en el interin desde diciembre del 2022 dejo de ser posible crear nuevas instancias de MySQL Single Server.

3. Cuando una característica es retirada de un servicio, ese fue el caso de Azure DevOps cuando se retiró la opción efectuar pruebas de performance (Load Testing), o el próximo retiro del conector con Jenkins, como en los casos anteriores, se da el tiempo necesario para buscar alternativas. En esta categoría también se incluye cuando un servicio deja de soportar una versión de API o de SDK para algún lenguaje.

En cualquiera de estas situaciones Microsoft envía correos a los administradores de la subscripción de Azure, indicando sus planes, las fechas planeadas, así como las opciones disponibles para el cliente, estos correos se mandan con bastante anticipación y de manera reiterativa según la criticidad del servicio impactado, aparte de la comunicación en sus webs y blogs. Ok, ¿pero si voy a adoptar un nuevo servicio, como puedo saber si voy sobre seguro? Para esto hay canales como esta página en Azure Charts, y obviamente Azure Updates.

Generaciones de Computo

Esto puede ser algo mas complicado de explicar, por lo que es necesario que precisemos algo: si bien al final del día los servicios como Azure Web Apps o Azure Functions (en modo App Service o Premium) se basan en máquinas virtuales, sus generaciones o versiones no están directamente correlacionadas con las del servicio de Maquinas Virtuales, o por decirlo de alguna forma, sus números de versión no significan lo mismo, dicho esto… prosigamos para entenderlo:

Máquinas Virtuales, como es lógico el hardware sigue evolucionando, por lo que periódicamente Azure agrega a sus datacenters equipos más modernos y actualizados, cuando esto ocurre es que una nueva generación o versión ha entrado al catálogo, veámoslo en este gráfico sacado de la calculadora de precios:

Prestemos atención a los sufijos subrayados en rojo: v3, v4, v5, etc, estos valores representan la generación de MVs correspondiente, en el momento de escribir este post la versión mas reciente es la versión 5, que fue lanzada el 2021.

En términos generales se recomienda provisionar la generación de MVs mas reciente disponible (el día de hoy la v5) excepto en el caso de que se trate de un producto “enlatado”, y el fabricante solo certifique su instalación en ciertas versiones o series de MVs especificas (1).

Ya que las mencione de pasada, cabe mencionar que las series son esos prefijos Da, Dads, DCds que figuran en la lista, cada serie corresponde a un tipo de máquina diferente: optimizado para memoria, para propósito general, si es AMD o no, para computación confidencial, etc. Para mas detalles recomiendo revisar esta pagina.

Curiosamente al revisar el enlace anterior me percate que las series de máquina “A” (sin sufijo de versión) han sido programadas para su retiro en Agosto del 2024, siendo que este retiro fue anunciado en Agosto del 2021, lo cual representa una ventana de 3 años, por lo que uno se puede preguntar ¿Por qué lapsos tan grandes para este tipo de servicio? (si lo comparamos con el caso de MySQL), y la respuesta es sencilla si lo relacionamos con el principio de Responsabilidad Compartida ya que en una MV es donde el usuario asume mas responsabilidades sobre el stack y mantenimiento del servicio, por lo que, siendo estas migraciones un proceso complejo, se hace necesario dar más tiempo para una salida ordenada que en el caso de una BD en la que “solo” hay que procurar migrar la data.

Otro detalle a considerar es que si tenemos un cluster, ya sea de Kubernetes o de MVs “tradicionales”, que funciona bien pero con una generación anterior de hardware, el proveedor no debería complicarnos la vida si lo único que queremos es agregar un nodo extra, esta es otra razón por la cual las MV tienen ciclos de vida tan largos.

Bueno, ya se hizo algo largo este post, en la siguiente entrega hablaremos sobre como se gestiona el ciclo de vida en servicios PaaS, poniendo énfasis en nuestras queridas Azure Functions, de momento espero tus comentarios por si quisieras algún detalle adicional a comentar, los espero!.

(1) El caso extremo podría ser Red Hat OpenShift, que en el momento actual solo despliega sus clusters de ARO en ciertas series de la V3, no aprovechando las características de hardware que ofrecen las versiones mas modernas.