Cloudflare K2: flujos de eventos sin servidor

Artículo original ↗ Discusión en Hacker News ↗

Cloudflare ha presentado K2, un servicio de streaming de eventos sin servidor construido sobre almacenamiento de objetos y posicionado como una alternativa más barata y totalmente gestionada a sistemas del estilo Kafka y Pub/Sub para mover grandes volúmenes de datos. Los comentaristas comparan K2 con Cloudflare Queues (acciones con reintentos frente a registros de eventos de alto rendimiento), destacan los compromisos entre menor coste y mayor latencia de extremo a extremo, y señalan una futura API compatible con Kafka para facilitar su adopción. El lanzamiento se enmarca en una tendencia más amplia hacia infraestructuras “object-store-first”, a la vez que reaviva preocupaciones recurrentes sobre el bloqueo con proveedor, los precios de salida de datos y el papel cada vez mayor de Cloudflare en el ecosistema cloud.

Propósito y posicionamiento

  • K2 se presenta como un primitivo de flujo de eventos duradero y sin servidor dentro de la plataforma para desarrolladores de Cloudflare.
  • Se diferencia de Cloudflare Queues:
    • Queues: “hacer este trabajo” – reintentos por mensaje, manejo de dead-letter, trabajos diferidos y seguimiento de tareas individuales.
    • K2: “esto ocurrió” – registros de eventos de alto volumen, múltiples consumidores independientes, reejecución, retención a largo plazo, patrones similares a Kafka.
  • Varios comentaristas lo ven como la pieza “tipo Kafka” que llevaba mucho tiempo faltando en la pila de Cloudflare.

Arquitectura y tendencia hacia el almacenamiento de objetos

  • Construido sobre almacenamiento de objetos (Cloudflare R2) para lograr almacenamiento barato, duradero y escalable.
  • Encaja en una tendencia más amplia: muchos sistemas modernos (similares a Kafka, registros, bases de datos) se están reconstruyendo “sobre almacenes de objetos estilo S3”.
  • Algunos sostienen que casi todo lo que no necesita latencia inferior a 100 ms se está moviendo al almacenamiento de objetos; otros encuentran esto paradójico dada la velocidad de NVMe.

Comparaciones con alternativas

  • Comparado con Kafka / MSK / Confluent: más barato, totalmente sin servidor, sin clústeres que gestionar, pero con mayor latencia.
  • Comparado con Google Pub/Sub y AWS Kinesis: el principal diferenciador percibido es el coste (especialmente para retención prolongada) y la integración estrecha con Cloudflare / enfoque en el edge.
  • NATS JetStream y otros productos similares a Kafka respaldados por S3 (AutoMQ, WarpStream, topics de Kafka sin disco) se mencionan como parte de un espacio parecido.

Precios y rendimiento

  • Se discuten los precios base publicados: ~0,04 USD/GB producido, ~0,04 USD/GB consumido, ~0,02 USD/GB-mes de almacenamiento.
  • Algunos lo ven atractivo frente a Kafka gestionado; otros señalan que el fan-out puede salir caro, ya que cada consumidor paga por GB.
  • Compromisos de latencia: los comentaristas citan ~1 s en p99 como lo esperado para flujos respaldados por almacenamiento de objetos; algunos informes de prueba muestran unos pocos segundos de extremo a extremo.

Semántica y API

  • Entrega al menos una vez con semántica de acuse de recibo/lease; soporte por flujo para hasta 100 suscripciones, cada una con su propio cursor y capacidad de reejecución.
  • Casos de uso ordenados frente a desordenados: el orden se gestiona mediante agrupación por clave; el consumo desordenado es más sencillo.
  • Se planean APIs compatibles con Kafka para facilitar la portabilidad, aunque la API propia de K2 es intencionalmente más simple que la de Kafka.

Estrategia de Cloudflare y preocupaciones

  • Algunos elogian a Cloudflare por construir rápidamente una plataforma de nube casi completa, con K2 y otros servicios formando un ecosistema convincente.
  • Otros se preocupan por la velocidad de producto, los despidos recientes y el riesgo de concentración de proveedor/monopolio.
  • Hay llamados a ofrecer bases de datos más potentes y mejoras en D1 para completar la plataforma.