Este é um artigo traduzido originalmente publicado dia 16/11/2022 no blog do Kai Waehner: "When to choose Redpanda instead of Apache Kafka?". Assine a newsletter do Kai para se manter atualizado com novas publicações.
O streaming de dados surgiu como uma nova categoria de software. Ele complementa middleware, data warehouse e data lakes tradicionais. O Apache Kafka se tornou o padrão de fato. Novos players entram no mercado por causa do sucesso de Kafka. Um deles é o Redpanda, uma implementação C++ leve compatível com Kafka. Esta postagem de blog explora as diferenças entre Apache Kafka e Redpanda, quando escolher qual estrutura e como o ecossistema Kafka, o licenciamento e a adoção pela comunidade afetam uma avaliação adequada.
O streaming de dados surgiu como uma nova categoria de software. Ele complementa middleware, data warehouse e data lakes tradicionais. O Apache Kafka se tornou o padrão de fato. Novos players entram no mercado por causa do sucesso de Kafka. Um deles é o Redpanda, uma implementação C++ leve compatível com Kafka. Esta postagem explora as diferenças entre Apache Kafka e Redpanda, quando escolher qual estrutura e como o ecossistema Kafka, o licenciamento e a adoção pela comunidade afetam uma avaliação adequada.
Disclaimer: eu trabalho para a Confluent. No entanto, a postagem não é sobre comparar recursos, mas explicar os conceitos por trás das alternativas de uso do Apache Kafka (e produtos relacionados, incluindo Confluent) ou Redpanda. Falo com empresas de todo o mundo todas as semanas. Abaixo, resumo mal-entendidos comuns ou falta de conhecimento sobre ambas as tecnologias. Espero que ajude você a tomar a decisão certa. Escolha executar o Apache Kafka de código aberto, uma das várias ofertas Kafka comerciais ou serviços em nuvem, ou Redpanda. Todas são ótimas opções com prós e contras…
Data Streaming: uma nova categoria de software
Aplicativos orientados a dados são o novo preto. Como parte disso, o streaming de dados é uma nova categoria de software. Se você ainda não entende como ele difere de outras plataformas de gerenciamento de dados, como data warehouse ou data lake , confira a seguinte série de blogs:
Data Warehouse vs. Data Lake vs. Data Streaming – Amigos, Inimigos, Frenemies?
Streaming de dados para ingestão de dados no data warehouse e no data lake
Modernização do data warehouse: do legado no local à infraestrutura nativa da nuvem
Estudos de caso: streaming de dados nativo da nuvem para modernização de data warehouse
Lições aprendidas com a criação de um data warehouse nativo da nuvem
E se você quer saber como o Apache Kafka difere de outro middleware , confira como Kafka se encaixa em comparação com ETL, ESB e iPaas .
Apache Kafka: O padrão de fato para streaming de dados
Apache Kafka tornou-se o padrão de fato para streaming de dados semelhante ao Amazon S3 é o padrão de fato para armazenamento de objetos. Kafka é usado em vários setores para muitos casos de uso .
A curva de adoção do Apache Kafka
O crescimento da comunidade Apache Kafka nos últimos anos é impressionante:
>100.000 organizações usando o Apache Kafka
>41.000 participantes do Kafka Meetup
>32.000 perguntas sobre estouro de pilha
>12.000 Jiras para Apache Kafka
>31.000 listas de empregos abertas solicitam habilidades Kafka
E observe o aumento do número de usuários únicos mensais ativos baixando a biblioteca cliente Kafka Java com Maven:
Os números crescem exponencialmente. Isso não é surpresa para mim, pois o padrão de adoção e a curva de maturidade do Kafka são semelhantes na maioria das empresas:
Comece com um ou poucos casos de uso (que provam o valor comercial rapidamente)
Implante os primeiros aplicativos para produção e opere-os 24 horas por dia, 7 dias por semana
Aproveite os fluxos de dados de muitos domínios, unidades de negócios e tecnologias
Mude para um sistema nervoso central estratégico com um hub de dados descentralizado
Casos de uso do Kafka por valor comercial em todos os setores
A principal razão para o incrível crescimento da curva de adoção do Kafka é a variedade de possíveis casos de uso para streaming de dados. O potencial é quase infinito. As características do Kafka de combinar baixa latência, escalabilidade, confiabilidade e verdadeiro desacoplamento estabelecem benefícios em todos os setores e casos de uso:
Pesquise em meu blog seu setor favorito para encontrar muitos estudos de caso e arquiteturas. Ou, para começar, leia sobre os casos de uso do Apache Kafka em todos os setores .
O surgimento de muitos fornecedores de Kafka
O mercado de streaming de dados é enorme. Com tantos casos de uso em potencial, não é surpresa que cada vez mais fornecedores de software adicionem suporte Kafka a seus produtos . A maioria dos fornecedores usa Kafka ou implementa seu protocolo porque Kafka se tornou o padrão de fato para streaming de dados .
Saiba mais sobre os vários fornecedores de streaming de dados nas seguintes postagens do blog:
Para ser claro: um número crescente de fornecedores Kafka é ótimo! Isso comprova a criação de uma nova categoria de software . A concorrência impulsiona a inovação. A participação de mercado é grande o suficiente para muitos fornecedores. E estou 100% convencido de que ainda estamos em um estágio muito inicial do ciclo de hype do streaming de dados…
Após uma longa introdução para definir o contexto, vamos agora revisar um novo participante no mercado Kafka: Redpanda…
Apresentando Redpanda: streaming de dados compatível com Kafka
Redpanda é uma plataforma de streaming de dados . Seu site explica seu posicionamento no mercado e estratégia de produto da seguinte forma (para diferenciá-lo do Apache Kafka):
Sem Java : uma infraestrutura sem JVM e sem ZooKeeper.
Projetado em C++ : Projetado para um desempenho melhor que o Apache Kafka.
Uma arquitetura de binário único : sem dependências de outras bibliotecas ou nós.
Autogerenciamento e autocorreção : uma arquitetura simples, mas escalável para implantações no local e na nuvem.
Compatível com Kafka : suporte pronto para uso para o protocolo Kafka com aplicativos, ferramentas e integrações existentes.
Isso parece ótimo. Você precisa avaliar se o Redpanda é a escolha certa para o seu próximo projeto ou se deve ficar com o “verdadeiro Apache Kafka” .
Como escolher a implementação “Kafka” adequada para o seu projeto?
Uma recomendação que algumas pessoas acham surpreendente: qualifique-se primeiro! Isso é muito mais fácil. Da mesma forma, como expliquei quando NÃO usar o Apache Kafka.
Como parte da avaliação, a questão é se Kafka é o protocolo adequado para você. E para Kafka, escolha diferentes ofertas e comece com a comparação.
Comece sua avaliação com os requisitos do caso de negócios e defina suas necessidades mais críticas, como SLAs de tempo de atividade, estratégia de recuperação de desastres, suporte empresarial, ferramentas de operações, serviço de nuvem autogerenciado x totalmente gerenciado, recursos como mensagens x ingestão de dados x integração de dados vs. aplicativos, e assim por diante. Com base em seus casos de uso e requisitos, você pode começar a qualificar fornecedores como Confluent, Redpanda, Cloudera, Red Hat / IBM, Amazon MSK, Amazon Kinesis, Google Pub Sub e outros para criar uma lista restrita.
As seções a seguir comparam o projeto de código aberto Apache Kafka com a reimplementação do protocolo Kafka do Redpanda . Você pode usar esses critérios (e informações de outros blogs, artigos, vídeos e assim por diante) para avaliar suas opções.
Semelhanças entre Redpanda e Apache Kafka
As proposições de valor de alto nível são as mesmas no Redpanda e no Apache Kafka :
Fluxo de dados para processar dados em tempo real em escala continuamente
Desacople aplicativos e domínios com uma camada de armazenamento distribuído
Integre-se com várias fontes de dados e coletores de dados
Aproveite o processamento de fluxo para correlacionar dados e agir em tempo real
Operações autogerenciadas ou consumo de uma oferta de nuvem totalmente gerenciada
No entanto, o diabo está nos detalhes e fatos. Não confie no marketing , mas examine mais profundamente os vários produtos e serviços em nuvem.
Opções de implantação: autogerenciado x serviço em nuvem
A transmissão de dados é necessária em todos os lugares . Embora a maioria das empresas em todos os setores tenha uma estratégia de nuvem em primeiro lugar, algumas cargas de trabalho devem permanecer na borda por diferentes motivos: custo, latência ou requisitos de segurança. Meu blog sobre casos de uso do Apache Kafka no limite ainda é um dos artigos mais lidos que escrevi nos últimos anos.
Além de operar o Redpanda sozinho, você pode comprar o Redpanda como um produto e implantá-lo em seu ambiente. Em vez de apenas auto-hospedar o Redpanda, você pode implantá-lo como um plano de dados em seu ambiente usando Kubernetes (suportado pelo plano de controle externo do fornecedor) ou aproveitar um serviço de nuvem (totalmente gerenciado pelo fornecedor).
As diferentes opções de implantação do Redpanda são ótimas. Escolha o que você precisa. Isso é muito semelhante às opções de implantação do Confluent para Apache Kafka. Alguns outros fornecedores Kafka fornecem apenas opções de implantação autogerenciadas (por exemplo, Cloudera) ou totalmente gerenciadas (por exemplo, Amazon MSK Serverless).
O que sinto falta do Redpanda: Nenhuma documentação oficial sobre SLAs do serviço de nuvem e suporte corporativo . Espero que eles se saiam melhor do que o Amazon MSK (excluindo o suporte Kafka de suas ofertas de nuvem ). Tenho certeza de que você obterá essas informações se entrar em contato com a equipe do Redpanda, que provavelmente incorporará em breve algumas informações em seu site.
Traga seu próprio cluster (BYOC)
Há uma terceira opção além de autogerenciar um cluster de streaming de dados e aproveitar um serviço de nuvem totalmente gerenciado: traga seu próprio cluster (BYOC). Essa alternativa permite que os usuários finais implantem uma solução parcialmente gerenciada pelo fornecedor em sua própria infraestrutura (como seu datacenter ou seu VPC em nuvem).
Aqui está o slogan de marketing da Redpanda: “Clusters Redpanda hospedados em sua nuvem, totalmente gerenciados pela Redpanda, para que seus dados nunca saiam do seu ambiente!”
Isso soa muito atraente em teoria. Infelizmente, cria mais questões e problemas do que resolve :
Como o fornecedor acessa seu data center ou VPC?
Quem decide como e quando escalar um cluster?
Quando agir sobre os problemas? Como e quando você implementa um cluster para incorporar correções de bugs ou atualizações de versão?
E a gestão de custos? Qual é o custo total de propriedade? Quanto valor a solução do fornecedor traz?
Como você garante os SLAs? Quem deve garanti-los, você ou o vendedor?
Para setores regulamentados, como os controles de segurança e a conformidade são suportados? Como você tem certeza sobre o que o fornecedor faz em um ambiente que você ostensivamente controla? Quão mais difícil será uma avaliação de risco de terceiros sob medida se você não estiver usando SaaS puro?
Por esses motivos, os fornecedores de nuvem hospedam apenas serviços gerenciados no ambiente do fornecedor de nuvem . Veja Amazon MSK, Azure Event Hubs, Google Pub Sub, Confluent Cloud, etc. Todos os serviços de nuvem totalmente gerenciados estão apenas na VPC do fornecedor pelos motivos acima.
Existem apenas duas opções: ou você transfere a responsabilidade para uma oferta SaaS ou controla você mesmo. Tudo no meio ainda é sua responsabilidade no final.
Comunidade x ofertas comerciais
A abordagem de vendas da Redpanda parece quase idêntica à forma como a Confluent vende streaming de dados. Uma edição comunitária gratuita está disponível, mesmo para uso em produção. A edição empresarial adiciona recursos empresariais como armazenamento em camadas, balanceamento automático de dados ou suporte empresarial 24 horas por dia, 7 dias por semana.
Nenhuma surpresa aqui. E uma boa estratégia, pois o streaming de dados é necessário em todos os lugares para diferentes usuários e compradores.
Diferenças técnicas entre Apache Kafka e Redpanda
Existem muitas diferenças técnicas e não funcionais entre os produtos Apache Kafka e o Redpanda. Tenha em mente que Redpanda NÃO é Kafka. Redpanda usa o protocolo Kafka. Esta é uma diferença pequena, mas crítica. Vamos explorar esses detalhes nas seções a seguir.
Compatibilidade do protocolo Apache Kafka vs. Kafka
Redpanda NÃO é uma distribuição Apache Kafka como Confluent Platform, Cloudera ou Red Hat. Em vez disso, o Redpanda reimplementa o protocolo Kafka para fornecer compatibilidade de API. Ser compatível com Kafka não é o mesmo que usar o Apache Kafka sob o capô , mesmo que pareça ótimo em teoria.
Dois outros exemplos de ofertas compatíveis com Kafka:
Hubs de eventos do Azure : uma oferta de serviço de nuvem SaaS compatível com Kafka do Microsoft Azure. O serviço em si funciona e tem um bom desempenho. No entanto, sua compatibilidade com Kafka tem muitas limitações. A Microsoft lista muitos deles em seu site. Algumas limitações do serviço em nuvem são consequência de uma implementação diferente nos bastidores, como tempo de retenção limitado e tamanhos de mensagem limitados.
Apache Pulsar : Uma estrutura de código aberto competindo com Kafka . O conjunto de recursos se sobrepõe muito. Infelizmente, o Pulsar geralmente só tem um bom marketing para recursos avançados para competir com o Kafka ou para se diferenciar. E um exemplo é seu mapeador Kafka para ser compatível com o protocolo Kafka. Ao contrário dos Hubs de Eventos do Azure como uma implementação séria (com algumas limitações), o wrapper de compatibilidade do Pulsar fornece uma implementação básica compatível apenas com partes secundárias do protocolo Kafka. Portanto, embora a alegada “compatibilidade Kafka” soe bem no papel, não se deve considerar isso seriamente para migrar sua infraestrutura Kafka em execução para o Pulsar.
Vimos produtos compatíveis para estruturas de código aberto no passado. As reimplementações geralmente estão longe de serem completas e perfeitas. Por exemplo, o MongoDB comparou o protocolo oficial de código aberto com seu concorrente Amazon DocumentDB para identificar o fato de que o DocumentDB passa apenas cerca de 33% da cadeia de teste de integração do MongoDB .
Em resumo, não há problema em usar essas soluções não Kafka, como Azure Event Hubs, Apache Pulsar ou Redpanda, para um novo projeto, se elas atenderem aos seus requisitos melhor do que o Apache Kafka. Mas tenha em mente que não é Kafka. Não há garantia de que componentes adicionais do ecossistema Kafka (como Kafka Connect, Kafka Streams, REST Proxy e Schema Registry) se comportem da mesma forma quando integrados a uma solução não Kafka que usa apenas o protocolo Kafka com sua própria implementação.
Quão boa é a compatibilidade do protocolo Kafka do Redpanda?
Francamente, não sei. Provavelmente e esperançosamente, o Redpanda tem melhor compatibilidade com o Kafka do que o Pulsar. Todo o produto é baseado nessa proposta de valor. Portanto, podemos supor que a equipe do Redpanda gasta muito tempo com compatibilidade. O Redpanda ainda NÃO alcançou 100% de compatibilidade com a API .
O tempo dirá quando veremos mais estudos de caso de empresas de vários setores que migraram alguns projetos Apache Kafka para Redpanda e operaram com sucesso a infraestrutura por alguns anos. Por que esperar alguns anos para ver? Bem, eu comparo com o que vejo de pessoas começando com o Amazon MSK. É muito fácil começar. No entanto, depois de alguns meses, os primeiros problemas acontecem. Os usuários descobrem que o Amazon MSK não é um produto totalmente gerenciado e não fornece Kafka SLAs sérios . Por isso, vejo muitas equipes começando com o Amazon MSK e depois migrando para o Confluent Cloud depois de alguns meses.
Mas vamos ser claros: se você executar um aplicativo no Apache Kafka e migrar para uma reimplementação com suporte ao protocolo Kafka, NÃO deve esperar 100% do mesmo comportamento do Kafka!
Alguns comportamentos subjacentes serão diferentes mesmo se a API for 100% compatível. Isso às vezes é um benefício. Por exemplo, Redpanda se concentra na otimização de desempenho com C++. Isso só é possível em algumas cargas de trabalho devido à reimplementação. C++ é superior em comparação com Java e JVM para alguns cenários de desempenho e memória.
Redpanda = Apache Kafka – Kafka Connect – Kafka Streams
Apache Kafka inclui Kafka Connect para integração de dados e Kafka Streams para processamento de fluxo.
Como a maioria dos projetos compatíveis com Kafka, o Redpanda exclui essas peças críticas de sua oferta . Portanto, mesmo 100% de compatibilidade de protocolo não significaria que um produto reimplementaria tudo no projeto Apache Kafka.
Menor latência vs. benchmarking
Sempre pense em seus requisitos de desempenho antes de iniciar um projeto. Se necessário, faça uma prova de conceito (POC) com Apache Kafka, Apache Pulsar e Redpanda. Aposto que em 99% dos cenários, todos os três mostrarão um desempenho bom o suficiente para o seu caso de uso.
Não confie em benchmarks opinativos de outras pessoas! Seu caso de uso terá requisitos e características diferentes. E o desempenho normalmente é apenas uma das muitas dimensões de avaliação.
Não sou fã da maioria dos “benchmarks” de desempenho e taxa de transferência. Os benchmarks são quase sempre opinativos e configurados para um problema específico (se um fornecedor, consultor independente ou pesquisador os conduz).
Meu colega Jack Vanlightly explicou esse conceito de benchmarking com excelentes diagramas:
Aqui está um exemplo concreto que você encontrará em um dos benchmarks do Redpanda: Kafka não foi construído para produtores de alto rendimento , e é isso que o Redpanda está explorando quando afirmam que o rendimento do Kafka é inferior ao Redpanda. Faça a si mesmo esta pergunta: Dos casos de uso de 1 GB/s, quem criaria essa taxa de transferência com apenas 4 produtores? Benchmarketing no seu melhor.
Portanto, mais uma vez, comece com seus requisitos de negócios. Em seguida, escolha a ferramenta certa para o trabalho. Os benchmarks são sempre construídos para vencer os outros. Ninguém publicará um benchmark onde a concorrência vence.
Tempo real suave vs. tempo real rígido
Quando falamos em tempo real no mundo da TI, queremos dizer pipelines de processamento de dados de ponta a ponta que precisam de pelo menos alguns milissegundos . Isso é chamado de tempo real suave. E é aqui que se encaixam Apache Kafka, Apache Pulsar, Redpanda, Azure Event Hubs, Apache Flink, Amazon Kinesis e plataformas semelhantes. Nenhum deles pode fazer hard em tempo real.
O tempo real rígido requer uma rede determinística com latência zero e sem picos . Cenários típicos incluem sistemas embarcados, barramentos de campo e PLCs em manufatura, carros, robôs, negociação de valores mobiliários, etc. Time-Sensitive Networking (TSN) é a palavra-chave certa se você quiser mais pesquisas.
Escrevi uma postagem de blog dedicada sobre por que o streaming de dados NÃO é difícil em tempo real . Portanto, não tente usar Kafka ou Redpanda para esses casos de uso. Isso é OT (tecnologia operacional), não TI (tecnologia da informação). OT é C simples ou Rust em software embarcado.
Sem ZooKeeper com Redpanda vs. sem ZooKeeper com Kafka
Além de ser implementado em C++ ao invés de usar a JVM, o segundo grande diferencial do Redpanda é não precisar do ZooKeeper e de dois complexos sistemas distribuídos… Bem, com o Apache Kafka 3.3, esse diferencial acabou. O Kafka agora está pronto para produção sem o ZooKeeper! O KIP-500 foi uma jornada de vários anos e uma operação no coração de Kafka.
Para ser justo, ainda levará algum tempo até que a nova arquitetura sem ZooKeeper entre em produção. Além disso, hoje, ele é suportado apenas por novos clusters Kafka. No entanto, os cenários de migração com tempo de inatividade zero e sem perda de dados também serão suportados em 2023. Mas é assim que um ciclo de lançamento severo funciona para um produto de software maduro: implementação passo a passo e testes de batalha em vez de começar com marketing e venda de recursos alfa e beta.
O streaming de dados sem ZooKeeper com Kafka não é apenas um grande benefício para a escalabilidade e confiabilidade do Kafka, mas também torna as operações muito mais diretas, semelhantes ao Redpanda sem ZooKeeper.
A propósito, esse foi um dos principais argumentos porque não vi o valor do Apache Pulsar. O último requer não apenas dois, mas três sistemas distribuídos: corretor Pulsar, ZooKeeper e BookKeeper. Isso é um absurdo e uma complexidade desnecessária para praticamente todos os projetos e casos de uso.
Redpanda leve + ecossistema pesado = transmissão de dados de peso médio?
Redpanda é muito leve e eficiente por causa de sua implementação C++ . Isso pode ajudar em ambientes de computação limitados, como hardware de ponta. Como consequência adicional, o Redpanda tem menos picos de latência do que o Apache Kafka . Esses são argumentos significativos para o Redpanda para alguns casos de uso!
No entanto, você precisa examinar o pipeline de dados de ponta a ponta completo. Se você usar o Redpanda como uma fila de mensagens, obterá esses benefícios em comparação com o mecanismo Kafka baseado em JVM. Você pode então escolher uma fila de mensagens como RabbitMQ ou NATs. Não começo esta discussão aqui, pois me concentro nos casos de uso de streaming de dados muito mais poderosos e avançados.
Mesmo em casos de uso de borda em que você implanta um único agente Kafka , o hardware, como um computador industrial (IPC), geralmente fornece pelo menos 4 GB ou 8 GB de memória. Isso é suficiente para implantar toda a plataforma de streaming de dados em Kafka e outras tecnologias.
O streaming de dados é mais do que mensagens ou ingestão de dados
Minha pergunta fundamental é: qual é o benefício de uma implementação C++ do hub de dados se todos os sistemas ao redor são construídos com tecnologia JVM ou tecnologias ainda piores e lentas como Python?
Ferramentas compatíveis com Kafka, como o Redpanda, integram-se bem ao ecossistema Kafka, pois usam o mesmo protocolo. Portanto, ferramentas como Kafka Connect, Kafka Streams, KSQL, Apache Flink, Faust e todos os outros componentes do ecossistema Kafka funcionam com o Redpanda. Você encontrará um exemplo para quase todas as ferramentas Kafka existentes no blog Redpanda.
No entanto, essas combinações matam quase todos os benefícios de ter uma camada C++ no meio. Todos os componentes de integração e processamento também precisariam ser tão eficientes quanto o Redpanda e usar C++ (ou Go ou Rust) sob o capô. Essas ferramentas não existem hoje (provavelmente porque não são necessárias para muitas pessoas). E aqui está uma desvantagem adicional: a infraestrutura de depuração, teste e monitoramento deve combinar plataformas C++, Python e JVM se você combinar ferramentas como Kafka Connect baseado em Java e Faust baseado em Python com Redpanda baseado em C++. Portanto, não entendo a proposta de valor aqui.
Replicação de dados entre clusters
Ter mais de um cluster Kafka é a norma, não uma exceção . Casos de uso como recuperação de desastres, agregação, soberania de dados em diferentes países ou migração do local para a nuvem exigem vários clusters de streaming de dados.
A replicação entre clusters faz parte do Apache Kafka de software livre. O MirrorMaker 2 (baseado no Kafka Connect) oferece suporte a esses casos de uso. Ferramentas mais avançadas (proprietárias) de fornecedores como Confluent Replicator ou Cluster Linking tornam esses casos de uso mais fáceis e confiáveis.
O streaming de dados com o ecossistema Kafka é perfeito como base de uma malha de dados descentralizada :
Como você constrói esses casos de uso com o Redpanda?
É a mesma história da integração de dados e processamento de fluxo: quanto ajuda ter um núcleo muito leve e de alto desempenho se todos os outros componentes dependem de bases de código e infraestrutura de “terceiros”? No caso de replicação de dados, o Redpanda usa o Mirrormaker de Kafka.
E certifique-se de comparar o MirrorMaker com o Confluent Cluster Linking – o último usa o protocolo Kafka para replicações e não precisa de infraestrutura adicional, operações, sincronização de deslocamento, etc.
Diferenças não funcionais entre Apache Kafka e Redpanda
As avaliações técnicas são dominantes quando se fala em Redpanda vs. Apache Kafka. No entanto, as diferenças não funcionais são cruciais antes de tomar a decisão estratégica de escolher a plataforma de streaming de dados para seu próximo projeto.
Licenciamento, curva de adoção e custo total de propriedade (TCO) são críticos para o sucesso do estabelecimento de uma plataforma de streaming de dados.
Código aberto (Kafka) vs. código disponível (Redpanda)
Como o nome diz, Apache Kafka está sob a muito permissiva licença Apache 2.0 . Todos, incluindo provedores de nuvem, podem usar a estrutura para criar aplicativos internos, produtos comerciais e serviços de nuvem. Committers e contribuições estão espalhados por várias empresas e indivíduos.
Redpanda é lançado sob a mais restritiva Source Available License (BSL) . A intenção é impedir que os provedores de nuvem ofereçam o trabalho da Redpanda como um serviço. Para a maioria das empresas, isso é bom, mas limita a adoção mais ampla em diferentes comunidades e fornecedores. A probabilidade de contribuidores externos, committers ou mesmo outros fornecedores escolherem a tecnologia é muito menor do que em projetos Apache como o Kafka.
Isso tem um impacto significativo na curva de adoção (futura) …
Maturidade, comunidade e ecossistema
A introdução deste artigo mostrou a impressionante adoção de Kafka. Lembre-se: Redpanda NÃO é Apache Kafka! Ele apenas suporta o protocolo Kafka.
Redpanda é um novo produto e implementação. As operações são diferentes. O comportamento do motor é diferente. Os especialistas não estão disponíveis. Ofertas de trabalho não existem. E assim por diante.
O Kafka está significativamente melhor documentado, tem uma comunidade tremendamente maior de especialistas e uma vasta gama de ferramentas de suporte que torna as operações mais diretas.
Existem muitas opções de treinamento Kafka locais e online, incluindo cursos online, livros, encontros e conferências. Você não encontrará muito sobre o Redpanda além do conteúdo do fornecedor por trás dele.
E não confie no marketing! Isso é verdade para todos os fornecedores, é claro. Se você ler uma ótima lista de recursos no site da Redpanda, verifique novamente se o recurso realmente existe e em que forma ele está. Exemplo: RBAC (controle de acesso baseado em função) está disponível para Redpanda. O diabo mora nos detalhes. Citação da documentação do Redpanda RBAC: “Esta página descreve o RBAC no Redpanda Console e, portanto, gerencia o acesso apenas para usuários do console, mas não para clientes que interagem por meio da API Kafka. Para restringir o acesso à API Kafka, você precisa usar ACLs Kafka.” Existem muitos exemplos semelhantes hoje. Apenas tente usar o serviço de nuvem Redpanda. Você encontrará muitas coisas que são mais alfa do que beta hoje. Certifique-se de nãocaem nos mesmos mitos em torno do marketing de recursos do produto que alguns usuários fizeram com o Apache Pulsar alguns anos atrás .
O custo total de propriedade e o valor comercial
Ao definir os requisitos de negócios e os SLAs do seu projeto, pergunte-se quanto tempo de inatividade ou perda de dados é aceitável . O RTO (objetivo de tempo de recuperação) e o RPO (objetivo de ponto de recuperação) afetam a arquitetura de uma plataforma de streaming de dados e o processo geral para garantir a continuidade dos negócios, mesmo no caso de um desastre.
O TCO não é apenas sobre o custo de um produto ou serviço em nuvem . Engenheiros em tempo integral precisam operar e integrar a plataforma de streaming de dados. Líderes de projetos caros, arquitetos e desenvolvedores criam aplicativos.
O risco do projeto inclui a maturidade do produto e o conhecimento que você pode trazer para consultoria e suporte 24 horas por dia, 7 dias por semana.
Semelhante ao benchmarking em relação à latência, os fornecedores usam a mesma estratégia para cálculos de TCO! Aqui está um exemplo concreto que você sempre ouve do Redpanda: “C++ permite um uso mais eficiente dos recursos da CPU”.
Esta afirmação está correta. No entanto, o problema com essa declaração é que Kafka raramente é vinculado à CPU e muito mais vinculado a IO. O Redpanda tem os mesmos requisitos de rede e disco que o Kafka , o que significa que o Redpanda tem diferenças limitadas do Kafka em termos de TCO em relação à infraestrutura.
Quando escolher Redpanda em vez de Apache Kafka?
Você precisa avaliar se o Redpanda é a escolha certa para o seu próximo projeto ou se deve ficar com o “verdadeiro Apache Kafka” e produtos relacionados ou ofertas de nuvem. Leia artigos e blogs, assista a vídeos, pesquise estudos de caso em seu setor, converse com diferentes fornecedores concorrentes e crie sua prova de conceito ou projeto piloto. Qualificar produtos é muito mais fácil do que avaliar muitas ofertas.
Quando considerar seriamente o Redpanda?
Você precisa de infraestrutura C++ porque sua equipe de operações não pode manipular e analisar logs JVM – mas esteja ciente de que este é apenas o núcleo de mensagens, não a integração de dados, processamento de dados ou outros recursos do ecossistema Kafka
As pequenas diferenças de desempenho são importantes para você - e você ainda não precisa de tempo real
Desenvolvimento simples e leve em seu laptop e em ambientes de teste automatizados - mas você também deve executar o Redpanda na produção (usar diferentes implementações de uma API para TEST e PROD é um antipadrão arriscado)
Você deve avaliar o Redpanda em relação às distribuições Apache Kafka e serviços em nuvem nesses casos.
Este post explorou as compensações que o Redpanda tem de uma perspectiva técnica e não funcional. Se você precisa de uma solução de nível empresarial ou serviço de nuvem totalmente gerenciado , um amplo ecossistema (conectores, recursos de processamento de dados etc. ) muitas razões pelas quais você correria o risco de adotar o Redpanda em vez de um produto Apache Kafka real ou serviço em nuvem.
O futuro nos dirá se o Redpanda é um competidor sério…
Eu nem cobri o fato de que uma startup sempre tem desafios para encontrar ótimos estudos de caso , especialmente com grandes empresas como empresas da Fortune 500. Os primeiros grandes logotipos são sempre os mais difíceis de encontrar. Às vezes, as startups nunca chegam lá . Em outros casos, uma tecnologia e um produto verdadeiramente competitivos são criados. Essa jornada leva anos. Vamos revisitar esta postagem do blog em um, dois e cinco anos para ver a evolução do Redpanda (e do Apache Kafka).
Quais são seus pensamentos? Quando você considera usar o Redpanda em vez do Apache Kafka? Você já está usando o Redpanda? Por que e para quais casos de uso? Conecte comigo e com o Kai no LinkedIn e vamos discutir isso! Mantenha-se informado sobre as novas postagens do blog assinando a newsletter.