¿Qué es Serverless? Una digerible pero extensa introducción a Serverless (con AWS)
Uno de los temas que encuentro que arrojan más complejidad a una conversación técnica es el término de “Serverless” o según AWS en su documentación en Español: Informática sin Servidor.
Y claro, en esta conversación de la que hablo, lo más probable es que una de las personas involucradas no está del todo familiarizadas con el término.
Y es que fuera de la complejidad o detalles técnicos que involucra, en este post buscaré explicar qué es Serverless tal cual y como me hubiera que alguien me lo hubiera explicado antes de empezar a trabajar con él, y que en mi caso muy personal se resume en no tener que pasar por la experiencia de tener que leer las 3,738 páginas de documentación de AWS, una serie de blog posts random encontrados en internet y el clásico video de YouTube que te deja con más preguntas que respuestas.
Cabe añadir, que tampoco es un tutorial de Serverless, pues como veremos más adelante a detalle, uno más bien consume servicios Serverless por ende un tutorial tendría que ser sobre un servicio en específico, así que mantengamos las expectativas claras: lo que se busca con esta entrada es que entiendas el concepto de Serverless para que puedas empezar a analizar opciones y adentrarte en este mundo.
También es importante mencionar que el texto está estructurado para que “lo cortes” de acuerdo a la información que necesitas, pues empezamos por entender la definición, ver y crear un servicio Serverless y conforme avanza el texto se aumenta la complejidad y lista de términos técnicos, por ende, cuando leas 2 párrafos y que ya no te hagan sentido es porque a lo mejor ya de ahí para adelante la información no es para ti (por el momento) asi que sientete en la libertad de cortar la lectura. No me agüito.
Pero no nos hagamos bolas sin haber empezado en esto…
¿Qué es Serverless?
Esta es la pregunta más básica que tienes al momento, pues
¿cómo podrás implementar algo de tu lado si no lo entiendes o no sabes qué hace?
Lo primero que creo que debemos de entender es que en este caso las definiciones que existen allá afuera no nos ayudan del todo, así que vamos viendo definiciones básicas de Serverless antes de que trate de explicarlo a mi manera.
La definición de Serverless de AWS¹
“Sin servidor se refiere a la arquitectura nativa de la nube, con la cual se le permite trasladar más responsabilidades operativas a AWS y se aumenta la agilidad y la innovación. Gracias a la informática sin servidor, puede crear y ejecutar aplicaciones y servicios sin tener que preocuparse por los servidores. Permite eliminar las tareas de administración de infraestructura, como el aprovisionamiento de servidores o clústeres, los parches, el mantenimiento del sistema operativo y la capacidad de aprovisionamiento. Puede crearlas para prácticamente cualquier tipo de aplicación o servicio de backend. Además, administra todo lo necesario para ejecutar y escalar la aplicación con alta disponibilidad”.
Ahora, hagamos un breakdown de este párrafo y quitemos la paja que trataron de usar para que hiciera algo de sentido todo ese parráfo.
Busquemos aislar las oraciones básicas que nos hacen sentido y que de cierta manera nos agregan valor o listan una posible definición
- Arquitectura nativa de la nube
- Trasladar más responsabilidades operativas a AWS
- Aumenta agilidad y la inovación
- Puede crear y ejecutar aplicaciones y servicios sin preocuparse por los servidores
- Permite eliminar las tareas de administración de infraestructura
- Para prácticamente cualquier tipo de aplicación o servicio de backend
- Administra todo lo necesario para ejecutar y escalar la aplicación con alta disponibilidad
Ahora, si lees esta oración de arriba, AWS te hablo de la nube, obviamente de AWS, servidores, infrastructura, backend, escalabilidad y alta disponibilidad, algo complicado llegar a una definición más sólida, por ende aplicaremos a nuestro desglose categorías de información por “responsabilidades”, oséase: para quién es cada oración de ese párrafo.
Cabe mencionar que nuestra guía para hacerlo será algo burda y acientífica pero nos funcionará, pues catalogaremos la información en una división basada en 3 temas: Información Técnica, de Proceso y Marketing.
Técnica.
Información que una persona técnica entenderá y que podría ser un dealbreaker de implementación, por ejemplo: ¿sólo soporta Node.js 10? Esto es información técnica y un posible dealbreaker para mis desarrollos hechos con Node.js 8.
Proceso.
Algo que habla de añadir pasos o hacer cosas diferentes al modo actual o que puede cambiar la forma de hacer cosas actuales en un sistema, pero sin llegar a ser completamente técnico, por ejemplo: ¿tengo que trabajar en la nube únicamente? Esto tendría que revisarlo dentro de mi proceso para primero que todo, ver si puedo almacenar información ahí (compliance) o incluso, ver la manera de que mi sistema tenga un proceso extra para mover información a la nube.
Marketing.
Cualquier frase que no no cuadre en lo técnico y en proceso pero que lo haga ver WOW. Ejemplo: es un único elemento para tu equipo de desarrollo que lo hará sobresalir. No aporta mucho, no dice mucho, no sabemos realmente qué es pero suena WOW.
Ahora hagamos el breakdown:
Entonces, con este breakdown podemos leer la parte técnica como:
Con una arquitectura nativa de la nube, serverless te sirve para cualquier tipo de aplicación o servicio de backend y está listo para ejecutar y escalar aplicaciones con alta disponibilidad.
Para aquellos enfocados en procesos:
Serverless te permitirá dentro de AWS eliminar aquellas tareas de administración de infrastructura.
Para las personas de marketing:
Con Serverless puedes crear y ejecutar aplicaciones y servicios sin preocuparse por los servidores para que aumentes la agilidad y la inovación de ellas.
Mi muy personal teoría es que AWS decidió encerrar a un arquitecto de soluciones con el ejecutivo de cuenta y con su recién nombrado Black Belt de Six Sigma y después de una borrachera de 12 horas lograron sacar un statement antes del deadline que tenían.
Porque, a pesar de que efectivamente trata de explicar algo, creo que cada que lo leo me hace menos sentido o siento que lo pudieron haber simplificado... Pero fuera de la crítica de estos docs, el término de Serverless es algo complejo de definir, pero la que más me ha gustado y me ha hecho más sentido de entre múltiples vendors es la que ofrece RedHat:
Serverless o informática sin servidor se refiere a un modelo de cloud computing en el que los desarrolladores de aplicaciones no tienen que implementar servidores ni gestionar la escalabilidad de sus aplicaciones. En su lugar, el proveedor de nube abstrae esas tareas rutinarias para que los desarrolladores puedan crear códigos para la producción más rápido que en los modelos tradicionales.
Creo que es un poco más digerible y sin tanto pitch de venta como el de AWS, pero sobre todo, nos habla de lo que es Serverless: un modelo de cloud computing.
Entendiendo Serverless
Si te fijas, una de las cosas claves que podemos deducir de todo el texto de arriba es que incluso entre vendors de Serverless se habla de diferentes definiciones, pues mientras que AWS dice que es “una arquitectura nativa de la nube” en RedHat hablamos de un “modelo de cloud computing”.
Y sólo por curiosidad, ¿Quieres saber que dice Google?:
Entonces, si no has entendido del todo Serverless a este momento no te apures, pues por si no te has dado cuenta tenemos algunos de los top 3 vendors de cloud computing y ninguno comparte siquiera como definir Serverless: para unos es una “plataforma” (Google), para otros es un “modelo” (RedHat) y para AWS es una “arquitectura”.
Entonces, con esta variante como se puede esperar que alguien que se está iniciando en Serverless pueda llegar a venderlo a alguien más o a su propio equipo de desarrollo? O peor aún ¿tener una discusión de implementación? (implementar ¿QUÉ? ¿exáctamante?)
Sea tu peer/colega, tu manager, tu cliente, no puedes llegar diciendo:
“Si mira, Pepe, necesitamos Serverless porque es un modelo/arquitectura/plataforma sin servidor y nos va a permitir crear y ejecutar aplicaciones y servicios sin preocuparse por los servidores”
Como te puedes imaginar, sabemos que ese no es exactamente el mejor pitch de venta para una tecnología...
Y la cosa a como yo lo entiendo y lo quiero explicar, es que debemos de dejar de lado el modelo/arquitectura/plataforma serverless, porque realmente tú no vas a trabajar con ella sino que la estarás utilizando como una base, por ende como debemos de tratar de entender este concepto es por medio de entender servicios basados en arquitecturas Serverless.
Un analogía que me vino a la mente en cuanto a esto es como actualmente usamos el término de memoria RAM en nuestro día a dia: sabemos que es necesaria para ejecutar programas de software y que estos se pueden beneficiar de un incremento o en su caso contrario, sufrir por falta de. Sin embargo, la mayoría de nosotros desconocemos como funciona realmente o sus inner workings.
Esto es algo similar a Serverless: no sirve de mucho saber como funciona a detalle o su core técnico, pero si sirve ver los beneficios de su implementación en una perspectiva más grande (así como ves y sientes los beneficios de un extra de RAM en tu laptop, pero no te preocupas por los detalles de cuantos pins tiene o que en una memoria DDR3 el mínimo de lectura o escritura en la unidad es a 8 bits por ciclo).
Ahora, antes de entrar en una parte más técnica cabe mencionar que dentro de la vasta gama de cloud vendors que existen vendiendo servicios Serverless, estaremos — como dije al principio — hablando de servicios de AWS, por ende usaremos su terminología y hablaremos de arquitecturas Serverless que tienen Servicios Serverless.
Y cabe hacer un énfasis especial en porque hablar con referencias de AWS, pues como ya viste el término, arquitectura y servicios en sí están presentes en Google Cloud, Red Hat, IBM Cloud, Alibaba Cloud, entre otros más.
Sin embargo, siendo que AWS domina el mercado de cloud computing, es estadísticamente más probable que tus inicios con Serverless sean precisamente con AWS. Sin embargo esto no quiere decir que sea superior o inferior a otros cloud vendors, pues realmente no tengo una comparativa técnica donde pudiera decir que AWS es mejor que otras, sino que sé que tiene mayor alcance en el mercado.
Y para empezar ahora si a entender Serverless, lo explicaré por medio de uno de los servicios Serverless más usados de AWS: Lambda.
Parte 1: Entendiendo Serverless con AWS Lambda
Nuevamente: hablaremos de un servicio basado en arquitectura Serverless para entender el concepto de Serverless.
Habiendo repetido esto, lo primero que haremos es definir que es Lambda: lo cual es un FaaS (Function as a Service) y el cual está basado en una arquitectura (o inserta tu definición propia de acuerdo a tu cloud vendor) Serverless.
Esto quiere decir que tendrás una función de código capaz de ejecutarse sin que te preocupes por su arquitectura o servidores, o incluso tener una aplicación de por medio.
Básicamente, esto es un Lamba:
Este snippet de código que incluyo es lo que verás cuando tu creas una Lambda en AWS bajo Node.js 12, y que como puedes ver es una sencilla función en Javascript que utiliza async/await y que regresa un JSON con un status code y un string.
No tiene nada de complicado ¿verdad? e independientemente del lenguaje de programación que escojas para tu Lambda (porque como veremos tiene una lista predefinida) tu verás una función así de básica en el lenguaje de programación de tu elección.
Pero tiempo de empezar a darle al lado técnico de un servicio Serverless, crearemos un Lambda dentro de la cuenta de AWS (aquí puedes ver como crear una cuenta) y esta es la pantalla de creación que debes de estar viendo:
En el ejemplo de arriba ya estoy seleccionando Node.js 12x y es que en su versión más simple, el crear un AWS Lambda solo te pregunta nombre y lenguaje de programación a usar y una vez que tengas estos dos listos ya la puedes crear.
Una vez creado, verás algo como la siguiente pantalla:
Ahora, aquí es necesario hacer pausar el código y lado técnico pues aquí ya se puede ver el poder que te da un Lambda, nuevamente, construida sobre en una arquitectura Serverless:
En menos de 1 minuto creamos un Lambda, sin necesidad de setupear el ambiente³: no estamos pensando en la versión del OS, ni abrir puertos, ni agregar scripts para monitorear el servidor, ni setupear las librerías adicionales que necesitas (por ejemplo, no hubo necesidad de instalar npm para poder tener Node.js), mucho menos hubo necesidad de crear una aplicación o incluso preguntarse que estructura de folders seguiremos, etc.
Esto es lo que realmente nos ofrece el servicio de AWS Lambda cuando dice que es Serverless: no preocuparnos por un servidor (caray, ni siquiera saber como está configurado o saber si es compartido o incluso tu bandwidth limit, etc).
En AWS Lambda todo ya está listo para que tu únicamente agregues tu código y te enfoques en el.
Ahora, regresemos a nuestra pantalla de Lambda: si presionas el botón de arriba a la derecha de “Test” y pones cualquier valor en el JSON que te pide, ya estará regresando la función un resultado, tal cual lo ves en el video:
¿Esto que quiere decir? que ya tenemos una función serverless funcionando y disponible para utilizarse.
Ahora, este fue el “sales pitch” introductorio a Serverless: que tu podrás crear un servicio donde no existe un servidor per se, tu nunca podrás hacer un netstat o un ls -l o saber si es un servidor compartido o no o incluso saber como tu servicio está consumiendo memoria de más con un comando top.
Pero uno de los “sales pitch” que sí te debes de enterar es precisamente algo que nos dijeron ellos mismos en su definición inicial pero que a lo mejor no tomaste mucho en cuenta:
Listo para ejecutar y escalar la aplicación con alta disponibilidad
Lo primero ya vimos que si es cierto: con menos de 5 clics ya generamos una Lambda y lo pudimos utilizar pero ¿qué significa escalar la aplicación con alta disponibilidad en AWS Lambda? lo cual nos lleva a nuestro siguiente tema: escalar la aplicación con alta disponibilidad en AWS Lambda.
Escalar la aplicación con alta disponibilidad en AWS Lambda
Lo de repetir el texto múltiples veces fue a propósito porque esto es uno de los temas que más me interesan y que personalmente me gusta contar de serverless en AWS; esto creo que realmente es una cereza del pastel pues a lo mejor tu te enfocaste en lo fácil que es ya tener un Lambda y empezar a trabajar con él, pero podemos ver esto de la alta disponibilidad y escalabidad como un added bonus que no pediste, pero que es muy bueno de tener.
Aunque - siendo honesto - esto es algo que puede o no interesarte según tus habilidades actuales pues si estás empezando a programar y sólamente quieres darte una idea de como funciona serverless esta información será secundaria propablemente, sin embargo si eres un arquitecto de soluciones o un developer interesado en escalabilidad o que está trabajando en sitios web con high load/traffic o con sistemas que tienen bursts o picos de usage, a lo mejor esto te va a interesar bastante.
La información queda relegada un poco dentro de las preguntas más frecuentes para Lambda y ahí vas a encontrar un pequeño párrafo con esta información:
AWS Lambda está diseñado para hacer uso de la replicación y la redundancia a fin de ofrecer una disponibilidad excelente al servicio y a las funciones de Lambda que opera. No hay periodos de mantenimiento ni tiempos de inactividad programados para ninguno de los dos ⁴.
Traducción de la 1era parte del párrafo:
Tendrás alta disponibilidad de tu Lambda que en resumen se traduce en esto (datos de Abril 2019):
- 3000 — US West (Oregon), US East (N. Virginia), Europe (Ireland)
- 1000 — Asia Pacific (Tokyo), Europe (Frankfurt)
- 500 — Other Regions
Esto quiere decir que al crear una Lambda en la región de us-west-1 (Oregon) tendrás 3,000 llamadas concurrentes a tu lambda, ahora, esto puede ser mucho o poco dependiendo de tu sistema pero aquí lo impresionante es que TÚ no te tienes que preocupar por hacer esta arquitectura o pedirle, esto es algo que AWS Lambda ya te está dando out of the box dentro de tu arquitectura Serverless.
Si lo vas a usar: genial, si no, que bueno, pero ya está aunque no lo quieras.
Y ahora, te podrás estar preguntando ¿y qué pasa si llego a la llamada #3,001 en mi sistema? ¿se cae todo mi sistema serverless como casa de cerdito de paja a la cual le sopló un lobo? ¿Jeff Bezos me cobra 3 millones de USD por pasarme del límite?
Pues no… porque OTRA de las funcionalidades que te incluye AWS Lambda por default es throttling, oséase, que cuando llegues a ese límite de llamadas y tu sistema haga otra petición, AWS te lanzará un status de que no está disponible, así tu sistema podrá tener una estrategia diferente pero sin llegar a un error crítico o tener que hipotecar tu casa para poder pagar el servicio extra. En propias palabras de AWS:
Si excede la limitación, las funciones de AWS Lambda invocadas de manera sincrónica mostrarán un error de limitación controlada (código de error 429). Las funciones de Lambda invocadas de manera asíncrona pueden absorber picos de tráfico razonables durante unos 15–30 minutos, tras los cuales se rechazarán los eventos entrantes por motivos de limitación⁵
Ahora, para aquellos devs o ingenieros de software con experiencia y que están entendiendo el párrafo, saben que implementar throttling no es algo que suele salir como feature #1 del sistema, pues eso equivale a un sistema que empieza a experimentar un high load es capaz de sostenerse, definir un limite máximo de capacidad del propio sistema, no caerse, y empezar a limitar a los usuarios del sistema para mantenerse vivo. En mi experiencia este es un feature que se añade una vez realizado el desarrollo base y en subsecuentes iteraciones, pero que en este caso AWS lo hace por ti, pues, nuevamente, aunque no lo quieras este ya es un feature out of the box.
Ahora, regresemos a la traducción de la 2da parte del parráfo:
“No hay periodos de mantenimiento ni tiempos de inactividad programados para ninguno de los dos” ⁵
¿conoces a ese SysAdmin o DevOps que planea downtimes a cierta hora para aplicar un parche o un update en el OS o una librería en específico que tiene una vulnerabilidad y que manda un correo a un cientos de personas para avisar? Pues eso ya no existe… AWS Lambda te garantiza estar disponible siempre, lo cual es otro de los excelentes puntos de venta para utilizar un servicio Serverless: pues al pasar la responsabilidad a un 3rd party tu dejas el mantenimiento y disponibilidad a alguien más.
Y solo para recapitular, en menos de 5 minutos eres capaz de montar una función de Lambda (FaaS) bajo una arquitectura Serverless (que por cierto, no existen FaaS que NO sean Serverless, pero lo menciono para enfatizar el tema) y así poder estar enfocándote en código.
Y a veces es muy fácil entender Serverless e ignorar que hubiera pasado si pensabamos crear una función “a la antigüita” hubieramos tenido que:
- Buscar los requerimientos que necesitamos de memoria, CPU, bandwidth, etc para nuestro server.
- Buscar la región adecuada para él
- Buscar un vendor disponible (o peor aún, pensar en un servidor físico)
- Planear que OS vamos a instalar
- Instalar librerías necesarias para ese OS y nuestro lenguaje de programación (de ser requeridas)
- Instalar NPM
- Instalar Node.js 12.x
- Configurar el package.json
- Correr nuestra aplicación con “npm run”
- Agregar un servicio de monitoreo para nuestra aplicación
- Agregar un servicio de monitoreo para nuestro servidor
- Tener cookbooks, recipes, books, lo que quieras para que nuestro servidor pueda recibir mantenimiento y actualizaciones
- Desarrollar un API o sistema capaz de obtener y procesar un evento
- Implementar sistema de throttling
- Etcétera…
Esta es el poder que te da Serverless: el evitarte una larga lista de tareas que según tu contexto pueden ser más o menos que las de arriba, y que incluso te pueden dar o no sentido, pero que independientemente de si las necesitabas o pedías, al pasar la infrastructura y arquitectura a AWS tu eliminas múltiples tareas y responsabilidades de tu lado.
Ahora, podríamos seguir hablando de AWS Lambda y sus múltiples funcionalidades y especificaciones, pero la realidad es que AWS Lambda es un tema propio y preferible para su propio blog post (deja un comentario si te interesaría leer sobre esto).
Pero más que seguir vendiendo el servicio Serverless, me gustaría cerrar con un tema que encontré que generaba confusión en personas que apenas están entendiendo AWS Lambda:
En este momento de seguro piensas “genial, entonces puedo utilizar todo este servicio serverless y conectarlo como un endpoint de mi aplicación y…”.
Y pues si, pero no…
Para iniciarte en Lambda necesitas pensar en una architectura serverless basada en eventos (aquí unas referencias de Red Hat, AWS y O’Reilly)…
Y a través de estos eventos (que puede ser una llamada a una API, un mensaje en un queue, un trigger de un CloudWatch Event, etc) podrás llegar a ejecutar poder ejecutar tu función de Lambda.
Después, lo segundo que debes de entender es que AWS Lambda es identificada o llamada por medio de un ARN (Amazon Resource Name), pero este a su vez no es accesible por nada fuera de la red de AWS por lo cual tendrás que tener un AWS Gateway (API), un AWS SQS (queue), un AWS Step Functions (Serverless Workflow), un Amazon DynamoDB Stream (DB) o un evento AWS S3 (por solo listar algunos de los servicios que pueden llamar un Lambda) para poder llamarla y ejecutarla, y lo cual te abrirá la puerta a la integración de aún más servicios de AWS (VPCs, AWS Secrets Manager, AWS Lambda Layers, CloudWatch, etc).
Por ende, mi recomendación personal al usar AWS Lambda (o en realidad, cualquier producto Serverless dentro de AWS) es no pensar en funciones serverless aisladas, sino en arquitecturas y/o aplicaciones serverless.
Entendiendo Serverless con AWS Fargate
Una de las cosas que más me molestan de algunos tutoriales es el happy path que hacen con sus explicaciones, pues toman en cuenta un contenido muy limitado. Y como bien dije desde el principio, esta es una larga introducción al concepto de Serverless, pues a mi forma de ver es mejor explorar un tema desde diferentes puntos de vista y es por esto que selecciono otro servicio de AWS para entender el concepto de Serverless: AWS Fargate.
AWS Fargate es un servicio denominado por AWS como “Cómputo sin servidor para contenedores” y que se resume como lo siguiente:
“AWS Fargate es un motor informático sin servidor que funciona tanto con Amazon Elastic Container Service (ECS) como con Amazon Elastic Kubernetes Service (EKS). Fargate le permite centrarse en la creación de sus aplicaciones. Fargate elimina la necesidad de aprovisionar y administrar servidores, le permite especificar y pagar recursos por aplicación y mejora la seguridad mediante el aislamiento de aplicaciones por diseño.”
En la sección de AWS Lambda ya viste como se desglosó (acientíficamente) la información técnica, de proceso y de marketing, así que te sugiero lo hagas de tu lado para poder darle un poco de sentido del párrafo.
Ahora, ECS involucra muchos más conceptos que AWS Lambda y a los cuales no entraré a detalle, pero que a lo mejor si harán sentido a alguien que ha trabajado con Docker o Kubernetes, pero no bajo una arquitectura Serverless.
Ahora, esta sección la vamos a trabajar con Amazon Elastic Container Service (Amazon ECS) usando Fargate, pues digamos que el usar Fargate es lo “Serverless” del servicio (de otra manera estás usando instancias de EC2 que tu administras lo cual como ya sabemos no tiene nada de Serverless si es que tu lo vas a tener que hacer).
Brevemente, tratare de explicar como funciona el lado técnico para poder beneficiarse del servicio de Fargate:
- Desarrollamos una aplicación dentro bajo un contenedor (Docker)
- Exportamos la aplicación a una Docker image
- Ligamos la imagen a a un Fargate Task
- El Fargate Task está en un Servicio
- El Fargate Service está en un Cluster
- El Cluster es Serverless
Oséase, tu crearás tu aplicación y lo lanzaráss a AWS que se encargará de provisionarlo, mantenerlo en línea y monitoreandolo.
Básicamente, lo único que hiciste fue crear tu docker image con tus especificaciones y decirle a AWS por medio de Tasks, Services y Clusters, donde está y como debe de ejecutarse ese docker image.
En esta excelente diagrama de AWS podemos entender mejor QUE parte se abstrae exactamente y que responsabilidades te quita.
Ahora, aquí a lo mejor te estarás preguntando:
¿Qué beneficio puedo sacar de Serverless cuando tengo que crear mi propio Docker container y setupearlo para mi aplicación? ¿Qué eso no es preocuparme de un servidor (box) en sí?
Ahora, aquí es donde yo puedo discutir con AWS y decir que Serverless NO es una arquitectura, sino que es más bien un modelo…
En la sección de AWS Lambda vimos como Serverless para FaaS te quita de las manos y de tu responsabilidad el crear un sinfín de cosas relacionadas a la infrastructura y arquitectura de la aplicación, sin embargo en Fargate, el término Serverless no entrá del lado de la aplicación y arquitectura de ella, entra del lado de la infrastructura, pues lo que está haciendo es abstraer el “servidor” que maneja, monitorea y deployea los contenedores que — valga la redundancia — contienen tu aplicación.
Si esta definición aun no te queda del todo clara, creo que antes es necesario una explicación que compara el modelo de deployeo y manejo de contenedores vs un modelo tradicional, y en la documentación de Kubernetes acerca de la evolución de los contenedores puedes encontrar una excelente respuesta (por cierto, ligo a la documentación en inglés porque es más extensa que la que está en Español).
Y nota, no estoy diciendo que aprendas Kubernetes para Fargate, sino que tomes nota de la parte donde explica el sistema de deployeo a través de la historia, pero sobre todo me interesa explicar esta imagen:
Aquí puedes ver que los contenedores están sobre el Runtime, el OS y el hardware, y esto es exactamente lo que Fargate está abstrayendo para nosotros cuando le pedimos que solamente maneje nuestros contenedores y le definimos algunas opciones del runtime. Sin embargo, el setup y configuracion de nuestros contenedores (versión de Node.js, de npm, puertos que se abre, por ejemplo, recae de nuestro lado).
Según la imagen de arriba, podríamos decirle el Cluster a los 3 containers que corren sobre el runtime (servicios / tasks) de Fargate, y fuera de eso ya entra la parte Serveless pues no sabemos nada de que tipo de sistema operativo tiene o incluso de los detalles operativos de Fargate en sí, pues fuera de setear algunos parametros de configuración para tu aplicación (memoria, cuantos servicios necesitas en tu cluster, variable de ambiente para tus contenedores, etc) todo lo demás queda manejado en modo Serverless por AWS.
Y ahora, no entré en tanto detalle con Fargate como lo hice con AWS Lambda, pero si AWS Lambda requiere su propio blog post, créeme que Fargate requiere 5 más (déjame dicho en los comentarios si te interesa este blog post y lo puedo trabajar), por ende terminaremos diciendo que Serverless incluso entre servicios de AWS tiene la misma definición (te quitan las responsabilidades de un servidor) pero incluso entre servicios pueden existir diferencias del nivel de abstracción y arquitectura.
Conclusión
Espero esta extensa introducción a Serverless por medio de AWS te quite un poco la complejidad de los docs de AWS y que te deje con una idea básica de qué es Serverless para continuar a explorar y desarrollar de tu lado, así como entender ya en términos de desarrollo los pros y cons que te puede ofrecer el usar Serverless como arquitectura/modelo/plataforma/you-name-it⁶.
Y porque ya entendiste que Serverless como tal, lo encontrarás definido y listado de diferentes maneras, sin embargo lo importante es que entiendas la parte de tu servicio que se va a abstraer y que responsabilidades te quitarán, así como el potencial beneficio que obtienes de hacerlo.
Una vez que evalues las ofertas de servicios Serverless bajo esta perspectiva podrás tomar ya desiciones correctas para tus necesidades específicas y tu desarrollo.
Por último, si te interesa que incluya algún otro servicio para explicar serverless o alguna parte no te quedo clara, dejame dicho en los comentarios.
Y ahora si que como por parafrasear al buen Don Vicente Fernandez: mientras Uds no dejen de aplaudir, yo seguiré escribiendo.
¹ Información obtenida de AWS el 13 de Abril de 2020
² Para los experimentados con aplicaciones serverless en AWS seguro estarán frunciendo la ceja en este comentario, pues en algún momento si tienes que crear un pipeline de CI/CD para tu aplicación. Sin embargo, este post busca ilustrar Serverless como definición, no replicar la inmensa documentación que tiene AWS donde ves todo y nada a la vez.
⁴ Existe la opción donde si lo puedes hacer por medio de custom runtimes pero incluirlo en el texto lo consideré como agregar bastante complejidad a un tema que está adentrándose en múltiples tecnologías. Al final, espero que si a alguien le intereso el tema de Serverless y Lambda pueda investigar más en su propio tiempo y no esperar que este post explique todo.
⁵ Informacion obtenida de AWS el 22 de Abril, 2020
⁶ Y solo como una pequeña nota al final y para añadir un poco más de confusión al tema de como llamar esto, existe un framework llamado Serverless para crear y administrar servicios Serverless basados en arquitectura/modelo/plataforma Serverless, pero no nos adelantemos, aún estamos definiendo que carajos es el primer Serverless
