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.