Bienvenido al mundo serverless, uno de los cambios de mentalidad más grandes de la nube. Hasta ahora siempre había un servidor de por medio: lo arrancabas, lo configurabas, lo escalabas, lo reparabas. Con AWS Lambda te olvidas de todo eso: solo escribes el código que quieres ejecutar, y AWS se encarga del resto. En este subcapítulo entenderás cómo funciona ese modelo.

Recordemos lo que has hecho hasta ahora con EC2 (Capítulo 4) y los Auto Scaling Groups (Capítulo 13): te preocupabas de servidores. Aunque AWS gestionara el hardware, tú tenías que pensar en cuántas instancias, qué tipo, cómo escalarlas, cómo repararlas.

Con Lambda, la unidad ya no es el servidor: es la función. Tú subes un trozo de código (una función), y AWS lo ejecuta cuando hace falta. No hay servidor que gestionar. De ahí el nombre «serverless» (sin servidor): no es que no haya servidores, es que no son tu problema; AWS los pone y los quita por ti, de forma invisible.

Aclaración importante: «serverless» no significa «sin servidores». Los servidores existen, pero están totalmente ocultos y gestionados por AWS. Tú no los ves, no los configuras y no pagas por tenerlos encendidos esperando.

El modelo de Lambda es sencillo de entender con una idea: tu código solo se ejecuta cuando ocurre algo, y solo durante el tiempo que tarda en hacer su trabajo.

Comparémoslo con un servidor tradicional:

• Un servidor EC2 está siempre encendido, esperando peticiones. Pagas por todo el tiempo que está encendido, aunque no llegue ninguna petición.
• Una función Lambda solo «existe» cuando hay trabajo. Si nadie la invoca, no se ejecuta y no pagas nada.

Analogía: un servidor es como tener un taxi con el motor encendido esperando todo el día en la puerta: pagas la gasolina aunque no vayas a ningún sitio. Lambda es como pedir un taxi por app: aparece justo cuando lo necesitas, te lleva, y solo pagas ese trayecto. El resto del tiempo, no pagas nada.

No hay sistema operativo que parchear, ni instancias que dimensionar, ni que reparar. AWS se encarga de todo el «por debajo». Tú solo te ocupas de tu código.

Si llega 1 petición, AWS ejecuta 1 función. Si llegan 1.000 a la vez, AWS ejecuta 1.000 funciones en paralelo, automáticamente. No configuras Auto Scaling Groups ni políticas (Capítulo 13): el escalado es inmediato y transparente, lo gestiona AWS.

Esta es la ventaja económica estrella. Pagas por el número de ejecuciones y por el tiempo que tarda cada una (en milisegundos). Si tu función no se ejecuta, no pagas nada. Esto puede abaratar enormemente las cargas de trabajo intermitentes o impredecibles.

Una función Lambda es, básicamente, una función en tu lenguaje favorito (Python, Node.js, Java, Go...) con una forma concreta: recibe un evento de entrada y devuelve una respuesta. Aquí un ejemplo simple en Python:

• event: los datos de entrada (qué desencadenó la función y con qué información).
• context: información sobre la ejecución (cuánto tiempo queda, identificadores...).
• Lo que return devuelve es la respuesta.

AWS llama a esta función cada vez que ocurre el evento que la dispara. No te preocupas de dónde se ejecuta ni de cuántas copias hay.

Lambda brilla en muchísimos escenarios, pero no es para todo:

Veremos los límites y antipatrones con detalle en el subcapítulo 14.5. Por ahora, quédate con la idea general.

• Lambda cambia la unidad de trabajo: del servidor a la función. Subes código y AWS lo ejecuta; no gestionas servidores.
• Serverless no significa «sin servidores», sino que los servidores son invisibles y gestionados por AWS: no son tu problema.
• El modelo es bajo demanda: tu código solo se ejecuta cuando ocurre un evento, y solo durante el tiempo que tarda. Si no se invoca, no se ejecuta.
• Tres ventajas: no gestionas servidores, escalado automático e instantáneo (1 o 1.000 ejecuciones en paralelo), y pagas solo por lo que usas (si no se ejecuta, no pagas).
• Una función recibe un evento de entrada y devuelve una respuesta; encaja en tareas cortas, tráfico intermitente y procesamiento de eventos.

En el siguiente subcapítulo veremos qué puede disparar una función Lambda: los triggers (API Gateway, S3, DynamoDB, SQS...).