 |
| Bellacosa Mainframe e uma comparação ibm mq versus kafka |
☕ Um Café no Bellacosa Mainframe
IBM MQ vs Kafka sem Mistérios para Programadores COBOL
Quando um Programador Descobre que Voltar no Tempo é Fácil no DeLorean... Difícil Mesmo é Dar Rollback em uma Transação Bancária
"Estradas? Para onde vamos, não precisamos de estradas." — Doc Brown
No universo Bellacosa Mainframe, porém, Doc Brown provavelmente corrigiria sua famosa frase:
"Mensagens? Para onde vamos, não precisamos apenas de mensagens. Precisamos de COMMIT."
Porque existe uma enorme diferença entre viajar pelo tempo e viajar com dados corporativos.
Um erro temporal pode fazer Marty McFly apagar sua própria existência.
Um erro numa transação bancária pode fazer desaparecer milhões de reais.
E é justamente aqui que entram dois dos maiores protagonistas da arquitetura moderna:
IBM MQ e Apache Kafka.
Embora muita gente os coloque no mesmo ringue, como se fossem dois boxeadores disputando o cinturão mundial da mensageria, a verdade é outra.
Eles nasceram para resolver problemas completamente diferentes.
Hoje vamos embarcar no DeLorean do Bellacosa Mainframe para visitar quarenta anos de evolução dos sistemas distribuídos e descobrir por que o IBM MQ continua sendo uma das tecnologias mais importantes do planeta para sistemas críticos.
Aperte o cinto.
Configure o Flux Capacitor para 88 mph.
E cuidado para não provocar um ABEND em 1955.
1985: O primeiro salto temporal
Imagine Marty chegando em Hill Valley.
Ele altera um pequeno evento.
Resultado?
Toda a linha do tempo muda.
Nos computadores acontece exatamente a mesma coisa.
Imagine um banco executando uma transferência.
Debita R$ 10.000 da conta A.
Cai a energia.
Nunca credita a conta B.
Parabéns.
Você acabou de criar uma linha temporal alternativa.
No universo do COBOL isso recebe outro nome:
Estado inconsistente.
É exatamente para impedir esse tipo de paradoxo que existem as transações.
O verdadeiro Flux Capacitor chama-se COMMIT
No filme, o Flux Capacitor garante que Marty chegue inteiro ao passado.
Nos sistemas corporativos existe um equivalente.
Ele chama-se:
COMMIT.
Enquanto o COMMIT não acontece...
Nada realmente existe.
É como se todo o processamento estivesse preso num universo paralelo.
Somente quando o commit é confirmado, aquela realidade passa oficialmente a existir.
Se o COMMIT nunca acontecer...
Imagine Doc Brown ligando o DeLorean.
A viagem começa.
Mas o capacitor falha.
Resultado?
A viagem inteira é cancelada.
É exatamente isso que um rollback faz.
Tudo volta ao estado anterior.
Como se nada tivesse acontecido.
IBM MQ nasceu para impedir paradoxos temporais
Quando a IBM criou o MQSeries (hoje IBM MQ), o objetivo nunca foi ser o software mais rápido do planeta.
O objetivo era outro.
Nunca perder uma mensagem.
Existe uma enorme diferença.
Velocidade é importante.
Confiabilidade é indispensável.
Kafka nasceu em outro universo
Apache Kafka surgiu décadas depois.
O problema era completamente diferente.
LinkedIn precisava registrar:
Bilhões de cliques.
Bilhões de visualizações.
Logs.
Eventos.
Métricas.
Streaming.
Analytics.
Machine Learning.
Não importava se um clique perdido acontecesse ocasionalmente.
O importante era processar milhões por segundo.
A analogia do DeLorean
Imagine dois veículos.
O DeLorean
Transporta uma única missão extremamente importante.
Não pode falhar.
É o IBM MQ.
Um trem-bala japonês
Transporta milhares de passageiros continuamente.
É o Kafka.
Os dois são excelentes.
Mas para objetivos completamente diferentes.
O problema da viagem temporal distribuída
Agora imagine uma viagem muito mais complicada.
Marty precisa alterar cinco épocas diferentes simultaneamente.
1985 Alternativo.
Todas precisam terminar corretamente.
Ou nenhuma pode acontecer.
É exatamente isso que faz uma transação distribuída.
XA Transaction
XA é uma especificação criada para coordenar vários recursos diferentes.
Imagine uma orquestra.
Cada músico representa um sistema.
Db2.
Oracle.
IBM MQ.
IMS.
JMS.
Todos precisam tocar exatamente a mesma música.
No mesmo instante.
Se um violinista errar...
Toda a apresentação para.
Two Phase Commit
Aqui aparece o verdadeiro maestro.
O Transaction Manager.
Ele faz duas perguntas.
Primeira fase
"Todos estão preparados?"
Db2
— Sim.
MQ
— Sim.
Oracle
— Sim.
Ninguém grava nada ainda.
Todos apenas levantam a mão.
Segunda fase
O maestro pergunta novamente.
"Posso executar?"
Agora todos respondem.
Sim.
Somente agora tudo é gravado.
Ou...
Caso alguém responda NÃO...
Todos desfazem absolutamente tudo.
Easter Egg nº 1
No filme, Doc Brown nunca aperta o acelerador antes de conferir o Flux Capacitor.
No mundo corporativo, um arquiteto nunca faz COMMIT antes de verificar se todos os recursos responderam "Prepare".
Porque isso importa?
Imagine pagar um boleto.
A aplicação faz:
Atualiza Db2
↓
Envia mensagem MQ
↓
Atualiza saldo
↓
Gera comprovante
↓
Envia SMS
↓
Atualiza limite
Agora imagine que o servidor reinicie exatamente entre o passo três e quatro.
Sem XA...
Você pode ter:
Dinheiro debitado.
Sem comprovante.
Sem mensagem.
Sem auditoria.
Um pesadelo.
IBM MQ resolve isso elegantemente
Quando o MQ participa de uma transação XA, ele espera o Transaction Manager.
Nada é entregue definitivamente.
Nada desaparece.
Tudo permanece consistente.
Persistent Message
Uma das maiores forças do IBM MQ.
Existem dois tipos de mensagens.
Persistent.
Non Persistent.
Persistent
Antes de responder:
"Mensagem recebida."
O Queue Manager grava tudo em disco.
Mesmo que falte energia.
Mesmo que o servidor exploda.
Mesmo que haja reboot.
A mensagem continua lá.
Curiosidade
Essa característica fez do MQ um dos pilares dos bancos durante décadas.
Enquanto aplicações inteiras eram reiniciadas...
As filas permaneciam intactas.
Rollback
Agora vem uma das maiores mágicas do processamento transacional.
Imagine escrever um cheque.
Assinar.
Carimbar.
Guardar.
Depois descobrir que o saldo é insuficiente.
Rollback significa destruir completamente aquela operação.
Como se ela jamais tivesse existido.
Marty McFly e o Rollback
No primeiro filme, Marty começa a desaparecer da fotografia.
Felizmente consegue corrigir a linha temporal.
No mundo do IBM MQ isso acontece automaticamente.
Rollback restaura a fotografia original.
Kafka pensa diferente
Kafka trabalha com outro paradigma.
Eventos.
Streaming.
Replay.
Histórico.
Retenção.
Consumidores independentes.
É quase uma máquina do tempo.
Os eventos ficam armazenados por dias, semanas ou meses.
Você pode voltar e "reassistir" os acontecimentos.
Essa é uma diferença fascinante.
MQ normalmente preocupa-se com entregar a mensagem.
Kafka preocupa-se também em preservar o histórico de eventos para que consumidores possam relê-los.
Throughput
Throughput significa capacidade de processamento.
Imagine duas rodovias.
Rodovia A.
Passam cem caminhões por minuto.
Rodovia B.
Passam cem mil carros por minuto.
Kafka foi projetado para a segunda situação.
IBM MQ prefere outra pergunta
Não pergunta:
"Quantas mensagens?"
Pergunta:
"Quantas mensagens chegaram corretamente?"
Essa diferença muda completamente a arquitetura.
Exactly Once
Esse termo gera muita confusão.
Existem três possibilidades.
At Most Once
Pode perder.
Nunca duplica.
At Least Once
Nunca perde.
Pode duplicar.
Exactly Once
Nem perde.
Nem duplica.
No IBM MQ isso é obtido por sessões transacionais e commit/rollback.
No Kafka, há recursos de exatamente uma vez dentro do ecossistema Kafka (produtores idempotentes, transações e Kafka Streams), mas quando entram bancos de dados e outros sistemas externos, normalmente usam-se padrões como Transactional Outbox, CDC e Saga, em vez de XA distribuído.
MongoDB
Existe uma observação muito interessante.
MongoDB suporta transações internas.
Mas não participa do padrão XA tradicional.
Por isso arquiteturas modernas normalmente utilizam:
Transactional Outbox.
CDC.
Saga Pattern.
Compensating Transactions.
Tudo isso substitui o velho Two Phase Commit quando múltiplos recursos heterogêneos estão envolvidos.
Alta Disponibilidade
Imagine Hill Valley sendo atingida por um raio.
Mesmo assim.
O sistema continua funcionando.
IBM MQ possui recursos empresariais como:
Multi Instance Queue Manager.
HA.
Disaster Recovery.
Logs.
Journal.
Replicação.
Failover.
No z/OS pode integrar-se ao Parallel Sysplex para disponibilidade extraordinária.
Disaster Recovery
Imagine perder um Data Center inteiro.
Mesmo assim.
As mensagens continuam existindo.
É exatamente isso que faz o Journal do MQ.
Easter Egg nº 2
No filme existe uma torre do relógio.
Ela registra um instante histórico.
No IBM MQ existe o Journal.
Ele registra cada passo importante da vida das mensagens.
JMS
Muitos iniciantes confundem.
JMS NÃO é um broker.
JMS é uma API.
Ela permite que aplicações Java conversem com IBM MQ, ActiveMQ, Artemis e outros provedores de mensageria sem ficarem presas a uma implementação específica.
Spring Boot
Hoje é extremamente comum encontrar:
Spring Boot
IBM MQ
Db2
@Transactional
JTA
Tudo trabalhando junto.
Uma única anotação Java coordena diversos recursos corporativos.
É como Doc Brown sincronizando todos os relógios de Hill Valley.
Onde cada tecnologia vence?
Imagine um banco digital.
Cliente faz PIX.
↓
COBOL no CICS processa.
↓
Db2 grava.
↓
IBM MQ garante entrega.
↓
Kafka distribui eventos.
↓
Machine Learning detecta fraude.
↓
Dashboard atualiza em tempo real.
Percebe?
Nenhuma tecnologia substitui completamente a outra.
Elas cooperam.
Curiosidade histórica
O IBM MQ surgiu como MQSeries, em 1993, para facilitar a comunicação confiável entre aplicações distribuídas em diferentes plataformas. Ao longo das décadas evoluiu para integrar z/OS, AIX, Linux, Windows e ambientes em nuvem, mantendo como principal característica a confiabilidade.
O Apache Kafka nasceu no LinkedIn e foi aberto como projeto da Apache Foundation em 2011. Sua proposta revolucionou o processamento de eventos em larga escala, tornando-se um dos pilares das arquiteturas orientadas a eventos modernas.
São tecnologias de épocas diferentes, criadas para resolver dores diferentes.
Dicas para o Padawan COBOL
Se você está começando no mundo mainframe, siga esta ordem de estudos:
Entenda primeiro o conceito de transação e por que ela existe.
Aprenda os fundamentos de COMMIT e ROLLBACK em Db2 e CICS.
Estude o funcionamento de uma Queue, incluindo mensagens persistentes e não persistentes.
Pratique o envio e recebimento de mensagens com IBM MQ em programas COBOL ou Java.
Compreenda como JMS abstrai o acesso ao MQ em aplicações Java.
Só depois mergulhe em Kafka, Event Streaming, CDC, Outbox e Saga. Você entenderá muito melhor quando conhecer primeiro a base transacional.
O que um arquiteto experiente realmente pergunta?
O iniciante pergunta:
"Qual tecnologia é melhor?"
O arquiteto pergunta:
"Qual problema estou tentando resolver?"
Se o problema é transmitir milhões de eventos para dezenas de consumidores independentes, Kafka provavelmente será a escolha natural.
Se o problema é garantir que uma transferência financeira de R$ 500.000,00 nunca fique pela metade, IBM MQ é uma das respostas mais sólidas já criadas.
Essa mudança de perspectiva separa quem conhece ferramentas de quem entende arquitetura.
O Grande Ensinamento do Dr. Emmett Brown
No final de De Volta para o Futuro, Doc Brown aprende que pequenas mudanças podem alterar completamente a história.
Nos sistemas corporativos acontece exatamente o mesmo.
Uma única mensagem perdida pode gerar:
É por isso que bancos, seguradoras, bolsas de valores e governos continuam investindo em tecnologias como IBM MQ mesmo décadas após sua criação.
No Bellacosa Mainframe, existe uma máxima que todo Padawan COBOL deveria gravar como se fosse escrita na lateral do próprio DeLorean:
"Velocidade impressiona. Escalabilidade encanta. Mas é a consistência que mantém a máquina do tempo da empresa funcionando sem criar paradoxos financeiros."
E talvez esse seja o maior segredo da computação corporativa.
No cinema, Doc Brown precisava de 1,21 gigawatts para viajar no tempo.
No mundo dos mainframes, um arquiteto experiente precisa apenas de quatro palavras para evitar um desastre que poderia alterar a história inteira de uma empresa:
COMMIT. ROLLBACK. MQ. CONSISTÊNCIA.
