Toda comparación entre serverless y arquitectura cloud tradicional empieza igual: serverless se ejecuta bajo demanda y pagas por lo que usas. Es verdad, y es lo menos interesante.

Lo que solo se aprende construyendo es una consecuencia. Con serverless no decides si escalas horizontalmente. Siempre lo haces. Y para escalar horizontalmente, tu aplicación tiene que ser stateless.

El escalado horizontal viene incluido

En una arquitectura tradicional empiezas con un servidor. Atiende todas las peticiones, así que puede recordar cosas entre una y otra. Escalar es una decisión posterior: primero una máquina más grande, después una segunda cuando toque.

En serverless la plataforma crea una instancia cuando llegan peticiones y la descarta cuando paran. Dos peticiones del mismo usuario pueden correr en dos instancias distintas, y la siguiente puede caer en una tercera que un segundo antes no existía. Nunca elegiste correr muchas copias. Así funciona el modelo.

Stateless es el precio

Si cualquier instancia puede atender cualquier petición, ninguna puede ser la que recuerda. Lo que vive en la memoria o el disco de una instancia es una apuesta a que la siguiente petición caiga en la misma, y tarde o temprano no cae.

En la práctica esto saca varias cosas del proceso:

  • Sesiones. Una sesión en memoria desaparece. Pasa a un almacén compartido, o a una cookie firmada que lleva el cliente.
  • Archivos subidos. Escribir en el disco local pierde el archivo. Va a almacenamiento de objetos.
  • Cachés. Una caché en memoria es una caché por instancia, cada una con contenido distinto. Una caché compartida lo arregla.
  • Tareas programadas. Un temporizador dentro del proceso muere con el proceso. Un planificador externo dispara la función.
  • Conexiones a la base de datos. Muchas instancias abriendo sus propias conexiones pueden agotar la base de datos. Se pone un pooler en medio.

Nada de esto es difícil por sí solo. Lo fácil de pasar por alto es que el código funciona en tu máquina, donde hay una sola instancia, y falla en producción, donde hay varias.

La arquitectura tradicional te deja posponerlo

En un solo servidor de larga vida, el estado en memoria sale gratis. La app funciona, publicas y nada se queja. La cuenta llega el día que necesitas un segundo servidor: hay que deshacer de golpe cada supuesto sobre sesiones, cachés y archivos, y con presión.

Serverless cobra por adelantado. Eres stateless desde el primer despliegue porque la plataforma no te deja ser otra cosa. Se siente como una restricción. También significa que el día que crezca el tráfico no queda nada por desenredar.

El caso extremo

Otro Lunes es el ejemplo más limpio que tengo. El servidor no guarda nada. La llamada al modelo corre en un Route Handler que recibe siete datos y devuelve un plan, y el plan se guarda en el navegador. No hay cuentas ni base de datos. Cualquier instancia puede atender cualquier petición porque ninguna depende de una anterior.

Cuándo seguiría eligiendo un servidor

Serverless encaja con tráfico irregular e impredecible y con trabajo que termina rápido. Un proceso de larga vida encaja mejor cuando:

  • la carga es constante, así que pagas una instancia que usarías todo el día de todos modos;
  • una petición dura mucho o mantiene una conexión abierta, como con websockets;
  • arrancar es caro, por ejemplo cargar un modelo grande en memoria, y quieres hacerlo una sola vez.

La pregunta que me hago antes de elegir

¿Puede cualquier instancia atender cualquier petición? Si la respuesta honesta es no, o lo arreglo primero o elijo la arquitectura que me deja guardar el estado. Elegir serverless y guardar el estado igual te da los costos de las dos.