Cloudflare K2: fluxos de eventos sem servidor

Artigo original ↗ Discussão no Hacker News ↗

A Cloudflare introduziu o K2, um serviço de streaming de eventos sem servidor construído sobre object storage, posicionado como uma alternativa mais barata e totalmente gerenciada a sistemas no estilo Kafka e Pub/Sub para mover grandes volumes de dados. Comentadores contrastam o K2 com o Cloudflare Queues (ações com retries vs. logs de eventos de alto throughput), destacam as trocas entre menor custo e maior latência de ponta a ponta, e observam uma API compatível com Kafka planejada para facilitar a adoção. O lançamento é enquadrado em uma tendência mais ampla de infraestrutura “object-store-first”, ao mesmo tempo que levanta preocupações recorrentes sobre lock-in de fornecedor, preços de egress e o papel crescente da Cloudflare no ecossistema de cloud.

Propósito e Posicionamento

  • K2 é apresentado como um primitivo de fluxo de eventos durável e sem servidor dentro da plataforma de desenvolvedores da Cloudflare.
  • Diferenciado do Cloudflare Queues:
    • Queues: “faça este trabalho” – retries por mensagem, tratamento de dead-letter, jobs com atraso e acompanhamento de tarefas individuais.
    • K2: “isso aconteceu” – logs de eventos de alto volume, múltiplos consumidores independentes, replay, retenção de longo prazo, padrões semelhantes ao Kafka.
  • Vários comentaristas veem isso como preenchendo uma lacuna “estilo Kafka” há muito ausente na stack da Cloudflare.

Arquitetura e Tendência de Object Storage

  • Construído sobre object storage (Cloudflare R2) para obter armazenamento de baixo custo, durável e escalável.
  • Encaixa-se em uma tendência mais ampla: muitos sistemas modernos (semelhantes a Kafka, registries, databases) estão sendo reconstruídos “em object stores no estilo S3”.
  • Alguns argumentam que quase tudo que não precisa de latência inferior a 100 ms está migrando para object storage; outros consideram isso perverso, dado o quão rápido é o NVMe.

Comparações com Alternativas

  • Comparado ao Kafka / MSK / Confluent: mais barato, totalmente sem servidor, sem clusters para gerenciar, mas com latência maior.
  • Comparado ao Google Pub/Sub e AWS Kinesis: o principal diferencial percebido é o custo (especialmente para retenção longa) e a integração estreita com a Cloudflare / foco na edge.
  • NATS JetStream e outros produtos semelhantes ao Kafka com backend em S3 (AutoMQ, WarpStream, tópicos Kafka sem disco) são mencionados como pertencentes a um espaço similar.

Preço e Desempenho

  • A precificação básica publicada discutida: ~US$0,04/GB produzido, ~US$0,04/GB consumido, ~US$0,02/GB-mês de armazenamento.
  • Alguns veem isso como atraente em comparação com Kafka gerenciado; outros observam que o fan-out pode ficar caro, já que cada consumidor paga por GB.
  • Compensações de latência: comentaristas citam ~1s no p99 como esperado para streams apoiados por object storage; alguns relatos de teste mostram alguns segundos de ponta a ponta.

Semântica e API

  • Entrega at-least-once com semânticas de acknowledgment/lease; suporte por stream para até 100 subscriptions, cada uma com seu próprio cursor e capacidade de replay.
  • Casos de uso ordenados vs. não ordenados: a ordenação é tratada por agrupamento baseado em chave; o consumo não ordenado é mais simples.
  • APIs compatíveis com Kafka estão planejadas para facilitar a portabilidade, embora a API própria do K2 seja intencionalmente mais simples do que a do Kafka.

Estratégia da Cloudflare e Preocupações

  • Alguns elogiam a Cloudflare por construir rapidamente uma plataforma de cloud quase completa, com K2 e outros serviços formando um ecossistema atraente.
  • Outros se preocupam com a velocidade de produto, demissões recentes e risco de concentração/monopólio de fornecedor.
  • Há pedidos por ofertas de database mais fortes e melhorias no D1 para completar a plataforma.