SRE e FinOps na Farmarcas: Observabilidade em 1700 Lojas
Convidados
Gabriel Costa
Gerente de Engenharia de Software @ Farmarcas
Bruno Pereira
CEO @ Elven
Explore o episódio
Gerenciar a operação de TI de 1700 farmácias espalhadas pelo Brasil inteiro, processando 40 milhões de registros por dia, não é tarefa para qualquer stack — e definitivamente não é para quem ainda trata observabilidade como custo. Esse episódio mergulha fundo na operação real de tecnologia da Farmarcas, uma das maiores redes associativas do setor farmacêutico do país, com faturamento de 10 bilhões de reais em 2024. Se você já se perguntou como empresas de escala nacional sustentam sistemas críticos, integram dados de fontes caóticas e ainda conseguem extrair inteligência de negócio disso tudo, essa conversa foi feita para você. Wellington Cruz recebe Gabriel Costa, Gerente de Engenharia de Software da Farmarcas, e Bruno Pereira, CEO da Elven e referência em observabilidade e SRE no Brasil, para destrinchar uma operação que vai muito além do que parece à primeira vista. Os três passam pelo processo de migração de cloud e implantação de cultura de observabilidade com Open Telemetry, pela arquitetura de ingestão de dados via Kafka e MongoDB para dar conta de 12 a 15 mil SKUs por farmácia a cada 15 minutos, e pelo projeto Sonar — uma aposta em banco de dados de grafo com Neo4j para correlacionar dados de sell-in, sell-out, ruptura de estoque e performance de associados com muito mais contexto do que qualquer banco vetorial ou BI tradicional entregaria. A conversa ainda passa por FinOps na prática, decisões de arquitetura que evitam desperdício sem sacrificar confiabilidade, e um captador próprio desenvolvido em Go para extrair dados diretamente dos ERPs nas farmácias — incluindo aquelas que rodam num Celeron embaixo do balcão, em regiões que às vezes só têm acesso de barco. Gabriel Costa e Bruno Pereira chegam a esse papo com bagagem real: um moldando a estratégia de dados de uma rede com dois empresários que operam mais de 90 farmácias e outro que já ajudou a automatizar 30% da triagem de eventos em ambientes de missão crítica com agentes de IA. Se você trabalha com engenharia de software, arquitetura de dados, SRE ou FinOps — ou simplesmente quer entender como tecnologia resolve problemas do Brasil real —, não pule esse episódio. Inscreva-se no canal, deixe seu like e, se quiser apoiar o PPT Não Compila, contribua pelo [email protected] ou vire membro no YouTube.
- Teaser: Observabilidade, 40 Milhões de Registros e o Custo de Não Monitorar
- Apresentações: Quem São a Farmarcas e a Elven?
- O Clique que Mudou Tudo: Quando a Farmarcas Percebeu que Precisava de Observabilidade
- ROI de Observabilidade: Custo ou Investimento? O Caso do E-commerce
- Stack Técnico e o Pesadelo dos 150+ Microsserviços Herdados
- OpenTelemetry na Prática: Como Observar uma Arquitetura Distribuída com 12 Bandeiras
- 40 Milhões de Registros por Dia: A Complexidade de Sincronizar Estoque de 1.700 Farmácias
- Agentes de IA e o Projeto Sonar: Democratizando Análise com Banco de Dados em Grafo (Neo4j)
- Banco de Dados Vetorial vs. Grafo: Quando Similaridade Não é o Suficiente
- FinOps Inteligente: Como Agentes Mineram Oportunidades de Saving em Nuvem
- O Captador: Construindo Autonomia de Dados com Go, S3 e SQS (Sem Kafka)
- Gestão de Incidentes em Escala: Observabilidade de Negócio Além das Métricas Padrão
- Engenharia Brasileira na Prática: Soluções Simples para Problemas Complexos do Mundo Real
- Convite: Observability Day — Casos Reais de Observabilidade em Produção
- Encerramento e Agradecimentos
Muitas empresas ainda têm uma barreira para implantar uma observabilidade robusta, que acho que vai ser um investimento a mais, que ela pode, o cara é sempre muito otimista, que ele acho que ele nunca vai ter problema.
Isso dá uma volumetria de quat e 40 milhões de registros por dia.
É porque é são 12, de 12 a 15.000 por farmácia. Se a gente for entrar tecnicamente, acho que não existe problema de dados que você não consiga modelar no post, por exemplo, seguir de um jeito ou de outro, né?
A diferença é a custo de quê?
Uma máquina, por exemplo, na Amazon, ela subia numa T4A nano, que é uma máquina minúscula, menor que micro, né?
Era muito muito pequena e era bom porque isso, sei lá, custava 3 por mês, né?
Muito bem, muito bem, meus amigos, o PPT não compil. Estamos aqui para mais um episódio e hoje junto com vocês eu vou entender como funciona a operação de tecnologia de uma grande empresa do ramo farmacêutico aqui do Brasil. E isso deve trazer muitas lições pra gente sobre como é operação, observabilidade e integração dessa dessa empresa como um todo. Eu tô falando aqui com o Gabriel que é da Farmar Marcas, que é gerente de engenharia do software, né, Gabriel?
Isso, isso mesmo.
Dá um oi pra galera aí, se apresenta completa.
Pessoal, tudo bem? Meu nome é Gabriel, eu sou gerente de engenheiri de software na Farmarcas. Hoje eu tô à frente de são oito squads ali. A gente tem são vários sistemas, né? São várias soluções, todas soluções voltadas para o nosso associado.
Nós como farmarcas somos uma associação, é similar a uma franquia. Então nós temos ali bandeiras, nós temos marcas no qual o empresário ele pode se associar e através disso ele tem um conjunto, né?
Ele tem são várias tecnologias, ele tem todo o nosso nohow, todo o nosso backoffice que auxilia ele a prosperar, a ele conseguir ali concorrer com as outras com os com as outras redes.
São quantas farmácias mais ou menos, cara?
Hoje são 1700 farmácias.
É muita coisa, hein?
É bastante coisa. Nós estamos em todo o Brasil e é e extremamente relevante, né?
Então, ano passado nós tivemos o faturamento de 10 bilhões.
É muita coisa. É bem bem bem relevante.
Eu acho, é, eu acho bom monitorar bem esse negócio aí, hein, cara.
Não tenha dúvida.
E para ajudar de complementar esse assunto, o cara que é a referência no Brasil em observabilidade, Brunão Pereira da Elvin. Dá um oi pra galera, cara. Obrigado, Wellton, mais uma vez aí pelo pelo espaço. Eh, bom, pessoal, acho que já me viu por aqui antes, mas apresentando novamente, eu sou o Bruno Pereira, sou fundador e CEO da Elvin. A gente é uma empresa especializada em observabilidade e AIS.
A gente, né, nessa era da EAI, a gente faz muito o trabalho de, a partir de um problema identificado, tentar solucionar ele da melhor forma. Então, muita solução e agentes de EA é basicamente esse o nosso perfil básico, né, de competência. a gente busca sempre contribuir com problemas de negócio que merecem, né, uma engenharia bem feita e um um trabalho que vai entregar um resultado bacana, trazer essa competência para facilitar todo o trabalho. E temos aí a a parceria aí com a com a Farmacas, cara, uma empresa que eu super admiro, uma cultura super legal, uma uma visão de dados muito interessante, cara. Estamos felizes aí por ter a oportunidade de trabalhar com com problemas interessantes que merecem essa observabilidade e um trabalho de engenharia bem feito, né?
Show de bola. E além de tudo, ele é modesto porque é o cara que manja muito de arquitetura, engenharia e observabilidade para nos eh nos guiar aqui para entender a operação, que não deve ser muito fácil, né, Gabriel? Uma operação desse tamanho deve ter suas complexidades. Vamos descobrir eu agora aqui com você, né?
Boa. É, não tenha dúvidas, né? É uma volumetria muito grande de informações, de dados. A gente tem que garantir a de fato a o receber esse dado, a questão da toda a parte de segurança, toda a parte de observabilidade, uptime nas aplicações.
Vamos entender então porque o o assunto é bom, né? Então antes disso, se você ainda não segue o PPT não compila, se você está no Spotify, aproveita para dar cinco estrelinhas pra gente agora. Se você tiver no YouTube, já deixa seu like. Tem um tem uma novidade agora que é aquele hype, dá o hype para ajudar o nosso vídeo encontrar mais pessoas que se interessam por esse conteúdo. E se você quiser apoiar ainda mais o PPT no Compila, você pode ser membro do nosso canal lá no YouTube. Vai lá, seja membro, vai contribuir com a nossa cerveja para fazer ainda mais conteúdos interessantes para você. E se você quer fazer uma contribuição esporádica, você pode ir lá no [email protected] falar: "Vou pagar a cerveja doit hoje".
lá e será muito bem-vindo. E se você é uma empresa e gostaria de ser parceira também do PPTNPila, faça contato no [email protected].
Vamos lá, vamos entender como é essa eh operação de TI, qual que é essa complexidade, como é que você traz tanto dado para dentro para fazer essa gestão do teu produto, da tua operação? Como que você monitora isso? Se você tá usando IA para para ter ganho operacional aqui, vamos, cara.
Eu tô cheio de pergunta para fazer, hein? Se segura.
Boa. Vamos nessa.
Bora que o Biz tá muito bom. Bora.
Autopila.
Gabriel, queria te perguntar, eh, a gente acabou de conhecer um pouco do que é a Farmarcas, né, e muitas pessoas não sabem o tamanho, né, e a complexidade que é uma operação como essa. E eu queria te perguntar o qual foi o o momento da dessa operação de tecnologia que a Farmarcas falou: "Cara, preciso de um apoio aqui para gerir essa operação".
Legal. Nós tivemos essa essa clareza, né, que de fato nós precisávamos de um parceiro a partir do momento que nós começamos a a evoluir os nossos produtos. Até então nós tínhamos uma um um olhar de criar muitas soluções internas, no qual um escopo bem reduzido e mais seguro, né? Então, a partir do momento que a gente foi, nós começamos a criar soluções pro nosso associado na ponta final, nós entendemos que nós precisamos de um parceiro.
O seu desenvolvimento ele é interno hoje, né?
Isso é é o time é mesclado, né? Então tem profissionais CLT, que é 100% interno, e tem um time também terceirizado que tá espalhado pelo país.
A partir do momento que a gente começou, que era soluções mais robustas, ter o maior número de ambientes, nós entendemos que aí sim faria muito sentido ter um parceiro que nos apoiasse ali em todas as iniciativas, todos os projetos. uma para poder sustentar os produtos que hoje que hoje nós já desenvolvemos e criar novas soluções.
Entendi. Você chegou a ter algum problema muito grave de produção assim que você falou: "Pô, agora eu preciso ter gente dedicada para olhar isso".
Eu já tive dois cenários. O primeiro com outro parceiro. Então assim, você via nitidamente ali que te falava: "Ah, aconteceu um desastre por esse motivo".
Aí quando você investigava, você identificava outra coisa. Eh, e cenário interno, né? Então o, beleza, eu vou dar um pouco mais de autonomia pro dev aqui, mas não é um cara tão capacitado em relação a cloud. Aí numa, ah, vou tentar subir um ambiente quebrava alguma coisa.
Uhum.
Aí depois eu percebi que a gente indicava muito mais tempo tentando corrigir aquilo e não era efetivo.
Então, a partir disso, com o parceiro, é um cenário bem mais seguro.
Sim. E e aí, cara, e que momento que depois que teve esse esse clique de começar a aperfeiçoar a operação, qual foi a primeira ação que vocês tomaram para começar a arredondar isso?
Tem um projeto que foi no qual nós trouxemos a Elvin de uma forma mais estratégica. Hoje eu vejo que muitas empresas elas olham o parceiro de cloud de uma forma é mais para poder sustentar as aplicações. Então você vê cenário quê? Ah, eu vou construir um novo projeto, eu não trago o parceiro, só para sustentar. Recentemente nós recebemos uma operação de de um de um aplicativo com e-commerce, é um ambiente bem mais crítico 24x7. Aí eu pensei, pô, esse projeto aqui eu vou trazer a Elv de uma forma estratégica.
Então eles participaram já na concepção, né?
É que eu nós recebemos um projeto, né?
Ele já tava já tava desenvolvido.
Ah, tá. Tá. Ele já tava desenvolvido.
Você precisava fazer a implantação ali para colocar.
Precisava migrar. migrar cloud, revisitar ali questões de segurança, fazer um FOPS. Esse foi um projeto que nós trouxemos a Elvin de uma forma bem estratégica. Tivemos profissionais dedicados para poder tombar de uma conta da WS por uma conta nova. Então, reconstruímos todo o ambiente e aí foi um projeto que nós implementamos NOC, que eh nós trabalhamos em algumas iniciativas com objetivo de diminuir custo, volume inteira de log, colocar observabilidade. Então esse acho que foi o projeto assim, um dos mais barrudos, né, Bruno? Em relação a isso.
Sim, sim. Esse aí como é um uma rede na ponta, né, que tem cara Brasil inteiro e é sempre suscetível, né, a tentativa de ataque, fraude, etc. tem que cobrir da melhor forma possível, porque tanto a perspectiva transacional, n está tudo disponível, como algum evento de segurança, você não não pode ser avisado por pelo cliente final, enfim, você tem que ter uma visibilidade de eventos bem bem rápida, né, até para poder eh se possível ainda prevenir qualquer impacto e cara alguma coisa que já foi identificada, ter dado de qualidade para investigar e resolver da melhor forma. E vocês não tinham ainda essa esse conceito de observabilidade, não? Não era bem tipo, um produto tinha, outro produto não tinha, não tinha culturamento do time acompanhar esse essas informações, essas métricas, né?
Então, com a chegada do e-commerce, e aí de fato nós criamos uma cultura de obserabilidade.
Hum. Legal. E aí, hoje isso deve est integrado já, né, para todos os produtos ou você ainda tem isso fragmentado?
Não são todos. Os mais críticos nós temos, tem produto interno que ainda não tem, mas aí a gente é um próximo passo.
Entendi.
Além disso, né, em relação ao o radar, o radar ecommerce, que é o produto que de fato nós fizemos a migração, foi bem interessante porque foi o primeiro produto que nós tivemos uma reunião para poder falar sobre a estratégia, no qual Elvin veio, trouxe todo o time dele e ali nós conseguimos criar no roadmap. Então foi bem interessante, é dividido por quarter e lincando ele quais são as prioridades de acordo com o objetivo da empresa. Então isso foi bem relevante, né? E hoje a gente vê o quanto consequentemente a gente vê a evolução do aplicativo, né, do e-commerce na conta final, aumentando o faturamento, número de pedidos.
Show. Uma coisa que dificilmente se se comenta, né, que como você falou, Brunão, tem todo o perigo eh reputacional, né, do de você ter um problema de fraude eh ou de você ter um sistema crítico fora do ar, etc. E vazamento de dados, vazamento de dados lá na ponta com e deixando o usuário final insatisfeito.
Tudo isso tem ali um um valor não mensurável que é muito ruim, né? É, mas existe também o valor que é mensurável de de ROI aqui, né?
Porque eu eu percebo que muitas empresas ainda tem uma barreira para implantar uma observabilidade robusta, porque acho que vai ser um investimento a mais que ela pode, o cara é sempre muito otimista, que ele acha que ele nunca vai ter problema e que ele vai conseguir lidar com o problema da melhor forma possível quando ele acontecer.
Uhum. e que acaba não investindo em ter de fato um um arcabolso de observabilidade eh mais parrudo para isso, achando que vai ser custo e não investimento. Vocês têm um caso onde vocês conseguem falar: "Cara, aqui a gente investiu nisso e eh nesse projeto e a gente conseguiu ter um ROI de impacto dessa forma nesse produto?
No meu contexto, de uma forma direta, eu não teria assim, a gente vê que de fato foi um investimento e que isso refleti de uma forma positiva. A gente vê o quanto isso vem nos ajudando assim a evoluir o aplicativo, mas eu não teria essa métrica. Isso de fato não foi feito. Mas entretanto, acho que a o ponto é esse, né? É olhar como como investimento, como você bem trouxe.
Uhum. Ah, beleza. Vamos ter um contrato aqui escopo fechado com a Even vai custar X. Não, não é um custo.
É, é que nem sempre é, como é que eu posso explicar?
Nem sempre é o que você passou a ganhar, mas o que você deixou de perder.
É, sim, sim. Aí tem uma até no nos e-commerce em geral, né? O pessoal da da Amazon tinha umas métricas lá de cada 100 msegundos que você coloca mais lento, né, do teu checkout, página de pagamento, você perde x de conversão.
Então eu tenho essa impressão que principalmente um produto que que tá ganhando mais adesão, porque assim, você passa a tentar transacionar mais por um aplicativo mobile, por um e-commerce, etc. Se as primeiras experiências do cliente ali, elas não são positivas, não são confiáveis, né? Você acaba tendo um limitante ali no que você vai ter que eh gastar cartucho com alguns clientes ali até você conseguir amadurecer. Aí você vai eh amadurecendo e chegando naquele nível ótimo ali de maturidade. Mas se você puder não queimar esses cartuchos, né? Você puder não ter falhas que você possa prevenir, eu acho que o o crescimento do canal se torna mais natural, né? Porque no final hoje em dia, acho que principalmente depois da da pandemia, muita coisa digitalizou de um jeito cara tão mais conveniente ou você simplesmente ter opção. Você fala: "Cara, eu hoje eu não não vou conseguir trabalhar de casa, eu vou para clientes, eu vou pro escritório, etc. Você poder ter tem ter um canal a mais que vai resolver teu problema, mas com uma uma marca, um parceiro que você já confia, né? Acho que é sempre muito bom. Então acho que isso de tentar não colocar a fricção desnecessária, né? não deixar o negócio falhando, aquele negócio, aquele botão ali que, [ __ ] tá carregando rápido, mas ele não funciona, né?
Pois é, car rápido, não funciona também não adianta, né?
É, exato.
É. E e isso é um fato, né? O o cliente baixa, ele tem o primeiro contato com o aplicativo. Ele pesquisou, uma de pirona, ele não achou, ele não volta, não volta, ele apaga o aplicativo e vai pro concorrente e Ville que segue.
Então é, é desafiador.
Eu sou eu sou desse cara, velho, que eu abro um aplicativo, o negócio já eu porque a gente tem um olho clínico, né?
A gente fala: "Porra, não acredito que o cara fez essa essa cagada, eu não vou usar mais esse aplicativo." Acabou, já era. Acabou, acabou, não volta. Você vê uns erros assim, falar: "Pô, não acredito, cara". É, não pode ser, né?
Então, eh, isso afeta do do problema de imagem, etc.
Sim.
E agora tô tô curioso, vocês pode falar um pouquinho do stack que vocês começaram a implantar, a a utilizar para para começar a levantar a superação?
Pode, pode sim. O todo o back end, né, em DNET.
Uhum.
Banco de dados, a gente tem banco PGRIS, a gente tem Mongo. Para busca tem Elastic.
Ah, aplicativo nós temos eh Switch. Não, não é sutwift, né? Ou foi com flutter.
É flutter. Flutter. Isso. E aí tem a outra, tem uma porrada de tecnologia assim, tem mais de 150 apps. Quando nós herdamos essa aplicação, esse é um ponto que até o time do Brunão deu uma assustada quando eles viram isso, porque eles elevaram muito ao pé da letra o conceito de microsserviços, tipo, ah, cara, isso muita gente errou no começo com isso aí, né, cara? Eu vou fazer um crude. Sobe uma app, faz um microserviço para para essa finalidade.
Isso se o cara não sobe um microservos pro update, um microserviço pro insert, é a galera perdeu muito a mão em relação a isso.
Perdeu a mão.
Então assim, hoje a gente já fez uma higienização, mas deve ter mais de 100 tranquilamente. Isso aumenta o desafio, né? Porque o que que conversa, com que, por onde que vai, da onde que vem?
É. E tem uma uma questão nesse ponto, né, que são 12 redes ali, acho que são 12, né?
É, é um label, né? Então a gente é o app são é um é um aplicativo que atende 12 bandeiras.
Ah, tá. Então ele é o mesmo build e aí em run time ele adota uma bandeira.
É isso mesmo.
Só que ainda tem e iPhone e Android, né?
Tem toda assim é se você for pensar é uma variedade de coisas que você tem que se preocupar e esteira de deploy, etc.
Tem tem sua complexidade por por toda essa variedade aí, né?
E e como vocês começaram a qual stack vocês começaram a usar para observar esse monstrinho todo? Porque eu lembro que na última vez que a gente fez uma grande implementação numa empresa que eu trabalhei antes de de com microsserviço, muitos micros serviços espalhados, era muito complexo de você conseguir observar de fato a malha como um todo, né? E aí enfim tinha soluções de service que você conseguia observar ali ainda um pouco com Grafana, etc. Não sei se esse é o estado da arte ainda. Ainda bem que o Bruno não tá aqui para salvar a gente hoje.
Sim, sim. É, nesse caso lá abordagem eh que eu acho que é uma uma abordagem interessante para qualquer empresa, a coleta de dados ser via Open Telemeter, né, que você consegue ter coleta ali de logs, métricas, trace, todos os dados e bem compatível com essa arquitetura distribuída, né? Você consegue pegar algo diretamente do cluster, enfim, fica muito muito mais fácil, né? E isso eh permite que você decida. Olha, ambiente não produtivo, eu posso mandar para um lugar, ambiente de produção posso ir para outro, etc. E nessa gama, né, de microsserviço e muita comunicação, que é difícil você humanamente compreender, ter o tracing, principalmente, né, você ver, cara, chegou a requisição por aqui, passou por aquela API, passou por aquele banco de dados, aquele serviço de fila, toda na na no caso de de plataforma de dados, principalmente lá da da Farmarcas, tem uma riqueza ali de modelo de eventos, né, cara, isso aí você tem que capturar a cadeia inteira, né?
Então, e a habilitar, por exemplo, uma coleta de tracing para ver, cara, onde que tá tendo algum gargalo, onde que aumentou a taxa de erro, é bem importante. Aí você começa a ter capacidade de entender o que que tá acontecendo, né? Essa transição entre um monitoramento base para observar habilidade é você tentar entender algo que chegou via um determinado canal, foi tratado ali uma parte sincronamente, uma outra parte virou um evento que vai ser processado depois. Tudo isso você você conseguir capturar com com tracing, acho que ajuda muito. E aí é tudo tem que tá conectado, né? Você tem que ter log de erro, log de transação, tudo isso, até porque você é um um ambiente que transaciona nesse volume. Tudo bem que assim como a Farmax ela transaciona um volume absurdo, nem tudo é canal digital, né? Nem nem tudo vai passar por aí, mas a expectativa é que tenha cada vez mais uma relevância desse canal.
Então tudo na princípio você tem que ter rastrabilidade, auditoria, né, para poder entender até para para repassar para um para um parceiro o que que pode ter acontecido que que o pedido dele não não chegou, né, sei lá. Então isso é uma abordagem que tende a sempre a usar padrões abertos que tragam sempre pra empresa a opção de escolha, né? E um negócio que a gente sempre acredita na na Elvin, né, cara? A gente gosta muito de trabalhar com padrões abertos, pô. A gente gosta sempre de ser um parceiro confiável, que seja bom de trabalhar, mas cara, a gente não quer ter um loquin, uma visão que [ __ ] vô permitir só que a gente seja opção. Por exemplo, tem e vários ambientes que a gente trabalha que permitem, pô, eu posso ter uma stack baseada em grafana como como é a nossa, né, num ambiente não produtivo, alguma coisa, menos missão crítica. Se cara aquela aplicação funciona muito muito criticamente, o time já tá acostumado a trabalhar com data do Dog Ric, a nossa abordagem permite isso. E acho que essa liberdade de escolha, ela até estabelece um vínculo de confiança mais legítimo cara. Sim, é mais fair, né? Você, tipo, você não tá trancando o cara dentro de um de um armário, né?
É. E tem assim hoje tem tem a questão do multicloud que algumas empresas inclusive não só em microsserviço, mas em plataforma de nuvem exageraram também. Tem alguns ambientes que a gente suporta que tem quatro ou cinco plata.
Quer dizer, às vezes são quatro plataformas de nuvem, mais um premises ali que você não sabe se vai sobreviver tal. E aí, eh, se você não não eh eh tem essa mentalidade, né, de cara, vamos permitir que as coisas convivam de uma forma harmônica, às vezes é linha do tempo, né, uma visão evolutiva, você até pode ter um plano de desligar algum componente, migrar alguma coisa, isso pode não ser agora, pode ser daqui a um ano, né? Então, a gente tem que estar sempre pronto para algo que eh vai evolucionário, né? Você começa com o que é possível, o que que já tá operando, vai gradualmente numa direção que vai te deixar com uma maturidade melhor, mas tem que ser sempre o problema e que eu sempre vejo nesses planos, Brunão, é que ele sempre acaba para no meio do caminho e aí você fica meia musçarela, meia calabresa.
Isso é verdade.
E é e é o que a gente vê, né? Tá metade numa nuvem, metade tá no no premies.
Sim.
Eh, aí o banco do premis tá tá Ende of life já. End of e o runtime rodando na nuvem, você começa a achar uns frankst aí no meio do caminho, né?
Que acontece.
Tem tem alguns casos que você vê, cara, que decisão peculiar essa aqui. E muitos casos peculiar muito bom, né? Adorei o barb.
Que decisão peculiar.
E tem muitos casos que assim tem aquela falta de decisão que também é um um problema. às vezes fala: "Cara, eu tô com uma comunicação aqui que, sei lá, entre nuvens aqui sai pra internet e volta, né? Em vez de estabelecer uma conexão interna segura".
Sim.
Fala: "Cara, quem é que decidiu isso aqui? Ou quem é que não decidiu?" Simplesmente saiu brotando ali com esse tráfego pela internet.
Quem foi que decidiu esse padrão, né? É.
E e no nosso caso, né? A gente tem um, não é bem um agravante, mas aumenta, o direito aumenta bem a complexidade que eu tenho que olhar o estoque da loja.
Então eu olho o estoque, eu são 1700 lojas, eu olho o estoque de cada loja para no aplicativo você ter a experiência, né, o cliente de conseguir ver qual que é o preço do remédio naquela loja.
Uhum.
Então isso dá uma volumetria de quat e 40 milhões de registros por dia.
Ou é porque é são 12 de 12 a 15.000 escaús por farmácia.
Pera aí. Então, mas aí você tem isso unificado e aí naquele mesmo build que você eh abraçou uma bandeira, depois você abraça uma unidade e você vai buscar na mesma base só o que é daquela unidade com aquelas quantidades e preços, etc.
Como é que é isso na prática, né? Eu tenho as bandeiras, a bandeira X, ela tem 10 farmácias.
Uhum.
dentro das 10 farmácias, ela pode utilizar quatro RPS que são credenciados a farmarcas.
Ah, tá.
O RP ele me manda estoque preço a cada 10 ou 15 minutos.
Hum.
Dos 12.000 SK. Tem RP que tem uma inteligência que só me manda o que foi de fato atualizado, tá? que é lógico, faz muito sentido.
Tem RP, cara, que dá um select lá e manda tudo.
Que beleza.
Então eu tenho que suportar essa volumetria de dados e conseguir de fato processar isso.
E aí você consolida isso num num banco de dados único normalizado pelo produto, pelo para você tem lá uma tabelona produto, unidade, marca. Eu tenho um, isso cai primeiro no Cafkaa a porrada e depois vai pro mongo. Então ele vem o ID da farmácia, SKU, quantidade, preço.
Entendi.
Aí quando você entra no aplicativo, eu quero ver aqui a farmácia X da bandeira que eu tô aqui logado. Beleza, eu tenho esse preço. Ah, eu quero trocar agora a farmácia, consigo, tenho essa experiência no aplicativo, eu troco a farmácia e vejo outro outro preço. Por qual motivo? As farmácias não necessariamente são dos mesmo dono.
Então vocês dois, cada um pode ter uma farmácia da mesma maneira e aí praticar um preço ali diferenciado.
Sim, sim. Não entendi. A a minha dúvida era justamente porque como você tem um build só da do aplicativo, você tem que ter um modelo de dados unificado. Então você tem que pegar todos esses dados que chegam do RP, enfileirar e persistir num d numa tabela normalizada que é compatível com o teu build.
Isso mesmo, né? E isso, cara, gera uma volumetria gigantesca. Tem quantas linhas tem?
Quantas linhas documentos, no caso, né, que mongo tem um um uma coleção dessa?
Ah, agora agora eu não saberia te responder.
E qual que é o agravante, né? O cliente entra lá no aplicativo e vê lá um salão desodorante, R$ 10.
Uhum. O cara compra aí, chega lá na farmácia, pô, o preço tá errado. Aí se eu não tenho observabilidade, eu fico vendido daqui.
Você não sabe onde é que teve o gap de tempo de atualização, né? Gap. E aí quando eu vou analisar, ah, o RP que não mandou, o R o RP encavalou lá o processo, não tá me mandando dado. Aí o senão aí aí o a Olha a relevância da observabilidade nesse cenário, porque cara, o cliente pagou, comprou por 10, ele vai levar por 10.
Uhum. Sim. Então eu tenho que conseguir dar essa visibilidade paraa empresa, falar: "Não, para eu levantar no RP, vamos tratar de junto ao RP".
Pô, só aí você tem um ROI absurdo.
Sim, sim, né? Você já consegue, é que você nunca calculou, mas consegue ter o assunto aí, a investigação humana para levantar essa capivara, como fala, né? E e chegar é complicada mesmo. E tem tem até uma uma questão, né? Isso é um ponto, um dos dos produtos internos que o pessoal tem trabalhado lá, que eu acho que é super interessante, que é esse modelo de de você facilitar a operação dentro da da farmácia, porque assim, estamos falando aqui de São Paulo, mas cara, tem farmácia lá no no Maranhão, tem lá em tudo que é lugar, cara. Você vai pegar um associado e uma equipe lá que não necessariamente são super sofisticados em tecnologia e a operação tem que funcionar, né, para aquele pessoal, né?
Então essa inteligência, além disso, tem tem uma outra questão que é o o Gabriel comentou, né? Você tem um RP que roda dentro da farmácia, ele roda naquele aquele desk server ali, duvidoso, não é aquele negócio ali, tá embaixo da mesa do balconista, às vezes ele chuta ali.
Não é aquela máquina que tá no hack ali refrigerado, não. O cara tá Brasilzão, aa e aí você pensar, cara, como que eu consigo ter esse funcionamento do do RP, sistemas que eu tenho localmente? Eu quero ter essa experiência de dado chegando o mais eh fresh possível, né? Não, não quero poder tomar uma decisão em tempo real. E tudo isso tem que ser confiável numa maquininha sem vergonha, cara.
Isso aí é porque assim, a gente pensa muito, ah, não, vou criar um negócio do estado da arte para rodar na AWS em alta disponibilidade, multi. Legal. Agora faz um negócio que vai ter que conviver com 2000 equipamentos ali duvidosos, né?
Com um Celeron rodando embaixo do do do ali.
Isso aí, 512 de RAM. É. E aí é isso.
E isso. Um ponto que eu acho que é bem interessante. A FMACAS foi numa direção que eu acho que é bem inteligente, que é, cara, eu quero trazer uma operação inteligente e cuidar bem do associado no Brasil todo. Só que, cara, não dá para ter ser humano cuidando dessa quantidade toda de farmácias. Então, foi um movimento que eu achei bem interessante, que é, cara, eu sei o que que é um atendimento excepcional feito para cada associado. Eu tenho um caso aqui de excelência, tem um caso em que não tá tão legal, às vezes por essa dificuldade de ter uma cobertura boa. Foi feita uma modelagem bem interessante, cara. Eh, eu quero que uma equipe humana eh inxuta consiga cuidar de várias farmácias com excelência. desenhou um modelo com operação com com agente, né, cobrindo várias dessas coisas, são mais operacionais para permitir pro pro o cara que tá cuidando do associado ter tempo livre para fazer mais aconselhamento, orientação, etc. Isso aí eu acho que é super interessante e isso convive, né, com esse parque tecnológico bem bem, sei lá, inxuto, né, que tem dentro da farmácia. Tudo isso convive com uma estrutura bem mais sofisticada e moderna que roda em nuvem, né? Mas essa e lidar com esse mundo real, né, cara?
Vou ter farmácias ali com pouco orçamento, um computador bem limitado, internet também duvidosa, né? E tudo isso traz um senso assim de criar algo resiliente. No final você tem que permitir a operação da farmácia, tolerar falha em tudo isso aí. Silva, RP falhou, se não tava com internet na farmácia durante algumas horas, a operação dele tem que continuar funcionando de de alguma forma ali. E aí você fazer isso, conseguindo coletar esses dados e levando pra pra farmácia recomendação, insightes ali para ele ter mais sucesso, cara, isso torna um negócio assim um negócio do mundo real, né? Que eu acho bem interessante porque você começa a ter a tecnologia cumprindo um papel ali, [ __ ] de de melhorar a vida daquele cara que, cara, ele não é aquele empreendedor cheio de recurso, não, cara. O cara tá lá na na cuidando da da vidinha dele ali, a farmácia dele, tendo que que operar com uma equipe que muitas vezes não é aquele que ele gostaria de ter, né? Tudo isso tem que funcionar. E isso acho que usar essa tecnologia de um jeito que encaixe nas possibilidades que o cara tem e traga inteligência, apesar disso tudo, né?
Acho que isso é uma das coisas que eu que eu acho que é é muito a gente usar o estado de arte e tecnologia em condições que são subótimas ali, né? Você não você não tá naquela aquela fartura de possibilidade. Você tá tendo que se encaixar nas limitações que aquele aquele empreendedor tem, né? Então, quero falar com você agora que ainda não conhece a Clever. Clever é uma empresa que já tem mais de três milhões de usuários em 30 países com 30 idiomas diferentes, que tem trazido soluções em blockchain, criptomoedas e ativos digitais. O objetivo da Clever é te dar liberdade financeira para operar nesse mercado de cripto. Então, se você acredita nisso, se você acredita nessa liberdade, você já pensa como a Clever, vai conhecer os caras, é clever.Ou estão contratando também pessoal para trabalhar com crypto, com blockchain.
Então, se você tem interesse, se você tem conhecimento nessa área, procura a Clever. Se você gosta de criptomoedas, se você opera no mercado, você precisa conhecer a Clever, precisa conhecer as soluções da Clever. Então, o endereço tá aqui embaixo no vídeo. Para quem não tá no YouTube é clever. Vai lá, vai conhecer que realmente é um mercado sensacional.
Vocês falaram sobre essa questão de de reduzir um pouco a operação, né, para deixar as pessoas estão na operação ali de orientação pro pros associados, etc., mais livres, resolvendo com alguns agentes ali. Vocês conseguem comentar um caso, o que faz esse agente, como vocês implementaram, quais são as métricas?
Legal. É isso aí.
Assim, claro que tem na operação lá eh uso de agentes em diferentes contextos, inclusive esses temas de de observabilidade, resposta incidente e tal, mas isso aí acho que é um um plus, né? Eu acho que o o core mesmo e e é o que eu acho que é o uso adequado, digamos assim, de agente, que é você modelar alguma coisa que é um trabalho muito bem feito, né, por uma pessoa, você conseguir embarcar a gente para cobrir um pedaço razoável disso aí, eh, coisa operacional, etc. Isso aí, cara, dentro do domínio e expertiz da da Farmacas, né? O pessoal modelou de um jeito bem aquele modelo híbrido mesmo, cara. Vou ter um time humano empoderado por a gente para, cara, cobrir um terreno muito, muito maior. Aí, cara, isso aí é o é o projeto aí especial do do Gabriel que ele tá tá brilhando aí com essa operação se tornando cada vez mais.
Não conta para nós, cara.
Boa. Qual que é o desafio, né? Nós como farmarcas temos muitos dados.
Deixa eu só voltar umas etapas, né? Lá na Farmárcas nós nós temos um time de operação, né, que nós atribuímos o nome para ele, são os anjos. Hum.
Qual que é o papel do anjo? É estar próximo do associado e ajudá-lo a prosperar. Então, o anjo ele faz análise, ele levanta ali as bases, tem que cruzar diversas informações de uma forma que ele consiga ali realizar uma leitura do cenário do associado.
Hum.
Qual que é o desaf?
E para isso você coleta uma série de dados para poder chegar numa namnese da situação do cara, né? Perfeito. É amoroso, é manual. Tudo bem que a gente tem um time de dados que trabalha ali para conseguir automatizar o maior número de etapas, mas ainda é manual.
Diante desse cenário, tanto o meu diretor quanto o presidente da empresa, Gabriel, tem que trabalhar com a gente, tem que trabalhar com agentes. Eu falei: "Pô, mas como é que a gente coloca isso na prática, né? Porque criar ali agentes, né, no cloud, no Gemini, isso por si só não resolver o problema.
Uhum.
Por qual motivo? Eh, se eu crier um agente ali, eu vou, talvez, eu vou definir um prompt, um, talvez algum similar kit, vou andar na mão do do time de operações. Cada colaborador vai inserir o dado de uma forma, eh, eu vou ter ali várias informações fragmentadas.
E aí eu tava tava participando de uma palestra, eu escutei o termo de grafo.
Falei: "Cara, tem algo de interessante aí". Muitos anos atrás eu já havia trabalhado com New For J.
Sim, acho que é o maior, né? Banco de dados. é um dos maiores, porque hoje eh tudo bem que a gente tem um Lá muito bem estruturado, mas eu ainda aquela informação por si só, ela não representa o negócio.
Eu tenho várias informações fragmentadas. Quando a gente fala de uma base de grafo, eu consigo abstrair o que é o Lake. Eu consigo reproduzir o negócio através de conexões.
Uhum.
Quando eu plugo isso com contexto, né?
E com contexto, né? É quando eu plugo isso no modelo de a, o que que eu consigo e o que que é uma, o que que eu já consigo garantir? Muito mais assertividade, porque todo mundo vai olhar a mesma base de dados, todo mundo vai olhar os mesmos relacionamentos, o número menor de tokens para poder realizar análise, porque vamos imaginando imaginar o analista e tá tudo bem que hoje a ferramenta que ele tem, ele deve pegar um arquivo em Excel ali com, sei lá, 15.000 1 linhas, mana para um modelo qualquer, tem que converter aquilo MD, tem que ler, tem que quebrar, vai utilizar vários tokens.
Depende da interpretação que o LM vai fazer das colunas, etc., é padronizado, né, do prompt que ele vai dar, consequentemente não tem uma resposta padrão. E aí o nosso intuito com esse projeto é democratizar essa informação de uma forma que eu tenho um sistema que ele já até tem o nome, que é o Sonar, no qual eu consigo dar um prompt, eu quero saber como é que tá a performance do CNPJ tal ou do nome do grupo. A partir disso, eu consigo ler Celin, Celout. O celin é a compra do grupo ou da farmácia junto à indústria. O sellout é a venda, né? Então eu consigo ver cesta, consigo ver, qual que é o cliente, qual que o produto mais, se é curva A, curva B ou curva C. Eu consigo correlacionar tudo isso e entender se esse cara tá performando, quem tá próximo dele, como é que tá a performance dele, se tá caindo, por que tá caindo, será que é uma ruptura de estoque, será que é uma indúster que não vendeu para mim? Eu chego no nível que eu consigo correlacionar qual que é a o impacto de eu tenho um gerente A que trabalha numa rede, ele saiu dessa rede, foi para outra. Se isso tá no nos meus nós, se isso tá ali como um contexto, esse gerente saiu de uma loja e veio para outra e essa loja começou a cair, esse modelo ele consegue me falar isso, porque são correlações, são conexões.
Algo que para um, para um ser humano seria muito difícil ele ter essa percepção.
Sim, sim.
E além disso, a gente tira os vieses, né? Então, sei lá, eu como analista, cara, hoje eu perdi o horário, perdi o ônibus, tô puto. Aí chego lá na empresa ela para fazer uma análise. Pode ser que eu esteja envzado, eu tiro o viés também da análise.
Você me deixou aqui faminto de curiosidade agora para entender algumas coisas. Vamos fazer aqui um um parênteses para falar de banco de dados de grafo, porque você acabou de me falar algumas perguntas atrás que você recebe um banco de dados que veio do Celeron com 512 M de memória de um RP que deve te mandar esse banco de uma forma estrutur e relacional, né?
Isso.
E como que é o seu processo de ingestão para transformar esses dados em grafos?
Porque fazendo um um um adendo aqui para quem não conhece o dado de grafo. O dado de grafo ele ele correlaciona os dados através de vértices, né?
E esses vértices têm significado, né?
Então você pode atribuir um contexto para aquilo, né? Então o dado ele tem mais informação não só a informação do dado, mas a meta informação da relação dos dados, né?
Perfeito.
Então você consegue carregar muito contexto, por isso que ele é usado muito em LLM. Só que modelar isso e ingerir isso não é simples, ainda mais quando você tá vindo de um banco de dados XP. E exato que uma outra complicação que existe dentro daquele Celeron lá é que, como o Gabriel falou, são quatro RPs.
Então esse componente que faz consultas nessa base de dados lá, é como se ele fosse aquele antigo Hybernet ou RM, né?
Ele tem que saber lidar com quatro estruturas de dados diferentes que não tem nenhum compromisso nem intenção de padronizar, cara. São vendors diferentes. Então isso aí tudo tem que ser abstraído, né, para poder você e alimentar e depois tratar esses dados e de alguma forma voltar em sites, independente qual que foi o parceiro de RP que o o cara da farmácia escolheu, né? você tem que transformar num um grafo, num modelo de grafo de quatro fontes que tem esquimas completamente diferentes, né? Perfeito. É, como é que como é que nós iniciamos o projeto, né?
Isso, eu assisti essa palestra foi numa sexta-feira, o cara falou de grafo, falei: "Cara, acho que isso se aplica".
Aí sabadão, tava em casa lá de boas, falei: "Pô, vou subir aqui um projetinho, eu comecei a fazer uns testes, eu vi que as respostas eram bem mais assertivas".
Uhum.
A partir disso, falei: "Tá, então vamos utilizar uma instância aqui. O New for J ele tem a versão comilot, isso.
Então você sobe uma instância ali, qual que é o ponto? Consome muita memória RAM. Hoje já a gente tem uma máquina dedicada na WS para essa finalidade, já tem mais de 100 GB de RAM.
Ou!
É absurdo. É um negócio absurdo.
É porque você tem que subir esses gráficos em memória de alguma forma em memória para conseguir performar em memória. Sim. E aí eu falei: "Pô, vamos entrar em contato com a New For para eles nos apoiarem nesse projeto". E aí conversa vai, conversa vem, cara. Ó, qual que é a pergunta de 1 milhão de dólares? Toda hora os caras perguntam, levei a galera lá na empresa, qual que é a pergunta de 1 milhão de dólares?
Falei: "Que que de acha essa pergunta que ele quer?" Aí eu entendi que a gente tem que abstrair o nosso leak. O que que é isso na prática? Eu penso eu, eu me pergunto qual que é a pergunta que eu quero responder. Então, por exemplo, eu quero entender qual que é a correlação de um associado que tá na mesma região do outro, um cai e um e um sobe o faturamento. Qual que é a diferença de um pro outro? Então, é isso aí. Beleza.
Quais são os dados que me mostram isso?
Se eu tivesse que realizar essa análise manual, se eu tivesse colocar aqui nessa mesa aqui as informações, como é que eu organizaria isso? A partir disso, é como se eu fizesse uma engenharia reversa. Eu começo a modelar o grafo, aí depois eu entendo, beleza? Então eu vou precisar dessa informação que tá no meu lake.
Essa informação tá numa base, tá no mongo da vida. Aí eu crio uma ETL, talvez na minha camada ouro, para poder inserir inserir o dado no no new forj.
Entendi. Você pega o o primeiro resultado do gráfico que você quer.
Isso é aí transforma isso onde estão suas informações. São os nós do gráfico, né?
Isso.
E aí você estabelece a relação entre eles para dar significado paraas correlações, né?
Isso mesmo. Porque se eu faço o inverso, se eu partir do meu lake ou da minha estrutura ali de dados que eu tenho atualmente, talvez eu caia e eh talvez eu corra o risco de repetir o que eu já tenho.
Sim. Sim.
Então, a gente faz o inverso, eu modelo isso e é bem interessante. A gente faz um trabalho em sala colando postiche, o que que eu quero entender? Então o cara entender se é um cara ter ruptura de estoque. Ah, eu tenho estoque, tenho, tá onde? Tá na tabela tal. Eu tenho mix da cesta, tenho. Tá na tabela. Normalmente vaiudo vai est tudo na camada ouro.
Então beleza. A partir daqui eu monto o meu ITL e eu faço uma carga no forj. Eu entendo se eu vou fazer uma carga mensal, diária, semanal. E aí eu consigo alimentar ali as informações e e representar o negócio.
Mega complexo e com resultado impressionante, cara. É absurdo, absurdo.
É incrível, né? É incrível.
É, a gente a gente já tem uma versão que a gente tá rodando só com celim, né, que é a compra da farmácia junto a indústria. Então eu pergunto ali, qual que é a penetração do Monjaro? Isso é um teste real. Sei lá, talvez eu demorasse ou eu teria que abrir um BI, fazer alguns filtros. Uhum. Aí tem um cenário que às vezes o usuário não sabe fazer o filtro correto, ele chega num valor que não é uma realidade. Aí o meu diretor em uma reunião de diretor, ele perguntou ali no prompt é milissegundos. Ó, a resposta é essa.
E e ele é muito coerente esse modelo de de grafo esse tipo de aplicação, porque ele é muito semelhante ao conceito do produto de dados que a gente tem nos links, né? Você tem que abstrair a regra de negócio dentro daquele produto para que todo mundo use a mesma regra. Quero falar do que é um selinho, um sellout. Todo mundo tem que calcular igual.
Isso.
E isso vai intrínseco quando você define o grafo, né? Isso mesmo.
É muito bom para você trabalhar com com esse esquema de produtos de dados, né?
Eu quero fazer um episódio aqui. Você já tá convidado para falar só de banco de dados vetoriais e banco de gráficos, que é um tipo de de banco vetorial no fim, né? E porque ainda é muito obscuro para muita gente de desenvolvimento esse tipo de É banco de grafo é um negócio que não é super difundido, né, no mercado, né, começou a ganhar relevância agora por causa dos LLMs, né?
É, e isso foi interessante porque assim, eu muito tempo atrás, eu já tenho data de nascimento antiga, né? Eu participei de um KC, né, na época da data de nascimento antigo. Você é ruim, é, o DNA dele é bom, ó. DNA. Exatamente.
O, na época da saudosa Celo, né, que depois virou virou a Lura, né, eles organizavam o QC nos primeiros 4 anos, né? E, cara, tive a sorte na época a gente tinha organizado isso antes de eu começar a empreender, eu trabalhei numa empresa, foi a primeira parceira da Amazon na América Latina e tal. E a gente montou nesse senso de comunidade, né, um grupo de estudo de no sequel aqui em São Paulo. Cara, tinha um um blog lá que chamava No Sequel Summer Reading List, né? Um monte de artigo interessante, Danb, Cassandra, Nel For já era um dos bancos que tinha naquela época, no Mongo DB também já tinha, né, cara? Tinha um monte de gente começando a usar em produção, queria entender um pouco melhor o que que tinha de utilidade, quais foram os desafios al cara, a gente juntou uma galera. Tinha gente da Conquit, onde eu trabalhava, tinha gente da Red hat, da Koton, cara, muito muito legal. Nessa época era todo mundo presencial, então tinha aquela questão de, cara, vamos pegar quem consiga vir e se encontrar. Cara, a gente conseguiu uma uma sorte, né, na época do Kong, acho que foi 2012, o Jean Webber, que era o CTO lá do do Nel For Chief Scientist, né, sei lá, é o cargo mais sofisticado, ele veio pro QCON e a gente conseguiu eh conectar e com ele para cara o grupo ali que tava tendo discussões e tal. Cara, isso foi muito interessante e trouxe, né, já para mim nessa época, cara, ficou no radar. [ __ ] tem na na prática com no sequel você tem eh esse conceito de um banco que foi desenhado para resolver muito bem aquele problema. DMDB foi o checkout da Amazon, etc. Ne forj tem vários cases, tem algumas coisas de antifraude, né, que são interessantes, lavagem de dinheiro, etc. E tem alguns casos, né, que permitem que você, uma vez que você modela bem esse problema, né, e isso é a beleza do no ciclo, né, às vezes você consegue ter alguns bancos de dados no mesmo produto, cada um com uma finalidade onde ele vai ser muito mais eficaz do que outro. Então essa lei sacada, né, de cara vou pegar uma massa de dados absurda que precisa ser compreendida, digerida, etc. E habilitar respostas mais complexas de negócio para um analista, né, saber o que fazer. Isso aí acho que é assim é excelente, né? E é muito você pegar, cara, pô, daria para fazer isso com Postugas? Claro que dá. O Postgas é fantástico, tal. Agora, se você pega eh algo que foi muito muito modelado para casos semelhantes ali, você consegue ter às vezes 5, 10 vezes mais eficácia para aquele problema específico, né? Então ter esse Lego assim, né, com com cara soluções que você vai em cima do problema que você fez uma imersão ali, fala: "Cara, isso aqui [ __ ] eu acho que merece uma solução especializada". Aí você, cara, vai numa linha de ser muito mais inteligente do que de repente um player que foi fazer ali aquela aquela arquitetura feijão com arroz ali que dúvida funciona. Mas assim, chega em 1000 farmácias, 2000 farmácias e sei lá quantos anjos tem desse aí, você já não conseguiria capturar tão tão bem esse tipo de detalhe que às vezes é um dado tão na ponta ali que, cara, um ser humano não vai conseguir ter essa atenção para para perceber essas nuances. você tem que fazer alguma coisa modelada para perceber aquele evento, aquele comportamento, né? Então é bem interessante mesmo.
Você que tá aí escutando esse episódio bacana e quer levar toda essa tecnologia, essas novidades pra sua empresa e não sabe como, chama o time da Vembers. A gente pode ajudar vocês com desenvolvimento de software, com arquitetura de soluções, a entender os problemas que vocês estão vivendo e sair do outro lado com uma solução bem bacana. E se você tá escutando o podcast para aprender coisas novas, faz o seguinte, manda um e-mail pra gente no peoplecare@vemers.
E você pode fazer parte também do nosso grupo de talentos. Valeu.
Agora o time do Relações Públicas vai gostar mais de mim.
Se a gente for entrar tecnicamente, acho que não existe problema de dados que você não consiga modelar no post, por exemplo, você vai conseguir de um jeito ou de outro, né?
Sim.
A diferença é a custo de Q, né?
Sim, sim.
Então, você conseguir ter, por exemplo, um processo desse, cara, aí você vai ter que fazer procedure de function, vai ter que ter uma série de uma solução que já não é mais adequada, né? Assim como o os bancos de dados no cicle, eles começaram a ser muito utilizados quando o pessoal começou a perceber que, cara, eu vou armazenar um monte de informação que é similar e que eu não vou fazer inferência entre elas. Eu não vou ficar rodando SQL entre um e o outro, né? Tanto que sim.
Até hoje tem tem umas pessoas que chamam banco de documentos, né? Porque são é isso do do Mongo Deb, é do próprio Lesc, que é um tipo de banco de documento e outros, né? O Postas, ele até tem essa estrutura de dados Jon.
você consegue usar, né?
E vetorial também tem o plugin lá, o PG Vector, que é cara, o PS é um bug que eu sou sou muito fã, cara.
É muito impressionante como que o negócio saiu de um de um banco relacional já muito bom há muito tempo para algo que, cara, teve uma evolução tecnológica para suportar vários usukes e, cara, é um negócio fantástico. E aí, assim, até pegando na nessa época foi interessante que assim em 2010, 12, etc. A nuvem tava engatinhando assim, você tinha alguns produtos já rodando em nuvem, mas a grande massa não tava. Você começou a ter os desafios, né? Você quer ter alta disponibilidade e uma resiliência geográfica. Cara, isso aí se eu for pegar o que que a galera rodava de banco on premis, etc. Não, não, não entregava isso. Para você fazer um negócio que funcionasse com 40 km de distância entre um ponto e o outro, cara, não era trivial. Então os ciclos na época foram desenhados permitindo essa tolerância ali a a o particionamento, essa questão um pouco maior. E alguns eram bem eh você pegava, por exemplo, banco de documento, encaixava muito, muito bem pro perfil de aplicação rica que tava sendo desenvolvendo em JavaScript e tudo na nessa época aí, pô, o cara já carrega um documento que tem tudo que ele precisa. em vez ele devia ficar fazendo um monte de join. Perfeito. Então foi um monte de solução um pouco mais nichada, cada uma com o seu grau de aplicabilidade e aí você vai tendo um de repente uma uma abordagem que para aquele problema específico que você quer resolver, aquela resposta de negócio que você quer dar, né, você tem um negócio que encaixa muito melhor do que eu pegar uma solução. Eh, o não existe, né, o oniz fit all. Você tem que falar, cara, eu vou adicionar de repente uma complexidade de ter mais de um tipo de banco de dados, né, na na minha arquitetura. Mas porque, cara, essa solução aqui encaixa tão melhor e eu vou ser tão mais assertivo, né, naquela resposta que vale a pena eu ter um componente a mais, porque ele vai me entregar uma assertividade que sem isso não não tem.
Sim, sem dúvida. Faz todo sentido. E trazendo o tema da observabilidade de volta, você precisa ter isso muito bem observável, porque no momento que você, o cara vai lá e pergunta, por exemplo, o resultado de uma determinada farmácia, etc., Sim, você precisa ter a garantia que aquele dado foi de fato entregue, tá atualizado, né?
Perfeito. E em alguns cenários, talvez eu consiga eh até sinalizar para quem pesquisou por quais nós que ele passou, quais informações que ele varreu.
Uhum.
Então eu consigo ter uma certa auditoria em relação a isso. Fala para ele, ó, a minha linha de raciocínio, a minha linha de raciocínio foi essa e apresentar isso pra pessoa que pesquisou. Então esse é um grande benefício. Então assim, aí tudo volta para contexto, né? A gente são 200 milhões de nó de nós que nós teremos. É um negócio absurdo.
Eu poderia muito bem pegar essas bases e vetorizar elas num banco de vetor ali, um pincone, até mesmo um postbl. Fala, galera, e conectar nisso. Mas a questão é o como é que as coisas estão correlacionadas.
Sim. Sim. Qual que é a similar? Não é só similaridade, é contexto.
Isso é porque diferença até explicando para quem não tem esse essa profundidade, o banco vetorial ele compara valores semelhantes por diferença de cossenos, né, por similaridade. Então ele transforma a informação num num vetor.
Isso.
E aí por similaridade dos vetores, eles chegam a fazer algumas correlações de similaridade. Mas a similaridade não quer dizer que existe correlação.
Perfeito.
Para a correlação você precisa ter o grafo. Isso porque você pode ter informações completamente diferentes que estão coligadas de alguma forma, né? E aí onde o gráfico ganha ganha relevância. É.
E e o curioso é que os nós são informações e o vértice é um vetor.
É, é interessante, né?
Isso é tava estudando esses dias o o funcionamento do do treinamento dos LLMs, né? Tô fazendo um curso, inclusive fica com a dica aqui, tem uma pós-graduação sobre LLM da Universidade de Stanford de graça no YouTube.
Foi legal.
Ficou legal, hein?
Aí eu comecei a assistir as primeiras aulas e aí peguei você, você vai vendo a eu faço isso, né? Eu vou vendo a aula aí, opa, boiei nesse assunto. Aí eu anoto e aí vou procurar entender, né?
E aí tava vendo justamente como que o LLM faz essas inferências, sabe? E é justamente para essa correlação de vetores, né? Então ele eh vou dar um exemplo aqui só porque eu fiquei muito empolgado com esse assunto, achei muito legal, mas por exemplo, ele ele treina a toda informação, todo token, ele é um vetor de nimensões, tá?
É difícil pra gente entender porque a gente só consegue ver três dimensões, né? Mas ele tem n dimensões e essas dimensões são cossenos ali, são são vetores, né?
Eh, e aí olha que que [ __ ] da ideia principal. Ele calcula, por exemplo, homem e mulher. Homem e mulher são dois nossos, tá?
Eu tenho um vetor entre eles que é a correlação entre eles. Por isso que gráfico é muito [ __ ] para LMIM, tá vendo? Então, se eu se eu tenho um vetor desse token para esse outro token que tem uma determinada distância, um determinado ângulo e ele significa que é o oposto de sexo, se eu perguntar para ele qual é o oposto de rei, ele vai no token de rei e ele projeta o mesmo vetor no mesmo cosseno de homem e mulher e o token que vai que ele vai encontrar é rainha.
Caramba! Uhum! Porque no treinamento ele fez essas, é, o modelo da LM é muito dele tentar prever qual que é o próximo nó que você vai chegar, né?
E aí ele faz essas inferências vetoriais para poder adivinhar qual que é o próximo, cara. Enfim, só uma um parênteses que eu dei aqui, uma viajada, mas é interessante mesmo.
E aí a gente tá trabalhando esse projeto, a gente tá negociando com for, não é barato, mas é como você bem trouxe ali no começo, né? Não é custo, é investimento.
Sim, sem dúvida, porque isso no dia a dia vai auxiliar muito toda a empresa, assim, tanto para negociar com indústria, então eu vou conversar com a indústria, eu quero fomentar um produto em tal região, rapidamente eu dou um prompt ali, ele já vai à base e já consegue me trazer esse dado, consegue me trazer essa informação, né?
Porque olha que que curioso, né? Quando você apresentou pra gente empresa no começo, dá a entender pelo core que a gente vê de fora, que é uma empresa de varejo, extremamente focada em varejo. Quando você entende a operação, o teu core é dados.
Sim. Sim.
Porque o que movimenta o varejo que vai te orientar é é dados, né?
Perfeito.
Sim. E cara, e isso até um ponto que você comentou que eu acho que é é um dos motivos ali de ter um potencial que eu acho que é que é bem interessante, porque cara, eu tô no mercado há bastante tempo, a gente já lidou com empresas de todos os perfis e, cara, tem algumas empresas que elas já têm alguns ativos ali de base instalada, volume transacional e etc. Só que você vai ver a cultura, a mentalidade, às vezes é um negócio muito varejão, aquele negócio, espreme ali o caldo, cresce ali um disco tentando chegar no dois. E cara, eh, quando você vai para uma mentalidade, uma cultura mais analítica, mais guiada por dados e habilitando o time a ter mais poder, cara, você consegue fazer um um um modelo de de negócio ali que sai um pouco daquela eh vala comum, né, e vai para algo com potencial bem melhor.
E aí quando você junta isso, né, o poder de uma cultura mais forte, né, com um foco em extrair insites de dados, né, ter pessoas ali que tm uma jornada na empresa que vão, [ __ ] dormir e acordar em cima daqueles desafios ali, vão tentar ter esses insites. Eu acho que você tem um potencial médio e longo prazo bem diferente do que aquele varejão ali que vai tentar massificar aquele modelo ali, que desafios vários a gente sabe, né? Tem tem sempre tem alguma inovação ali, sempre tem alguma coisinha que surge, mas cara, ele é um modelo sofrido ali para você escalar esse modelo, né? potencializado em um conhecimento de dados mais profundo que vai ter esse potencial aí Brasil todo e um time que vai ser eh bem bem moldado em cima de ser analítico e buscar soluções criativas fora da caixa para problemas que são de problemas abertos ali de difícil solução. Acho que isso é bem interessante e foi uma das coisas que me chamou atenção, assim, não não vamos citar nós, né? Mas cara, quando você compara a cultura e o jeito, né, do que que o time se conecta na Farmacas, vendo algumas redes varejão aí, né, que que tem, você fala: "Cara, eh, eu, se eu tiver que escolher meu meu time, né, eu vou escolher um time que tá mais entrosado e alinhado numa visão de longo prazo do que aquela galera que tá sobrevivendo ao varejo ali, que, cara, é, sempre tem seu mérito, é muito execução, bumbo, só que tem ali alavancas, né, isso de de dados e cultura que te permitem andar numa velocidade diferente, né? Então, acho que isso é é um dos pontos aí às vezes eh deixado em segundo plano, mas que que sem dúvida no jogo de longo prazo, acho que isso é bem bem impactante mesmo.
Eu nunca trabalhei no reteio, mas eh eu sempre tive essa visão de que o resultado de venda, etc., ele é consequência de outras coisas que você faz por trás, né?
Uhum. E então acho que aquelas empresas varejão clássico de cara tem que vender mais e gastar menos, cara. Tá, mas vende mais como? Com quem, né?
Então quando você tem uma profundidade com dados, é uma empresa de fato que é data driven, que é orientada por dados, né? Você consegue ter melhores resultados por consequência, né?
é menos esforço naquele problema que não merece de repente tanta Exato. exatamente tanta fricção, né?
Uma pergunta que me deu curiosidade aqui, você falou da máquina na WS com 6 GB de 100 GB de 100 GB, é, e você deve ter um volume absurdo de transação e de banco, etc. Como que é o esquema de gestão de nuvem de vocês e FOPS para garantir que isso tudo não fuja do controle? Boa. Em relação a Finops, o time da Elvin que nos apoia, então nós temos ali uma cadência de reuniões. Eles realizam um trabalho de entender o que que tá superdimensionado.
Por exemplo, Gabriel, essa máquina aqui tá consumindo 30% da sua capacidade.
Vamos diminuir, vamos acompanhar.
Isso foi eh foi bem feito, né? foi muito feito no, principalmente em relação ao e-commerce, como tinha muitas aplicações, eles fizeram um ótimo trabalho.
Eh, em relação a, agora assim, em relação a essa instância que tem a muita memória aí, o Finops foi por água baixa assim, porque é uma máquina cara, é uma máquina cara. A gente tá utilizando mais de 100 GB.
É, mas é é assim, você pega, por exemplo, no e-commerce, eh, de maneira geral, você tem uma característica de sazonalidade enorme, né? Inclusive, daqui a pouco a gente vai ter Black Friday, ele chega aquele aquele momento ali de fazer teste de carga, um tuning ali da do dos servidores, né? O que a gente quer normalmente é que se o teu negócio ali é multissazonal, você tem uma arquitetura que te permita ter uma infraaseline pequena e que nos momentos de pico ela possa crescer de uma forma rápida e depois ela voltar.
Tem uma elasticidade eficiente, né?
Exato. Tem alguns casos em que o pessoal tem o o scale up, mas o down nunca acontece.
Pois é. e aí não atinge o propósito. Só que tem componentes da tua arquitetura que permitem essa elasticidade e banco de dados normalmente não é esse perfil.
Se você vai ter um banco que ele vai ter que ter uma capacidade de escrita, alguma uma um dimensionamento para para segurar a operação. E os componentes que são acho que aplicação, serviço, API, etc., eles têm essa elasticidade e essa escalabilidade horizontal mais fácil, né? O banco, ele normalmente é o é o cara que [ __ ] ele tem que segurar um volume de dados ali grande, ele vai ter seus picos e não é trivial. Assim, com no cicle é um pouco mais fácil quando você tem alguma coisa naqueles modelos ali, tipo um eles mon, você pode ter três nós, cinco nós, vai incluindo nós, né? É, mas mesmo assim não é trivial você, por exemplo, remover um nó ali. Isso a gente já já trabalhou muito muito com clusters ali.
El na época que o que o ESCK era a única opção praticamente, né, de log centralizado, de motor de busca, etc.
Cara, você gerenciava alguns clé ali de alguns terra de de dados, tinha essa possibilidade conveniente, né, de adiciona o nó ali, vai ter mais acesso, não sei o que, distribui, só quando você tentava fazer uma uma contração, beleza, vou temporariamente ficar com cinco, depois eu vou voltar para quatro. Cara, no curto prazo, a sincronização que esses componentes tinham, porque ele tinha aquele modelo, né? você tem eh um um nole que vai tá com aquela cópia principal daquele dado e tem uma ou mais réplicas dos outros.
Cara, quando você decide eliminar um dos nós, esse rebalanceamento, bicho pega, cara. É um negócio que assim dá para fazer, mas não é não é trivial. É um negócio, você tem que escolher muito o momento em que isso vai acontecer, porque senão você acaba ficando com processamento tão crítico ali só pro negócio se rebalancear, que às vezes não se paga. Então isso é é um pouco é é um risco que não não vale a pena.
É mais fácil você conseguir isso com componentes que são mais voláteis, né?
Tipo, cara, uma máquina de API que você sobe, ela cumpre ali o papel dela de servir requisição durante um tempo, daqui a pouco você volta. Processo BET também tem componentes que são mais elásticos com a natureza, né?
Geralmente são componentes que eles não são não guardam estado, né? Então, exatamente, os que guardam estado como banco de dados é muito difícil escar. É. E aí o esses que não guardam estado, você subir uma máquina e derrubar é muito, muito rápido, é muito coisa de segundos ali, você consegue ter o processo se completando, né?
Sim. E fala um pouquinho como é que é essa operação de Finops que a que a Elvin faz. Fica um cara lá olhando todo dia o o biling. Então, isso é um ponto que é interessante, cara, porque assim, ah, a gente na na Elv até um ano e pouco atrás, dois anos atrás, a gente operava esse RE já bastante automação, bastante coisa ali, eh, com uma tentativa de não ter necessidade de ter tanto engenheiro humano, mas não era tão fácil assim a gente conseguir cobrir muitos ambientes sem crescer time do jeito que a gente tá conseguindo agora. Agora a gente conseguiu fazer algumas coisas que são eh muita coisa de um trabalho, não não vou dizer repetivo, mas um trabalho que dá para você padronizar e componentizar.
Por exemplo, eu fazer investigação de incidentes. Eu vou ter um runbook ali que eu vou modelar um agente que consegue executar. Eu vou ter um trabalho aqui de analisar o being, tentar modelar o que que é considerado um desperdício, o que que é um recurso que tá ali não não mais utilizado, né?
Eu consigo ter a gente fazendo isso eh ao longo do tempo. E isso torna eh para pra gente, né, o que que a gente tem tem conseguido fazer, que um engenheiro humano ele pegue aquele dado já pescado ali, processado por a gente e ele consiga avaliar que decisões fazem sentido, né? Por exemplo, ó, cara, pô, tô aqui com um componente que tá com extended suporte lá do do Kubernet, por exemplo, lá. Eu tô com uma versão aqui, pô. Isso aí é óbvio, porque você precisa pegar e atualizar aquele cluster. Não tem motivo pelo qual não faça sentido você atualizar.
Tem alguns outros componentes que é aquela aquela linha tênue, né? Pô, eu t toquei com um banco de dados que tá com 45% de processamento, né, no pico, etc.
Volta e mexe em 50 e tal. É tranquilo e assim decisão segura. Eu reduzi o tamanho dele pela metade e aí eu vou ficar no talo ali, 80 e poucos%. Tem aplicação que pode encaixar bem com isso e não. E aí que que esse cara normalmente vai fazer? Ele vai pegar hipóteses ali de redução que um agente já vai minerar. vai pegar ali e aí, cara, essa riqueza de você pegar dados ali de métricas detalhadas de de consumo de CPU, memória, disco, latência, um monte de coisa, ele conseguir procurar oportunidades, você definir para ele, cara, o que que é um algo candidato a reduzir, cara? Você consegue varrer um terreno maior e e você tem um engenheiro basicamente interpretando aquilo e sabendo como que é a arquitetura, vendo quais são hipóteses reais que fazem sentido para aquela empresa, né? Porque, por exemplo, tem situações, a gente vai mexer com esses legados aí que tm que ser ou modernizados ou descontinuados.
Tem coisas que você vai olhar e fala: "Cara, pô, é verdade que eu posso talvez reduzir 20% desse custo desse legado aqui." Só que o esforço de validação, de percorrer toda essa jornada aqui, talvez seja um negócio complexo e arriscado.
Não vale a pena entrar nessa encrenca, né? Então, ficar mais caro. O risco, o risco é mais caro do que a economia que você teria. E aí o que a gente tem tentado modelar e acho que tem um paralelo forte com essa questão do modelo lá do do anjo lá da Farmacas com os agentes e tal, é tentar ver cara o que que eu gostaria de analisar e que dados que me são relevantes aqui ao longo do tempo. Vamos colocar a gente percorrendo isso aqui ao longo do tempo. De tempos em tempos o engenheiro vai sentar ali com atenção em cima daqueles dados que foram já trazidos de uma forma mastigada, ele vai ter uma interpretação e uma decisão sobre aquilo. falar, olha, dessas 10 hipóteses que você trouxe aqui, tem cinco ou seis que realmente vão fazer sentido, vamos planejar, vamos entregar isso aqui, né, numa próxima release, etc. Mas esse tipo de coisa, acho que até com o volume de dados que a gente tem que lidar hoje, cara, imers, a gente não consegue mais humanamente se concentrar como era antigamente. A gente tem que fazer alguma coisa que, cara, vamos escolher quais são as nossas brigas aqui, quais são as coisas que a gente realmente tem que olhar. E aí tudo que for um dado mais operacional, uma massa bruta lá que você vai ter que percorrer, tentar trabalhar com a gente de um jeito que apareça lá. Olha, isso aqui se tornou um problema de de segurança. Por exemplo, cara, eu tô com um tráfego aqui fora do padrão em algum componente. Eu tô com, cara, alguma interface aqui que tá exposta demais.
Esse tipo de coisa. Se for pegar um ambiente em nuvem, né, uma AWS da vida que tem seus 400, 500 serviços SK lá e tal, cada um com n configurações, cara, a gente não consegue de forma eh assim frequente, recorrente, percorrer esse terreno inteiro. Mais é um ponto você tem que fazer. possível, cara.
É, e aí o que a gente fez muito foi criar um modelo no qual as coisas que são boas práticas, coisas que a gente gostaria de verificar, fazer acesso, cara, a gente vai fazer assess hoje comparando que a gente fazia dois anos atrás, cara, modela um negócio lá em cima dos próprios STKs de nuvem que vamos trazer informação que eu preciso e de uma forma determinística. Inclusive, isso até um ponto bacana. A gente usa muito code, por exemplo, ali para para desenvolver as coisas. Só que tem algumas situações em que é melhor você ter algo que é determinístico, executado em cima de um STK de nuvem, do que você ficar queimando token para algo que você pode modelar de um jeito mais mais assertivo, mais objetivo, né?
E você pode usar o Ll para gerar um código determinístico.
Exato. Exato.
E e não ficar usando o Ll pro. E aí, e aí nesse contexto de operação, tem algumas coisas que são, é mais sobre, sei lá, você vai investigar um incidente complexo ali, pode ser, vai querer ter de repente um modelo com reasoning, alguma coisa bem sofisticada, só que tem muita coisa mais operacional, cara. Um modelo, é um deep se lá. É até complicado falar que deep seek é menos sofisticado, porque cara tá tá super ali.
Só que tem às vezes alguns modelos bem mais baratos e que às vezes não precisam ter reasoning para coisas mais operacionais. por exemplo, um cenário que a gente começou a encontrar disso, o próprio Rico da do Cloud, pode ser um exemplo, né?
Exato. Exato.
E e aí fal em relação a isso, eu fui no fórum E-commerce Brasil, né? E aí o engenheiro Denidde, o que que ele trouxe? Principalmente agora a galera utiliza, tá utilizando ela elemp para tudo, cara. Vai dar um bom dia perguntando por para Iar se ela tá bem, se ela não tá, que o modelo e em relação a custo, o melhor do modelo é o híbrido.
Uhum. É como você trouxe, Brunão, por que não ter uma instância ali um com modelo treinado para talvez resolver alguma coisa mais simples?
Sim, tem muita, por exemplo, cara, a gente tem um no Command Center agora a gente tá com com uma cobertura interessante. 30% dos eventos já são processados por um agente antes até de um de um engenheiro eh ter algum contato com aquilo. E aí o o command center é aquele negócio, né? As coisas ali são muito diretas e objetivas. Você não, cara, você não vai precisar nem [ __ ] perguntar 80 90% do do que tem numa LLM nem é é lixo ali. Não, não, não precisa daquilo.
Então a gente começou a ter uma visão de tipo, cara, tem algumas coisas, tipo, chegou um alerta aqui, eu quero ver se eu tenho um Rambook associado à aquilo ali. Talvez eu não tenha um específico para aquele produto já modelado, como que eu tenho que fazer o trouboting, mas se eu vou pegar, cara, tô gerenciando ambientes ali que tem cubernets, tem PSO, tem banco no ciclo, etc, etc, tem muito alerta que, pô, às vezes na na Farmarcas eu tô tendo um alerta que é muito parecido com outro cliente meu, mercado automotivo, não tem nada a ver uma coisa com a outra, mas cara, no bits e bytes ali, se a stack for parecida, às vezes o problema por baixo ele é semelhante. Então, o que a gente tenta fazer? a gente usa às vezes um match ali de DLM. Aí eu posso usar, por exemplo, um Open Houter com modelo bem mais simples, falar: "Cara, eu quero ver se eu tenho um runbook que seja semelhante ao alerta que eu tô recebendo aqui e ver se parece um uma boa hipótese ou não, porque assim, qual que é um gap sempre na visão de SRE, comand center, etc, as coisas, muitas vezes não tem documentação adequada de qualidade, etc.
Aonde acontece isso? Na Europa, né? Aqui no Brasil é tudo muito bem documentado, cara.
Exato. Noruega. Nosso modelo é praticamente o Japão aqui, né? Quase a Toyota aqui.
Imagina aqui.
E o o que acontece muito é, cara, eu tenho que fazer funcionar algo com confiabilidade, tudo certinho, apesar de não ter essas coisas, né? Então, a gente vai ter que lidar com o fato de que eu não vou ter runbook específico daquele produto, eu vou ter que fazer algo mais avançado. E a gente consegue, né, pegando uma expertise documentação que existem de repente em alguns ambientes e outros ainda não, eu vou evoluindo, né, nisso aí. E aí eu vou conseguindo ter de repente uma forma de eu resolver um problema que aquele time, né, ali específico, de repente não teria tanta expertise, mas eu consigo puxar um runbook que pode ser adequado para aquilo. E aí, por exemplo, esse tipo de coisa, um match, né, entre um alerta e um runbook que eu tenho, isso não precisa de reason, é um negócio bem mais simplão. E a gente vai começar nessa linha, né, cara, eu vou tentar ter um modelo que seja escalável, barato e etc, com um grau de sofisticação que cada problema precisa, né? Um incidente mais aberto ali, eu vou querer correlacionar dados de deploy, de mudanças, etc. Pô, eu vou precisar de algo um pouco mais sofisticado. Agora, algo que eu consigo tornar um pouco mais direto e objetivo, né, eu consigo ter algo que vai ser rápido e barato, né, e aí eu consigo aplicar em larga escala. Então acho que um um muito que a gente tem tentado caminhar, né, é nessa direção de eu vou tentar modelar o que que é uma boa prática, um bom trabalho de engenharia, fazer com que, né, os meus agents lá, os meus minhas skills, etc., consigam se apropriar daquilo. E aí nas próximas investigações eu consigo fazer. E aí para Fops, cara, o bom de Finops é que ele, de maneira geral ele é bem objetivo assim, né? Não é aquela pergunta super aberta. tem decisões de arquitetura que podem fazer sentido ou não. E aí você vai colocar para um engenheiro levar, mas assim, mapear as oportunidades de saving é um negócio que você consegue desenhar um um scan, né, que roda ali diariamente, roda algumas vezes, né, por mês e aí você traz muito mais uma discussão. essa mudança na arquitetura, essa, enfim, essa e captura aqui desse saving, ele é algo inofensivo, dá para fazer no brain, beleza, toco pau aqui, próxima janela que eu puder fazer essa mudança, faço. Se for uma mudança que envolve eh a adaptação da arquitetura, aí vamos colocar na prancheta e ver se se tem risco, se o impacto ali vale a pena, né? E aí com isso, cara, a gente tem conseguido fazer coisas preventivas, que isso aí, cara, Finops é um negócio que é preventivo, assim como revisão ali de problemas de segurança, tem muita coisa preventiva que os times ficavam tão sobrecarregados que não conseguiam fazer. Agora a gente consegue poupar algum tempo ali valioso, trazendo essas hipóteses. E aí eu deixo pro engenheiro eh muito mais o papel de mede o risco disso aqui, vê qual que é o caminho e aí eh com isso a gente tem conseguido fazer um trabalho que não deixa esses débitos técnicos aí, esses problemas se acumularem, né?
Show. Então, toda essa esteira que vocês colocaram aqui, que é monitorada com observabilidade, com FOPS, como colocou o Brunão, eh, traz porque eu fiquei com uma dúvida, eh, Gabriel, você falou que da integração que você tem do RP, tá?
Direto com com a tua plataforma.
Perfeito.
Mas me deu impressão que você tem um escopo muito maior de dados aqui, porque pela inferência que você faz no NewJ, parece que você tem mais informações eh que que são trazidas ali. Essa impressão tá correta ou você tira tudo ali do RP mesmo?
A impressão tá correta.
Quando a gente, de fato, quando nós, quando nós fomos modelar o Newj e a gente olhou para os nossos dados, a gente viu que não que tá faltando informação.
Uhum.
Por qual motivo? Hoje essas informações elas vend parceiro.
Uhum.
Então beleza. Hoje eu não tenho estoque.
Eu não tenho estoque na farmarcas, eu não recebo estoque ali da farmácia. E o estoque é uma informação muito rica para falar se um se uma farmácia tá indo bem ou não.
A partir disso, né, a gente pensou em duas possibilidades. Ou conversar com o parceiro para eles conseguirem trazer o dado pra gente. Só que isso é amoroso porque às vezes o parceiro tem uma outra esteira, talvez atende outras empresas.
E aí a gente olhou para dentro de casa, falei: "Pô, vamos construir o nosso captador, vamos construir a nossa inteligência para capturar o dá do RP".
Ah, é bem desafiador, porque eu tenho grandes grupos. Eu tenho um grupo hoje que fatura eh 2 B. Eu tenho dois empresários que tem mais de 90 farmácias.
Eu tenho uma farmácia que é o cara que tem um Celeron, que eu chego lá na farmácia dele só de barco. Então assim, o negócio são dois cenários, né? E como eu consigo captar o dado dos dois? Aí nós estamos criando uma um captador, uma aplicaçãozinha, ela fica ali e no desktop.
A partir disso, ela vai mandar o dado pra gente, para Farmarcas. Então eu pego esse dado, eu mando pro meu S3 e aí depois ali o time de dados, monta as ETS para poder jogar isso no leak.
E isso vai substituir o dado que você já recebe do RP?
Futuramente. Sim, entendi.
Futuramente ele vai. Vai porque ele consegue trazer o dado ali no menor tempo possível.
Hoje a gente vai trabalhar com janela de 15 minutos. Hoje meu parceiro, ele me entrega o dado em um dia útil.
Então assim, hoje D1 D men1 é assim, a gente tem produtos lá na Farmarcas, por exemplo, tem dois produtos que eles estão em standby porque eu não tenho dado, o parceiro me demora para entregar o dado. Você tem outras empresas que eles vão lá, eles conseguem plugar no RP, eles criam solução e fornecem por associado.
Uhum. E aí eles eles conseguem ter rodado ali o mais quente possível e não é o nosso caso. Aí a partir disso a gente trabalhou numa estratégia, tempo bem curto, utilizamos muito IA e trouxemos a Elvin para poder para poder desenhar a estratégia do projeto. E assim, cara, tá praticamente pronto, já tá em via de começar a implementar. E uma coisa que me chamou muito atenção, né, porque o instalador ele foi desumbido em gol e não é stack do time.
E aí o cara me mandou um print, pô, Gabriel, já tá pronto já. Eu falei: "Cara, mas você programa em Gol?" Ele falou: "Cara, eu não, não, mas o Cloud sim".
É isso. Eu falei: "É isso mesmo." Falei: "Porra, do cacete." Mas eu falei: "Sim, mas é, eu falei, cara, do cacete." Mas eu falei, "Porra, eu preciso minimamente validar isso, porque qual que é o trabalho, né? O time de operações tem que instalar o o essa aplicação em 1700 farmácias.
Eu não posso voltar aqui duas semanas falar: "Galerinha, deu estava de novo".
E aí eu falei: "Pô, Brunão, você tem um cara féri?" Falou: "Gabriel, tenho". Aí ele trouxe um profissional dele, aí o cara veio no modelo de consultoria e tá nos apoiando. Mas, cara, o projeto tá caminhando super bem. E aí o esse ponto é até interessante porque nossa jornada de de produto, né, plataforma SAS da Elvin, a gente viveu um problema diferente, mas com similaridade, né, que assim primeira versão da plataforma da Delvin, a gente fazia um monitoramento all inone, tinha monitoramento, gestão de incidentes, etc. E a gente tinha esse desafio de [ __ ] eu preciso ter uma peça dentro da infra do cliente para poder monitorar tudo sem abrir pra internet, etc. Monitorar banco de dados, um monte de coisa. Só que eu não não posso que esse monitoramento se torne caro, né?
Não pode ser um servidorzão lá, é, tem que ser uma infra bem pequenininha, né?
E a gente acabou ainda nessa pegada, cara, pô, eu quero ter algo que rode no menor tamanho de máquina que a nova tiver, né? Claro, um ambiente um pouco maior, vai precisar de uma máquina um pouquinho maior, mas vários ambientes que a gente monitorava, cara, eu subia um contêinerzinho que embarcava todas essas regras de monitoramento e tal, numa máquina, por exemplo, na Amazon, ela subia numa T4A nano, que é uma máquina minúscula, é menor que a micro, né? era muito muito pequena e era bom porque isso, sei lá, custava 3 por mês, né, no no na Amazon para ter isso aí. E aí o que que era interessante? A gente levantou várias possibilidades, né?
Assim como esse caso do captador, né?
Que tem o o cara tem um celleron lá e é muito limitado. A gente falou: "Cara, se eu te fizer, se eu fizer algo em Java, em DNET ou qualquer coisa que tenha uma máquina virtual, cara, o ciclo de atualização dessa máquina virtual é problemático e consome recurso, etc. E é uma camada extra de processamento também, como você exato. E a gente viu, cara, para esse cenário do captador aqui é uma similaridade forte com esse nosso problema do do monitoramento também. Eu quero algo o mais leve que eu puder ser e o menos error proness em termos de atualização. E aí esse contexto do Gol que é um binário embarcado já com tudo, cara, você controla todo o ciclo de vida dele, permite que mesmo o Céon tenha seu sua sobrevida ali, né, consiga sobreviver, né? É, então foi foi interessante porque assim, cara, um problema de negócio completamente diferente, mas que tinha requisitos não funcionais ali de [ __ ] conseguir rodar numa infra barata e que encaixasse, né? Isso foi foi bom porque os insightes de um cenário bem diferente trouxeram eh aprendizado para outro, né?
Agora, uma curiosidade, não precisa falar se não puder, tá? O que que o captador faz de diferente do dado que é enviado o D-1 do parceiro?
Autonomia. Então eu consigo trazer qualquer dado que tá no banco de dados RP. Hoje com um parceiro, você depende do cara, eu dependo dele. Isso não é flexível, né? Então, tem dado que eu consigo trazer, tem dado que não. Eu consigo reprocessar os meses anteriores porque eu tenho notas de cancelamento, então eu consigo trazer esse dado aqui para Farmarcas.
E um terceiro ponto é flexibilidade, assim, flexibilidade em todos os sentidos, porque eu fico agnóstico a esse parceiro. Eu consigo aqui ter um produto com dado, obviamente que eu tenho ali o processo das ETIS, mas a cada H-1, eu tenho um dado atualizado aqui na Farmarx, eu tenho monitoria, aí nós vamos ter a observabilidade junto a Elvin. Então eu consigo ver ali o teu consigo ter o mapa do Brasil e falar: "Ó, essa região aqui eu tô com problema de internet ou o RP tá desligado?" aconteceu alguma coisa. Aí o o time de operações entra em contato com a sociedade, fala: "Ó, sua máquina tá desligada." E a máquina ligou, ele sobe como serviço e é 100% autônomo, já começa a capturar os dados e mandar pra gente.
Show. E nesse sentido, como que vocês, porque você falou, cara, 1700 farmácias, né? Sempre vai ter um engasgo em algum lugar. Como é que vocês fazem essa gestão de incidentes que não deve ser pequena no dia a dia? É, então isso é um ponto que é interessante, né? Porque é, você pega a observabilidade padrão, é muito ali em torno de latência, tráfeg, isso aí, sei lá, o out of the box, não, que você ganha de observabilidade é meio que em torno disso. Só que esse tipo de problema, né, do captador, ele é um problema que vai numa granularidade bem diferente. Você tem que ver, cara, aquele dado ali não tá íntegro ou veio, eu preciso entender as nuances das métricas ali de negócio, de controle que eu vou ter capacidade para processar, né? E ao mesmo tempo, como esse modelo do do captador até pela natureza dele, ele precisa ser um modelo de eventos que seja eu posso reprocessar, etc., a gente começa a ter a capacidade de de perceber problemas através desses eventos. Então consigo ter um agente, por exemplo, que percorra o stream ali, consiga ver, cara, eu tô tendo algum alguma quebra aqui, alguma coisa. [ __ ] parou de vir nesses eventos aqui os dados na linha do que vinha tendo. Ou, cara, de repente veio uma volumetria diferente ou eu consigo ter algo muito mais especializado para aquele problema de negócio, porque assim, nesse cenário, a princípio, tá, eu não tenho nada indisponível, nada com latência diferente, etc., Só que eu tenho uma métrica ali que meio que o data quality daquele daquele cenário ali ficou ruim.
Então isso aí eu preciso desenhar uma uma opção e aí é tudo nessa linha de openem. Eu vou fazer adaptadores ali que permitem que eu capture esse dado da forma mais padronizada e aberta possível. Posso decidir para onde que eu vou, etc. Mas eu preciso ter a capacidade de de criar eh dimensões de negócios, né, que já não são mais as métricas padrão ali de observabilidade, que vão me sinalizar um problema. E aí, muito nessa linha que a gente tá falando, né, observabilidade, AIOPS, né, que é um, como a gente tem enxergado a a gestão de incidente nesses contextos de EAE, eu teve tive um problema ali, um incidente, alguma coisa que que na perspectiva de negócio é um problema. Eu quero, pô, colocar um agente para investigar alguma coisa. Eu quero eh executar um runbook, né, de validação, né, pô. Beleza, veio um dado aqui quebrado. O banco de dados do parceiro, será que ele corrompeu? Ele parou de rodar, né? No Celer não pode, pode, de repente um RP, po, pode ter um infarto a qualquer momento.
Pode. Cel não parou de rodar, de repente, [ __ ] eu tô capturando aqui, sei lá, tive aqui 5 6 horas de de dados aqui, os eventos não comunicaram mudança nenhuma. Será que o meu o meu componente lá do do RP, será que ele ele morreu, né? E aí é um negócio que assim, a princípio, são coisas que são eh não são aplicações desenvolvidas ali pela farmacas, mas são no perímetro ali que ela tá tá atuando, né? Então esse tipo de coisa, o mundo ideal é que a gente, assim como a gente vai ter um um agente lá estendendo a capacidade daquele anjo que cuida do do associado. Qualquer coisa que a gente perceber nessa operação que seja um sinal de problema, vou colocar um agente para investigar, etc. traz a bola redonda para alguém de repente, pô, você não quer ligar pro cara da farmácia lá no Maranhão, falar: "Olha, vamos ver como é que tá o teu cé." Não, você não quer. Você quer falar: "Olha, eu percebi um problema aqui. Eu vi que de repente o teu RP tá com eh algum problema. Você quer dar uma instrução a mais assertiva possível?" Até porque aquele cara de repente, pô, aquele cara que tem ensino médio no máximo, tem um Não é um cara sofisticado, não é um cara de TI, né?
Exato. Então assim, você não não pode falar, não, habilita aí o teu remote desktop para eu conectar. Não, não dá. É isso é abre os processos do Windows aí, vê se o meu capturador tá rodando.
Vê, vê como é que tá o consumo da da memória. E e esse é um ponto que o e esse é um diferencial, né, de ter um parceiro como a Elvin, porque senão eu poderia muito bem ter estruturado o projeto. Cara, com a Iá, uma semana a gente coloca de pé, depois eu falar Elvin, coloca. É isso aqui.
Uhum. A gente fez o inverso. Falei: "Brunão, o desafio é esse". Então, na reunião de que cof, o Brunão tava comigo, Gabriel, dá para fazer assim, dá para fazer assado.
Uhum.
Ó, isso aqui a gente já sofreu, não dá certo, cara. Vai em gol, que é o caminho. Pô, Brunão, então já fiz a solução em gol aqui. Tem um cara, esse exemplo ele é muito legal porque quando a gente fala de engenharia de software, a gente tá sempre falando muito sobre o código e etc. Esse caso ele é muito interessante porque a operação dele fala muito mais sobre o software do que o código que tá lá.
Perfeito.
Porque o código não deve ser nada de outro mundo. Ele vai capturar informação, vai te enviar para algum end point externo, né?
Não. E aí, eh, teve um outro problema que a gente já viveu, né, que nesse contexto da da farmácia ele eh se manifesta muito rápido, que é, cara, eu vou capturar dados ali de tempos em tempos, eu vou ter que mandar isso para uma API. Vamos pensar, pô, eu tenho 1700 farmácias. Se todas mandarem dados no mesmo segundo, imagina que a o scaling é um pouco complicado.
Então, o que que a gente falou, cara?
[ __ ] eu eu tenho similaridades aqui com monitoramento, com questões de e-commerce, tem tem a n questões. Será que eu não posso modelar esse meu captador para que ele escalone um pouco ali? Olha, essa farmácia aqui é a farmácia 101. Ela vai mandar dados no segundo 11 de cada minuto. Eu quero ter o dado chegando a cada 15 minutos. um sigo aqui que tem ETR, etc, etc. Se eu pegar aqui, cara, vou escalonar as minhas farmácias, cada uma delas vai mandar e a cada, sei lá, no segundo 11, outra no segundo 25, etc. Cara, eu alivio tanto a pressão na minha infra para receber essa pancada, porque se eu for no caminho padrão, não deixa todo mundo vai, cara. Eu começo a ter chicotadas ali a cada um minuto, que faria a minha infra ser muito mais propenso. A vai ter momentos de ociesidade e momentos de que vai receber um gargalo muito grande e vai ter um custo alto.
E aí um negócio meio bobo, solução zero complexidade. Só que assim, como que eu desenho uma infra que vai ser propensa a ser mais confiável, etc. Não vai ser cara, né? e que, [ __ ] eu não preciso exigir dela com nenhuma característica assim fora do comum de escalabilidade.
Eu simplesmente decidi, pô, vamos escalonar, porque assim, para cada farmácia, se eu mando dado minuto a minuto hipoteticamente, mas eu não junto todas elas de uma vez, eu já resolvi boa parte do problema da origem. Então, você conseguiu dividir a carga ao longo do tempo, né, em porções e razoavelmente similares ali, né? Então você tem um fluxo Uhum.
Eh, médio estável, sem gargalos, né?
E e nós, né, o time de engenharia, nós cogitávamos utilizar o Cafka, já tava ali supondo, pô, vai ser, vai ser a pancada isso aí, porque vai ser um custo alto. Aí quando o Bruno não veio com o time, não, Gabriel, dá para fazer de outra forma. O que que a gente faz? A gente pega o dado, joga direto no S3.
Uhum.
Então, o próprio captador do Mano PS3.
Aí eles só mandam 200 por um orquestrador para falar: "Ó, eu já fiz o processo aqui, tá OK? Eu tenho uma camada de auditoria, é o dado imutável.
E do S3, se eu preciso, se eu preciso do dado o mais quente possível, eu jogo no SQS.
Hum.
Consigo pegar ali e que aí você usa ele já com broker de evento para poder processar. Isso mesmo.
Se for o caso do do AD, se for preciso.
É assim, a baita de uma solução simples.
Uhum. e um custo baixo e vai resolver uma dor da empresa, que é um negócio absurdo, porque se você fosse usar um Cafka nesse nessa esteira aí, tu ia gastar uma graninha, hein?
Ia. É, é. E o o Cafka tem essa questão, ele é um para-choque que aguenta um tranco grande, né? Mas essa questão do rebala todo, ele não é tão horizontal, né? Não é tão simples você ter ele pequenininho, baratinho e é eh, enfim, não, o carro fica pequenininho. É. É igual o gnomo. Eu nunca vi.
É, o cara falou em CP e já começa. É, é, já começa de médio para cima, cara.
É, e aí assim, acho que é um pouco isso, gente pensar um pouco eh solução simples para um problema que poderia ficar mais complicado, né? E é muito isso, né?
Tentar fazer a arquitetura ser a mais simples que ela possa ser, respeitando ali, claro, as especificidades de cada domínio, né, cara? Que bacana, cara. Que operação legal que vocês conseguiram eh estruturar, né?
Sim.
Soluções que são que impactam diretamente o negócio, né? Então são soluções que movem de fato o ponteiro, né?
Sim, sim.
E cara, poderia ficar aqui mais uma hora fazendo perguntas, mas a gente que já Quanto tempo tem, Jo? 1 hora:35.
Caramba, rendeu o bate-papo, hein?
Não, e cara, acho que isso aí é um bom gancho também pra gente falar, olha, a gente vai ter oportunidade de discutir bastante sobre esse problemas casos de negócio lá no no evento. No Exatamente. Era isso que eu ia te falar, Brunão. Quando é que vai ser o evento, o Observability Day?
Vai ser 18 de setembro, num lugar muito muito agradável, fácil de chegar e tal, que é o prédio da farmaca. A gente tem um auditório lá, pô, a primeira primeira classe ali super moderna. a gente vai juntar um pessoal, a gente tá fazendo majoritariamente via convites o pessoal na comunidade, como o público do PPT, ele é exatamente o público que a gente gosta de discutir, já tem maturidade, né, para eh observabilidade em produção, a gente deixa o convite aqui pro pessoal eh se reunir com a gente lá. Vai ser uma sexta-feira o dia inteiro, né? muito muito estudo de caso, painel de discussão, muito observabilidade em produção, AIs nesse contexto de o que que eu tô fazendo quando eu percebi um problema, seja ele de infra, seja de uma métrica de negócio, etc. E também nesse cenário, né, que a gente tá tendo uma velocidade absurda de desenvolvimento, ciclo de release muito, muito rápido, né, guard rails que façam sentido pra gente colocar um pouco mais de ordem na casa, né, conseguir ter os times com essa velocidade, sem capotar tudo.
Coisas como observabilidade, segurança, teste automatizado, tem que virar uma entrega dos agentes também, senão você não não consegue humanamente blindar isso tudo, né? Então, todas essas discussões vão ser super fértas. A gente tá com uma grade bem legal, já confirmada. A gente deixa o convite pro pessoal se juntar a gente.
Inclusive estamos contando com o nosso amigo para lá. Estarei lá com certeza. Então se você quiser trocar uma ideia com nós três aqui, ó, aparece lá no evento que vai ser show de bola, porque vai ter outros monstros da observabilidade também pra gente trocar ideia.
Cada um com problema às vezes de engenharia de negócio que pode ser parecido com com o de quem tá assistindo a gente, né? Exatamente. Você tá vendo o QR code aí na tela já e o endereço pra inscrição também tá aqui na descrição do vídeo.
Exatamente. Vamos se encontrar lá e trocar uma ideia, porque operação de tecnologia e observabilidade sempre dá muito papo, cara.
Sim, sim.
Porque é uma coisa muito característica.
Um negócio que eu que eu converso bastante com o pessoal, onde tem confraria de Colos, tem esse próprio grupo, né, do PPT. Cara, eu acho que os nossos problemas aqui no Brasil, eles não correlacionam tanto com o que a gente consome muito da infra, do Netflix, do Shop.
Com certeza tem aprendizados ali, tem muita coisa que vira Open Soci que pode ser solução bacana pra gente, pode o próprio K fica, né, solução surgindo LinkedIn, etc. Só que eu acho que o o sabor e as escolhas que a gente tem de engenharia aqui no no Brasil, a gente precisa adaptar paraa nossa realidade. É muito muito adoção de soluções open source, muitas coisas que vão ter competências e e enfim uma uma comunidade em volta também que esteja presente no Brasil, porque cara, algo muito sofisticado que só a NASA consegue operar não vai servir para cá, né? Então acho que essa questão de saber o que que tá funcionando aqui no Brasil com times que a gente consegue montar, contratar, etc. Inclusive, Farmacas tem muito desafio interessante que, cara, eu ficaria ligado aí com as vagas que eles vão soltar e tal, porque é um ponto, cara, tem desafios aqui que a gente tá falando que, cara, eh, cada vez mais surge um um desafio que, [ __ ] pede soluções diferentes, né? Então, eu acho oportunidade de tá aí na vanguarda de de tecnologia, né?
Certeza. E se quiser acompanhar as nossas vagas, nosso LinkedIn, vamos deixar na descrição. E o Gup, isso aí que é é um pouco isso, cara.
Acho que é é a gente pegar toda essa expertise. [ __ ] beleza, tem o Cloud, tem L, tem um monte de coisa que a gente vai tentar ficar muito próximo da vanguarda lá fora, só que às vezes a gente tem que resolver coisas com 100 vezes menos orçamento que a empresa lá fora. Muita coisa não encaixa aqui e muita coisa a gente tem que ver o que que eu tenho e um esse grupo, né, para ter trocas em volta. Acho que isso traz o nosso eh DNA ali de engenharia brasileira, que acho que tem, cara, uma sofisticação enorme, mas a gente precisa procurar acho que mais benchmarks parecidos com a gente e não com o Netflix, a Amazon, que cara são outra outra infinito, né? Outra realidade.
Outra realidade.
Beleza, cara. Te espero lá então no Observability Day. Vamos trocar uma ideia lá que vai ser muito bom. Brunão Gabriel, obrigadaço, cara, que o episódio foi muito bom. Conseguimos trazer luz aqui numa operação que eu não imaginava que era um um um gigante, né, para para para operar essa tecnologia, cara.
E parabéns pelo trabalho que vocês têm sido tem sido feito lá.
Boa, obrigado. Eu que agradeço o convite aí. É um prazer estar com duas férias aí. Valeu.
Obrigado mesmo, Brunão. Obrigado novamente, cara. Sé imagina, cara, eu que que agradeço sempre. Acho que é um terreno fértil assim. E até, cara, parabéns aí pelo trabalho de juntar referências de engenharia que estão atuando em diferentes indústrias, tudo a que esse terreno para discussão. E a gente inclusive pega o que você ouviu num episódio, você discute interno, cara, isso promove uma troca que eu acho que é bem legal. Então, parabéns aí pelo pelo canal, pelo trabalho que você tem feito também, cara. Obrigado aí pelo espaço que a gente quer no final das contas trazer nossa contribuição também para essa engenharia poder evoluir, todo mundo se preocupar mais com temas ali de infraem produção, observaridade. São temas que sempre vão ter que aparecer quando o produto ganha ganhar essa tração mais forte.
Isso. É que é o que importa na verdade, né? É, é software rodando e trazendo resultado pra empresa, né?
Isso meus amigos, obrigado você que acompanhou a gente até agora, muito obrigado pela audiência de vocês. Se você entende que o nosso trabalho agrega valor na sua vida, você pode contribuir também aqui com o PPT no compil. Você pode ser membro lá do canal no YouTube, vai lá, seja membro, vai contribuir com valor pro PPT, não compila todos os meses. Ou você pode fazer uma contribuição esporádica pro PPT. Lá [email protected] br e sei lá, paga uma peruca pro Brunão.
Boa.
E a ou para mim ou o nosso diurético aqui, né? Nosso, o nosso diurético, exatamente. Já dá uma colaborada aqui com a gente. E se você é uma empresa e gostaria também de ser parceira do PPT não compila, [email protected].
BR, meus amigos, obrigado de novo.
Valeu,
Episódios Relacionados
2h 7minObservabilidade Moderna: Do APM aos Agentes de IA
Rômulo Barbosa, Bruno Pereira
8 de jun. de 2026
1h 22minGovernança de Dados no Agro: Do IoT ao Self-Service com IA
Rômulo Barbosa, Diego Dias
13 de jul. de 2026
1h 46minNoSQL vs SQL na Prática: Como a Natura Adotou Performance em Escala
Fabricio Pinho Rucci, Sócrates Vieira, Andrea Gomes Ribeiro
9 de jul. de 2025
1h 13minDo Legado ao Cloud Native: O Case de Modernização da Natura
Felipe Matheus, Márcio Willian Cabreira, Valdir Scarin
5 de fev. de 2025
