Abordagens

Geralmente o Confluent costuma ser o melhor serviço de kafka SaaS. Possuí integração com várias ferramentas, é bem completo, vale a pena conferir.

Porém se quisermos instalar o Kafka auto gerenciado recomendo fortemente que se use Kafka dentro do Kubernetes. Apesar de ser possível a instalação bare metal com VMs, por que sofrer? Você quer essa responsabilidade? Quem vai manter? Pensa nisso....

Requisitos:

• docker ou algum outro container runtime
• kind ou algum cluster com pelo menos 3 nós workers.
• kubectl
• helm

Zookeper vs Kraft

A primeira abordagem que devemos entender é se devemos ou não utilizar o Zookeper para cooerdenação do cluster que iremos montar.

Primeiro devemos entender sobre Raft Consensus. Aqui no site tem uma matéria sobre Raft Consensus para ajudar a entender melhor o conceito.

Se quiser uma matéria para entender por que devemos utilizar o kraft aqui esta uma boa idéia de leitura.

Depois da leitura, você deve ter entendido que o Kafka Raft tem maior performance, menos tolerancia a falhas e menos grafação. Então se você está hoje preparando uma instalação para Kafka, utilize o novo padrão Kakfa Raft.

Auto Gerenciado ou SaaS

Se o cluster Kafka for muito grande, partir para uma solução SaaS, como a Confluent Cloud, pode fazer sentido por alguns motivos:

• Escalabilidade Automática
  • Gerenciar centenas ou milhares de tópicos e partições manualmente é complexo.
  • O Confluent Cloud escala automaticamente conforme a carga aumenta, sem precisar ajustar brokers ou partições manualmente.
• Menos Overhead Operacional
  • Em um cluster muito grande precisamos de uma equipe dedicada para gerenciar: Atualizações de versão do Kafka, Balanceamento de carga, Configuração de segurança (RBAC, ACLs, autenticação), Monitoramento e troubleshooting.
  • No SaaS, tudo isso é gerenciado pela Confluent, reduzindo o esforço da equipe.
• Alta Disponibilidade e Disaster Recovery
  • Manter um Kafka altamente disponível (HA) e com disaster recovery exige múltiplos clusters distribuídos e replicação entre regiões.
  • A Confluent já oferece isso pronto e gerenciado, com SLAs garantidos.
• Segurança e Compliance
  • Empresas grandes precisam garantir segurança de ponta a ponta (encriptação, IAM, logs de auditoria).
  • O Confluent Cloud já vem com suporte para compliance com GDPR, HIPAA, SOC 2, ISO 27001 etc.
• Custos vs. Equipe
  • Manter um cluster Kafka grande no Kubernetes (Strimzi ou CFK) exige muitos recursos: Infraestrutura potente (vários brokers, storage), Time especializado para operar o cluster
• No SaaS, você paga pelo uso e elimina custos operacionais, podendo focar no desenvolvimento das aplicações ao invés de gerenciar a infraestrutura.

Quando faz sentido ir para SaaS?

• Se o cluster cresce rápido e você quer evitar dores operacionais.
• Se precisa de alta disponibilidade e disaster recovery sem complicação.
• Se a empresa tem requisitos de segurança e compliance rigorosos.
• Se quer diminuir o time de infraestrutura e focar só na aplicação.

Se a sua infraestrutura for pequena ou moderada, um cluster autogerenciado ainda vale a pena. No entanto, faz sentido considerar uma solução SaaS quando o custo de manter seu próprio Kafka (equipe + infraestrutura) se torna excessivo.

Quando a operação cresce demais, não estamos apenas pagando pela conveniência, mas também terceirizando os desafios — e, de quebra, tendo alguém para assumir a responsabilidade quando algo der errado!

Instalação No Kubernetes

Antigamente a melhor maneira que eu conhecia de disponibilizar algo perto do que a Confluent oferecia era rodar vários diferentes helm charts: um helm chart do bitnami para instalação do Kafka, um chart para rodar o serviço do schema-registry (também do bitnami), um serviço kafka UI que me dava um dashboard e vários outros serviços agregados ao kafka que também eram instalados via Helm chart e podiam ser visualizados pela UI (ksql, connects, rest e control-center).

Felizmente hoje em dia temos um projeto na CNCF chamado Strimzi que facilita bastante a instalação de um cluster kafka dentro no Kubernetes.

Qual a vantagem?

• Deploya e executa clusters Kafka
• Gerencia componentes do Kafka
• Configura o acesso ao Kafka
• Protege o acesso ao Kafka
• Atualiza o Kafka
• Gerencia os brokers
• Cria e gerencia tópicos
• Cria e gerencia usuários
• Foca no controle do Kafka não nas ferramentas agregadas a ele.

Aqui temos aquela arquitura que já conhecemos do estudo, porém agora temos algumas coisinhas a mais.

• O Kafka Bridge (Já mensionando antes como Kafka Rest) fornece uma interface RESTful que permite que clientes baseados em HTTP interajam com um cluster Kafka. Ele oferece as vantagens de uma conexão HTTP API com o Strimzi para que clientes produzam e consumam mensagens sem a necessidade de usar o protocolo nativo do Kafka.

• Kafka Exporter extrai dados para análise como métricas do Prometheus, principalmente dados relacionados a compensações, grupos de consumidores, atraso do consumidor e tópicos. O atraso do consumidor é o atraso entre a última mensagem escrita em uma partição e a mensagem que está sendo atualmente coletada dessa partição por um consumidor.

• Kafka MirrorMaker (Não usaremos) replica dados entre dois clusters Kafka, no mesmo data center ou em locais diferentes.

Um cluster Kafka é composto por vários nós que operam como brokers que recebem e armazenam dados. Os tópicos são divididos por partições, onde os dados são gravados. As partições são replicadas entre os brokers para tolerância a falhas. O kafka costuma ser a espinha dorsal de tudo quando utilizado, tudo passa por ele,então vamos pensar na redundância.

Strimzi vs Confluent for Kubernetes (CFK)

Podemos instalar um cluster Kafka completo utilizando o Strimzi ou o Confluent for Kubernetes (CFK). Ambos utilizam o conceito de Operators, que trabalham com Custom Resource Definitions (CRDs) no Kubernetes para facilitar a instalação e configuração dos componentes do Kafka.

O Strimzi foca exclusivamente na gestão do cluster Kafka, oferecendo suporte para brokers, Zookeeper, Kafka Connect e MirrorMaker. No entanto, não inclui diretamente componentes como Schema Registry, KSQL e interfaces gráficas. Talvez isso mude no futuro, mas atualmente esses recursos precisam ser gerenciados separadamente.

Já o CFK gerencia todo o ecossistema Confluent, incluindo o Kafka, o Schema Registry, KSQL e Control Center, tudo sob um único Operator. No entanto, ele tem duas versões:

• Community – gratuita, mas com funcionalidades limitadas.
• Enterprise – paga, com recursos avançados como RBAC, Multi-Tenancy e Observabilidade.

Se a intenção for pagar, talvez faça mais sentido utilizar o SaaS da Confluent, em vez de deployar tudo no Kubernetes.

Embora seja possível usar somente o CFK para instalar o Kafka, existem algumas desvantagens em relação ao Strimzi, que tornam este uma opção melhor:

• Kafka Open Source Puro
  • O Strimzi segue 100% o Apache Kafka open-source, sem dependência de um vendor específico.
  • O CFK instala a versão Confluent do Kafka, que pode trazer limitações na versão Community e exigir licenciamento para certas funcionalidades.
• Menos Dependência de Software Proprietário (Vendor Lock-in)
  • Com o Strimzi, você mantém o controle total do seu ambiente e pode migrar ou personalizar seu cluster Kafka sem restrições.
  • O CFK pode gerar dependência da Confluent, especialmente se você precisar de funcionalidades que só existem na versão Enterprise.
• Leveza e Eficiência
  • O Strimzi é mais enxuto e focado exclusivamente no Kafka, sem trazer dependências desnecessárias.
  • O CFK, por outro lado, gerencia Kafka + Schema Registry + KSQL + Control Center, o que pode ser um overkill caso você só queira rodar Kafka.
• Melhor Integração com Kubernetes
  • O Strimzi foi criado especificamente para Kubernetes, seguindo padrões nativos de Operators e CRDs.
  • O CFK também usa CRDs, mas seu foco maior é reproduzir o ecossistema Confluent dentro do Kubernetes, o que pode adicionar complexidade desnecessária.
• Comunidade Ativa e Independente
  • O Strimzi é um projeto CNCF (Cloud Native Computing Foundation), com suporte da comunidade e alinhado ao ecossistema Kubernetes.
  • O CFK é mantido pela Confluent, e seu desenvolvimento está mais atrelado à estratégia comercial da empresa.

Apesar de suas desvantagens para gerenciar o Kafka, o CFK facilita a instalação do Confluent Schema Registry, KSQL e Control Center dentro do Kubernetes se for utilizar algum desses recursos faz sentido utilizá-lo.

Não vamos utilizar nenhum desses recursos do CFK pelo seguinte motivo.

• Se utilizarmos o Confluent Schema Registry

Com essa abordagem híbrida, conseguimos o melhor dos dois mundos:

• Strimzi para gerenciar o Kafka (leve, flexível e sem lock-in).
• CFK apenas para Schema Registry e outros serviços (facilidade de deploy).

Dessa forma, evitamos dependências desnecessárias e mantemos o Kafka mais leve e independente, enquanto ainda aproveitamos a facilidade de deploy dos componentes adicionais da Confluent.

Schema Registry e KsqlDB

Já que o Strimzi não fornece um Schema Registry nativo em seu conjunto de funcionalidades é necessário optar por uma ferramenta externa.

Não falaremos sobre Avro ou Protobuf aqui, somente uma ferramenta que te possibilita registrar seus schemas para serializar e deserializar mensagens.

Se você planeja usar o Schema Registry da Confluent internamente na sua empresa, sem oferecer serviços que competem com os produtos SaaS da Confluent, então você pode usar essas ferramentas sem pagar por uma licença.

No entanto, é importante notar que se você precisar de funcionalidades avançadas do Schema Registry, como segurança ou validação de esquemas, essas podem exigir uma licença Confluent Enterprise. Mas para uso interno básico, o Schema Registry da Confluent pode ser utilizado sem custos adicionais. O mesmo vale para o KsqlDB (antigo Ksql).

Em outro momento gostaria de falar mais sobre schema registry e explorar outras alternativas, como por exemplo o Apicurio que aparemente até agora o único schema registry na CNCF. Como falei anteriormente, se o cluster kafka crescer demais ao ponto de vale a pena uma migração para o Confluent Cloud já estaremos usando ferramentas desenvolvidas por eles.