Qué es serverless y por qué adoptarlo en el desarrollo de tu próxima aplicación

Aunque a día de hoy existen multitud de proveedores de computación que siguen basando su negocio en la provisión de infraestructura como servicio (IaaS), existe un claro objetivo perseguido por los líderes del sector: Convertir la computación en algo transparente.

A lo largo de los siguientes apartados definiremos qué es serverless, sus características, ventajas e inconvientes, junto a algunos ejemplos de uso.

Historia

Parece que los primeros usos del término aparecieron allá por el 2012 en un artículo de Ken Fromm. En un inicio, se asoció este tipo de enfoque sobretodo al uso de sistemas de integración continua y control de versiones como servicio, sin la necesidad de ser provisionados _on-premises_.

Posteriormente, el término se hizo más popular hacia el 2015, ya que en 2014 _Amazon_ lanzó su servicio AWS lambda que nos permitía desplegar porciones de código sin tener que hacernos cargo de la infraestructra subyacente. El interés en esta tecnología era claro y continuó creciendo cuando en Julio de 2015 _Amazon_ lanzó su API Gateway, que permitía además realizar peticiones HTTP sobre estas funciones desplegadas.

A partir de ese momento, podemos encontrar un sin fin de materiales y ejemplos de su evolución, tales como este artículo de 2015 sobre el futuro de los servidores Servers are dead... o casos reales de migración a _serverless_ en las re:Invent de Amazon PlayOn! Sports: The Serverless Company using AWS Lambda, que culminaron con la consagración a finales de 2015 de Serverless Framework como herramienta de referencia a partir del proyecto de código abierto _Javascript Amazon Web Services (JAWS)_.

Finalmente y tras la aparición en 2016 de la Serverless Conf, nada ha vuelto a ser igual en el mundo de la computación en el cloud :)

Definición

En general, el término _serverless_ se emplea para referirse al modelo de computación según el cual el proveedor de la capa de computación nos permite ejecutar durante un periodo de tiempo determinado porciones de código denominadas "funciones" sin necesidad de hacernos cargo de la infraestructura subyacente que se provisiona para dar el servicio. En este modelo, el proveedor se encarga de ofrecer los recursos de forma transparente, de escalarlos automáticamente si crece la demanda y de liberarlos cuando no son utilizados, definiendo una serie de restricciones referentes al procesamiento y un modelo de pago por el consumo de los recursos derivados de la ejecución.

No debemos confundir el modelo _serverless_ con otros existentes en el cloud y que, de una forma u otra, han permitido su misma evolución:

• IaaS. Infraestructura como servicio (Digital Ocean, OVH o AWS Lightsail). Basado en la provisión de máquinas virtuales donde, después de instalar y configurar el sistema operativo, podemos desplegar y ejecutar nuestras aplicaciones tras instalar el runtime necesario. La unidad de despliegue es el servidor virtual o la máquina virtual.
• CaaS. Contenedores como servicio (Google Cloud Engine, AWS EC2 Container Service o Microsoft Azure Container Service). Nuestra unidad de trabajo mínima es el contenedor docker que desplegamos en el servicio del proveedor. La unidad de despliegue es el contenedor.
• PaaS. Plataforma como servicio (Google App Engine, AWS Beanstalk o RedHat OpenShift). Su característica principal es la capacidad que ofrece de desplegar en el Cloud aplicaciones que utilizan lenguajes de programación, bibliotecas, servicios y herramientas soportadas por el proveedor. El cliente pues, no gestiona ni controla la infraestructura subyacente, incluyendo la red, los servidores, los sistemas operativos o el almacenamiento, sino que tiene control sobre las aplicaciones desplegadas y, posiblemente, sobre los ajustes de configuración del entorno de alojamiento de aplicaciones. La unidad de despliegue es la aplicación.
• BaaS o MBaaS. Backend as a Service o Mobile Backend as a Service (Parse, Firebase, Auth0 o AWS Cognito). Modelo en el que podemos integrar nuestra aplicación con backends de distinto tipo disponibles en el Cloud y que nos ofrecen un servicio especializado que podemos consumir como si de un API tradicional se tratara. Algunas de las características que me pueden proporcionar pueden ser: Gestión de usuarios, notificaciones push, integración de servicios de redes sociales, etc.

Serverless va de centrarnos en qué es lo que realmente ofrece valor a nuestros usuarios: El modelo de dominio de nuestra aplicación y no los servidores en los que se ejecuta

Así pues, ¿Que hace serverless una aplicación?:

• Cero administración de la infraestructura.
• Auto-escalado.
• Pago por uso.
• Reducción del time-to-market.

En base a las características enunciadas para los distintos tipos de modelos de servicio, podemos ver como en _FaaS_ la lógica es desarrollada dentro de un flow de trabajo clásico, pero al contrario que sucede en las arquitecturas más tradicionales, automáticamente es desplegada en procesos sin estado que son capaces de responder a distintos eventos que se produzcan en la infraestructura, su tiempo de vida es limitado (mientras la función esté "caliente" o disponible) y completamente gestionada por el proveedor.

Soluciones disponibles

Actualmente, AWS Lambda es una de las implementaciones más populares de _FaaS_ (Function as a Service) que podemos encontrar y una de las que ofrece un nivel de innovación mayor. En cualquier caso, los distintos proveedores están evolucionando cada vez más rápido sus soluciones, consolidándose como serias alternativas:

• Google Cloud Functions.
• Azure Functions.
• IBM Apache OpenWhisk Function.
• Alibaba Cloud Function Compute.
• Auth0 Webtask.
• Spotinst Functions.

También disponemos de otras opciones que nos permiten abstraernos del uso del proveedor, las cuales nos ofrecen herramientas de despliegue agnósticas a la infraestructura utilizada:

• Zeit. _The Global Serverless Platform_. Ofrece tanto el modelo de despliegue abstracto, como una infraestructura disponible montada sobre AWS, Google Cloud y Azure.

Soluciones _open source_ _on-promises_ o desplegadas sobre máquinas virtuales o servicios de Kubernetes gestionados:

• OpenFass.
• Fission.
• Kubeless.

Por supuesto, no debemos olvidarnos de la existencia de interesantes frameworks de abstracción que nos permiten desarrollar soluciones agnósticas del proveedor elegido:

• Serverless Framework. _The most widely-adopted toolkit for building serverless applications_.
• Pulumi. _Cloud native programming model for serverless applications_. Centrado en ofrecernos un framework de abstracción sobre los distintos servicios Cloud.

Finalmente, uno de los aspectos más sorprendentes de esta tendencia _serverless_ que estamos viviendo es la llegada de este concepto a servicios tradicionalmente estáticos y monolíticos como son las bases de datos. En el AWS re:Invent de 2017 pudimos asistir al nacimiento de una nueva generación de servicios relacionales que son capaces de crecer bajo demanda, permitiendo el uso infrecuente o la cobertura de los flujos de carga inesperados. Con RDS Aurora _serverless_, este esquema de servicio es ahora posible.

Serverless Framework

Serverless Framework nos provee de una capa de abstracción sobre los servicios de AWS en general y sobre AWS lambda en particular. Mediante su fichero yaml de configuración podremos describir el despliegue a realizar incluyendo las funciones lambda a crear, sus permisos de acceso y cómo van a interactuar con el resto de servicios del cloud de AWS como son API Gateway, S3, CloudFront, Route53, DynamoDB, etc.

Principales características de Serverless Framework:

• Agnóstico del proveedor cloud empleado. Soportando tanto AWS, como Google y Azure.
• Orientado a componentes. Enfocado a construir integraciones con distintos elementos de la infraestructura y poderlas reutilizar de forma sencilla.
• Infraestructura como código. Define y despliega un conjunto de funciones y su interacción en una única operación atómica contextual al entorno o contexto seleccionado.
• Developer friendly. Centrado en la experiencia del desarrollador para maximizar su productividad.

NOTA: Es requisito mínimo tener una cuenta en AWS y haber configurado el AWS cli junto a la _access key_ y _secret key_ de un usuario activo.

Para comenzar a trabajar con _Serverless Framework_, lo primero es instalar su dependencia globalmente a través de _NPM_:

$ npm install serverless -g

Una vez instalado, vamos a crear nuestro primer proyecto con el único objetivo de profundizar un poco más en el flujo de trabajo habitual con este framework.

Para ello vamos a ejecutar el comando serverless para generar un boilerplate que nos sirva de base para comenzar a definir nuestro proyecto. Como Serverless Framework nos permite definir funciones lambda implementadas en múltiples lenguajes, será necesario indicarle el lenguaje de trabajo (javascript en este caso) y el nombre del proyecto:

$ serverless create --template aws-nodejs --name first-project --path first-project

Para este primer proyecto vamos a crear una función invocable por HTTP mediante _API Gateway_ que devolverá "Hello world!!". Lo se, un clásico es un clásico :)

Para ello deberemos configurar el yaml principal de _Serverless Framework_ con la información básica de la función a ejecutar. Como puedes observar más abajo en el fichero de configuración yaml, tenemos disponible un apartado functions donde podremos definir todas las funciones lambda que queramos invocar, así como la descripción de cómo realizar esta invocación.

En el caso de nuestro primer endpoint, vamos a hacer que se ejecute el saludo al recibir una petición GET a la URL / del servicio generado, de forma que el código a ejecutar cuando esta situación se produzca se definirá en el fichero handler.js, dentro de la función exportada como get:

service: first-project

provider:
  name: aws
  runtime: nodejs8.10
  region: eu-west-1
  stage: dev

functions:
  first-project:
    handler: handler.get
    events:
      - http:
          path: /
          method: get

Con estas condiciones, ya sólo nos queda implementar la función get, la cual devolverá un status 200 y la respuesta esperada:

module.exports.get = async event => {
  return {
    statusCode: 200,
    body: "Hello world!!"
  };
};

A continuación, desplegaremos el proyecto y todas sus funciones asociadas son el comando deploy:

$ serverless deploy

Y finalmente invocaremos por HTTP la función definida:

$ curl https:///dev/
Hello world!!

Saludo completado!!

Si queremos, podemos verificar además que la función ha sido invocada examinando los logs que se han generado tras su ejecución ejecutando el comando:

$ serverless logs -f first-project

Nota: Si queremos eliminar cualquier rastro del proyecto desplegado, sólo tendremos que lanzar el comando remove de serverless que limpiará todos los puntos de la infraestructura afectados por el despliegue:

$ serverless remove

Por supuesto, hay muchísimas cosas que hacer todavía para que esta función sea _production ready_ (seguridad, logs, dominio propio, etc), pero como podéis ver es un inicio muy sencillo y prometedor, que ya nos da una idea del flujo completo de trabajo, cómo gestionaremos el código del proyecto y cómo acabaremos desplegando e invocando el resultado de nuestro trabajo.

Conclusiones

El cambio de paradigma y la promesa de un cloud transparente y productivo ya han llegado con servicios como AWS lambda y frameworks como Serverless Framework. No tengas ninguna duda, están aquí para quedarse y se han convertido en una posiblidad real y lista para producción que no podemos obviar. ¿Vas a perder el tren de _serverless_? Seguro que no :)