Arquitecturas serverless y basadas en espacios

Dos respuestas a la cuestión de la capacidad

Todos los estilos de este capítulo vistos hasta ahora suponen que alguien ejecuta servidores y los dimensiona para la carga. Esta sección trata dos estilos que responden a la cuestión de la capacidad de formas opuestas. La arquitectura serverless entrega por completo los servidores a un proveedor de nube y paga por uso, lo que conviene al trabajo pequeño, dirigido por eventos y a menudo inactivo. La arquitectura basada en espacios mantiene en memoria todo lo que necesita una solicitud con mucha actividad, repartido entre muchas unidades idénticas, para que la base de datos deje de estar en la ruta crítica, lo que conviene a picos extremos y repentinos, como la puesta a la venta de entradas. Ambas son herramientas especializadas; ambas se eligen a menudo por motivos equivocados.

Serverless: funciones y backends gestionados

Serverless no significa que no haya servidores; significa que el equipo no aprovisiona, parchea ni dimensiona servidores, ni paga por ellos cuando están inactivos. El artículo de Mike Roberts de 2018, muy citado, distingue dos ingredientes. Las funciones como servicio (FaaS) ejecutan pequeñas piezas del código propio del equipo en respuesta a eventos, en contenedores que el proveedor crea, escala y destruye, y que pueden durar una sola invocación. AWS Lambda, anunciado en noviembre de 2014 y disponible de forma general en abril de 2015, popularizó el modelo; Azure Functions, Google Cloud Run functions y Cloudflare Workers son otros ejemplos. El backend como servicio (BaaS) sustituye componentes del lado del servidor por servicios de terceros totalmente gestionados a los que el cliente o la función llaman directamente: autenticación (Auth0, Amazon Cognito), bases de datos (Firebase, DynamoDB), almacenamiento de objetos, correo electrónico y colas.

Una aplicación serverless suele ser una combinación: las funciones contienen la lógica de negocio específica de la organización, y todo lo demás, incluido todo el estado duradero, vive en servicios gestionados. El proveedor se encarga de la capacidad, la disponibilidad entre zonas y el sistema operativo. El equipo sigue siendo responsable de su código, sus datos, su configuración y sus ajustes de seguridad, como explica el modelo de responsabilidad compartida en los servidores y la nube.

Cómo se comportan las funciones: las características que condicionan el diseño

Disparadores de eventos. Las funciones se ejecutan en respuesta a eventos: una solicitud HTTP a través de un gateway, un mensaje en una cola o un flujo, un archivo que llega al almacenamiento de objetos, un cambio en una base de datos o una programación horaria. Los disparadores que invocan la función de forma asíncrona, como las colas y las notificaciones de almacenamiento, suelen entregar al menos una vez y reintentar en caso de fallo, por lo que los manejadores deben ser idempotentes, exactamente igual que en la arquitectura dirigida por eventos.

Escalar a cero y escalar horizontalmente. Sin tráfico, no se ejecuta ninguna instancia y no se factura nada de cómputo. A medida que llegan eventos, la plataforma arranca más instancias en paralelo, hasta un límite de concurrencia de la cuenta o de la función; en AWS Lambda, el límite regional por defecto es de 1000 ejecuciones concurrentes en el momento de escribir esto, ampliable a petición. El escalado horizontal rápido es a la vez una ventaja y un peligro: mil funciones concurrentes pueden abrir mil conexiones de base de datos y desbordar una base de datos relacional diseñada para unos pocos cientos, y por eso existen los proxies de conexiones y los topes de concurrencia por función.

Facturación por invocación. El costo suele ser un pequeño cargo por solicitud más un cargo por la memoria multiplicada por el tiempo de ejecución (gigabytes-segundo). Por tanto, el código que espera sin hacer nada a una API lenta de la que depende está pagando por esperar.

Arranques en frío (cold starts). La primera solicitud a una instancia nueva debe esperar mientras la plataforma arranca un contenedor, carga el entorno de ejecución y ejecuta el código de inicialización: desde decenas de milisegundos hasta varios segundos, según el lenguaje, el tamaño del paquete y la configuración de red. Las instancias se reutilizan para solicitudes posteriores mientras siguen calientes, así que los arranques en frío afectan sobre todo al tráfico poco frecuente y a las ráfagas repentinas. Las mitigaciones incluyen paquetes de despliegue más pequeños, entornos de ejecución más ligeros, inicializar fuera del manejador y pagar por mantener instancias preinicializadas (AWS lo llama provisioned concurrency), lo que reintroduce en parte el costo de tener capacidad siempre activa.

Límites. Las funciones se ejecutan con límites estrictos de tiempo de ejecución, memoria, tamaño de la carga útil y disco temporal; para AWS Lambda, en el momento de escribir esto, 15 minutos, de 128 MB a 10 240 MB de memoria (con CPU asignada en proporción) y 6 MB para una solicitud o respuesta síncrona. Los trabajos largos deben dividirse en pasos, y las cargas útiles grandes deben pasarse por referencia al almacenamiento de objetos.

Ausencia de estado. Nada de lo que hay en la memoria o el disco local de una instancia tiene garantizado sobrevivir hasta la siguiente invocación. Guardar en caché en memoria entre llamadas es una optimización que puede acertar o no, nunca un lugar para datos importantes.

Adónde va el estado

Como las funciones no guardan nada, el trabajo de arquitectura pasa a consistir en elegir dónde vive cada tipo de estado. Los datos de negocio duraderos van a una base de datos gestionada, a menudo una que maneje bien muchas conexiones de corta duración (almacenes clave-valor o documentales, o una base de datos relacional detrás de un proxy de conexiones). Los objetos grandes van al almacenamiento de objetos y se pasan entre funciones mediante su clave. El estado compartido de corta duración, como los contadores de limitación de tasa, va a una caché gestionada. El progreso de un proceso de varios pasos va a un servicio de flujos de trabajo (AWS Step Functions, Azure Durable Functions o similares), que actúa como orquestador de sagas duradero, como se describe en sagas. Las sesiones de usuario van en tokens que guarda el cliente o en un almacén de sesiones.

La consecuencia es que un sistema serverless es un sistema distribuido por construcción, con todas las inquietudes de este capítulo: latencia de red entre cada función y sus datos, fallos parciales, eventos duplicados, consistencia eventual y la necesidad de trazado distribuido. Una sola acción de negocio puede atravesar un gateway, tres funciones, una cola y dos bases de datos. La observabilidad (consulta observabilidad) no es opcional.

Acoplamiento al proveedor: el precio de no ejecutar servidores

Serverless acopla un sistema a su proveedor más estrechamente que alquilar máquinas virtuales o ejecutar contenedores. Los formatos de los eventos, la configuración de los disparadores, los modelos de identidad y permisos, las definiciones de flujos de trabajo y los propios servicios gestionados son todos específicos del proveedor. Trasladar una aplicación serverless madura a otra nube se parece más a una reescritura que a una migración.

Los profesionales no se ponen de acuerdo sobre cuánto importa esto. Una postura sostiene que la dependencia del proveedor (lock-in) es el precio de una gran reducción del trabajo operativo y que la mayoría de las organizaciones nunca cambian de nube, así que optimizar para la portabilidad es un esfuerzo perdido. La otra sostiene que los cambios de precios, las exigencias regulatorias o las adquisiciones sí obligan a cambiar, y que un acoplamiento profundo elimina poder de negociación. Un camino intermedio es aceptar el acoplamiento en los bordes y contenerlo en el núcleo: mantener la lógica de negocio en módulos simples detrás de puertos, con manejadores de función finos que actúan como adaptadores (el enfoque de la arquitectura hexagonal), mantener la infraestructura como código y registrar el acoplamiento como una decisión explícita. El costo y la dependencia del proveedor se tratan con más detalle en FinOps y dependencia del proveedor.

Cuándo encaja serverless y cuándo no

Serverless encaja en cargas de trabajo con picos, impredecibles o de bajo volumen, en las que pagar por servidores inactivos es un desperdicio; en el pegamento dirigido por eventos, como reaccionar a subidas de archivos, mensajes de cola y cambios en bases de datos; en los trabajos programados y la automatización administrativa; en los prototipos y productos nuevos, en los que el equipo debería dedicar su tiempo al producto y no a la infraestructura; y en equipos sin capacidad de plataforma ni de operaciones.

Encaja mal con el tráfico constante y de gran volumen, en el que el precio por solicitud supera a la capacidad siempre activa (como en el ejemplo práctico); con los procesos de larga duración o con estado, como la transcodificación de video que supera el límite de tiempo o los servidores WebSocket que mantienen muchas conexiones; con requisitos estrictos de baja latencia de cola que los arranques en frío incumplirían; con cargas de trabajo que necesitan hardware especial o un control fino del entorno de ejecución; y con diseños de grano fino en los que muchas funciones se llaman entre sí de forma síncrona, lo que añade saltos de red, costo y puntos de fallo en cada paso. El Capítulo 1 describió cómo Amazon Prime Video, en 2023, pasó un servicio de monitorización de pasos serverless distribuidos a un único proceso e informó de una reducción de más del 90% en el costo de infraestructura (por qué importa la arquitectura): no es un veredicto sobre serverless, sino un recordatorio de que el encaje importa más que la moda.

Arquitectura basada en espacios: sacar la base de datos de la ruta crítica

La mayoría de las arquitecturas escalan con facilidad los niveles web y de aplicación, pero acaban chocando con la base de datos, que toca cada solicitud. Añadir servidores delante solo traslada la cola a la base de datos. La arquitectura basada en espacios, tal como la describen Mark Richards y Neal Ford en Fundamentals of Software Architecture, elimina por completo la base de datos de la ruta síncrona. Cada solicitud se gestiona íntegramente en memoria en una de muchas unidades de procesamiento idénticas, y la base de datos se actualiza de forma asíncrona, entre bastidores.

El nombre procede del espacio de tuplas, una memoria asociativa compartida introducida por el lenguaje de coordinación Linda de David Gelernter en 1985: los procesos se comunican escribiendo tuplas en un espacio compartido y leyendo o extrayendo las tuplas que coinciden, sin conocerse entre sí. JavaSpaces, de Sun, llevó la idea a Java a finales de la década de 1990, y plataformas comerciales construyeron sobre ella espacios distribuidos y replicados, que evolucionaron hasta los grids de datos en memoria actuales, como Hazelcast, Apache Ignite y Oracle Coherence.

Colisiones de datos y otros costos

Mantener copias replicadas en muchas unidades traslada a la memoria los problemas de consistencia de las secciones anteriores. Con una caché replicada, cada unidad tiene una copia completa y los cambios se copian de forma asíncrona, lo que da lecturas locales rápidas, pero dos unidades pueden actualizar el mismo elemento antes de que la replicación se ponga al día. Richards y Ford llaman a esto colisión de datos y estiman su tasa como el número de unidades multiplicado por el cuadrado de la tasa de actualización, dividido por el número de elementos y multiplicado por la latencia de replicación. Con 5 unidades, 20 actualizaciones por segundo, 50 000 elementos y 100 ms de latencia, eso da 5 × 400 ÷ 50 000 × 0.1 = 0.004 por segundo, unas 115 colisiones en una jornada de ocho horas; reducir la latencia a 1 ms la deja en torno a una.

Para los datos que nunca deben colisionar, como el último asiento de una fila, las alternativas son una caché distribuida, en la que cada elemento vive en una partición y todas las unidades lo leen y escriben allí (consistente, pero cada acceso es una llamada de red y las particiones del grid deben seguir disponibles), o dirigir todas las solicitudes de un evento o una zona a la misma unidad, de modo que solo una unidad cambie esos asientos. La mayoría de los diseños reales combinan ambas cosas: particionan por clave los datos calientes y disputados, y replican los datos que se leen mucho y se escriben poco, como los mapas del recinto y los precios.

Los demás costos son importantes. Los datos guardados en memoria están limitados por el tamaño de la memoria y deben reconstruirse tras un reinicio completo. La base de datos es eventualmente consistente con el grid, así que los informes y otros sistemas ven los cambios con retraso, y perder cambios en cola es un riesgo real que debe cubrir la durabilidad de las bombas. Probar con una carga de pico realista es caro y difícil. Y el estilo es complejo y costoso de construir: Richards y Ford le dan una puntuación baja en simplicidad y en capacidad de prueba, y alta en costo. Solo merece la pena cuando la carga de verdad no puede atenderse con caché, réplicas de lectura y una base de datos bien ajustada.