AWS Serverless

Podríamos definir la computación sin servidor como un modelo de computación en la nube, cuya principal característica es, que el desarrollador de la aplicación ha de centrarse solamente en la lógica de negocio y no debe preocuparse por factores como:

Planificar la capacidad de computo
La configuración
La gestión
El mantenimiento
La tolerancia a fallos
El escalado de la infraestructura sobre la que se ejecuta dicha aplicación

Básicamente, se trata de delegar tareas al proveedor de la tecnología Serverless. En este caso al proveedor cloud, quien debe garantizar que el stack sobre el que se ejecuta nuestro código es óptimo, altamente disponible, tolerante a fallos, ofrece el mejor rendimiento posible y, muy importante, se factura por el tiempo que se ha estado usando, lográndose un verdadero pago por uso.

No olvidemos que, en el caso de máquinas virtuales en la nube, se factura cuando la máquina está levantada, independientemente de que el software que ejecuta esté recibiendo carga de trabajo o no.

Es importante tener en cuenta que serverless no hace referencia únicamente a computación, sino que también es aplicado a otra serie de servicios cloud en los que se aplica la misma filosofía, los denominados servicios cloud gestionados.

En el caso de Amazon Web Services, tenemos principalmente los siguientes:

Computación (AWS Lambda o AWS Fargate)
Almacenamiento (Amazon S3 o Amazon EFS)
Gestión de Datos (Amazon Aurora Serverless o Amazon DynamoDB)
Integración de Aplicaciones (Amazon API Gateway o Amazon SQS)

1 Pago por uso

Es la ventaja más inmediata, ya que si una carga de trabajo se ejecuta solamente durante un lapso de tiempo concreto (como puede ser: de actualización de datos, de carga en el datawarehouse o cualquier carga de trabajo periódica), solamente se nos facturará por el tiempo que hayamos utilizado el servicio.

Aparte del ahorro inmediato, hay un segundo ahorro derivado de la inexistencia de posibles costes, por errores de programación de encendido y apagado de los entornos, que muchas veces suponen un gran coste detectado solamente al recibir la factura mensual del proveedor.

3 Alta disponibilidad y tolerancia a fallos incluida

Si bien cuando desplegamos un aplicativo sobre un stack que nosotros gestionamos, tenemos que encargarnos también de velar por la alta disponibilidad y la tolerancia a fallos de la arquitectura desplegada (grupos de autoescalado, clústeres, configuraciones activo-pasivo, etc.), en caso de optar por tecnologías Serverless, esta parte suele estar resuelta por el proveedor cloud.

De nuevo, los costes asociados a desplegar servicios o metodologías que garanticen unos determinados SLA a nivel de disponibilidad y tolerancia a fallos se ven reducidos, y en muchos casos eliminados, al ser el proveedor cloud quien ha resuelto esa problemática.

4 Agilidad, rendimiento, escalabilidad y paralelización

La mayoría de los servicios Serverless que veremos en este blog tienen en común un objetivo primordial: hacer que la carga de trabajo se pueda ejecutar con el máximo rendimiento, el mínimo coste y la mayor paralelización, y al mismo tiempo ofrezca una escalabilidad que permita absorber los picos de trabajo más demandantes que podamos encontrarnos, todo ello sin penalización de rendimiento.

Por ejemplo, el servicio estrella dentro de la familia serveless de AWS, concretamente AWS Lambda, ofrece una concurrencia máxima de 1000 funciones lambda ejecutándose en paralelo, limite que podría aumentarse si fuese necesario.

Como vemos, no se trata de una máquina virtual que rinde bien hasta llegar al límite de 500 peticiones concurrentes y comienza a sufrir a partir de la petición número 501. Con AWS Lambda estamos hablando de que el rendimiento de la función 1 será igual a de la función 501, sin verse el uno influenciado o perjudicado por el otro.