El articulo anterior dejo las bases respecto a como ha ido la evolución de las tecnologías de contenedores, y el contexto en que se ubican los Azure Container Apps (ACA), pero creo que falta precisar un poco respecto a los casos de uso en que se puede aplicar esta tecnología o sus “hermanos” en Azure.

Empezare con algo que puede que ahora luzca menos glamoroso, pero que si que causo impacto en el momento de su lanzamiento: los Azure Container Instances, como mencionamos en su momento, esta tecnología surge para evitar el tener que lanzar los contenedores dentro de un cluster o de una MV, en ese sentido, que se puede hacer ahora con ellos:

• Lanzar servicios de “servidor” basados en contenedores, que no requieran una orquestación ni escalamiento, como puede ser un servidor SFTP en la nube
• Experimentación individual, en desarrollo, de un contenedor que luego se integrara como parte de una plataforma de microservicios.
• ML, si, esto es algo que aprendí mientras preparaba mi certificación en Azure AI, resulta que algunos modelos sencillos de ML se pueden desplegar en Azure Container Instances, interesante la verdad.
• Dar soporte a un escalamiento sencillo a los clusters AKS, creando virtual nodes en escenarios en que no es conveniente escalar el cluster hacia nodos “reales”, ojo este modelo tiene algunas limitaciones por lo que toca revisar si es la solución para nuestra necesidad en concreto.

Como se puede ver, los ACI aun dan mucho juego, pero de nuevo vamos a la pregunta respecto a los casos de uso que corresponden a AKS y ACA, y esto ya entra en los terrenos del mal llamado “juicio de experto” que son tan subjetivos, pero trataremos de delimitar la cancha:

Primero debemos tener en claro las dos diferencias fundamentales entre las propuestas de ambos servicios: Control en el caso de AKS y Sencillez/Flexibilidad en el caso de ACA, con esto como punto de partida podemos seguir adelante.

Entonces un primer escenario de uso en el que AKS encaja mejor es cuando por negocio o cumplimiento regulatorio necesitas un mayor aislamiento de tus recursos de cómputo, por ejemplo garantizar la separación por redes de los nodos de tu cluster (por ejemplo en el caso de PCI), o yendo un paso mas allá, cuando se tiene necesidad de Computación Confidencial, algo muy amarrado a ciertas características de la MV que aloja nuestros nodos.

Y me dirán que ¿por qué esto no sería posible con ACA? Bueno la razón básica es que cada vez que provisionamos un contenedor de ACA, para ser enrolado a nuestros Environments, lo estamos sacando de un pool de espacios de computo compartido, por lo que es perfectamente posible que los distintos contenedores de nuestros ACAs provengan de distintas MVs en su origen.

Otro aspecto en el cual K8s tiene un espacio interesante es el de las BD, ¿qué? ¿Cómo? Si, efectivamente Bases de Datos, una tendencia que ha tenido cierto empuje en los últimos meses, debido el mayor soporte a procesos stateful en Kubernetes, en corto: tradicionalmente K8s estaba orientado a procesos sin estado, por lo que instalar un motor de DB en un cluster K8s era un proceso muy complejo, hoy eso ha cambiado y varias propuestas facilitan el uso de K8s como base para la ejecución de DB como PostgreSQL y MySQL.

De manera análoga, si por la razón que sea nuestro proyecto requiere hacer uso directo de las APIs nativas de Kubernetes, no queda, sino que provisionar un cluster AKS y seguir para adelante, porque entendemos que asumimos esa complejidad.

Entonces ¿qué espacio queda para ACA? Pues bastante la verdad, esencialmente el grueso de aplicaciones basadas en microservicios son susceptibles de ser implementadas en ACA, a menos que haya alguna característica de AKS aun no soportada por ACA que nos haga pensar de otra forma, y aun así hay que confiar en que las cosas vayan mejorando en ACA, como ya paso con la integración de secretos y volúmenes con Key Vault.

De todas maneras no puedo dejar de avisar que si ya se tiene un desarrollo hecho con K8s en mente, es muy probable que este sea complicado de portar hacia una plataforma mas ligera como ACA, por ejemplo en el caso de que se este apoyando en las características de un mesh como Istio, siendo que en el caso de ACA contamos con alternativas como Dapr, la cual también funciona en AKS. Así que tenemos otra conclusión: si por la razón que sea deseamos migrar de ACA a AKS no hay ningún problema, pero en sentido inverso puede ser complicado.

Es así que regresamos a las bases con las que se presento a ACA, un servicio que facilite el desarrollo en contenedores, facilitando que el equipo se enfoque en el código y no en la infraestructura, y es en ese aspecto en que ACA brilla sobre AKS donde tenemos mucha complejidad, la cual a veces puede ser necesaria, pero… no siempre.

Espero que esto les sea de utilidad para definir los escenarios de uso para estas tecnologías y les ayude a elegir adecuadamente basándonos en el caso de uso.