Un Vistazo a la Arquitectura Serverless

Uno de los temas que hemos explorado durante los últimos meses en los distintos canales de Software Guru, es el de arquitectura serverless (sin servidor). Ya en el primer episodio del vlog Devotion lo comentamos de forma casual, y luego en el congreso SG Next tanto Verónica López como Obie Fernández nos platicaron al respecto con mayor detalle. Así que ahora es mi turno de compartir mi perspectiva sobre este modelo arquitectónico.

Lo primero que hay que aclarar es que, a pesar de lo que diga su nombre, en las arquitecturas serverless sí hay servidores. Y de hecho no es uno, sino muchos. La diferencia respecto a las aplicaciones tradicionales es que no hay un servidor maestro que controle el flujo de la aplicación, sino que los servidores simplemente hospedan servicios que atienden peticiones de forma atómica y no están conscientes del flujo de la aplicación, ya que éste se controla del lado del cliente. Dichos servicios pueden haber sido implementados por nosotros (en el caso de comportamiento específico a nuestra aplicación) o también podemos usar servicios proporcionados por terceros para resolver aspectos comunes tales como, autenticación de usuarios, almacenamiento, mensajería. Por último, los desarrolladores no tienen ninguna visibilidad a los servidores que hospedan los servicios, ya que estos son administrados por terceros. Así que los desarrolladores se pueden dedicar exclusivamente a implementar la funcionalidad de la aplicación sin tener que preocuparse por administrar servidores.

La figura 1 (es la misma que aparece en la cabecera de este artículo) brinda un panorama de este concepto.

Figura 1. Arquitectura serverless. Fuente: http://martinfowler.com [1]

Las aplicaciones serverless típicamente hacen uso extensivo de servicios terceros para cumplir tareas que no son centrales o específicas a la aplicación. Una aplicación puede utilizar una familia de servicios terceros de un mismo proveedor (ej. Firebase) o usar servicios de proveedor distintos, por ejemplo una aplicación podría usar Auth0 para la autenticación de usuarios, Azure Media Services para entregar video por streaming, y OneSignal para push notifications.

Una de las principales responsabilidades de una aplicación tradicional centrada en el servidor es controlar el ciclo de petición-respuesta. Los controladores en el servidor procesan las entradas, invocan el comportamiento correspondiente y construyen una respuesta dinámica usando un motor de plantillas (template engine). En contraste, en una aplicación serverless, donde el comportamiento se ensambla a partir de servicios, el control del flujo se hace del lado del cliente y el contenido se genera de forma dinámica en el cliente. Por ejemplo, las aplicaciones móviles, IoT e incluso las de smart TV utilizan frameworks de interfaz de usuario para generar contenido dinámico a partir de información obtenida por medio de llamadas a APIs remotas.

En las aplicaciones centradas en el servidor, la aplicación está compuesta por procesos que están continuamente activos y atendiendo peticiones. En contraste, en las aplicaciones serverless el ciclo de vida de los programas es mucho más corto, tendiendo a ser un solo ciclo petición/respuesta en HTTP. El programa se activa cuando recibe una petición, la procesa y en cuanto termina se apaga. Este tipo de programas típicamente están hospedados en un entorno como Amazon Lambda, Azure Function o Google Cloud Functions, que se encarga de gestionar el ciclo de vida y escalabilidad del programa. Este tipo de estructura se conoce como “Funciones como Servicio” (FaaS).

Ventajas y desventajas

Cualquier decisión de diseño arquitectónico involucra ventajas y desventajas.

Uno de los principales beneficios de la estrategia serverless es el ahorro en costo. En sistemas que tienen patrones de tráfico con picos repentinos, tener un servidor con grandes recursos continuamente disponible es costoso; en cambio, en el modelo FaaS se cobra por petición atendida. Otro componente de costo que te ahorras con serverless es el del personal y del esfuerzo requerido para administrar el servidor.

En cuanto a las desventajas, la primera sería la complejidad que se agrega al estructurar las aplicaciones de esta forma. También puede haber un impacto en el desempeño de la aplicación debido a la carga y latencia introducida al estar continuamente invocando servicios que no están inmediatamente disponibles.

Este artículo apenas ha sido un panorama general sobre serverless. Si te interesa conocer más al respecto, te recomiendo leer el artículo “Serverless Architectures” [2] de Mike Roberts.

Referencias:

1. B. Janakiranam. “Serverless”. http://swgu.ru/rs

2. M. Roberts. “Serverless Architectures”. http://swgu.ru/rr