^{_{Introducción}}

A lo largo de los últimos años estamos viendo como la tecnología en general y los servicios Cloud en particular avanzan a un ritmo cada vez más rápido con un crecimiento exponencial de servicios que cuesta seguir incluso para los profesionales más experimentados.

En este contexto, he tenido la oportunidad de participar en varios proyectos con parte de las tecnologías Cloud más populares en la actualidad. Entre ellas, servicios Serverless, brokers de mensajería asíncrona, servicios de captura y procesado masivo de eventos, cachés distribuidas, containers, servicios de orquestación, microservicios, etc.

Así pues, surgen estos artículos como un modo de compartir conocimiento, dar mi visión personal y servir de asesoramiento para no incurrir en errores iniciales de diseño o sobrecostes.

Me centraré en la creación de Workflows Serverless con Azure Durable Functions con una serie de cinco artículos.

¿Qué es Serverless?

En la actualidad, Serverless en uno de los tipos de servicios Cloud más populares que existen. Su nombre, traducido al castellano como Sin Servidor genera confusión, dando lugar a la típica pregunta de ¿pero es que no hay servidor detrás? Por supuesto que sí, hay infraestructura, servidores y sistemas operativos detrás, pero el cliente consumidor solo dispone de estos recursos cuando realmente los necesita, con algunos matices que indico más adelante. En todo caso, el proveedor Cloud se ocupa de todo lo referente a tareas de mantenimiento de infraestructura, servidores, sistemas operativos, middlewares y dependencias, siendo su gestión y administración transparentes al cliente final.

Serverless surge como resultado de la evolución de los modelos de servicio Cloud hacia elementos de computación cada vez más pequeños, donde el proveedor Cloud asume más responsabilidades y el cliente se focaliza en la creación del código o business logic para sus aplicaciones.

En resumen, Serverless es un modelo de ejecución caracterizado por:

• El proveedor Cloud provisiona dinámicamente recursos de computación bajo demanda, como CPU, memoria y máquinas virtuales de modo transparente para el cliente.
• El proveedor Cloud despliega un runtime o entorno de ejecución apto para ejecutar las cargas de trabajo, codificadas en algunos de los lenguajes soportados por el servicio: .Net Core, .Net 5.0, Java, Python, etc.
• El cliente sólo necesita codificar sus cargas de trabajo previa selección de lenguaje y entorno de ejecución, mejorando los tiempos de puesta en producción de los servicios finales.
• Sólo existe carga de costes al cliente por el uso real de los recursos. Una vez ejecutados los trabajos, por defecto y salvo excepciones, los recursos de computación utilizados son desasignados tras un tiempo variable pero corto que depende del proveedor Cloud.
• A medida que la demanda de peticiones aumenta, el proveedor Cloud es capaz de escalar y desescalar los recursos de forma automática y prácticamente transparente al cliente final. Si una carga es invocada mil veces en poco tiempo, el proveedor se encarga de escalar los recursos y generar los runtime necesarios para responder a las mil invocaciones.
• La capacidad de la tecnología Serverless para ejecutar estos escalados y desescalados (scaling) de forma transparente, elástica y orientada a peticiones concretas es lo que marca una diferencia clave con los entornos PaaS (Platform as a Service).

Entre los servicios de funciones Serverless ofrecidos por los diferentes proveedores Cloud están, entre otros, Azure Funtions, AWS Lambda, OpenFaaS, IBM Cloud Functions, Google Cloud Functions o Alibaba Function Compute

Recientemente Microsoft anunciaba el lanzamiento de Azure Container Apps, un nuevo servicio Serverless enfocado no a la ejecución de funciones sino de containers. Todo lo explicado es válido para este nuevo servicio, pero en este caso la unidad de computación ya no es la función sino el container. AWS App Runner o Google Cloud Run también ofrecen servicios similares.

Como ya se ha visto, la tecnología Serverless proporciona importantes beneficios, pero eso no significa que todas las aplicaciones deban o puedan ser implementadas completamente en este escenario. La adopción de modelos híbridos también es una opción muy interesante hoy en día y mi visión personal es que lo será cada vez más a corto plazo.

Es suficiente por ahora, tan sólo añadiré el concepto de cold start o arranque en frío, es decir, el tiempo que el proveedor Cloud necesita para provisionar los recursos de computación y desplegar el runtime requerido para ejecutar las cargas de trabajo. Los proveedores Cloud ofrecen diferentes planes para mitigar esta latencia adicional donde alguna de las soluciones aportadas está en la frontera de la definición de Serverless. En el próximo artículo de esta serie se ampliará este concepto hablando sobre Azure Functions. Hasta entonces espero que esta primera entrega os haya sido de utilidad.

Autor del artículo

José Antonio Muro