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:

De momento ignoremos el Log Analytics y el Redis, y primero veamos al Container App Environment, básicamente es el espacio lógico donde van a correr nuestros contenedores, a diferencia de un cluster de Kubernetes no especifica una capacidad base de computo y toda esa complejidad añadida:

Como podemos ver, no hay mucha ciencia en ello, el clásico IAM para la seguridad, algo de Automation, pero la parte que mas nos interesa es la que dice Apps, que como dice su nombre, nos permite ver los Azure Container Apps que tengo configurados (si, los puedo ver a nivel de Resource Groups, pero mejor seamos ordenados):

Sip, tengo unas tres Apps definidas, pero ojo… es importante entender que lo que tengo ahí son “definiciones”, no instancias corriendo en si…¿comó? sigamos viendo en este caso la mas sencilla:

Comó dije, esto debemos entender a esta Apps como una “definición” completa de un container que cobra vida, cuando es ejecutada, y por ende solo se paga cuando hay ejecución de ella, para definirla debemos tener una imagen Docker a desplegar (ubicada en Docker Hub o Azure Container Registry), especificar cual es el minimo y máximo de instancias que se podrán desplegar, su vinculación a una VNET, etc, pero para no complicarnos veamos algo muy sencillo y es el Ingress.

Como podemos en el Ingress definimos las capacidades de conexión de nuestra App, si aceptara trafico y de donde, lo cual tiene un efecto colateral en la definición de nuestra App.

Podemos ver claramente que Azure ha definido para nosotros un FQDN para poder acceder y visitar a nuestro contenedor ejecutándose, así que vamos allá:

La URL funciona, y devuelve lo que se espera de este modulo de una aplicación de ejemplo en Dapr (ah si! me olvidaba, Azure Container Apps también soporta Dapr), sobre el cual no me extenderé para no alargarme.

Para terminar, debo indicar que tengo otra App que NO tiene el Ingress habilitado, por lo que no tiene FQDN, revelando su naturaleza de contenedor backend “puro”.

Ok, suena bien, pero.. esto ¿qué aplicación practica tiene? veamos, a veces es necesario lanzar procesos batch que muevan archivos o registros de base de datos por varios minutos, utilizar Kubernetes solo para esto no sería practico ni eficiente pues implicaria tener encendidos los recursos del cluster las 24 horas del día usandolos solo cuando el timer dispare el batch (1), una opción seria usar nuestras queridas Azure Functions, pero aquí nos topamos con dos limitaciones, siendo una que los procesos de Functions tienen un limite de time-out, mientras que las ACA tienen la posibilidad de ejecutar procesos de larga duración, siendo ademas que las ACA pueden enrolarse a una VNET, lo cual les permite acceder a recursos (como los ubicados en el on premise) a los que las Azure Functions de tipo Consumption (2) no pueden llegar, así que esta tecnología nos abre muchas posibilidades de trabajo de manera directa..

Bueno, espero que esto haya servido para entender un poco este servicio y las ventajas que nos puede traer para el desarrollo y despliegue de nuestras aplicaciones, espero en futuras entregas hablar sobre su despliegue y caracteristicas adicionales como las Revisiones.

(1) Esto puede ser mitigado si nuestro container batchero es uno mas de los procesos que se despliegan en un cluster, por lo que el costo muerto no lo es tanto.

(2) Las Azure Function de tipo Premium si pueden, mediante el Regional VNET Integration, acceder a ese tipo de recursos, pero son mas caros y requieren tener la instancia permanentemente encendida, lo cual nos regresa al problema original.

Nunca es tarde si la dicha es grande: edición sencilla de templates en Azure Pipelines

Bueno, con algo de retraso debo compartir una noticia que era muy reclamado por los usuarios de Azure Pipelines, la capacidad de contar con el editor visual de nuestros YAML pero… en la edición de templates, lo cual hace mas sencillo la inserción de pasos en nuestros YAML sin saber del todo los parámetros en las Tasks disponibles en la herramienta. Pues bien, en mayo se anuncio la capacidad, por un descuido mio no me di cuenta a tiempo, pero apenas lo vi, decidí que la mejor forma de compartirlo era mediante un video, que espero sea de utilidad:


Para que vean, Azure Pipelines sigue evolucionando.

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)

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)

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…

Desplegando Static Web Apps con Azure Pipelines

Invitado especial: Bitbucket.

Hace unos meses comentábamos aquí acerca del lanzamiento de las Static Web Apps, las cuales ofrecen la facilidad de gestionar en un único servicio el backend mediante la tecnología de Azure Functions, así como el front end apoyándonos en los servicios de CDN que ofrece Azure, pero con una gestión muy sencilla, aunque seguro se habrán percatado que el despliegue se hacia con GitHub Actions y no con Azure Pipelines, por lo que, apenas este servicio se puso disponible, hubo buena demanda hacia Microsoft para conseguir el soporte hacia nuestro motor CI/CD favorito, y finalmente Microsoft lanzo el soporte y la guia para poder lograr el despliegue usando Azure Pipelines:

Tutorial: Publish Azure Static Web Apps with Azure DevOps

Y, la verdad es ocioso repetir paso a paso lo que se explica bien en la documentación, pero si que podemos profundizar algunas cosas que nos pueden ser de interes a la hora de intentar repetir este proceso, por lo que, a diferencia del tutorial, en lugar de usar un “Hola Mundo” decidí probar con una aplicación sencilla, como la que use para la demo que ven en el video que compartí hace un tiempo, así que .. no me enrollo mas:

  • El hecho de poder usar Azure Pipelines para desplegar las SWA, nos permite usar repositorios Git diferentes a GitHub, e inclusive a Azure Repos, de hecho la prueba la hice usando Bitbucket (!!), y funciono perfectamente! De igual manera, esto nos pemite valernos de la estructura de trabajo de Azure DevOps que ya conocemos bien Team Project-> Repos.
  • Lamentablemente de momento no podemos usar las características de creación de entornos temporales bajo demanda, como demostré en el vídeo, ojala lo incluyan en el mediano plazo.
  • El pipeline usado como ejemplo es muy “plano” (pero funciona) por lo que decidí acomodarlo un poco para que trabaje usando el flujo de stages y jobs propio de los YAML pipelines, el resultado lo comparto aquí, para que les sirva de base en sus trabajos, esto permite ver como logramos un flujo como el de esta imagen.
  • Hay que estar atento (como nos indica la documentación) a los parámetros  app_location, api_location, output_location, pero también a routes_location, y en este proceso puede haber cierto prueba y error (a la hora de probar alguno de los ejemplos disponibles) en mi caso me di cuenta que en el código fuente había una carpeta routes, así que tuve que pasar el parámetro respectivo, lo bueno es que el editor de Azure Pipelines nos brinda una gran ayuda para editar la task AzureStaticWebApp@0 en nuestro YAML.
  • El modo de conexión entre Azure Pipelines y las Static Web Apps es mediante un token, como se indica en la documentación, y no mediante un Service Connection (basado en RBAC/service principal), que es el mecanismo usual para poder enlazar nuestros pipelines, en este momento hay publicado un issue que pide desarrollar esta opción, asi que seria bueno darle un like para motivar a Microsoft a desarrollar esta solución.

Y bueno, como les comente, hice las pruebas usando Bitbucket en lugar de Azure Repos (que es lo que usa el ejemplo de Microsoft), ya que justamente una de las ventajas que nos ofrece Azure Pipelines es usar diversos repos Git de manera transparente, por lo que explicare como lo hice. Finish Reading: Desplegando Static Web Apps con Azure Pipelines

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

¿Psicosociales en el mundo de los contenedores? Kubernetes depreca a Docker

El día de ayer, buena parte del mundillo informático se sacudió con una noticia, que si bien ya se veía venir, por el lenguaje utilizado causo revuelo y preocupación, veamos:

Docker support in the kubelet is now deprecated and will be removed in a future release.

Esta nota formaba parte del log de cambios de Kubernetes, lo cual iba en la línea de un anuncio anterior donde se anunciaban este objetivo por parte de Kubernetes.

Obviamente las preguntas saltaron, ¿ya no podre seguir usando Docker si quiero trabajar con Kubernetes? ¿Qué pasara con el soporte para contenedores en Windows?, y la verdad la respuesta tardó algo en darse, y de eso hablaremos aquí, pero antes contextualicemos un poco.

Primero, veamos la parte técnica, a estas alturas en el mundo informático ya el concepto de contenedores esta mas o menos establecido, que la equivalencia con los contenedores usados en el transporte marítimo, que es una unidad de software con lo mínimo para ejecutar en un entorno destino y asi asegurar la portabilidad, las diferencias con las máquinas virtuales etc. Dicho esto, si que debemos repasar cual es el ciclo de trabajo que la mayoría de nosotros usamos al trabajar con contenedores, por simplicidad he quitado los componentes DevOps para enfocarnos en los contenedores, Docker y Kubernetes.

  • Tenemos un archivo llamado Dockerfile que define los componentes de software que queremos empaquetar y algunas acciones alrededor, este Dockerfile actúa como “receta” para que el comando “docker build” construya una imagen que la llamaremos X.
  • En este momento la imagen X esta en nuestro equipo, por lo que ya podríamos ejecutarla usando el comando “docker run”, o publicarla en un Registro tal como Docker Hub, Elastic Container Registry o Azure Container Registry, para lo cual usaremos “docker push”.
  • Con la imagen X subida en uno de estos Registros, ya esta lista para ser usada en diversos ambientes (generalmente en la nube), tales como Azure Container Instances, una máquina “convencional, Elastic Beanstalk y… Kubernetes, para lo cual este entorno destino deberá hacer un “pull” contra el Registro respectivo.

Entendiendo este gráfico podemos ver el porque de las dudas, si hemos subido nuestras imágenes apoyándonos en las funcionalidades de Docker… ¿quiere decir que en un futuro ese flujo va a cambiar?, bueno… para responder esta pregunta toca revisar un poco el como hemos llegado hasta aquí. Finish Reading: ¿Psicosociales en el mundo de los contenedores? Kubernetes depreca a Docker

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!