Enfim um dos mais esperados conteúdos do curso de RabbitMQ está no ar. Event Driven Architecture.

Promessa desde 2021, o módulo de EDA Concept chega com novidades falando sobre EDA e desde os motivadores que conduziram as arquiteturas até chegar nesse estágio de desacoplamento.

Event Driven Architecture pode ser encarado por diversas perspectivas. O nome não é sugestivo o suficiente para explicar uma só coisa. Enquanto o design arquitetural está em formação há quem diga que Event Notification é Event Driven, há quem diga que CQRS é Event Driven, há quem fale que Transferência e Propagação de estado transportada por Eventos seja Event Driven, como aponta Fowler em seu post de 2017.

O assunto ainda é novidade para muitos, e complexo para outros. Mas o que fazemos do lado de dentro é formatar de forma a facilitar o entendimento desse tipo de desenho, tangibilizando no contexto do uso do RabbitMQ pra transportar esses eventos e comandos por todo o sistema.

Afinal, como chegamos a esse desenho? O que motivou?

Em um passado não tão distante escrevíamos monolitos assim.

Esse tipo de código tem a natureza procedural. Embora faça-se uso de classes e linguagem orientada a objetos, estamos encapsulando os casos de uso em procedures, usando uma infraestrutura de orientação a objetos simplesmente como fachada para as procedures. Essas procedures não estão no banco, é o código C# que é procedural.

Por sorte, acidente ou maturidade, a gente evoluiu, e então começamos a componentizar, reaproveitar código, e isolar responsabilidades em novas classes.

Mais tarde alguns componentes que tinham características especiais passam a ser chamados de serviços, diferenciando-os dos componentes internos ou de infraestrutura da aplicação.

Assim, com a componentização aquele mesmo código agora se parece com isso:

Nos beneficiamos com o reaproveitamento, com a redução das responsabilidades. Reduzimos a complexidade ciclomática mas… Faltava algo.

Mais à frente percebemos que usávamos pouco de fato da orientação a objetos, e que ela poderia garantir uma série de elementos se realizada seguindo algumas premissas. DDD nasce como molde para essas premissas. Domínio Rico, repositórios, linguagem ubuqua, domain services. Uma série de recursos novos que nos assegura maior isolamento.

Então juntando tudo, temos algo parecido com isso.

O acoplamento entre microsserviços

Mas… ainda podíamos enxergar certo nível de acoplamento entre serviços. Necessário pela própria necessidade de encadeamento de atividades dos fluxos de negócio.

No popular: Era necessário fazer um serviço chamar o outro para que as coisas funcionassem.

No entanto se um serviço precisa conhecer outro serviço, precisa conhecer sua existência, precisa realizar chamadas, saber como parametrizar, e se importa quando algo é alterado do lado de lá. Ou seja, temos um nível de dependência e acoplamento indesejado. Tolerado, sem deixar de ser indesejado.

Isso não parecia ser um problema no mundo monolítico. No entanto com os microsserviços esse tipo de acoplamento se torna um martírio. Na medida que times buscam independência e o menor nível de acoplamento possível, entre times, entre roadmaps, é necessário pensar em estratégias que proporcionem ainda um acoplamento ainda mais baixo.

Event Driven é uma resposta para esse acoplamento e para outros vários assuntos relacionado à distribuição de aplicações, principalmente no mundo de microsserviços.

Por que falar de Event Driven no curso de RabbitMQ?

Event Driven não faz sentido sem mensageria, no entanto mensageria pode caminhar sozinha sem nunca tocar no assunto EDA. Mas eu resolvi trazer o tema para dar vida ao assunto que eles estão vendo.

Mensageria é um tema disruptivo. Para que pudéssemos programar, sofremos uma lavagem cerebral, com a intenção de nos ensinar a pensar de forma lógica, step-by-step. Não é a toa que traduzimos exatamente isso para o código e toda vez que algo fere essa ordem, nos vemos perdidos.

O caos do mundo real, com eventos dos mais variados, acontecendo simultaneamente gera medo, confusão, e muitas vezes paralisa.

Quantas e quantas vezes eu vi desenvolvedores querendo tornar o consumo de filas uma tarefa ordenada e síncrona, sequencial. De forma a pensar em apenas 1 consumidor por vez, 1 consumidor por fila. É o tipo de coisa que tá errada já na ideia, está errado querer acesso serial e ordenado.

Eliminando as queries agendadas

Ao adotar Event Driven eles podem ver, na prática, como eliminar as queries por status e os foreaches para execução de novas etapas e fluxos: tudo acontece via mensageria. Isso me permite mostrar como tirar o banco de dados do estágio de sofrimento, mostrando executar um fluxo inteiro sem a necessidade dessas queries executadas a cada X tempo.

Isso se traduz em mais fôlego para o banco de dados que agora pode aguentar uma carga maior, sem nenhum esforço adicional.

Por outro lado, você só executará a tarefa quando seu processo pegar a mensagem, não necessariamente quando o usuário demandou. Isso quer dizer que você não precisa ofender seu banco de dados, simplesmente porque recebeu 10% a mais de tráfego em algum momento específico.

E por fim, não ficamos esperando o próximo loop, daqui a 5 minutos, para processar as novas mensagens. As mensagens são processadas por demanda, de acordo com a capacidade de processamento, online, no mesmo segundo. Essa é a eficiência que o RabbitMQ consegue entregar.

Para alguns, isso será traduzido em redução de custos, para outros isso será traduzido em uma capacidade maior de processamento. Para alguns, ambos.

No final das contas o que mais me chama a atenção é a capacidade de me desligar e pouco me preocupar com a pressão repentina.

Eu hoje tenho um cliente, um grande banco, que implementou o PIX com gRPC e estão voltando para mensageria.

Comandos e Eventos

Afinal, por que separamos mensagens nesses 2 estereótipos? Por que uma mensagem não pode ser apenas uma mensagem? Na verdade pode sim, mas se você pensa em implementar EDA, aí, de fato temos essa segmentação clara. Ela diz respeito à divisão de responsabilidades em quem produz mensagens e em quem consome mensagens.

Essa divisão pode parecer suave, serena, mas produz imensa confusão, descrença e desconfiança.

A tendência natural é que inadvertidamente produziremos, o que Fowler chama de, Evento/Comando Passivo-Agressivo. Uma mensagem que se parece simultaneamente com um comando e com um evento. E se fizermos isso, estamos jogando fora nossa implementação porque estamos produzindo o acoplamento de que estávamos fugindo.

Handlers/Adapters

Se de um lado, temos que demandar a continuidade de um fluxo, mas de outro não devemos fazer isso diretamente, como faremos? É aí que entram os handlers de eventos.

Aparentemente você poderia olhar para o eShopOnContainers para ver isso na prática. Exceto pelo fato dele realizar cada operação de negócio diretamente no consumo do evento. O que é traduzido em vazamento de responsabilidade, ferindo o isolamento do domínio.

O módulo

A função do módulo é ir da introdução à implementação usando esse tipo de imagens que você viu acima, no post, para elucidar como de onde viemos, onde estamos e para onde vamos com EDA.

São quase 2 horas de conteúdo, que vai do básico sobre acoplamento até o cenário distribuído de eventos e comandos. Esse módulo é a base para nossa implementação (em andamento) de e-commerce.

Se você estava esperando

Se você estava esperando algum momento bom para entrar no RabbitMQ para Aplicações .NET, chegou a hora. A função do curso é mostrar como usar RabbitMQ pra alcançar 5 objetivos.

DISPONIBILIDADE

Quando sua aplicação cai, ninguém precisa te ligar de madrugada. Quando um serviço de terceiros cai, sua aplicação não precisa cair também. Quando recupera-se, também tudo volta ao normal, sem que você tenha algum efeito que não seja o processamento acumulado durante a paralização. E esse acúmulo será processado devidamente em alguns minutos ou até horas dependendo da demanda

EFICIÊNCIA

Como eliminar as queries de tempos em tempos no banco, como usar o fluxo de mensageria para evitar esses gargalos. Como não ficar ocioso, e como lidar com cargas de trabalho de forma eficiente, sem produzir demandas de infraestrutura. Como extrair o máximo da sua infra, sem precisar gastar mais para isso.

Ao mesmo tempo caso você tenha problemas relacionados com o volume, tem tempo para tomar decisões sobre escala horizontal e vertical. Aliás você também ganha a habilidade de simplesmente acumular mensagens deixar que a pressão volte ao estágio normal, não precisando se preocupar com aumento de infraestrutura.

RESILIÊNCIA

As falhas vão existir e poder não se preocupar com isso é fantástico. Ou seja, serviços que você depende caem, ou mesmo quando um bug grave faz com que você não consiga concluir suas tarefas, você deve saber configurar o RabbitMQ para que ele seja o garantidor dessas mensagens.

CONFIABILIDADE

Aquelas mensagens que falhavam e se perdiam em requests que morriam. Agora não morrem mais. E podemos tratar proativamente.

ESCALABILIDADE

Escalar não será um problema. Agora, inclusive sem necessidade de um load balancer.

Event Driven, onde se encaixa?

Todos os 5 benefícios, por isso EDA é tão pertinente ao tema do curso. A segmentação em microsserviços que recebem comandos via Message Broker, dá o isolamento necessário para garantir Disponibilidade, Resiliência e consequentemente Confiabilidade. A infraestrutura que dá suporte é escalável e permite a escala de nossas aplicações. Ao mesmo tempo, abdicamos das queries por status, executadas de tempos em tempos e passamos a processar mensagens em real time, à medida que conseguimos processar, sem ofender nossa infraestrutura, mesmo que haja uma carga de trabalho elevada. Isso é traduzido em eficiência computacional. De quebra, ponto de vista de acoplamento, chegamos o mais próximo possível de suprimi-lo.

Infelizmente, como tudo na vida, e principalmente na tecnologia. Quando a esmola é muito, o santo desconfia. Sim EDA também tem seus tradeoffs, e aliás tem seus cuidados, principalmente com a separação clara entre eventos e comandos. Se você esteve presente em alguma implantação de SOA, já se deparou com a discussão infindável sobre modelos canônicos, né?! Pois bem! É sobre isso que estamos falando.

Por que estudar mensageria, em especial RabbitMQ?

Mensageria é o pilar garantidor da entrega de alguns dos benefícios na distribuição de aplicações em especial microsserviços. RabbitMQ continua consolidado como o principal message broker do mercado, um dos únicos sob o AMQP 0.9.x, que por sua vez é substancialmente diferente do AMQP 1.0, não podendo sequer ser comparado. Não é incomum que profissionais que só conhecem Amazon SQS ou Azure Service Bus, façam muita besteira ao usar RabbitMQ exatamente por isso.

Ao mesmo tempo a adoção de aplicações distribuídas usando mensageria cresceu nas empresas grandes, mas projetos pequenos também ganharam implementações pautadas em mensageria, como meio de aumentar sua sobrevida, e dar trazer alguns benefícios típicos de microsserviços. O que naturalmente causa uma demanda por entendimento do que está ao redor do assunto. E mensageria é um dos seus pilares.

No mundo real, no mundo físico, tudo acontece de forma assíncrona e caótica. Eventos e acontecimentos, que produzem novos eventos e acontecimentos em sequencia, de forma desordenada. Já quando falamos no mundo digital, naquele em que programamos, sofremos uma lavagem cerebral para que possamos lidar com ordenação, sequencia, encadeamento, e principalmente sincronismo. Faz parte do ato de aprender a programar, ignorar a sequencia aleatória e desordenada de fatos do mundo real, para nos fixarmos em resolver problemas, step-by-step, linha-a-linha, if-a-if, método-a-método. Não é a toa que threading e concorrência sejam considerados assuntos avançados e que geram muita confusão.

Quando adicionamos mensageria, processamento assíncrono e distribuído, voltamos ao caos, só que agora sem conhecer as regras desse jogo.

E meu papel aqui é formatar isso de forma a ser tão indolor quanto foi para você conhecer um banco de dados um dia.

Então fica aqui o meu convite para você participar da nossa turma.

RabbitMQ para Aplicações .NET

RabbitMQ para Aplicações .NET é meu curso de RabbitMQ. Uma resposta para o assunto que é demanda de um mercado que quer ver aplicações distribuídas, em especial microsserviços usando .NET.

Mensageria está no coração de microsserviços, ao ponto de sequer ser possível alcançar todos os benefícios da arquitetura, sem o emprego de mensageria.

O que por sua vez se traduz em complexidade. E RabbitMQ como principal message broker do mercado é sempre uma opção competitiva na decisão de qualquer arquitetura.

Aqui vai uma lista de quem declarou usar RabbitMQ lá no StackShare.

Hoje no Linkedin são 327 vagas para o termo RabbitMQ C#, por exemplo.

Assim, após quase 10 anos trabalhando com RabbitMQ falando de .NET e RabbitMQ aos 4 cantos, resolvi empacotar em um curso, o que aprendi ao longo dessa década resolvendo problemas e recuperando projetos.

Em janeiro de 2021 eu lancei um curso e agora em 2022 estamos fechando os últimos módulos.