¿Cuales son las diferencias entre Azure Container Instances, Azure Container Apps y Azure Kubernetes Services? (y ii)

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: Finish Reading: ¿Cuales son las diferencias entre Azure Container Instances, Azure Container Apps y Azure Kubernetes Services? (y ii)

¿Cuales son las diferencias entre Azure Container Instances, Azure Container Apps y Azure Kubernetes Services?

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. Finish Reading: ¿Cuales son las diferencias entre Azure Container Instances, Azure Container Apps y Azure Kubernetes Services?

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:

Finish Reading: Presentando las Azure Container Apps

¿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