Introduciendo a arquitecturas serverless

Ronald Neftali Berdúo Morales

Estudiante de Ingeniería en Ciencias y Sistemas - USAC

Palabras Clave:
Servicio, función, proveedor, servidor

Aunque el término Serverless traducido al español es “sin servidor”, en realidad una arquitectura Serverless se refiere específicamente a lo que es olvidarse de la gestión de servidores al momento de desplegar aplicaciones y servicios.[1]

¿Qué es Serverless? Es un término que se refiere a otros dos términos a la vez los cuales son Backend as a Service (BaaS) y Function as a Service (FaaS).[2]

Backend as a Service Es un término que lleva ya bastante tiempo de existir; el primer proveedor en lanzar este tipo de servicio fue Amazon con Amazon S3 lanzado en el año 2006 el cual provee un alojamiento de archivos en la nube. BaaS es muy similar a Software as a Service (SaaS) en donde los proveedores proporcionan servidores que son conectados a nuestras aplicaciones mediante una API, en general nos ofrecen componentes genéricos como almacenamiento, autenticación de usuarios, servicios de base de datos, entre otros. Generalmente estos servicios son utilizados para construir otros servicios más específicos, esto tiene una gran ventaja ya que como desarrollador puedo decir que no se pierde lo que es tiempo en construir aplicaciones o servicios que ya existen y sin preocuparse por mantenerlas. Hay muchas empresas que nos ofrecen este tipo de servicios entre ellas tenemos a Amazon con DynamoDB y Firebase de Google.

Function as a Service FaaS, nació en 2014 con la llegada de Amazon Lambda [3] ha sido el término que ha hecho popular a Serverless y lograr que aparezca. FaaS no es más que una nueva forma de ejecutar y diseñar aplicaciones con la cual se pueden reducir inversiones en infraestructura ya que solo se generan costes cuando se utiliza el servicio, algunos ejemplos de proveedores de FaaS son Amazon Lambda, Google Functions y Azure Functions [4].

¿Cuándo usar Serverless? Antes de entrar a detalle de cuando es correcto usar Serverless, veamos los siguientes beneficios [5]:

Beneficios - Como sé a dicho anteriormente una ventaja es no administrar los servidores.

  • No hay administración de infraestructura, el desarrollador no tiene ningún control sobre las instancias y contenedores, ya que los proveedores FaaS o BaaS se encargan de mantenerlos.

  • La escalabilidad automática, la capacidad aumenta y se distribuye automáticamente según se necesita esto es así para todos los servicios Serverless; los proveedores siempre tienen algún contrato donde exponen cual es la máxima capacidad que ellos proveen, aunque se puede llegar a dar el caso en donde se comunique con el proveedor para solicitar un aumento en las capacidades de nuestros servicios.

  • Arquitectura orientada a eventos, como por ejemplo responder a peticiones Http, a cambios en una base de datos, modificación de archivos, en la creación de un nuevo usuario en el sistema, o cualquier tipo de evento valido para que se disparen nuestras funciones.

  • No hay costos de contratación, ya que simplemente se paga por lo que se usa, si una función no se está ejecutando, esta función no llega a generar un costo.

Con los beneficios que nos otorga Serverless se puede decir que es conveniente usarlo cuando se tiene los siguientes casos:

  • Cuando necesitamos que una tarea corta se deba ejecutar con una frecuencia fija.

  • Si necesitamos trabajar con un modelo de integración y despliegue continuo.

  • Poder realizar microservicios ya que no necesitamos gestionar instancias.

  • Aplicaciones web que no requieran realizar procesos rigurosos.

¿Cuándo no usar Serverless? - Cuando no queremos depender de un proveedor, ya que estamos usando servicios sin haberlos creados nosotros mismos, esto limita a empresas que no quieren migrar a un servicio a la nube, para esto es recomendable realizar un análisis de riesgos para estar completamente convencidos si vale la pena o no utilizar estos servicios.

  • Cuando tenemos ejecuciones largas que no se pueden cortar o no se pueden paralelar, ya que servicios como Amazon Lambda solo nos provee un máximo de 5 minutos de tiempo de espera por cada función.

  • Para operaciones complejas, existen operaciones que necesitan infraestructura dedicada, muy específica para poder resolver ciertas tareas en un tiempo razonable ya que la infraestructura que nos provee la plataforma de la nube es muy genérica y no se puede realmente modificarla.

Un ejemplo sencillo Supongamos que tenemos una aplicación web en cual podemos subir imágenes y poder visualizarlas, también se tiene que administrar usuarios, y por último se tiene que interactuar con un servicio RESTful para poder obtener las imágenes y poder guardarlas. Para esto se describirán los servicios a utilizar para implementar esta aplicación en Amazon Web Services (AWS). La aplicación hará uso de AWS Lambda, Amazon API Gateway, Amazon S3, Amazon DynamoDB y Amazon Cognito, como se muestra en la imagen 1.[6]

Imagen 1: Ejemplo de una arquitectura sin servidor en AWS

S3 Como primer punto tenemos lo que es Amazon S3 que es un servicio de almacenamiento para internet, es decir es donde nosotros alojaremos nuestros archivos estáticos como HTML, CSS, JavaScript, imágenes o cualquier tipo de archivos que se puedan cargar en algún tipo de navegador.

Cognito Este servicio es muy útil ya que nos facilita en gran medida lo que es la autenticación, autorización y administración de usuarios para nuestras aplicaciones móviles y web.

DynamoDB Es un servicio de base de datos NoSQL en la cual para este ejemplo se guardará la información necesaria para guardar una imagen como por ejemplo el nombre del archivo y la ruta de S3 en donde se localizará la imagen.

Lambda En lambda se crean una función para almacenar una imagen en S3 y guardar la información en una tabla de DynamoDB, también se creará una función para obtener toda la información de las imágenes que se guardaron en DynamoDB.

API Gateway Y por último tenemos a quien dispare los eventos Http para poder invocar a las funciones creadas en Lambda para guardar una imagen y poder obtenerlas.

Conclusiones

  • Las arquitecturas Serverless han logrado evolucionar hasta ser una herramienta de gran utilidad para el despliegue de alguna funcionalidad a un ambiente de producción sin invertir en la infraestructura y pagando solamente cuando se ejecute.

  • Al utilizar Serverless se reducen los costos, se reduce el tiempo de desarrollo, se aumenta la seguridad y se incrementa la fiabilidad.

  • Serverless no es el enfoque correcto para cada problema, así que siempre se tiene que realizar un análisis antes de pasarse a trabajar con este tipo de arquitectura.

Referencias