¡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!

Actualizando sobre las Managed Identities

Como mencionamos en nuestros posts anteriores, esto de las Managed Identities va en constante evolución por lo que este articulo se cala de maduro para actualizar unas cuantas cosas respecto a lo comentado anteriormente, así que vamos a ello:

Nueva forma de asignar permisos en el portal de Azure

En el articulo interior incluía varios pantallazos de como asignar un rol sobre un recurso (KeyVault/Azure Storage) a otro recurso (Function/Web App), pues bien, la forma ha cambiado ligeramente, pero esta vez para resumirlo he creado un pequeño video, aquí va:

Mejoras en el soporte para Service Bus

Como comentábamos anteriormente si uno quería usar Managed Identities en un Service Bus como trigger para un Azure Functions, tenia que usar la “sintaxis keyvault” desde los Application Settings, pero con la limitante de que esto solo funcionaba para Azure Functions Premium, pues bien ahora ya es posible usar MI como mecanismo de conexión/seguridad entre Azure Functions y Services, quedando la configuración así:

Dos detalles a considerar: Finish Reading: Actualizando sobre las Managed Identities

Presentando las Azure Container Apps

Una de las novedades por las que estaba mas expectante en este #MSIgnite de hoy era el anuncio de las Azure Container Apps, el nuevo servicio de Azure que hoy sale en Preview y que ya había tenido ocasión de probar en las ultimas semanas, pero … ¿por qué es tan importante este anuncio?

Para entenderlo hay que contextualizar como ha ido la evolución del mundo de los contenedores desde el boom iniciado por el querido Docker:

  • Los contenedores se ejecutaban de uno en uno dentro de una unica computadora (generalmente una MV)
  • Eventualmente se logra tener una pequeña orquestación de varios contenedores mediante Docker Composer
  • Rápidamente surge la necesidad de orquestar y escalar “en serio” y a través de varias máquinas (un cluster), por lo que surgen diversos orquestadores tales como Mesos, Swarm, pero el que gano (para bien o para mal) fue Kubernetes.

Entonces ¿problema resuelto? pues no, ya que si bien Kubernetes nos brinda un contexto en el cual podemos desplegar nuestros contenedores y hacer que estos vayan escalando según la demanda, nos plantea una situación de la que debemos ser conscientes: la capacidad base (numero y tamaño de nodos del cluster) siempre esta encendida y hay que pagar por ella, lo cual nos puede derivar a escenarios de recursos de computo no aprovechados.

De esta forma… ¿qué hacer cuando nuestros requerimientos son pequeños y solo queremos lanzar UN contenedor? Pues bien para esa circunstancia se facilito el desplegar contenedores en Azure Web Apps, y surgieron los Azure Container Instances (ACI), de los cuales ya hablamos en nuestra serie sobre serverless, tecnología muy interesante que permitió el surgimiento de KEDA, servicio el cual facilita a un cluster de Kubernetes escalar de manera elástica sin agregar nuevos nodos (mediante un esquema orientado a eventos similar a Azure Functions), solo contenedores “autónomos”, ayudando a un objetivo que se vuelve recurrente; “escalar a 0”, que no es otra cosa que si deja de haber demanda sobre un pod/contenedor su numero de instancias en ejecución pase a ser 0. Nada mal esto de KEDA ¿No?

Pues si, KEDA es de gran ayuda, pero pero pero… aun necesitas tener un Kubernetes, y toda su complejidad añadida, para lograr el efecto, así que ahí entran las Azure Container Apps, que es la propuesta de Microsoft para lograr la simplicidad en el despliegue escalable de contenedores para que de esta manera nos enfoquemos en el desarrollo de nuestras aplicaciones, y no en la infraestructura, infraestructura que por detrás esta soportada por el Control Plane de AKS, pero eso es transparente para nosotros.

Y..¿Qué tipo de contenedores podemos desplegar? pues esencialmente: Microservicios, APIs HTTP, Proceso de Eventos, y procesos backend de larga duración.

Esta es la definición pero… ¿como esto se lleva a la practica? Para entenderlo trataremos de conocer los elementos fundamentales de esta tecnología, así que les muestro un Grupo de Recursos, donde ya tengo desplegado unas ACA:

Finish Reading: Presentando las Azure Container Apps

Conociendo los modelos de seguridad en la nube con Managed Identities (y II)

En el artículo anterior revisamos las bases del nuevo concepto de seguridad en la nube, recursos identificados a los que se les da autorización sobre otros recursos, y… eso ¿Cómo se implementa? Pues lo usual hasta hace pocos meses ha sido trabajar con los llamados “Service Principal”, los cuales la verdad (como lo pudimos comprobar en un post previo) son bastante engorrosos de utilizar, hay que crearlos explícitamente (aunque algunos se crean automáticamente tras bastidores) y mediante estas entidades es que se pueden manejar la asignación de permisos entre recursos.

Llegado este momento toca presentar a las Managed Identities, en las que básicamente como desarrolladores se nos permite asumir que los diversos recursos de Azure cuentan con identidades de pleno derecho, casi casi como si fueran usuarios humanos, para empezar veamos como nos lo propone Microsoft:

Finish Reading: Conociendo los modelos de seguridad en la nube con Managed Identities (y II)

La nube es híbrida… y no nos habíamos dado cuenta…

En los últimos años ha habido un fenómeno, sutil, pero no por ello menos real, la convergencia entre lo que conocemos como la nube pública y el “viejo mundo” del on premise. Es que la verdad sea dicha, a menos que seas una startup, es muy probable que tengas una buena cantidad de aplicaciones desarrolladas para el on premise, con sus servidores, centros de computo y todo eso, algunas muy bien hechas y bien optimizada, otras legados que están de mirar y no tocar, y claro el viejo que se resiste a morir, el mainframe.

El caso es que con la penetración progresiva de la nube, algunas cosas empezaron a ocurrir en las organizaciones cuando pasaron de la prueba de concepto:

  • Adoptar una política de Cloud First para las nuevas iniciativas
  • Darse cuenta de cuán conveniente es el “estilo cloud” de provisionar y desplegar aplicaciones
  • Descubrir las potencialidades del Serverless para desarrollar nuevos tipos de aplicaciones
  • Percatarse que por muy en la nube que esten tus apps, van a tener que consultarle información a aplicaciones que (aún) no se migraran a la nube
  • Tropezar con el hecho de que comprar servicios en la nube requiere un reaprendizaje
  • Considerar el “cloud native” (con o sin contenedores) como parte de tu estrategia

Entonces casi por inercia empezaron a darse soluciones a dos problemas: ¿como llevar las ventajas de las tecnologías cloud al on premise? y ¿como mejorar la integración entre ambos mundos? Finish Reading: La nube es híbrida… y no nos habíamos dado cuenta…

Pero… ¿qué es eso de Cloud Native?

Probablemente uno de los términos más usados últimamente en el mundo tecnológico es el de “Cloud Native”, pero a la vez también uno de los mas confusos de entender o con el que probablemente haya mala interpretación de su significado, que sí es una tecnología (¡contenedores!), que si es un tipo de aplicación, que sí es una forma de trabajo, que si tú proveedor te brinda esa facilidad, pero lo que haremos ahora es tratar de tener adquirir un poco de mayor claridad respecto a este concepto y ver cómo podemos adaptarlo en el día a día.

La primera vez que tome conocimiento del concepto fue fácil asociarlo con algo relativo a las aplicaciones cloud y entendí originalmente que Cloud Native eran aplicaciones que estaban hechas para sacar partido de las características inherentes a la nube: escalabilidad, pago por consumo, etc; pero de igual manera me dí cuenta de 2 cosas: que eso no era todo pero que el concepto de cloud native se había vuelto un comodín para promocionar cierto tipo de tecnologías en concreto, como veremos más adelante así que empecé a investigar. Finish Reading: Pero… ¿qué es eso de Cloud Native?

Tu estrategia cloud pasa por (re)aprender a comprar

El reciente anuncio de AWS , sobre el lanzamiento y futura disponibilidad de Aurora Serverless V2 , me ha hecho regresar a unas reflexiones, acerca de cómo la nube nos obliga a enfocar las compras de otra forma, pues de otra manera no sacaremos ventaja real de las innovaciones que trae esta tecnología, que (se supone) queremos introducir como parte de nuestra estrategia tecnológica y (sobre todo) de negocios.

Empecemos con la contextualización, en una forma simpática:

En este tweet Javi nos recuerda, de manera sencilla, los esquemas de trabajo usuales en Bases de Datos (y extrapolables a casi servicio de cómputo): para evitar quedarnos cortos de capacidad de proceso las organizaciones estiman “hacia arriba” la capacidad que necesitarán (usualmente servidores y número de cores) para cierto requerimiento, con lo cual damos “tranquilidad” a la organización si dicha aplicación es de misión crítica (al precio de tener capacidad sin usar durante buenos tramos de la operación); vamos, lo usual en el mundo on-premise y tiene cierto sentido porque el agregar, retirar, o cambiar de uso a un conjunto de servidores no es cosa sencilla. Claro, me dirán que la virtualización y tal, pero nos olvidamos que aún en un esquema virtualizado trabajamos con un “colchón” grande para ir asignando sucesivamente la capacidad demandada, por lo que para este análisis prescindiremos del modelo de virtualización gestionado por la organización.

El caso es que el anuncio de AWS pone el foco en dos factores claves de lo que ha sido la “propuesta cloud”: escalabilidad y pago por uso. Sí pues… lo que hemos venido escuchando en los últimos 10 años “arranca con un servidor y escala automáticamente según la demanda y sólo paga a fin de mes por lo realmente consumido”; sí, el argumento no es nuevo y no deja de ser cierto, la diferencia es que usualmente este argumento ha sido orientado a las aplicaciones (generalmente web), no a las BD.

En ese sentido, esto continua la senda de los últimos dos o tres años: más ofertas de bases de datos serverless como SQL Database, la v1 de Aurora Serverless, y hace poco Cosmos DB. Estos movimientos de la industria deben indicarnos por dónde van las tendencias; que el viejo modelo de mirar sólo el número de servidores, nodos o cores a desplegar debe cambiar ya; que además de considerar PaaS y Serverless para el desarrollo de aplicaciones (como ya hemos hablado antes), no podemos ignorar ese rumbo de la industria.

A todo esto, si quieres entender un poco mas sobre el modelo serverless (y en este post hablaremos mucho de el), hace poco escribí la serie de artículos Serverless: Realidad y perspectivas (1), (2) y (3) que seguro te servirá.

Finish Reading: Tu estrategia cloud pasa por (re)aprender a comprar

Presentando las Static Web Apps

Un stack de desarrollo integrado para la creación de aplicaciones frontend estáticas, pero apoyadas en un backend basado en Azure Functions, sumado a un ciclo sencillo de trabajo y despliegue basado en GitHub Actions, eso es lo que nos ofrecen las Static Web Apps, presentadas hoy en el Microsoft Build, que como todos saben se ha llevado a cabo de forma online debido a la situación actual.

Ojo, el termino “estático” puede llevar a confusión, pero los desarrolladores de JavaScript entenderán que se hace referencia (*) al modo de trabajo usado para desarrollar SPA (single page applications) donde si bien solo se envian recursos estíticos al browser del usuario, la aplicación en si ofrece mucho dinamismo e interacción, pues bien esta nueva tecnología otorga a estas aplicaciones (basadas Angular, Vue o React) la posibilidad de contar con el poder y escalabilidad del serverless como backend de una forma integrada, esto basado en el patrón Jamstack que nos propone una abstracción respecto a los servidores para lograr una mayor eficiencia operativa.

De esta manera logramos tener un único repositorio de GitHub, donde estarán todos los recursos y servicios necesarios para nuestra aplicación, que sera el punto de partida para el ciclo de despliegue en minutos.

Bueno, eso dice la teoría, pero si quieres ver esto en acción… aquí te dejo el video para que veamos el potencial de esta nueva plataforma:

Bueno ¿què tal les ha parecido? a mi me ha gustado mucho esto de poder trabajar tanto tu backend y frontend como un proyecto integrado y lo fácil que es desplegar y jugar con las ramas.

De momento el proyecto esta en Public Preview, por lo que puedes empezar a probarlo ya, para lo que te dejo aquí el enlace a la documentación.

(*) Esta tecnología también es aplicable para generadores de sitios estáticos como Hugo, Jekyll o Hugo, con los cuales recién me estoy topando, por lo que no puede describir como seria su experiencia de integración con las Static Web Apps.

Serverless: Realidad y perspectivas (y 3)

Bueno, llegamos al final de esta serie de reflexiones sobre Serverless en el contexto actual, y empezamos dejando algo claro:

Serverless no es solo Functions as a Service.

Y ¿eso por qué? Porque si bien la referencia  a Serverless nos hace pensar en Azure Functions o AWS Lambda, debemos valorar el concepto de manera adecuada, asi que de manera preliminar digamos que Serverless es un servicio cloud en el cual no tenemos “conciencia” de cual es el servidor o servidores que nos proveen la funcionalidad deseada (lo cual no quita que podamos tener una URL referencial, ojo).

En ese sentido, pues si, un Event Hub, un Service Bus, un gestor de APIs o servicios DNS calzan dentro de la definición de Serverless, de hecho en un pasado Microsoft Ignite, el orador decía que el servicio Serverless mas usado era … Azure Storage, y claro tiene sentido bajo la premisa inicial que hemos hecho ¿no?.

Ok, la definición puede ser laxa y por eso a veces me veo el lios para establecer una definición, así que para el resto del articulo hablaremos de Serverless en tanto servicios de computo en el que podemos ejecutar el código de nuestras aplicaciones abstrayendonos totalmente de los servidores (fisicos o virtuales) que dan soporte a la operación, razón por la cual cabria considerar como tales a las Logic Apps pero no a nuestras viejas cómplices las Web Apps (y mucho menos Elastic Beanstalk de AWS). Finish Reading: Serverless: Realidad y perspectivas (y 3)

Serverless: Realidad y perspectivas (1)

Aquí de vuelta al ruedo con el nuevo año, en este tiempo de ausencia desde el Microsoft Ignite, le he prestado atención a un tema muy apasionante cuyo uso e interes ha ido creciendo en los últimos años: computación serverless, así que visto el estado actual repasaremos donde estamos y hacia donde podemos ir mediante el uso de esta tecnología, especialmente con las mejoras introducidas en Azure.

A estas alturas se han dado muchas definiciones sobre lo que implican los componentes serverless, pero es mejor basarnos en lo que debería componer usualmente una arquitectura/componente serverless:

  1. Abstracción sobre los servidores utilizados. Que si, al final todo proceso computacional requiere tener hardware (servidores) por detrás, pero la diferencia es que tanto nos abstraemos sobre ellos, no que no existan; nuestras queridas amigas las Web Apps ofrecen un buen nivel de abstracción (ya no tenemos que tunear el Sistema Operativo, por ejemplo), pero con serverless damos un paso mas allá, esencialmente lo que nos importa es tener donde ejecutar nuestras porciones de código.
  2. Basado en eventos. Este tal vez sea uno de los componentes mas difícil de entender, pues para lograr efectos similares, a lo que estábamos acostumbrados es a tener procesos que cada x porción de tiempo validaban si una condición se había efectuado o no, para con ello invocar la ejecución de una acción o programa. Con este modelo basicamente vinculamos una acción sobre un recurso (una escritura de archivos, una petición HTTP, la escritura sobre una cola, un timer, etc) con un programa, y listo, sera la propia infraestructura cloud la que se haga cargo de invocar nuestro programa cuando la condición se cumpla.
  3. Escalamiento inmediato. Esto es mas sencillo de entender, si tienes muchas peticiones o uso de computo sobre tu aplicación serverless, el sistema debe ser capaz de agregar las instancias necesarias para cumplir la demanda requerida, y claro reducirla cuando el pico termine.
  4. Pago por uso. Bueno, eso es lo que se tiene mas claro cuando se trata de nube, en este caso significa solo pagar cuando nuestros programas sean invocados, aunque esto tiene algunos matices como veremos luego.

Finish Reading: Serverless: Realidad y perspectivas (1)