Visión y panorama general Serverless

Cuando hablamos de arquitecturas *Serverless o “Sin Servidor” *puede que sea algo confuso. Principalmente el concepto lo vemos asociado a los siguientes enfoque:

1. Aplicaciones que incorporan o delegan **de manera significativa su lógica **en servicios o aplicaciones cloud de terceros. Por ejemplo una SPA con Auth0, Firebase y almacenamiento en S3.
2. Sistemas basados en eventos, en donde la lógica se implementa en plataformas del tipo FaaS (Function as a Service). Lo que nos permite ejecutar, de manera directa el código en funciones abstrayéndonos de la infraestructura necesaria para la ejecución y escalamiento.

*aaS

Hay un sin fin de modelos del tipo “ as a Service”*, desde mi favorito ***FO*aa**S hasta el FaaS que nos convoca.

Ahora veremos los modelos más comunes que nos ayudan a entender un poco, el cómo llegamos a Serverless y qué implica en términos de capas de abstracción y responsabilidad cada uno de ellos.

En la imagen vemos los verdes como responsabilidad nuestra y los azules del proveedor, es decir la responsabilidad de administración disminuye hacia la derecha. Para ejemplificar utilizaré la sabrosa — y quizás no tan exacta — analogía de las pizzas de Paul Kerrison.

• On Premises. Como hacer una pizza en la casa, hacemos todo. Equivalente a nuestro datacenter.
• IaaS (Infraestructure as a Service). Compartimos la cocina con otros, tenemos las herramientas, pero debemos hacer y cocinar la pizza nosotros mismos. Por ejemplo: AWS EC2, Azure VMs, GCP Compute engine, Digital Ocean.
• CaaS (Container as a Service). Llevamos la pizza a alguien para que la cocine por nosotros en sus dependencias. Ejemplo: ECS, GKE, ACS.
• PaaS (Platform as a Service). Ordenamos una pizza para recojer, la pizzería la hace y cocina en sus dependencias. Ejemplo: Heroku, Google App Engine.
• FaaS (Functions as a Service). Vamos a la pizzería con amigos, pedimos pizza y tragos los que hace el restaurante y bar. O bien, subimos nuestro código, que se ejecuta en respuesta a un evento, por ejemplo: AWS Lambda, Azure Functions, etc.

Viendo los distintos modelos podemos entender que un enfoque FaaS busca “liberarnos” de la responsabilidad de provisionar o administrar servidores, y de esta forma enfocarnos en la lógica de nuestro producto o negocio. Para esto, nos ofrecen un servicio como la luz, gas o agua, el que pagamos en función de lo que consumimos.

Entonces, ¿qué hace que mi sistema sea Serverless?

Bueno, por un lado tenemos servicios de terceros y por otro tenemos el modelo FaaS. Amazon por su parte, define las siguientes características que debe tener un servicio o plataforma para considerarlo Serverless:

• **Sin administración de servidor. **No tenemos que provisionar o mantener servidores. Sin software o entornos de ejecución que instalar, mantener o administrar.
• Escalabilidad flexible. Nuestra aplicación escala de manera automática o ajustando las unidades de consumo (memoria, procesamiento) en lugar de hacer ajustes a los servidores.
• Alta disponibilidad. Las aplicaciones serverless tienen alta disponibilidad y tolerancia a fallos por defecto dada por la plataforma donde se ejecuta.
• Inactividad sin costo. No se paga lo que no se usa. No hay necesidad de sobre provisionar capacidad para anticipar altas cargas.

Consideraciones en el diseño e implementación de Serverless

Para crear aplicaciones con este paradigma, en nuestra experiencia, vemos algunos puntos a considerar:

• Incluir y manejar servicios de terceros. Estar familiarizados con servicios de terceros para hacer integraciones y tener una idea de los costos
• Escribir funciones de propósito único, manteniendo simpleza y bajo acoplamiento.
• Diseño basado en eventos.
• Ciudado con los coldstarts. Las partidas en frio son comunes en los servicios FaaS, como recomendación rápida para esto: utilizar lenguajes no compilados, evitar desplegar funciones en vpcs, mantener funciones pequeñas y utilizar una cantidad de memoria acorde a lo que realiza la función.
• No siempre es más barato ni recomendable una solución serverless. Es importante considerar los costos reales.
• Recomendamos la utilización de Serverless Framework.

Para el diseño de aplicaciones Serverless es importante considerar un cambio de enfoque a un modelo basado en eventos y con alta granularidad similar a microservicios sin estado y de propósito único. Además, el análisis de costos en una solución de este tipo es otro aspecto que no debemos pasar por alto.

Ventajas

En resumen, dentro de las ventajas relativas de una arquitectura serverless vemos lo siguiente:

• No requiere administración de servidores.
• Alta disponibilidad por defecto
• Tolerancia a fallos por defecto
• Solo se paga por lo que se usa.
• Mayor velocidad de desarrollo, mejora time to market.

Desventajas

• Alto grado de dependencia terceros. Cuidado con las nubes pegajosas.
• Relativa inmadurez del ecosistema.
• Dificultad para la evaluación real de costos.

Panorama General Plataformas y de Serverless

Actualmente, entre herramientas, frameworks y plataformas Serverless existe una gran cantidad de opciones. Entre las más conocidas (por mi), tenemos:

**Frameworks. **Herramientas que nos permiten estandarizar los desarrollos que realizamos para distintas plataformas FaaS.

• Serverless Framework
• AWS SAM

**Plataformas cloud. **Nos abstraemos complemetante de administrar la plataforma y pagamos solo lo que utilizamos por el servicio FaaS.

• AWS Lambda
• Azure Functions
• Google Cloud Functions
• Zeit
• Auth0 Webtask

**Plataformas Instalables. **Nos permiten administrar nuestra propia plataforma FaaS, la que maneja la infraestructura, servidores y escalamiento automático a través de contenedores docker y kubernetes principalmente. Estas plataformas las podemos montar on-premise o algun proveedor de servicios cloud como aws, azure, google, etc.

• OpenFaaS
• Apache Openwhisk
• Nuclio
• Fission

En otro artículo profundizaré sobre estas opciones y para más detalle se puede ver en https://landscape.cncf.io.