El serverless stream processing consiste en ejecutar pipelines de datos en tiempo real sin aprovisionar, dimensionar ni operar los servidores o clústeres que los sustentan. La plataforma escala la capacidad de cómputo hacia arriba y hacia abajo según el volumen de eventos entrantes, y solo se paga por lo que se usa. Su equipo escribe la lógica de procesamiento, ya sea una función o una sentencia SQL, y el proveedor se encarga de ejecutarla.
La idea resulta atractiva, porque los clústeres de stream processing son de los sistemas más difíciles de dimensionar y mantener en buen estado. Sin embargo, en streaming "serverless" abarca dos enfoques muy distintos, y no son intercambiables. Elegir el equivocado es el motivo más habitual por el que los proyectos de serverless streaming chocan con sus límites.
En general, un servicio serverless tiene tres características. No hay servidores ni clústeres que aprovisionar. La capacidad escala automáticamente con la demanda, a veces hasta cero. La facturación se basa en el uso y no en la capacidad reservada. Aplicado al stream processing, significa que los eventos se filtran, transforman, combinan o agregan a medida que llegan, sin que su equipo tenga que gestionar el cómputo que realiza el trabajo.
El primer modelo es functions as a service. Una función como AWS Lambda se activa con los nuevos registros de un stream, los procesa en pequeños lotes y después se detiene. La Serverless Lens del Well-Architected Framework de AWS describe este patrón con Amazon Kinesis como stream, Lambda como consumidor y DynamoDB como almacén de resultados.
El segundo modelo es un motor de serverless stream processing. En este caso, un framework completo de stream processing, normalmente Apache Flink, se ejecuta como un servicio gestionado que escala por sí mismo. Confluent Cloud for Apache Flink es un ejemplo: usted envía sentencias de Flink SQL y el servicio se ocupa del autoescalado, el paralelismo y el balanceo de carga, incluido el escalado a cero cuando una carga de trabajo está inactiva. El motor se ejecuta de forma continua, algo importante para todo lo que dependa del estado.
La mayoría de las arquitecturas de serverless streaming comparten la misma forma. Los productores, como aplicaciones, dispositivos y bases de datos, publican eventos en una event streaming platform como Apache Kafka o Amazon Kinesis. Un procesador serverless lee de esa plataforma, aplica la lógica y escribe los resultados en un destino: otro topic, una base de datos, un data warehouse o una aplicación que reacciona a ellos.
La diferencia entre ambos modelos está en el procesador. Una función recibe un lote de registros, lo procesa y termina. Cualquier estado que necesite entre lotes debe transmitirse o almacenarse externamente. Un motor serverless se ejecuta como un job de larga duración con su propio estado gestionado, por lo que puede mantener el contexto de una ventana o de un join a lo largo de millones de eventos sin una base de datos externa.
La elección correcta depende de lo que el procesamiento tenga que recordar. Esta tabla compara los dos modelos serverless con la opción autogestionada que conocen la mayoría de los equipos.
| Funciones (p. ej., AWS Lambda) | Motor de serverless stream processing (p. ej., Flink serverless) | Motor autogestionado (Flink, Kafka Streams) | |
|---|---|---|---|
| Infraestructura | Nada que gestionar | Nada que gestionar | Clústeres que dimensionar, actualizar y monitorizar |
| Estado | Se transmite entre invocaciones o se almacena externamente | Gestionado por el motor | Gestionado por el motor, operado por usted |
| Ventanas | Tumbling windows cortas (hasta 15 minutos en Lambda) | Tumbling, sliding y session windows de cualquier duración | Tumbling, sliding y session windows de cualquier duración |
| Escalado | Por lote, vinculado a shards o particiones | Automático, dentro de los límites que usted establezca | Manual o mediante scripts |
| Modelo de costes | Por invocación y duración | Por unidad de cómputo consumida | Infraestructura reservada más tiempo del personal |
| Uso más adecuado | Lógica stateless, con picos y evento a evento | Pipelines stateful sin carga operativa | Cargas de trabajo muy grandes y estables con experiencia interna |
El trabajo stateless (sin estado) trata cada evento de forma independiente. Descartar registros irrelevantes, enrutar eventos al destino correcto, enmascarar datos personales o enriquecer un evento con una consulta son tareas stateless. Encajan bien con las funciones, sobre todo cuando el tráfico presenta picos y no se quiere tener capacidad ociosa entre ellos.
El trabajo stateful (con estado) necesita recordar eventos anteriores. Contar transacciones por cliente y hora, combinar un stream de pedidos con un stream de envíos o detectar una secuencia de eventos que indique fraude dependen de un estado que se mantiene a lo largo de muchos eventos. Un motor serverless está diseñado para ello. Guarda el estado mediante checkpoints, lo recupera tras un fallo y gestiona los eventos que llegan tarde sin que usted tenga que construir esa maquinaria.
Las funciones pueden resolver agregaciones sencillas, pero sus límites aparecen rápidamente a medida que crecen los requisitos. Las tumbling windows de Lambda tienen un máximo de 15 minutos, y el estado que se transmite entre invocaciones dentro de una ventana tiene un tamaño limitado. Todo lo que sea más largo o más grande tiene que ir a un almacén externo, lo que añade latencia, coste y un componente más que operar.
La semántica de entrega también requiere atención. AWS advierte de que con Kinesis pueden producirse registros duplicados, por lo que consumidores y productores deben ser idempotentes. La concurrencia está ligada al número de shards o particiones, lo que significa que la planificación del throughput no ha desaparecido, simplemente se ha desplazado.
El coste es la última consideración. La facturación por uso es eficiente para streams con ráfagas o de bajo volumen. En un pipeline que procesa grandes volúmenes las 24 horas, pagar por invocación o por unidad de cómputo puede salir más caro que la capacidad reservada. Los motores serverless resuelven parte de este problema al permitir limitar el cómputo máximo que puede utilizar una carga de trabajo.
Cada uno de los principales proveedores cloud ofrece al menos una forma de procesar streams sin gestionar clústeres:
Si sus eventos ya están en Kafka, un motor serverless que lea Kafka de forma nativa evita tener que copiar antes los datos a un stream cloud independiente. Si prefiere construir de forma visual en lugar de escribir código, las herramientas de no-code stream processing ofrecen otra vía.
Empiece por la lógica de procesamiento, no por la plataforma. Si cada evento puede tratarse de forma independiente y el tráfico llega en ráfagas, las funciones suelen ser la opción más sencilla y económica. Si el pipeline necesita joins, ventanas de más de unos pocos minutos o resultados exactly-once, un motor de serverless stream processing elimina la mayor parte del trabajo operativo sin obligarle a asumir los límites de las funciones.
Después, tenga en cuenta el volumen, las capacidades del equipo y los sistemas existentes. Un throughput estable y muy elevado puede hacer que la capacidad autogestionada o reservada resulte más rentable, siempre que su equipo pueda operarla. La mayoría de las organizaciones acaban con una combinación: funciones para la gestión ligera de eventos, un motor serverless para los pipelines stateful y una regla clara para decidir qué carga de trabajo va a cada sitio.
Mimacom diseña, construye y opera plataformas de data streaming sobre Apache Kafka y Apache Flink. Como partner de IBM con servicios de consultoría de Confluent, ayudamos a los equipos a trasladar sus cargas de stream processing a Confluent Cloud, incluido Flink serverless, y a decidir qué lógica corresponde a funciones, a motores gestionados o a clústeres autogestionados.
Nuestros equipos han entregado soluciones de streaming en producción en banca, retail, transporte y fabricación. Esa experiencia determina cómo abordamos el estado, las garantías de entrega y el coste antes de que un pipeline entre en producción, para que el modelo serverless reduzca el trabajo operativo en lugar de trasladar los problemas a otro sitio.
AWS Lambda funciona bien para el stream processing stateless, como filtrar, enrutar y enriquecer registros de Kinesis o Amazon MSK, sobre todo cuando el tráfico presenta picos. Es menos adecuado para el trabajo stateful. Las tumbling windows están limitadas a 15 minutos, y las ventanas más largas o los joins requieren almacenamiento externo o un motor de stream processing dedicado.
Sí, si se utiliza un motor de serverless stream processing en lugar de funciones. Servicios como Confluent Cloud for Apache Flink gestionan el estado, los checkpoints y la recuperación por usted mientras escalan automáticamente. Las funciones solo pueden transmitir un estado limitado entre invocaciones, por lo que no son adecuadas para ventanas largas, joins o detección de patrones.
Depende del patrón de tráfico. Los precios por uso suelen ser más baratos para volúmenes con ráfagas, bajos o impredecibles, porque no se paga por capacidad ociosa, y eliminan el tiempo que el personal dedica a operar clústeres. Con un throughput estable y muy elevado, la capacidad reservada o autogestionada puede costar menos, así que conviene modelar ambas opciones antes de comprometerse.
El serverless stream processing compensa cuando el modelo se ajusta a la carga de trabajo: funciones para la gestión de eventos sencilla y con ráfagas, y motores serverless para los pipelines stateful. Hable con nuestro equipo de Confluent sobre qué cargas de streaming pueden ejecutarse en modo serverless, o descubra nuestros servicios de consultoría de Confluent.