Bueno, llegamos al final de esta serie de reflexiones sobre Serverless en el contexto actual, y empezamos dejando algo claro:

Serverless no es solo Functions as a Service.

Y ¿eso por qué? Porque si bien la referencia  a Serverless nos hace pensar en Azure Functions o AWS Lambda, debemos valorar el concepto de manera adecuada, asi que de manera preliminar digamos que Serverless es un servicio cloud en el cual no tenemos «conciencia» de cual es el servidor o servidores que nos proveen la funcionalidad deseada (lo cual no quita que podamos tener una URL referencial, ojo).

En ese sentido, pues si, un Event Hub, un Service Bus, un gestor de APIs o servicios DNS calzan dentro de la definición de Serverless, de hecho en un pasado Microsoft Ignite, el orador decía que el servicio Serverless mas usado era … Azure Storage, y claro tiene sentido bajo la premisa inicial que hemos hecho ¿no?.

Ok, la definición puede ser laxa y por eso a veces me veo el lios para establecer una definición, así que para el resto del articulo hablaremos de Serverless en tanto servicios de computo en el que podemos ejecutar el código de nuestras aplicaciones abstrayendonos totalmente de los servidores (fisicos o virtuales) que dan soporte a la operación, razón por la cual cabria considerar como tales a las Logic Apps pero no a nuestras viejas cómplices las Web Apps (y mucho menos Elastic Beanstalk de AWS).

Bueno, la cancha esta delimitada, y corresponde hablar de las opciones serverless para la gestión de contenedores, y a estas alturas del partido no hablare de que va Docker, el modelo de contenedores y las ventajas que trae para el despliegue de aplicaciones, pero si debemos repasar un concepto que es la orquestación de contenedores, que en corto significa tener un cluster de X servidores donde se iran desplegando (y escalando! ojo) los contenedores que conforman nuestras aplicaciones (generalmente hechas usando oh! microservicios).

Para nadie es un secreto que desde el 2017 en que veíamos cierta competencia en el rubro de orquestación (DCOS, Mesos…) el mercado se ha decantado por una plataforma: Kubernetes, pero el provisionamiento de un cluster no deja de ser complejo en terminos de configuración, teniendo en cuenta que se debe de reservar lo que se conoce como «master nodes» tanto para la ejecución de nuestros contenedores como para la gestión y monitoreo de toda la ejecución de nuestro cluster, como se explica aquí.Con esta base de complejidad de los proveedores de nube optaron por desarrollar soluciones de Kubernetes (abreviado: k8s) manejado: «te cobramos por los nodos que reserves para ejecutar y escalar tus contenedores, pero corre por nuestra cuenta la infraestructura necesaria para la gestión de tu cluster», y así a nosotros «tan solo» nos queda definir los nodos y su capacidad, para desplegar ahí nuestras aplicaciones y que los pods vayan escalando horizontalmente según nuestras …..

Espera, espera… no que estábamos hablando de serverless?? pues si, pero requeríamos un contexto previo antes de mencionar la convergencia entre estos mundos, asi que regresemos a serverless.

Cuando empece con esto de Docker y contenedores, para hacer mis pruebas tenia que provisionar toda una MV Linux, lo cual como buen usuario de Windows no resultaba muy practico para mi, luego surgieron otras opciones como Web Apps for Containers, o los ya mencionados orquestadores como Kubernetes, pero ¿Y si tan solo quiero lanzar un contenedor y olvidarme del resto? Pues bien en estos casos tenemos la opción de lanzar contenedores serverles, que en el caso de Azure se llaman Azure Container Instances y en el de Google se llaman Cloud Run.

La promesa detrás de estos servicios de contenedores serverless es sencilla, ejecutar contenedores sin administrar servidores, ya tengo subida una imagen al Registro, por lo que solo tengo que decirle a nuestro proveedor cloud que quiero provisionar una instancia de contenedor basada en la imagen respectiva, claro toca definir detalles sobre la ubicación geografica, dimensiones y redes, pero una vez pedidos esos detalles ya no deberemos preocuparnos del asunto, hasta que decidamos «matar» la instancia.

El salto se da cuando combinamos los conceptos de cluster Kubernetes con contenedores serverless, ¿como asi? Recordemos que un cluster K8s se conforma de nodos sobre los cuales se van instanciando los pods/contenedores conforme la demanda (escalamiento) los va requiriendo, pues bien ¿qué pasa cuando hemos metido tantos contenedores que hemos llegado a los limites de nuestro cluster? Pues la opción lógica era agregar otro nodo, pero ¿qué tal si proveemos esta capacidad instanciando contenedores serverless? Pues es mas o menos lo que se tiene, en el caso de Microsoft, integrando AKS (Azure Kubernetes Service) con ACI (Azure Container Instances):

Potente ¿verdad? En lugar de crecer vía una maquina virtual adicional, lo hacemos mediante objetos serverless, y claro, cuando la demanda caiga la infraestructura los ira matando progresivamente.

Claro, esto obliga a aprender nuevos conceptos como virtual-kubelet, scale to zero, CNI, knative, etc pero la idea basica es esa, ahora resta ver como lo implementa nuestro proveedor de nube usual para lo cual los dejo con este articulo que compara estas capacidades de manera mas profunda.

Dicho esto, y para ir cerrando hay que precisar algunas cosas, parrafos atrás no incluí a AWS Fargate como una opción de contenedores serverless, debido a que para poder hacer uso de Fargate siempre debe provisionarse un cluster EKS (la implementación manejada de K8s de AWS) o ECS para poder lograr el efecto, por lo que tan serverless no sería, pero si que permite lograr el efecto de escalar mas allá de los dimensionamientos iniciales del cluster. Otras cosas a considerar es si se tiene la posibilidad de crear un cluster «sin nodos» pero con cargo a llenarlo luego con contenedores serverless, al momento de escribir este post AKS no lo permite, pero EKS (Elastic Kubernetes Service) y GKE (Google Kubernetes Engine) si.

Bueno aquí acaba esta serie sobre serverless en el día de hoy, se me queda en el teclado hablar sobre KEDA, pero ya habra ocasión sobre ello y quiero volver a comentar algo mas de Azure DevOps ;), de momento espero tus comentarios.

Serverless: Realidad y perspectivas (1)
Serverless: Realidad y perspectivas (2)