El objetivo que se persigue con esta serie de artículos es "aprender" a utilizar el framework de Serverless y entender un poquito más en que consiste el enfoque arquitectónico de Serverless.

En alguna ocasión he escuchado que esto del "serverless" es el futuro y que mola mucho porque una aplicación implementada con ello "no se ejecuta en ningún servidor". Entonces yo me quedo con cara de "poker" e imagino (de broma :-) ) que la otra persona piensa que ...

• ¿Se ejecuta en el "aire"?
• ¿Usa un CPD de Narnia?
• ¿Se quiera quitar "alegremente" todos los problemas asociados a un servidor de aplicaciones ligero o no SIN ningún tipo de sacrificio ritual?
• ¿Se le aplica en el despliegue algún tipo de magia ancestral?
• ...

El término "Serverless" significa sin servidor. Comercialmente tiene un nombre potente y el "deseo" de muchas personas de que se haga realidad, pero hay que decir que los servidores siguen y seguirán existiendo por muchos años, aunque el término diga lo contrario...jejeje. Lo que si va a cambiar es que los desarrolladores no van a tener tanta responsabilidad a la hora de realizar operativas, controlar los tiempos (respuesta, ejecución, etc), tener que aplicar tuning sobre los servidores, etc.

De hecho, a día de hoy con este término hacemos alusión a tres cosas: Arquitectura, Organización y Framework... ¡cómo no vamos a estar confundidos! :-)

PROBLEMA... (Lo que pasa siempre)

Algunos términos pueden ser engañosos y pueden llevar a la gente a pensar cosas que NO son.

De hecho yo he llegado a escuchar que esto del serverless es que "no utiliza backend"...

Hay que tener especial cuidado con la abstracción que hacemos (os suena el término "cloud" usado para todo).

Trataré este tema y otros relacionados en una serie de artículos con el objetivo de tratar de ayudar a fijar conceptos, tanto a nivel teórico como práctico, con la idea de que al final de ellos tengamos un ejemplo de alto nivel técnico, práctico y real (como se puede ver no pinta nada mal... jejeje).

Este artículo está dividido en 3 partes:

• 1. Introducción General: Se hará una breve introducción sobre los diferentes entornos de ejecución sobre los que se pueden encontrar nuestras aplicciones
• 2. Introducción FaaS: Introducción sobre Faas , características, casos de uso , ventajas e inconvenientes.
• 3. Conclusiones: Opinión sobre lo que se ha explicado.

1. Introducción General

Este punto va a tratar de poner el "primer ladrillo" para tratar de entender de qué va esto, para ello creo que es interesante hacer un pequeño recordatorio sobre los entornos de ejecución que nos hemos encontrado o nos podemos encontrar en nuestras aplicaciones

Clasificación:

• Entorno de ejecución "clásico" / "legacy"
• Entorno de ejecución "cloud".
• Entorno de ejecución "infraestructura como código".
• Entorno de ejecución "serverless".

Entorno de ejecución "clásico" / "legacy"

Desde casi el principio de los tiempos TODOS los desarrolladores hemos trabajado con un entorno de ejecución "clásico" para nuestras aplicaciones.

Estoy dispuesto a apostar un café que al menos has utilizado alguno una vez en la vida (aunque haya sido haciendo alguna frikada en casa).

¿Qué es un entorno de ejecución "clásico"?

Cuando se dispone de un servidor físico con una asignación específica de sus recursos, una configuración particular de los lenguajes/versiones a utilizar donde se ejecutarían las diferentes aplicaciones

Es decir, tenemos una máquina física/servidor dedicada con una configuración del HW específica y cerrada (o bien en el estado de cuando la compramos o con alguna pequeña evolución según presupuesto :-) ) y con un SW prácticamente en igualdad de condiciones.

Problemáticas típicas:

• Añadir más "hierro" cuando nos quedamos sin capacidad de almacenamiento, capacidad de computo, velocidad de trabajo, etc.
• Controlar la infraestructura a nivel de almacenamiento de datos y copias de seguridad.
• En los casos más importantes tener planes de Disaster Recovery.
• La responsabilidad sobre el software requerido, es decir, el encargado de que todo vaya bien (SSOO, drivers, software de HW utilizado, etc.) -> Parches, actualizaciones, etc.
• Segregación entre entornos -> DEV, INT, UAT, QA, PRE y PRO:
• Tratar de igualar los entornos altos para que sean lo más parecidos.
• La imposición de algunos SW a la hora de determinar qué irá instalado en una máquina.
• Problemas de las librerías incorporadas o las dependencias directas (implementaciones y versiones).
• Escalado Horizontal.
• Monitorización global.
• Cambio de personal encargado de esta parte.
• ...

Con todas nuestras experiencias podríamos ser capaces de escribir un libro contando nuestras alegrías y penas... yo tengo muchas :-)

A partir de ellos aparecieron una serie de evoluciones o revoluciones (según se mire) que todos conocemos:

• Uso de Mainframes -> Son mega máquinas con recursos HW impensables para un usuario medio.
• Acceso a HW a precios más bajos e interesantes.
• Mejoras en las infraestructuras de comunicaciones -> Internet, redes LAN, redes móviles, etc.
• Aparición de las máquinas virtuales.
• Aparición de la virtualización bajo demanda -> Facilita la creación y configuración de entornos virtualizados de forma automática (Por ejemplo: Vagrant, Heroku, etc.).
• Aparición de automatización de infraestructuras -> Facilita automatizar los procesos de configuración de los servidores (Por ejemplo: Puppet, Chef, Ansible, etc.).
• Se hablará más en el punto de "infraestructura como código".
• Aparición de los contenedores (Por ejemplo: Docker, Rocket, etc.)

Tanto el enfoque "clásico" como con las "evoluciones" se utilizarán actualmente y en los próximos años :-)

Entorno de ejecución "cloud"

Desde hace unos años se está produciendo un cambio de enfoque en algunas empresas en lo que se refiere al aprovisionamiento de infraestructura, todos esto gracias a la aparición de los entornos de ejecución cloud:

¿Qué es un entorno de ejecución "clásico"?

Cuando se dispone de un servidor físico proporcionado por un proveedor (Azure, AWS, Google, etc.) asignación específica o dinámica de sus recursos, una configuración particular de los lenguajes/versiones a utilizar donde se ejecutan las diferentes aplicaciones

Hay que tener en cuenta la dependencia que existe sobre los modelos de servicios a la hora de realizar la distribución de SW.

Y con ello hay que tener claro lo que son los modelos de servicio:

- IaaS (Infraestructura como Servicio)

Modelo basado en que un proveedor se encarga de la distribución de la infraestructura necesaria.

También se denomina HaaS (Hardware como Servicio):

• Unidad de despliegue: el sistema operativo.
• Objetivo: externalizar el servidor (espacio disco, tiempo computación y/o base de datos).
• Proporciona: proporciona máquinas virtuales empaquetadas con sistemas operativos.
• Abstracción: servidores físicos.
• Características: escalabilidad, elasticidad, disponibilidad, seguridad, automatización, mantenibilidad, etc.
• Pago: por configuración y uso.

Símil "Pizzería Online" - IaaS"

Un IaaS en una pizzería online sería como que la pizzería nos facilitarán en el configurador de la pizza: los ingredientes de la masa, elegir la levadura/agua/sal, su proporción, la calidad de los ingredientes, el tipo de horno , etc. Pero la pizzería se encarga de todo la preparación, cocinado y entrega.

En nuestro caso podremos elegir procesadores, memoria, sistema operativo básico, etc., cuando acabamos el proceso se nos da la forma con la que nos conectaremos a esa máquina y a partir de ahí se nos cobrará por su uso.

- PaaS (Plataforma como Servicio)

Modelo basado en que un proveedor se encarga de proporcionar TODO lo necesario para soportar un ciclo de vida completo de puesta en marcha de aplicaciones y servidores:

• Unidad de despliegue: las aplicaciones.
• Objetivo: externalizar la aplicación (base de datos, SSOO, servidor de aplicaciones).
• Proporciona: proporciona plataformas de aplicaciones para el desarrollo.
• Abstracción: sistemas operativos y middleware.
• Características:  lo mismo que IaaS.
• Pago: por licenciamiento, configuración y uso.

Símil "Pizzería Online" - PaaS"

Un PaaS en una pizzería online sería como que la pizzería nos facilitarán en el configurador de la pizza: la masa dentro de unos modelos establecidos (medida, proporción de ingredientes, etc.), los ingredientes disponibles en base a unos proveedores, etc. (sin mucho detalles). Pero la pizzería se encarga de todo la preparación, cocinado y entrega.

En nuestro caso podremos elegir aplicaciones, sus versiones, acceso, funcionalidad extra, etc., cuando acabamos el proceso se nos da la forma con la que nos conectaremos a esas aplicaciones, todo lo que tiene que ver con su infraestructura pasa a ser transparente (el proveedor a elegido lo mínimo para funcionar de una forma normal) y a partir de ahí se nos cobrará por su uso.

- SaaS (Software como servicio)

Modelo basado en que un proveedor se encarga de proporcionar mantenimiento, soporte y operación a un cliente durante un periodo de contratación de servicio:

• Unidad de despliegue: los servicios.
• Objetivo: externalizar el uso.
• Proporciona: proporciona servicios/funcionalidad bajo demanda.
• Abstracción: aplicaciones online.
• Características: lo mismo que IaaS.
• Pago: por volumen de usuarios, módulos utilizados, plan de soporte, acceso por dispositivo, etc.

Símil "Pizzería Online - SaaS"

Un PaaS en una pizzería online sería como que nos facilitaran en el configurador de la pizza: establecen unas pizzas en concreto que tienen ya preparadas, unas medidas de consumo determinadas (porciones, media, entera), puede no ser reciente y unas opciones concretas de menú.

En nuestro caso podremos elegir las condiciones de uso del servicio en base a las opciones proporcionadas, pero todo lo que tienen que ver con la infraestructura y la aplicación que estemos utilizando es transparente a nosotros.

Todo lo que tiene que ver con su infraestructura pasa a ser transparente (el proveedor a elegido lo mínimo para funcionar de una forma normal) y a partir de ahí se nos cobrará por su uso.

Aparece el enfoque "XaaS" o "Todo como servicio" que es un modelo basado en proporcionar todo para pago por “uso” en lo referente a servicios específicos: BI, Seguridad, Desktop, Backup, Email, ...

Entorno de ejecución "infraestructura como código"

Este entorno surge como evolución "natural" del entorno de ejecución "Cloud", es decir desde que aparece la posibilidad de pagar por el uso y la creación de entornos casi automática y con una tareas de mantenimiento que pueden variar según la habilidad del técnico (bueno y porque la destrucción también es sencilla ... jejeje).

Ahora nos interesa automatizar el proceso para NO tener que volver a repetir pasos manualmente cada vez que se crea un entorno (por ejemplo:  instalar linux con un Apache Tomcat y la JDK 8). Y además porque como tenemos en algunas ocasiones dependencias a ciertas versiones de elementos, tenemos que ser capaz de generar "clones" en ciertos contextos.

Las características que son cubiertas con este enfoque son:

• Creación de una infraestructura versionable, reproducible, consistente e independiente del entorno.
• Disponer de entornos limpios y sin estados anterior.
• Automatización del proceso manual mediante una explotación programáticos sobre los entornos de ejecución: clásico y Cloud.
• Facilita la creación / destrucción de entornos como ciclo de integración / entrega continua.
• Uso de herramientas específicas.

Detalle sobre la forma de encajar este punto en un proceso CI/CD:

Para ello se aconseja tener en cuenta los siguientes aspectos : Aprovisionamiento Automatizado y Gestión de la configuración:

- Servidores "Mascota" vs "Ganado" (Pets vs Cattle)

Esta "comparación"/teoría surge a partir de qué cada vez los servidores importan menos y lo que importa es proporcionar servicio.

En un entorno de ejecución "clásico" donde se hace todo lo que está en nuestras manos para "cuidarlo" tenemos la circunstancia de que en algunas ocasiones NO es tan fácil poder cambiarlo. Es decir, es irreemplazable y por tanto es el que tenemos (tratamiento de "Mascota" -> "lo tenemos que querer con sus cosas buenas y malas").

Actualmente esto ha cambiado con los entornos de ejecución "Cloud" como ya se ha visto. En Muchos casos ahora es más fácil crear un servidor nuevo y tenerlo listo de forma automatizada que realizar cualquier operativa para solucionar cualquier problema sobre uno antiguo (tratamiento de "Ganado" -> "su perdida en general importa poco y siempre se puede cambiar por otro”).

Por lo tanto, los entornos Cloud facilitan el enfoque "Serverless" porque se da mayor importancia al código que a la infraestructura.

Entorno de ejecución "serverless"

Este entorno surge a partir de la existencia del entorno de ejecución "Cloud" con modelo de servicio "SaaS" en concreto del enfoque FaaS.

¿Qué es un entorno de ejecución "serverless" o "FaaS"?

Servicio proporcionado por un proveedor (Azure, AWS, Google, etc.) donde se facilita un servidor (físicos o cloud), la asignación dinámica de sus recursos, una configuración concreta de los lenguajes/versiones a utilizar y una única función de entrada como contrato.

En líneas generales se consigue:

• No exista aprovisionamiento, gestión y mantenimiento de servidores.
• Toda la infraestructura está delegada al proveedor.
• Enfoque "On-Demand" / "Bajo demanda":
• Funcionamiento basado en el uso .
• Facturación basado en el uso -> Sólo se paga por los recursos que se consumen.
• Como los recursos los establece el proveedor la medida de facturación suele estar asociada con el tiempo de ejecución) -> "más tiempo es más coste".
• Escalado continuo/elástico basado en el uso.
• Reaprovechamiento de contenedores.
• Disponibilidad y Tolerancia a fallos (por defecto suele ser proporcionado por el proveedor) -> Reduce las preocupaciones de los desarrolladores.
• Ante un error el proveedor cambia el código de máquina sin que el usuario se entere.
• Facilita la orientación a Eventos -> Arquitecturas EDA (Event Driven Architecture) -> Buen comportamiento.
• Latencia establecida por el proveedor
• Un evento invoca a esta función que genera el entorno y una vez ejecutado, ese entorno desaparece -> arranque “frío” / “caliente” -> latencia.
• Ahorro de costes en general si se hace un buen uso y se utiliza para lo que realmente fue diseñado.

2. Introducción FaaS

Serverless también puede describirse como Funciones como un Servicio (FaaS), por lo que se trataría de un tipo de producto que se encarga de ejecutar funciones (código) bajo demanda en respuesta a algún tipo de los eventos considerados sobre un entorno de ejecución "Serverless" (proporcionado por el proveedor):

• Unidad de despliegue: las funciones.
• Objetivo: externalizar el uso.
• Proporciona: ejecución de código bajo demanda.
• Abstracción: runtime de desarrollo.
• Características: lo mismo que IaaS.
• Pago: por tiempo de ejecución.

Algunos de los servicios de ejecución de funciones proporcionado por diferentes proveedores serían: AWS Lambda, Google Cloud Functions, Azure Functions, IBM Cloud Functions (basado en Apache OpenWhisk), Iron.io, Webtask.io etc.

El lenguaje de implementación soportado depende del proveedor.

Símil FaaS - Método main Java

Un símil en el desarrollo Java sería que el proveedor de FaaS te dejara el hueco del método "main" para desarrollar pero el resto de detalles (ubicación del proyecto, versión de java, lanzador de aplicaciones , etc.) sería elegido por el proveedor... ;-)

...
 public static void main (String [ ] args) {
     // Aquí añadiríamos la funcionalidad
}

Con esto lo que se consigue es la minimización del desarrollo a la mínima expresión: la función.

Un producto FaaS o una función de este tipo suele:

• Cumplir “SRP” (Single Responsability Principle).
• Ser Efímera -> por lo que se persisten un cierto periodo de tiempo.
• Tener una duración limitada -> tiende a mínimos.
• Ser SIN estado (Stateless).
• Si se quiere estado hay que utilizar otros servicios:
• Combinación con otros servicios externos (servicios de computación sin servidores):
• “Juntar Piezas”.
• Esta parte se la suele considerar BaaS (Backend as a Service):
• Autenticación (Auth0, Amazon Cognito).
• Productos API (API Gateway,etc).
• Sistemas de mensajería (SQS, SNS, etc.).
• Streaming de datos (Kinesis, etc.).
• ...
• Requerir un API Gateway que actúa como capa de comunicaciones entre el frontend y la capa FaaS.
• Ayuda a establecer endpoints de comunicaciones.
• Si se requieren otros servidores se necesitan otras piezas para balancear la carga o bien redirigir el tráfico.

Ejemplo de handler de una petición FaaS para AWS Lambda implementado en Node.js:

'use strict';

module.exports.hello = async (event, context) => {  
  return {
    statusCode: 200,
    body: JSON.stringify({
      message: 'Go Serverless v1.0! Your function executed successfully!',
      input: event,
    }),
  };

  // Use this code if you don't use the http event with the LAMBDA-PROXY integration
  // return { message: 'Go Serverless v1.0! Your function executed successfully!', event };
};

Diferencias de los FaaS frente a los microservicios:

• Conceptualmente son similares, pero presentan diferencias en los casos de uso que abordan:
• Un microservicio divide la aplicación grande en aplicaciones pequeñas que están desacopladas y que son independientes pero que se conectan entre sí o interaccionan para que la aplicación funcione.
• Las funciones son más pequeñas que los microservicios.
• Las funciones también tratan de ser desacopladas.
• Un microservicio puede contener múltiples funciones.
• Funcionalidades complejas -> requieren más de una función -> Patrón Orquestador vs Patrón Coreográfico.
• Se suele considerar que una función se ejecuta de forma más esporádica que un microservicio.
• Una función consume menos recursos que un microservicio.
• Cada uno tiene sus pros y contras

Problemática: Arranque Frío / Arranque Caliente

Arranque Frío / Cold Start

La primera vez que se ejecuta una función el tiempo total de ejecución se compone de: tiempo de arranque + tiempo de uso.

Incluye: Tiempo de arranque de la máquina/contenedor + Tiempo de inyección del código

El tiempo de uso se compone de: Tiempo de respuesta al evento + Tiempo extra “vida” útil

Arranque Caliente/ Warm Start

En cada ejecución se encuentra el servidor ya arrancado.

El tiempo será únicamente tiempo de uso: Tiempo de respuesta al evento + Tiempo extra “vida” útil.

Características:

• Depende de: proveedor, límites de lenguajes, tiempo / límites de ejecución , tamaño de la función, etc.
• Los lenguajes interpretados suelen tener mejores tiempos de arranque y consumo de recursos.
• Evitar arranques “Cold Start” -> Mantener las funciones “calientes” (con invocaciones periódicas).
• Los microservicios mantienen el servidor.
• ...

Enfoque Arquitectónico Serverless

Aquí hablaríamos de cualquier desarrollo que se despliega en un “entorno de ejecución Serverless” proporcionado por los diferentes proveedores (Azure, AWS, Google, etc.) o en soluciones OnPremise (OpenWhisk, OpenFaas, Kubeless, Fn Project, etc.) dónde solamente hay que introducir el código para poder ejecutarlo.

Con este punto se pretende ayudar a sentar las bases de los motivos reales por los que elegir este diseño de arquitectura:

• Cloud-First.
• Pay-for-Use o Pay-for-execution-time.
• Less Ops -> Abstracción de la infraestructura:
• Fully managed service -> Total responsabilidad en el proveedor.
• Agnóstico del proveedor.
• Aprovechamiento de las mejoras proporcionadas de forma "cross" por el proveedor como: escalabilidad, alta disponibilidad, etc.
• Orientación al desarrollo -> Más tiempo para dedicar al desarrollo.
• Desaparecen los servidores para el desarrollador -> NO aprovisionamiento ni mantenimiento.
• On-Demand -> El código NO necesita estar funcionando todo el tiempo.
• Diseño push-based.
• Facilita el uso de EDA (Event-Driven Architecture).
• El código que se ejecuta se corresponde con una función.
• El lenguaje de implementación depende del proveedor (tipo y versiones) -> heterogeneidad:
• Depende del criterio del desarrollador.
• Facilita el escalado particular de dicha funcionalidad.
• Facilita el despliegue individual -> Cuidado con la Orquestación.
• Tiene similitudes con la Arq. de Microservicios.
• Focalización en la construcción y mantenimiento de aplicaciones -> Productividad.
• Requiere un cambio cultural y no solo técnico.
• Facilita la integración con otros servicios del proveedor (Logging, monitorización, etc).
• Fuente de invocación: API , otro FaaS o bien evento o mensajes de otros productos.
• Determinar el enfoque: Patrón Orquestador vs Patrón Coreográfico.
• Cada uno tiene sus cosas buenas y sus cosas malas.
• Una mala elección puede condicionar a todos los desarrolladores.

Propuestas de uso

Estos serían algunos "ejemplos" en los que utilizar este tipo de enfoque:

• Soporte para implementar de forma rápida PoCs y "laboratorios".
• Extensión de un backend de aplicaciones (web/mobile/IoT): Unidad de expansión de cierta funcionalidad por ejemplo sobre bloques monolíticos, etc.
• APIs: Ejecución de una acción tras una petición para que realice "algo".
• Webhooks: Ejecución de una acción tras provocarse algo en el contexto de ejecución (alarma, evento, etc).
• Orientación a eventos -> EDA (Event Driven Architectures).
• Uso de servicios externos (por ejemplo bases de datos Cloud).
• Comunicaciones asíncronas (por ejemplo el uso de colas como Kafka, SQS, ...).
• ETL: Procesos de conversión de entradas en salidas específicas.
• Tareas programadas(scheduled task / jobs).
• Procesamiento de datos.
• CDC (Change Data Capture).
• Pipelines CI / CD.
• ...

3. Conclusiones

A parte de que Serverless quita mucho tiempo y ahorra muchos costes, a mí me ha quitado un peso de encima ya que no tengo que configurar servidores ni servidores de aplicaciones (cuantas horas en mi vida habré dedicado a ello...).

Aunque se ha podido ver que pueden ayudar mucho al utilizarse en muchos casos de uso hay algo que yo ha podido extraer de todo el artículo :

• Serverless no es trivial , para llegar a entender su "magia" hay que entender muchas cosas -> "No es otra bala de plata", debemos escoger bien el caso de uso adecuado para utilizarlo.
• Su uso esta relacionando más con una frecuencia esporádica de las ejecuciones que con una frecuencia regular, por lo que no es útil en tareas o servicios / de larga duración.
• "Impone" ciertas latencias que muchas organizaciones o aplicaciones no están dispuestas a asumir por lo que el rendimiento no debe ser un problema.
• Que facilita mucho usar los servicios y productos de los distintos Clouds Públicos con lo que eso significa.
• Tiene una gran una orientación a eventos.
• Se encuentra en una etapa temprana de desarrollo y uso por lo que "el tiempo dará o quitará la razón" a su implantación en las empresas.

En los siguientes artículos veremos unos ejemplo muy chulos y su aplicación directa en enfoques reales de uso.

No dejarás pasar la oportunidad de aprender "Serverless"  ;-)

Si te ha gustado, ¡síguenos en Twitter para estar al día de próximas entregas!