Esse é um post resposta ao post POR QUE ADOTAR KAFKA PARA MENSAGERIA? do Elemar JR no site da Eximia, sua empresa.

A resposta estava ficando longa demais, e resolvi transformar em post. Principalmente por se tratar de um conteúdo (RabbitMQ) que está no meu toolset, assim como Kafka está para entrar. Vou aproveitar para usar essas resposta para compor a seqüência de posts da série RabbitMQ de A a Z, pois essa questão RabbitMQ vs Kafka foi um tema solicitado pela audiência e não foi respondida na época.

Primeiro vai meu pedido de desculpas. O argumento da resposta não ter sido publicada era a falta da compreensão a respeito de Kafka. Como ainda não fiz nenhuma implantação baseada em Kafka, e não havia estudado o projeto em profundidade, não seria possível sanar as dúvidas da audiência. Embora tivesse realizado diversas imersões no universo do kafka, algumas questões a respeito de sua arquitetura só se fecharam recentemente.

O coração da pergunta

A questão central é o uso de Kafka em detrimento ao uso de RabbitMQ, em cenários de mensageria.

É um excelente tema para começarmos o aprofundamento em temas importantes, problema que que citei no fim do post The Microservices Journey – S1E1. Essa discussão enriquece nossa blogosfera técnica!

A imponência dos cases

Quando as pessoas olham impressionadas para o Stackshare vendo Uber, Spotify, Slack Coursera, Digital Ocean usando Kafka, é natural que essa publicização produza autoridade ou respalde o projeto. Além disso, é comum que se parta do pressuposto do abismo entre grandes players e nossa própria realidade. Então subjugamo-nos incapazes de tomar nossas próprias decisões, e assumimos que nossa perspectiva é limitada.

Isso parece complexo do “arquiteto” vira-lata.

De fato, à primeira vista parece prudente, principalmente pois se olharmos SUPERFICIALMENTE ambas as soluções, veremos alguma similaridade em sua aplicabilidade. Ok, que essa similaridade só dura até a página 2, mas é o que se enxerga em uma folheada superficial.

A superficialidade é o coração dos problemas das decisões erradas tomadas por times de tecnologia.

O reflexo direto dessa superficialidade é a falta de compreensão do que é um message broker e o que é uma stream platform.

Message Broker

Um message broker é um middleware, um mediador, que intermedia a comunicação entre 2 atores. De um lado publishers publicam mensagens em um message broker, enquanto do outro lado consumers consomem essas mensagens.

RabbitMQ de forma simples, objetiva e direta.

Gepostet von Luiz Carlos Faria am Samstag, 22. Dezember 2018

Acima, em menos de 1 minuto, temos a anatomia geral de um Message Broker em especial RabbitMQ. Azure Service Bus tem os mesmos conceitos, implementados de forma diferente.

É só isso?

Sim, só! Demais elementos são conexões, usuários, segurança, enfim: infraestrutura.

Se você entender que RabbitMQ é só isso, você sai na frente de 70% das pessoas que não entendem RabbitMQ. Não há resto, não há outros elementos a serem compreendidos. É simples assim, raso assim.

RabbitMQ não chama sua API, ele não sabe falar HTTP, ele não sabe acessar banco, nada disso. Ele tem um provider nativo em que você se conecta nele para consumir mensagens.

RabbitMQ não pega dados de um banco, é você, via código, que deve publicar mensagens nele.

Os patterns residem na forma de uso das exchanges e queues. E são dezenas de formas de uso. Para cada objetivo há uma forma de usar Filas e Exchanges, com roteamentos e configurações diferentes.

Stream Platform

Uma plataforma de stream é uma linha do tempo de eventos. Oferece mecanismos para processamento, transformação e captação desses eventos. Esse processamento pode ser de fato o processamento de negócio sobre os eventos, ou o processamento pode simplesmente produzir novas streams de eventos enriquecidos/transformados.

A vantagem desse modelo é a natureza persistente dos eventos, que tendem a durar em uma stream por muito tempo e é até comum durarem por toda a vida da aplicação.

Enquanto em um Message Broker, a dinâmica é entregar a mensagem para o Broker, para que o Broker entregue para os devidos consumidores, em um Stream Platform, a mensagem permanece na stream para ser processada. Esse processamento pode ser contínuo e imediato ou não.

Uma vantagem do modelo de Stream platforms é a capacidade de reprocessamento.

Sobre resiliência

Não há comparativo de resiliência que aponte para nenhuma das soluções como melhor.

Afinal, quem é melhor?

Enquanto RabbitMQ foi desenhado seguindo o pattern de mensageria, que é mais simples e tende a ser ideal para uma quantidade de cenários maior, plataformas Kafka ganha notoriedade exatamente pela capacidade de oferecer reprocessamento. Uma vez que a mensagem não é descartada nunca* a capacidade de reprocessar uma mensagem é algo trivial e isso pode fazer uma diferença significativa.

Uma característica única e exclusiva das plataformas de stream, é a capacidade de realizar agregações, de forma a produzir métricas baseadas em janelas de tempo.

O ponto crucial na decisão entre RabbitMQ e Kafka é se você pretende ou não armazenar e reprocessar eventos armazenados. Se sim, Kafka é para você. Se não, RabbitMQ tem o melhor fit.

Eu já ouvi falar de cenários em que os 2 são empregados. Algo que apenas ouvi falar, mas sinceramente nunca vi.

Why RabbitMQ?

RabbitMQ está sob um standard de mercado, o AMQP, isso o torna automaticamente compatível com milhares de soluções. Você já viu um ESB ou um Servidor de aplicação que use Kafka para enfileiramento? Não! Simplesmente pois não faz sentido.

De qualquer forma a escolha que fiz pelo RabbitMQ em 2014 leva mais ou menos os mesmos aspectos que me levariam a usar RabbitMQ em detrimento do Kafka hoje.

1) O Standard. AMQP me possibilita trabalhar não somente com RabbitMQ, mas com outras implementações que podem concorrer entre si e essa concorrência produz variações de design, como é o caso do Azure Service Bus, por exemplo.

2) A adoção de um standard em vez de uma implementação proprietária, me favorece na medida que qualquer implementação baseada em JMS, por exemplo, geralmente tem do lado uma implementação AMQP. Seja no JBOSS, ou websphere, ou em ESB’s.

Usar AMQP como transporte é uma atividade comum, cotidiana, normal. Até para RPC, como em plataformas de chatbot.

Outra vantagem, longe do AMQP são os outros protocolos, como MQTT e STOMP.

Esses são bons argumentos que me fazem olhar para o RabbitMQ como primeira opção. Nada contra o Kafka, mas se eu não pretendo manter a mensagem armazenada para reprocessamento, ou se não faz tanto sentido pipelines de enriquecimento de mensagem, definitivamente eu tendo a não usar.

Stream platform é stream platform, Message broker é message broker….

Why Kafka

Algumas características do Kafka fazem sequer haver uma discussão a respeito de se uso, se sua resposta for sim para algumas dessas perguntas, kafka é para o teu cenário:

• Você pretende manter mensagens antigas?
• Você pretende reprocessar mensagens antigas?
• Consumidores novos devem poder ler mensagens antigas?
• Após o processamento, se a mensagem for deletada, há algum problema para a sua solução?

Qualquer resposta positiva para as perguntas acima te empurram diretamente na direção do kafka.