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

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

Seguridad, palabrita omnipresente en este mundo tecnológico pero que tantas confusiones trae a quienes de alguna manera tienen que lidiar con ella, ya sea estableciendo infraestructuras seguras, o desarrollando aplicaciones que no sean vulnerables a malos usos o ataques, y claro… con la nube hay cosas que toca revisitar, y … a eso vamos.

Este articulo no pretende ser una guía de como implementar la seguridad en Azure, pero si que espera contextualizar el entorno en que nos encontramos, como hemos llegado hasta el y una (entre otras) forma adecuada de gestionar la seguridad de nuestras aplicaciones en la nube.

En todo caso tenemos que partir de dos conceptos esenciales (otros son los relativos a la categorización de los recursos a proteger) en este rubro: Autenticación y Autorización.

Grosso modo, Autenticación es la capacidad de garantizar que quien quiere acceder a un recurso (sistema, dato, infraestructura) es quien dice ser, y esto se ha ido logrando mediante: contraseñas, biometría, tokens físicos, etc. Por otro lodo la Autorización se enfoca en la asignación correcta de los permisos respecto a que se puede hacer con el recurso en cuestión, dependiendo del rol o perfil de la persona ya Autenticada.

Hasta ahí todo claro, ahora reflexionemos como hemos trabajado con estos conceptos, supongamos que tenemos una BD llamada “Negocios” con dos tablas: “Productos” y “Ventas”, y supongamos que se necesita que Juan, pueda mantener el catálogo pero que solo pueda consultar las ventas realizadas, empecemos poco a poco.

Pues bien, para esto será necesario que Juan se autentique ante la BD, ya sea mediante usuario y password manejados por la BD, o que la BD “acepte” la autenticación que Juan ha hecho ante el Sistema Operativo, ya sea local o el de la organización, y por otro lado aplicar un GRANT al usuario “Juan” para que este solo puede hacer SELECT sobre la tabla “Ventas”, y además un GRANT para que este mismo usuario pueda hacer INSERT, SELECT, UPDATE y DELETE sobre “Productos”, pero no permisos para borrar la tabla o modificar su estructura, hasta aquí nada fuera de lo común, y con la misma lógica podríamos dar GRANT más generosos a Elena para que haga operaciones de mantenimiento sobre ambas tablas.

Esto de manera muy simplificada, en un entorno real y mas ordenado, lo usual es que se creen “roles” preestablecidos con las diversas combinaciones de permisos y de esta manera a Juan se le podría asignar un rol ya existente que tenga los permisos ya mencionados sobre “Ventas” y “Productos” (en este caso Rol1), siendo que luego a alguien nuevo se le asigne ese mismo Rol1, simplificando la administración en lugar de asignar los permisos de manera individual, como se ve aquí:

Permisos y roles sobre BD Finish Reading: Conociendo los modelos de seguridad en la nube con Managed Identities (I)

Aprendamos Azure Pipelines (con videos)

Curiosamente una vez que esto de la cuarentena se hizo que las comunidades se adaptaran y empezaran a proponer eventos online, así en Agile Perú organizamos, junto al a comunidad Agile Uy, el meetup “Retros remotas desde las trincheras”   que cubrio temas muy interesantes de como enfocar nuestras retros cuando los equipos no estan juntos, situación que durara por un buen tiempo, y que creo que cubrio varias de las dudas que mencione en mi post anterior, si no han visto el video, haganlo, Camila se lucio en este meetup.

Y por el lado de las comunidades Microsoft, las cosas han estado muy activas, tan asi que el 25 de abril participe en dos eventos el Virtual Azure Community Day, organizado por el Microsoft Users Group Perú, y en el Global Azure Latinoamerica, organizado la Comunidad Xamarin en Español; en el primer caso hable sobre “Despliegue de Aplicaciones Serverless con Azure Pipelines y Azure Functions“, para luego exponer “Mejora la seguridad de tus despliegues con Environments en Azure Pipelines“, la verdad es que estaba nervioso, la expectativa sobre los eventos era alta, pero felizmente todo salio bien y además hubo algo que aprovechar….

Resulta que en mi sesión sobre Environments (tema del que ya he comentado en este blog) se me pregunto por la disponibilidad del YAML que use para mi demo, y luego me recomendaron hacer un paso a paso de como crear un multi-stage pipeline, como un paso previo a los conceptos de seguridad que explicaba sobre Environments, así que prepare este video sobre como crear tu primer multi-stage pipeline en Azure Pipelines:

Y como es lógico también comparto el YAML usado en esta demo, la cual es efectivamente una preparación para ver lo explicado en la sesión sobre seguridad y Environments:

Y ya como bonus track les dejo mi presentación sobre serverless y Azure Functions.

Espero que les sea de utilidad!! Ya en breve estaremos hablando de las novedades que se trae el Build!

Serverless: Realidad y perspectivas (2)

Bueno continuando con esta revisión respecto a la plataforma Serverless, veamos algunas consideraciones para entornos de trabajo y como enfocarlo de la mejor manera.

Para empezar debemos recordar que nuestras aplicaciones, por lo general, viven en un contexto, teniendo interacciones con otros sistemas, fuentes y consumidores de datos, sistemas externos, etc, los cuales al momento actual en su mayoría se encuentran en entornos on premise, lo cual nos lleva al reto de como hacer que nuestras aplicaciones en la nube se integren con los componentes on premise. Si nuestro ecosistema nació íntegramente en la nube (sin que eso implique ser cloud native) no es que no haya retos, pero son diferentes y a ellos nos enfocaremos en otro momento.

Lejanos son los tiempos en que las organizaciones podían tener todo un conjunto de direcciones IPV4 publicas a todos los equipos de sus organización (si, yo viví esa época en tres de mis primeros trabajos), ahora la escasez de direcciones IPv4 como las necesidades de asegurar los recursos frente a ataques e intrusiones, nos ha llevado de manera natural a un escenario en que los recursos criticos de computo de nuestras organizaciones hagan uso de direcciones IPv4 privadas, y claro, con segmentos de red dedicados y protegidos detrás de un firewall, dándose “confianza” de acceso solo a equipos dentro de la red propia de la organización (la excepción, claro, se da cuando es necesario exponer servicios al publico o a agentes externos).

Entonces cuando se aborda el crecimiento hacia la nube, un paso natural y conveniente es tratar (con las limitaciones de ancho de banda) de considerar a la nube como una continuación de nuestras redes privadas, para lo cual se habilitan VPNs, enlaces dedicados, nuevas reglas de firewall, se asignan segmentos de red (en el caso de Azure se denominan VNETs y en AWS VPCs), pero… Finish Reading: Serverless: Realidad y perspectivas (2)

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)