Entendi. E outra coisa aqui. Nessa arquitetura de microsserviços, vocês adotaram algum ferramental de monitoramento? Como vocês fazem o tracing de tudo isso? Quer falar do MSK? 

Pode ser, mas é que, no final, a gente usa o New Relic. Por trás Tinha a ideia de... Na época, não tinha o OpenTelemetry. O OpenTelemetry ainda também não está aquelas coisas, não tem tracing, nem log. E a gente criou uma biblioteca para encapsular o New Relic. Possivelmente, o New Relic também é caro para caramba. Se a gente precisar tirar, é só substituir o SDK por trás e fazer as chamadas corretas. Então, foi de onde veio o Hermes, que está até atrelado ao Pipes, que faz todo a... cria o transaction de ponta a ponta e vai repassando em cada um dos passos na mensagem que vai pelo Kafka. Então, você tem a sequencialidade por onde está indo e vai reportando para o New Relic, onde a gente tem os dashboards que a gente acompanha. 

E a gente colocou nele também a padronização dos logs. E a parte de tracing, em geral, o que pega é o... Bom, a gente já fazia antes mandar um trace ID nas mensagens, sempre nos logs sem ele e nas transações no New Relic também, para poder fazer a visão do tracing distribuído, de olhar entre os serviços todos. Isso a gente manteve e ele mantém também o padrão dos logs. Então, para fazer essa busca também do, eventualmente, que aconteça com uma transação específica.

E vocês estão usando o modelo de orquestração, certo? Qual foi o motivo da escolha? Eu acho que o motivo da escolha foi logo no começo da apresentação. Eu acho que isso foi logo no começo da apresentação. Eu acho que isso, olhando o começo da apresentação, mostra a loucura que estava acontecendo. Então, você conseguindo garantir os passos de entrada e de saída, eu acho que resolveram o problema. Um detalhe…

peraí. A gente usa a coreografia, na realidade, porque olhando para os dois a gente entendeu como um risco eu ter um dono da verdade no meio do que a gente estava querendo fazer e a gente, quando entendeu o como o “sabe” próximo passo. O como fazer isso. Isso aqui cai como uma luva para a gente mandar para frente, vai para trás e também as variações de caso de uso que a gente falou, que eu posso ter uma criação de ordem, que ela segue passos diferentes, dependendo do cliente, o grau de parceria que eu tenha com ele. Então, é mais essa linha, então, é a coreografia. O pseudo-orquestrado está mais ali no solenoid, quando ele vai tomar alguma ação, mas a gente nem usa ali tanto a orquestração ou o nome porque não é o princípio mesmo da literatura, a gente está tentando achar o nome. Chamou de monitor, como o melhor nome para a gente mesmo não se confundir.

 Eu acho que é importante organizar esses conceitos, porque é o seguinte, toda vez que um microsserviço chama o outro, que depois chama o outro, que vai chamando o outro, independente se isso está caindo numa parte, sendo de forma assíncrona, através de tópicos, isso por padrão, é coreografia. Quando a gente está falando de orquestração, no final das contas, significa que você tem um orquestrador, ou seja, um cara responsável por garantir o estado de cada etapa e ele mostra para todo mundo especificamente qual é o estado que aquele cara está naquele momento. Então, normalmente o pessoal fala muito de saga pattern. Basicamente, você cria uma nova saga falando: Iniciou uma nova transação. Os passos vão ser de 1 a 5. E cada vez que você faz um passo, avisa o cara da saga para o saga falar assim: Olha, terminei. Então, a todo momento, você consegue ter o controle do que está acontecendo em todas aquelas transações. Você consegue dar mais alguns exemplos e falar um pouquinho rapidamente sobre a saga e essa diferença de coreografia, Rafael? 

Sim, acho que o ponto principal que o saga traz é em relação a ter as rotinas de compensação. É a parte mais densa que tem ali, que é a parte do desfazimento, que é onde a gente tem a maior dor. Quando erros acontecem, eu garantir que eu estou desfazendo tudo o que tenho que eu tenho que desfazer, de forma limpa. Então, no nosso caso aqui, o que a gente tinha era os erros, como a gente nomeava internamente, basicamente saldo preso e ordem fantasma. Acontecia. O que era a ordem fantasma? O cliente via o estado, tipo, essa ordem está aberta. Tentava cancelar e não cancelava. Sim. E sim, justamente porque a rotina de cancelamento dependia de passar por outro sistema que nele estava cancelado, mas no primeiro não estava, uma baita zona. Justamente porque em algum passo eu tive um erro, tive alguma coisa, e eu não fiz um rollback em todas as minhas bases como eu deveria ter feito. Então, ou mesmo se alguma coisa... Esse é o ponto principal que o Saga traz para a gente. Então, vai falar muito da parte sobre a rotina de compensação, o principal, e depois são os mecanismos de controle. E tem essa parte, como o Wesley falou. Se eu tenho um sistema A que chama sistema B, sistema C direto, chama da coreografia porque eu não preciso de um mediador para dizer qual é o próximo passo. Eles já sabem se resolver na cadeia. Isso tanto na ida como na volta. E o orquestrador é literalmente um cara no meio, como se fosse um maestro, dizendo, agora vai você ali para colocar: você vai fazer essa ação depois do primeiro. 

Então, vantagens e desvantagens. Em geral, o próprio Chris Richardson coloca no curso dele, no livro também, sobre microsserviços. Ele falou, no orquestrado, em geral, a gestão das regras é mais fácil porque fica num lugar só. Então, você tem as regras do jogo, você sabe onde elas estão. 

Você não precisa ficar mandando lá no kafka o step 1, 2, 3 e 4. Isso já está tudo definido no orquestrador. 

Vai estar… provavelmente vai ter um banco de dados ali no step 1, 2, 3, 4, naquele lugar. Ou um arquivo de configuração, o que for, mas está em um lugar. Esse é o ponto principal. A parte da governança que eu falei, que a gente tem que fazer, é porque hoje,  eu tenho um init no serviço, num produto. O meu próximo produto tendo um init, está naquele código de steps. Hoje, na versão atual. Então, eu preciso centralizar pelo menos o motor das regras. Mesmo que eu, de alguma forma, se eu deixar mega espalhado pela empresa, cada lugar coloca quais são os seus passos, em algum momento a gente vai ter um problemão de visibilidade, de rastreabilidade do que está acontecendo. Então, a vantagem do orquestrado é justamente você centralizar isso. Na arquitetura, porque você tem, literalmente, um serviço responsável. Então, está num lugar só a regra de quais são os passos, qual é a ordem deles. A desvantagem é justamente ser um serviço só. Se ele cair, ferrou. Você tem o ponto único de falha ali. A coreografia,  já fica a parte do... Parece um pouco mais com o Kubernetes per se. Aquela ideia de que, se o agendador do Kubernetes morrer, os clusters continuam rodando com o que já tem, porque já está definido. Onde tem pod, onde está cada coisa, assim, é muito, é parecido com essa ideia. Então que, se uma parte da minha infra cair, outra parte continua rodando melhor, e eu não tenho isso necessariamente centralizado nesse ponto de falha e a desvantagem é justamente estar espalhando as regras. Então, essa é a balança da coreografia e orquestração e a gente escolheu a coreografia para ter a flexibilidade das coisas irem para o ar e quer resolver o problema da configuração, dessa forma de ter uma base central, um sistema central que eu tenha as regras e propague. Seja, de alguma forma, do tipo, a API sobe, pega as regras e vai rodar, porque a regra não vai mudar no meio do dia, assim, a regra daquilo. Mas, quando mudar, eu sei onde mexer e eu vou ter uma rotina para atualizar isso. 

Agora, se vocês tivessem criado um microsserviço de orquestração, realmente, centralizado essas regras e trabalhado nesse mesmo esquema de... canal de entrada, canal de erro, saindo, etc. Talvez não ficaria um pouco mais fácil. Vocês chegaram a pensar nisso? Por que vocês não foram para essa linha? 

Um ponto anterior, tem mais um detalhe referente específico do MB, que era o desempenho. Quando você tem o orquestrador, você tem mais um ponto de volta para o orquestrador e ida para o próximo serviço que é adicionado entre todas as etapas. Então, você tem um overhead de tempo, tanto indo para o kafka quanto para o orquestrador que é adicionado. Então, tem esse ponto que é um dos diferenciais por conta da nossa regra de negócio, que é uma exchange 24 por 7 com muitas mil mensagens percorrendo.

Vai ter uma segunda parte de dupla latência para bater o tempo inteiro no orquestrador. 

Sobre a decisão, depois que a gente olhou esses pontos, a gente não reconsiderou de voltar. A gente tinha essas dúvidas sobre, e quando se perder? Porque parece terra sem lei. Quando a gente começa a falar dessa questão de vai para lá mensagem, os caras sabem com quem falar. E quando a gente começou a aprofundar a ideia ali do monitor ali, do solenoid, eu falei, por aqui a gente tem… a gente vai conseguir colocar alguns parâmetros para ver a saúde das coisas. É quase como um extintor de incêndio. A gente brincou: Está ali. Eu sei onde está. E quando precisar, eu sei como usar desse cara. Se a gente fosse realmente ter, acho que o orquestrador, porque a gente lançou hoje, acho que a gente bateria em problemas sérios de escala. Porque em relação ao mandar tudo, voltar, eu tenho que passar por esses caras mesmo, voltar. Provavelmente, no Kafka, a gente iria para alguma coisa também de distribuir mini-orquestradores de qualquer jeito para grupos de tópicos, porque a gente ia ficar congestionado nas partições, nas coisas. Porque, no fim das contas, a gente chegou numa parte de, tudo isso que eu faço, quais são os passos mais lentos que, então, para eu cumprir aqueles poucos milissegundos, eu preciso escalar mais. Então, a gente olhou, eu tenho o passo 3 e 4, eles são mais lentos. Então, esses caras eu preciso de mais consumidores porque, estatisticamente, eu vou eu vou paralisar mais e encaixar com que eu faço lá com três réplicas de um eu faço em 12 nesse cara que é mais lento, porque aí eu tento compensar a lentidão dele no primeiro momento com mais Paralelismo. E aqui a gente teria que replicar isso para o orquestrador também. Porque ele ia ser sempre um cara que ele tem que ser rápido o suficiente.

Ele tem que ter muita disponibilidade no caso. Não tem muito o que chorar. Ele vai ser um cara mega requisitado no meio de toda a história.  Acho que já deu para a gente ter uma boa ideia do que os caras desenvolveram É muito bom falar com quem tem track record. Está passando a dor e resolveu e criou. E ainda está sempre em andamento, e tentando melhorar como as coisas funcionam na empresa. 

Rafael e o Lucas, muito obrigado por terem colaborado com essa talk fantástica. Eu acho que foi bacana, porque deu para a gente ir um pouquinho mais a fundo do que simplesmente a talk quando a gente vê um evento e tentando, inclusive, entender o porquê das coisas. Durante eventos, esses tipos de coisas, a gente acaba não conseguindo perguntar. Pessoal, espero que vocês tenham gostado. É um papo de altíssimo nível. Como eu disse, eventualmente vai ter gente que vai passar a carreira inteira e não vai precisar trabalhar com isso. Mas eu acredito que, o quanto mais esses temas, esses assuntos, essas abordagens não soarem estranhas para você, melhor você já vai estar preparado para desafios. O maior problema que a gente pode ter, quando a gente trabalha nessa nossa área, é nem saber do que você não sabe. É aquela parada, eu nem sei o que eu não sei, então eu estou ferrado. Então, todas as vezes que a gente traz alguns assuntos que não são comumente falados, são importantes para a gente saber que existe mais alguma coisa aqui que a galera está usando e que é importante em determinadas situações. E deixa eu estudar um pouco mais sobre isso. Todo mundo vai entrar lá agora, microservices.io, vai pegar no livro lá do Chris Richardson, eu estou tentando trazer ele para fazer uma talk para a gente, inclusive. Então, eu espero que vocês tenham curtido, pessoal. Novamente, muito obrigado pela presença, o Rafael, o Lucas, e saibam que vocês podem contar sempre aqui com a gente.