Aquí de vuelta, y me complace comentar que he sido renovado por séptima vez como Microsoft MVP para Developer Technologies y Microsoft Azure, reconocimiento que es a la vez un reto que motiva a seguir compartiendo conocimiento, así que vamos a ello.

Hace unas semanas tuve una conversación respecto a las diferencias entre ACA, ACI y AKS, lo cual me hizo pensar que si, puede haber cierta confusión ya que los servicios no nacieron en el mismo tiempo, así que para entender su contexto repasemos un poco de historia.

Muchos recordamos el boom de Docker y los Contenedores durante 2015 y 2016, y si, en ese momento significo toda una revolución respecto a como se desarrollaban y desplegaban las aplicaciones, no nos detendremos en eso, pues ya se ha escrito mucho al respecto, pero si anotaremos las consecuencias inmediatas de ese boom para entonces:

• Impulso para el uso de Linux, ya que era el único Sistema Operativo que permitía ejecutar Docker
• Se abrió el camino para el crecimiento de un patrón de arquitectura llamado “microservicios”
• Lo cual derivo en la necesidad de ejecutar mas de un contenedor a la vez

Si pues, yo un usuario clásico de Windows de toda la vida tuve que desempolvar mis oxidados conocimientos de Linux (¡en una MV sobre Azure!)  a fin de poder practicar con Docker y así hacer mis primeras demos al respecto. Y claro, eso me dejo con la inquietud de “¿es conveniente desplegar una MV para tan solo un contenedor?”, claro eso me llevo a conocer y probar lo que era Docker Composer, y leer sobre algo llamado Docker Swarm.

Tiempos acelerados, y en ese momento los objetivos de Microsoft iban por dos frentes: integrar a Windows (Server) en el mundo de los contenedores y por otro lado ofrecer alternativas para simplificar el despliegue y la orquestación de los contenedores en la nube.

Si, orquestación, la capacidad de desplegar en un contexto (un cluster por ejemplo), mas de un contenedor y gestionar su ciclo de vida: escalamiento, creación y destrucción de instancias; así que en abril del 2016, Microsoft anuncia Azure Container Service, una plataforma manejada (PaaS) que permitía desplegar los orquestadores emergentes de ese entonces: DCOS y Docker Swarm.

Ok, eso solucionaba el tema de la gestión de mas de un contenedor a la vez, pero de igual forma, seguíamos con la situación de tener que lanzar toda una MV de Linux si lo que queríamos era desplegar UN contenedor en la nube, es por eso que en julio del 2017 se anuncia Azure Container Instances (ACI), que esencialmente lo que permite es desplegar un contenedor “libre” sin necesidad de definir un host para ello, simplemente especificando la fuente de la imagen, los parámetros de tamaño, región, etc, y listo! Ya tenias tu contenedor en la nube, ah… y también permite lanzar contenedores Windows.

Como les dije, esa fue una época muy acelerada, y resulto que en ese entorno creciente de los orquestadores hubo un producto que emergió rápidamente como el estándar de la industria: Kubernetes, desplazando rápidamente a los productos mencionados arriba, ya que las organizaciones lo iban adoptando a pesar de su mayor complejidad, tanta ha sido su influencia que no nos dimos cuenta y en algún momento dejamos hablar de Docker para tan solo hablar de “contenedores” y de Kubernetes como “la” forma preferente de desplegarlos y orquestarlos (*).

En ese sentido es que a nadie sorprendió que en Octubre del 2017 se anunciara el lanzamiento de Azure Kubernetes Services (AKS) en estos término “estamos haciendo que sea aún más fácil administrar y operar sus entornos Kubernetes, todo sin sacrificar la portabilidad. Este nuevo servicio presenta un Control Plane alojado en Azure, actualizaciones automatizadas, recuperación automática, escalado sencillo y una experiencia de usuario sencilla tanto para desarrolladores como para operadores de clúster. Con AKS, los clientes obtienen el beneficio de Kubernetes de código abierto sin complejidad ni sobrecarga operativa.”

Prestemos atención a esa declaración que efectivamente promete el manejar la cruda realidad de Kubernetes: su complejidad, sin entrar en detalles solo diremos que si uno quiere provisionar un cluster por si mismo deberá preocuparse por dos elementos: el Control Plane y el Data Plane, el primero se hace cargo de administrar y monitorear la operación del cluster, mientras que en el Data Plane se instanciaran los contenedores en si mismos, lo cual obliga a reservar y administrar nodos (maquinas virtuales) tanto para el Control Plane como para el Data Plane.

En ese sentido la propuesta de AKS tiene sentido, hace que los usuarios ya no tengan que preocuparse por las operaciones del Control Plane, ni administrar el Sistema Operativo de ninguno de los nodos involucrados en el despliegue, si, son Maquinas Virtuales, pero a efectos prácticos son nodos abstractos donde se alojaran nuestros contenedores (pods).

A pesar de estas ventajas, una implementación de Kubernetes en AKS sigue siendo compleja de administrar, aun hay que velar por archivos YAML de despliegue, gestionar Ingress, deployment, replicas, namespaces, etc, pero algo deberá de tener para que a pesar de su complejidad AKS y otra versiones manejadas de K8s hayan terminado de consolidar la adopción de Kubernetes como sinónimo de “cloud native” (a pesar de que la definición va mas allá) para grandes despliegues de aplicaciones basadas en el patrón de microservicios.

De esta forma para el 2021 nos encontramos con el escenario de que Kubernetes se ha establecido como la Plataforma preferente para el Desarrollo de aplicaciones contenerizadas, pero ya hace rato se han evidenciado algunos detalles mas allá de la complejidad natural de K8s:

Si uno quiere provisionar un cluster de K8s necesariamente debe dimensionar su uso potencial, ergo definir el tamaño (CPU y RAM) y cantidad de nodos que conformaran nuestro cluster, lo cual implica definir un “colchon” para que los pods puedan escalar con seguridad, por lo cual no será raro que durante momentos “valle” de la operación tengamos una buena capacidad ociosa por la que estemos pagando, lo cual impacta menos en aplicaciones grandes, pero y… ¿en aplicaciones pequeñas o medianas? Mas aun si recordamos que se recomienda que un cluster de Producción este conformado como mínimo por 3 nodos.

Ya que mencionamos el escalamiento, cabe recordar que el escalamiento de los pods en K8s (HPA) se realiza esencialmente basado en el uso de CPU o de la memoria, por lo que si se desea gestionar dicho escalamiento basado en las peticiones o eventos que van ocurriendo, no seria posible de forma nativa, y si, hay formas de lograr eso mediante tecnologías como KEDA, pero igual hay que hacer esa configuración.

Es así que en noviembre del 2021 Microsoft presenta las Azure Container Apps (ACA) como un “un servicio para el alojamiento serverless de aplicaciones en el que los usuarios no ven ni administran máquinas virtuales, orquestadores u otra infraestructura en la nube subyacente. Azure Container Apps permite ejecutar código de aplicación empaquetado en cualquier contenedor y no tiene opiniones sobre el tiempo de ejecución o el modelo de programación. Las aplicaciones pueden escalar en respuesta a solicitudes HTTP, eventos (por ejemplo, mensajes de cola de almacenamiento, temas de Kafka, etc.) o simplemente ejecutarse como trabajos en segundo plano siempre activos.”

Ya comenté con mas detalle este producto con motivo de su lanzamiento, pero para resumir, consideremos que ACA nos da un espacio o “bolsa” (los environments) donde ir desplegando nuestros contenedores, solo pagamos por los contenedores que vayamos instanciando, siendo que el escalamiento lo podemos hacer no solo basándonos en el uso de los recursos de cómputo, sino también basándonos en eventos como es mencionado en la definición anterior.

Ok, ya bastante de historia, salvo para comentar que en algún punto (como era esperable) ACS fue deprecado por Microsoft, lo cual nos deja en esta situación respecto a los servicios de Azure basados en contenedores:

• Azure Container Instances (ACI): para cuando requerimos lanzar tan solo un contenedor de manera sencilla y autónoma, un uso muy frecuente ha sido para montar servidores sFTP en la nube, tan solo instanciando una imagen y mapeando el storage respectivo. Y claro, también para realizar pruebas atómicas del contenedor que vayamos desarrollando. (**)
• Azure Container Apps (ACA): para aplicaciones pequeñas y medianas que no requieren la complejidad añadida de k8s, pero que desean desplegar aplicaciones basadas en microservicios sin dimensionar de antemano el consumo global y aprovecharse de un modelo de escalamiento flexible. De hecho, la filosofía detrás de este producto es que debemos orientarnos hacia el desarrollo de nuestra aplicación y ya no tanto hacia la infraestructura subyacente.
• Azure Kubernetes Service (AKS): para aplicaciones grandes que van a sacar partido de los “tuneos” que se pueden hacer a la plataforma, o que requieren de interactuar con la API de K8s para su funcionamiento, de igual forma seria la opción deseada si se quiere el control sobre el host (los nodos) donde se despliegan los contenedores, algo que puede ser necesario si se está bajo regulaciones como PCI.

Bueno, esto es todo, espero que esto haya aclarado las dudas y puesto las cosas en perspectiva, he tratado de enfocarme solo en los contenedores y su ecosistema, pero recordemos siempre que una perspectiva de desarrollo en la nube va mas allá de los contenedores y hay mucho mas que considerar.

(*) Vale la pena leer este articulo donde se cuenta como Docker paso de ser el gran referente en contenedores, a ceder totalmente su lugar a Kubernates, a pesar de su excesiva complejidad.

(**) Cabe mencionar que otro uso de ACI es poder dar la capacidad, a los clusters de AKS, a escalar los contenedores que se vayan necesitando, sin agregar nuevos nodos, tan solo adscribiendo ACIs bajo demanda al control de un cluster AKS.