 melhorar na primeira vez. Eu vou... eu vou ensinar o que é isso agora aqui, então... aí é o seguinte, tá? A hora que ele der Live, contem até 10 que ele tem um pouquinho de delay, e aí vocês comecem, tá? Então eu vou... beleza? Aí tá aparecendo já, tá funcionando na tela, tá tranquilo dá pra ver tudo de bom aqui. Tá, tá ouvindo aí, é... o... o redão tá dando pra colegar o slide. O seu... o seu... o seu microfone ainda tá dando um pouquinho de chiado, tá, William? Não sei se... se sou só eu, tô ouvindo. Tá um pouquinho mesmo. O meu tá normal? O seu tá normal, o seu tá normal. Deixa eu ver se... melhorou? Acho que melhorou, não é nada também muito absurdo. Eu acho que o Pedro, como ele tá te ouvindo também, qualquer coisa ele consegue te falar se... se chiar ou não. Beleza, fechou. Beleza? Deixa eu sair aqui, então... aí vocês começam, conta até 10 e começa, beleza? Tá, tá bom, beleza. Valeu. Bom, boa tarde a todos e a todas. Eu sou o Pedro Tote, e tô aqui junto com o Savedra hoje. Nós somos do Itamuni Banco e a gente vai falar um pouquinho do nosso case de SRE, usando Thanos, um ambiente de sandbox que nós temos na nossa equipe. Passei, por favor, rapidinho eu. Boa. Rapidinho passando aqui, com alguns rápidos, tá? Eu sou o Pedro Tote, como eu falei. Eu era piô do time, até pouco tempo atrás. Eu acabei mudando aqui internamente no banco, mas eu acompanhei a equipe de métricas, que é a SPAD ACME, que cuida dessa plataforma hoje. Foram muitos desafios no ano, então, que a gente vai compartilhar com vocês aqui hoje. É um pouquinho do que a gente passou, do que a gente viveu, do que a gente teve que modificar na nossa plataforma, tá? Então, falando rapidamente, nós somos uma comunidade de confiabilidade, tá? Então, a gente é focado 100% no SRE, na confiabilidade, na entrega de produtos melhores. Os nossos times são time multidisciplinares, então, a gente vai ter pessoas aí focadas em cloud, focadas em desenvolvimento, focadas em infraza-code, enfim, tem um pouquinho de tudo, tá? Hoje a gente costuma falar que a gente ataca nos pilares de SRE mais dois, então, a gente vai atacar em métricas, logs, tracing, e a gente põe mais dois, que é a parte de APM e a parte de que a gente também abraça nessa nossa empreitada. Hoje nós somos a principal plataforma de métricas do banco. O banco é muito grande, né? São mais de 10 mil funcionários só na tecnologia. 100 mil funcionários em todo. Então, existem, lógico, diversas plataformas aí, mas hoje a nossa é a maior 100% da infraestrutura do banco, tá? Então, hoje a gente atende todos os ambientes computacionais. Tanta parte mais nova, tanta parte cloud, quanta parte on-premises, parte de IaaS, Paas. Nós somos por DNA open-source, sempre. Então, sempre que a gente pode, sempre que a solução é viável, a gente está usando open-source. É até um ponto legal comentar aqui que o banco está se movimentando para poder contribuir mais com a comunidade open-source. Então, o banco está criando suas políticas internas. Então, logo, logo, o pessoal do Itaú vai estar podendo comitar códigos no próprio login do Itaú. Isso vai ser muito legal para a comunidade. E acho que o recado principal que eu tinha também aqui é que nós temos vagas. Temos muitas oportunidades dentro dos times de SRA de contabilidade. Então, se você está aí, tem interesse em trabalhar numa equipe grande, uma equipe legal. No final, a gente vai deixar nosso contato bom? E vamos lá, Will, contigo. Boa, galera. Bom, meu nome é William. Atuei junto com o Pedrão junto na comunidade de confeabilidade aí. Eu vou mostrar aqui um case que a gente tem, onde a gente criou a nossa plataforma de métricas baseada em cima de algumas ferramentas open-source. Acho que, talvez, a principal dela aí é o Thanos. O Thanos é o grande viabilizador desse projeto. Vamos falar de algumas outras ferramentas também que compõem o case inteiro e vamos passar aí algumas configurações que a gente diz aí que é chave para o case. Então, vamos lá. Então, por que do Thanos? O banco, ele não só banco, mas também de que boa parte do pessoal que decide aí passar essa jornada de métricas. Já deve ter visto falar do Thanos. Existem outros play, existem outras soluções bacanas, mas o Thanos aí a gente acabou vendo um pouco dos pontos positivos deles e a gente acabou a do Thanos. Então, uma delas aqui que o elenco é a possibilidade de a gente ter alta retenção com performance. Então, dentro da nossa solução a gente tem a necessidade de fazer uma alta retenção tanto de período quanto de quantidade de métricas e o Thanos se provou bastante performático dentro do que a gente esperava para as consultas e para o pessoal que utiliza a plataforma, principalmente os devs utilizar. Então, a gente consegue colocar ele em alta disponibilidade também. Então, a gente consegue ter alguns componentes escaláveis no momento da consulta. Também sofre alguma carga. Histórias de baixo custo talvez coloquei até aqui em Negrito em um bullet que talvez isso também é um dos pontos principais que faz a gente aderir o Thanos. Então, a gente consegue aí, dependendo da sua cloud, se consegue colocar na S3 para WS no cloud storage para Google enfim, Azure também. E o último ponto é o famoso DelSemp que faz com que a gente consiga ter a longo prazo, essas retenções a gente consegue também dar uma parametrizada para poder diminuir um pouco essa parte de retenção fazendo esse DelSemp das métricas dentro do test DB e também a compactação. Então, vou falar um pouco sobre as soluções utilizadas Então, vou separar aqui alguns quadros para a gente poder entender um pouco da forma Então, a gente vai passar por gerenciamento IAC o que a gente utilizou para poder fazer gerenciar tanto o state quanto a parte de infraza-code que essa infraestrutura tem. Run, então, que Kubernetes é melhor fora inclusive para a gente falar um pouquinho de como a gente implementou também dentro seja o ponto principal mas a gente vai passar um pouco de como a gente estruturou isso para a parte de camada de rede dentro do cluster a gente escolheu o Istio um pouco pode parecer um pouco o bala de canhão porque tanto que às vezes alguém pode só para a parte de rede mas aqui no Istio a gente provou a gente fez algumas coques para a parte de renda estável para a parte de alta requisição embora a gente tenha alguns estudos que pode ser um pouco negroso mas vocês vão ver que a implementação do Istio se deu aqui para essa plataforma um pouco mais simples e não carregando tantos componentes quanto tinha antes e na parte de metrics e adaptação o Thanos, Prometheus e Grafana Na parte de Alert também a gente utiliza a solução do Prometheus o Alert Manager junto com o Thanos Rouge para poder fazer essa parte de de regra e armazenamento e para a gente provar que em casa de ferreira a gente já falou um pouco sobre como a gente observa a observabilidade dessa plataforma então vamos lá toda a parte de toda a infraestrutura foi aprovisionada via Terraform então hoje a gente tem todos os clusters e todo o gerenciamento via IAC todos os serviços dentro do que são depoados dentro desses clusters, eles estão todos em realcharts então a gente tem ali toda a parte de alert team que a gente criou um chart exclusivo levando um alert manager pelo Isto mesmo, que são os charts da comunidade que a gente utiliza com Prometheus que é o Prometheus do cluster que faz a parte de observabilidade dos serviços que a gente tem do Thanos e até o próprio Splunk que é a nossa ferramenta de log que a gente utiliza também tem o seu hamshark então aqui tem uns print aqui de como a gente organiza um pouco enfim a gente não conseguiu trazer o code porque por enquanto o próprio Pedrão falou que a gente está a um trabalho de poder compartilhar isso com vocês a gente tem um trabalho aqui provavelmente a gente vai ter essa permissão para a gente poder compartilhar com vocês falar um pouco sobre Kubernetes então a gente tem três clusters para cada tipo três clusters idênticos então a gente tem uma infraestrutura dedicada para dev um logação em produção e aí aqui está uma curiosidade a gente trata como a gente é a squad que cuida desse produto dessa plataforma então para a gente independente serão um cluster de dev um logação a gente trata todos como produtivo afinal são contas de dev que o banco tem como enviando métricas para essa estrutura tanto para uma logação e aí a gente tem uma criticidade que a gente enxerga que o tratamento é igual perante esses clusters então falando um pouco agora sobre como a gente distribui esses workloads e esses nodes eu acho que aqui vale ressaltar que quando a gente entra e decide ali colocar alguma aplicação dentro do Kubernetes eu acho que vale muito o entendimento de como a aplicação também funciona então a gente fez um estudo o Thanos hoje a gente chegou assim numa fase de ascensão vamos dizer assim com relação à plataforma do Thanos mas também levou um certo período para a gente amadurecer e ter a evolução dele como a gente conhece hoje aqui dentro a gente tem workloads voltados para cada tipo de workload a fim de ter mais um pouquinho de relisilência ali perto para o Kubernetes então a gente separou da seguinte forma a gente tem cinco workloads específicos um voltado para Thanos query que é um dos componentes já já vou falar um pouco mais sobre os componentes um voltado para a Thanos Receiver Store a gente tem um específico para o Graphana um específico para monitoramento que é onde está o observabilite de cada cluster e a gente tem um general que a gente fala aí que são workloads que pode levar a vários tipos de aplicações que talvez não esteja tão relacionado ali com core vamos dizer assim do objetivo do cluster então a gente fez o capacity de esses caras hoje aqui a gente atua 100% na AWS então a gente sabe que essa parte de capacidade para cada tipo de aplicação é importante então além do ICS também tem algumas limitações com tipos de instâncias a quantidade de pods que a gente pode incluir em cada instância então isso é uma parte que também está dentro desse plano de nodes e a gente colocou aqui um pouco do pense na conta a gente também fez um trabalho de tentar entender qual a importância dentro da estrutura e é onde a gente consegue também economizar com máquinas de spots, um domain, onde pode ou não pode então a gente entendeu ali que até por exemplo vocês vão ver que estão mostrando que o workload digitando o square todas as máquinas ali são spot e também para o monitoring falando um pouco da parte de rede e da implementação do Istio então a gente levou o Istio para poder ganhar um pouco mais de resistência e controle dentro do tráfego dos clusters e então é bem simples como falei a gente usa a adoção bem simples do Istio a gente não chegou a componentizar ele por inteiro a gente tem dois Ingress dedicados para o query um para o query e um para o receiver então são dois Ingress e cada um plugado ali no NLB da nossa conta principal para poder fazer todo o serviço de interface para as outras contas também e um dos ganhos aí que a gente viu com o Istio até da parte de configuração que a gente achou bem amplificativo nas documentações é fazer esse gerenciamento de tráfego vou entrar um pouco mais a fundo agora nos próximos slides com relação ao Thanos mas a gente tem um puxando só dando um spoiler aqui a gente tem dentro do Istio a gente faz o gerenciamento e a distribuição de tráfego para cada tipo de orquilode via Header então a gente tem um Header que a gente chama de Thanos Tenant que ele vai fazer um pouco mais sentido na próxima explicação para a gente poder paguear essa conexão e fazer com que o Ingress do Istio faça a entrega lá para o orquilode dedicado então falando agora um pouco mais sobre Thanos e Prometheus a gente utiliza os principais componentes do Thanos então a gente tem aí como Stateful 7 implementado dentro do cluster o Story Receiver a gente tem um como deployment a gente tem o Compact Query Front e Ruler para quem não sabe história ali ele funciona como Gateway ali mais ou menos para o S3 com sim que dos test DB que estão no S3 Receiver ele ao principal cara responsável por fazer receber as métricas do Prometheus via Remote Write e a gente tem o Compact para poder fazer a parte de contractação e também o Dalsamp dos test DBs que estão no S3 ou enfim que estão lá o Query que é bem interessante e não sei se alguém já tentou colocar o Prometheus e fazer as cons... várias Prometheus e fazer consulta nele então o Query também faz um papel ali além não só de fazer consulta mas também um papel de dedo aplicação existem outras ferramentas que a gente tem na comunidade quando você tem um Prometheus distribuído e você faz essa dedo de dedo aplicação mas aqui dentro do Thanos isso já está contemplado o Query Front ali para parte de ele faz uma interfação entre a conexão a parte de Gateway do Grafame para fazer alguma Query com o próprio Query então ele também é possível fazer um cache com ele e por isso ele está ali como Query Front que é mais uma camada que você consegue ganhar um pouco mas ele é esse e até mesmo dependendo do tipo de consulta fazer um cache até utilizando outros tipos de ferramentas de cache que a gente já conhece no mercado e tem o Thanos Ruler que ele é basicamente o... ele faz o papel ali do que tem um pouco do Prometheus também que é fazer a avaliação dos Alert Rulers ele funciona como um um job ele fica fazendo o Scrap da dos Alert Rulers que você cadastra para poder ver se alguma regra foi ferida ou não e aí a gente utiliza esse componente para cada para poder fazer essa parte de monitoramento então vale ressaltar que cada cliente que ele tem dentro do cluster tem a Solene Space com uma stack do Thanos essa foi uma forma que a gente encontrou para fazer ganho ter um ganho mais de resiliência o Thanos ele funciona a gente configurou ele com os telas de cada cliente e a gente vai falar um pouquinho mais a frente e aí a gente utiliza na conta do Consumer então se a gente parar para pensar a nossa conta a conta dos clientes que é onde realmente eles tem o Prometheus ele atua como Remotivate e vê essas métricas para o Thanos vocês vão ver aqui curiosamente que a gente também coloca o S3 dentro da conta do cliente isso porque aqui dentro do banco cada conta ele tem um centro de custo então o S3 fica na conta do cliente e a gente tem uma role específica uma polícia que faz um cross account nessas contas e que dá a permissão do Thanos tanto fazer o PUT quanto o Deligit e enfim o que ele precisa fazer dentro dos bancos do cliente a gente também já tem uma frente com open telemetry foi até bacana a gente ter aí agora a última palestra que passou falando sobre collector então a gente também está hoje hoje está muito mais embasado no Prometheus mas a gente já está começando também a fazer essas pocs com open telemetry usando collector também para poder fazer um envio dessas métricas por Thanos vamos falar um pouco sobre como é que funciona e entrar um pouco mais a fundo nos serviços acho que talvez aqui para exemplificar um pouco eu escolhi aqui o Thanos recível para a gente entrar um pouco mais a fundo como a gente configurou o Thanos quando você vai configurar o Thanos você precisa do Thanos recível para fazer para você receber essas métricas e ele tem um componente que a gente chama uma configuração específica que é o hatchwing que é onde você cria um tenet do Thanos e esse tenet está relacionado muito lá com aquele que a gente instrumentou lá dentro do Easter então só para poder falar dentro do hatchwing você pode criar vários tenets onde você pode criar um grupo de receivers para poder receber métricas então aqui está um pouco da configuração do que a gente utilizou então a gente tem aqui o hatchwing aqui tem até um exemplo de no mesmo hatchwing que no mesmo Thanos recível tem três tenets até mostra aqui que no tenet A eu tenho dois grupos de receivers atuano eu tenho esse tenet BC também com esses dois grupos e eu tenho um soft tenet que também tem apenas um receiver atuano então o receiver você tem essa possibilidade de você criar diversos tenets e aí ah beleza qual seria a ocasião que eu poderia estar criando um tenet diferente você pode criar um tenet básico o soft tenet é onde você receberia poucas métricas e você pode criar um outro tenet que a gente considera até na documentação tão exemplificado como hard tenet então eu posso pendurar vários receivers em cima desse tenet e quando isso é preciso, quando você vai lidar com um alto volume de métricas uma forma que o Thanos ele tem de dar conta do recado vamos dizer assim, falando lá um pouco mais liga é você ter um conjunto de receiver onde ele consiga fazer esse farm out e consequentemente dando conta dessas exições e também gravando esses dados então se você tiver um cluster muito grande e um que está enviando muita métrica ao mesmo tempo provavelmente se você tiver um Thanos ali, um receiver um só, provavelmente ele não vai dar conta também ele vai fechar o test db ele vai dar alguns problemas e aí a forma de você contornar isso é você criar no tenets com grandes quantidades de receiver para você suportar a alta demanda beleza acho que só pode estar ok e aí como é que a gente faz o tráfego chegar até lá então eu tenho o tenet configurado se você for ele usa esse valor dentro dessa configuração para fazer o match do tenet e o Thanos tenet é o header padrão que eu utilizo ele pode ser customizado também se você não gostou do momento do Thanos tenet você pode colocar um outro se você quiser mas no caso a gente mantele então o tráfego do ischio quando a requisição chega as requisições eles têm esse header o ischio ele analisa esse header para poder saber para onde ele precisa enviar qual o name space o receiver está para poder direcionar esse tráfego então não está aqui um pouco da configuração que a gente cria um virtual service é um componente do ischio que a gente cria dentro do próprio Kubernetes quando a gente implementa o ischio ele vira um server para você poder fazer essa criação então ele verifica que o tenet se esse tenet der um match ele ele direciona para os destination que está cadastrado para o tenes query a gente faz da mesma forma se a gente reparar lá no começo quando eu falei cada cliente tem a sua name space contando o query e tal com o ecossistema dele então quando o grafana faz as consultas a gente também instrumenta todo o lado do grafana a gente vai mostrar um pouquinho para fazer o envio desse header para a gente então quando o cliente ele está no grafana, na organização ele criou e faz as requisições o grafana também envia esse tenet para a gente para a gente poder direcionar ele para o tenes query dele e aí tudo isso galera é porque a gente tem que mostrar um pouco dos números a gente trabalha mesmo com um alto volume de grandes quantidades de gente enviando métricas para a gente existem outras formas também de ser multi tenet dentro do Thanos mas existem algumas formas e aí eu acho que talvez esse é uma das coisas mais legais de a gente trabalhar com o do Opensur é que a gente também pode criar soluções novas e achar soluções novas porque a ferramenta permite isso para a gente e essa foi uma forma que a gente encontrou para a parte do Prometes então Prometes estabelecido na conta do cliente essas são as configurações e eu estou trazendo uma configuração de EC2 mas a concepção de envio de métricas é basicamente igual tanto para a ICS e para os outros serviços então a gente tem aqui a parte de external labels que a gente utiliza para fazer a identificação das contas então isso é uma coisa que está instrumentada no modo serviço quando o pessoal cria a conta a gente tem um EC2 Discover aqui que eu trouxe um job que a gente utiliza para poder fazer o um inventário das EC2 que estão na conta do cliente e fazer por si só fazer a coletagem das métricas a gente instrumentou que esse a coleta começa a partir de uma tag que a gente colocou então a gente tem aqui uma tag uma dessa R&Metrics e tudo que for, quando ela for go through o Prometes identifica essa fazer a coletagem das métricas vale ressaltar que todas as imagens do banco elas já nascem com exportas hoje dentro do fluxo então basicamente isso também já está contemplado por isso que a gente tem essa essa automação e aqui por último remote write mandando para o endpoint do Thanos todas as contas elas têm o VPC de ponte do Thanos com pré-configurada então de nascência da e-mail quando o pessoal de cloud do banco ele já cria conta essas dispões já estão disponíveis lá para ser utilizada nas VPCs então isso também entra no nosso serviço que a gente criou então falando agora um pouco de grafana a gente separa tudo por organization então cada conta a gente tem lá mais ou menos que cada tendo um pouco de cenário cada conta lá a gente consegue ter se não me engano que são três contas da WS que são devem, mogação e produção então essas pessoal, os devs e as squads que utilizam o serviço eles entram no grafana e eles têm as suas organizations falando um pouco de grafana como que a gente provisão no grafana né como eu disse tudo está linkado com o nosso serviço né então a gente usa o grafana provisão pra quem não conhece é como se fosse uma estrutura uma automação que o grafana tem ali é parecida ali com alguns templates que eles dão como se fosse um IAC, vamos dizer assim mas você consegue fazer templates tanto pra data source quanto pra dashboard então a gente utiliza ele pra poder fazer o provisornamento dessas configurações dentro das ordens então aqui está aqui está um exemplo de data source né mostrando a gente cria nos três data source de produção, mogação e desenvolvimento e também a gente também faz a gente possui alguns templates defaults que são pra pra ter uma visualização de dados quando essas metas chegar lá, então tem tanto pra EC2 KS, ECS, a gente também é disponibiliza os dashboards padrões lá e a gente também pode fazer o dashboard como ele quiser também se ele for necessidade dele então visualização passando aqui um pouco agora pra alerta, então a gente utiliza o tannis ruler pra poder fazer esse sync com as regras dele e ver se a regra está em firing ou não essas regras como que a gente fez, a gente desenvolveu aqui muito parecido com o um pouco docturo de GitOps mas a gente desenvolveu um componente, um conector que ele sincroniza, a gente tem um repositório onde a gente guarda todas as metas, as rulers né todas as regras de alerta ele faz um sync de 2 em 2 minutos cutando as rulers e isso ocorre o disparo de algum alerta ele vê essa requisição pro alert manager o alert manager vê a webhook e consegue disparar o alerta pra qual canal seja necessário hoje a gente utiliza o service now e também contém meio com ele e aí trouxe um pouco sobre essa visão de como a gente construiu esse sync com o tannis ruler ele basicamente é onde a gente desenvolveu ele aqui dentro pra fazer um sync commit hub e ele compartilha né ele faz o download ali dentro do ele vai como um extra container dentro da implementação do tannis ruler e eles compartilham mais o volume pra poder fazer o download dessas métricas essas regras e disponibilizar ali o tannis ruler e ele mesmo também já faz o próprio reloading com só um jobzinho ali que fica rodando de tempos em tempos pegando as configurações do git e jogando pra dentro do tannis ruler e aqui eu tenho um overview trazendo um overview direto aqui pra vocês de como ficou toda essa implementação basicamente a gente tem aqui dentro da name space o ecossistema do tannis com as configurações do list virtual service de cada serviço basicamente a gente só usa dois para o funcionamento que é pro receiver e pro query envio de métrica e consulta a gente tem os nlbs dentro da nossa conta principal que faz a interface para as contas dos usuários que a gente coloca com o consumer do Prometheus enviano e isso pro nlb com uma interface e ele chegando pra dentro do receiver e também o grafana a gente tem um nlb dedicado pra ele também fazendo as consultas pra dentro do query e para falar um pouco sobre observabilidade então essas são os ferramentas aqui a gente tem splunk a gente usa os splunk e grafana e o Prometheus com composite métricos pra monitorar todo esse ecossistema que a gente falou e aqui tá um pouco sobre algumas informações que a gente tem antes do grafana que a gente tem não vou mostrar um mundo ideal, tem uns alertas aqui a gente sabe que se mostrar só algo bonito não também pode ser um pouco imitido então a gente também tem aqui uns alertas mostrando então a gente vê que a gente tem um isso aqui é uma visão de um cluster só a produção, então a gente tem aqui praticamente quase 12 mil 12 mil operações aqui por segundo ocorrido graças a Deus a taxa de erro que ainda é baixa mas a gente tem aí bastante coisa sendo monitorado pelo nosso observabilidade e aqui eu coloquei um pouco sobre uma das visões que eu mais gosto lá atrás quando a gente começou a gente viu que a gente tinha essa deficiência um pouco e com essa nova versão que a gente trouxe com esse case a gente implementou um pego muito forte na parte de observabilidade do produto então a gente consegue ver por exemplo aqui os request conseguindo de cada Thanos receiver então a gente chega no detalhe a gente consegue ter uma observabilidade muito boa com isso daqui sobre com que cada receiver aqui está recebendo e também toda a parte de latência a gente também consegue medir além de saber se algum endpoint deu erro 500 tanto aqui também na parte de Rio 400 enfim e por último, trazendo alguns sites desse desse case hoje são 72 nodes praticamente por cada cluster é bem é bem robusto e tende a crescer mais graças a Deus a gente tem aí uma taxa de sucesso assim que a gente subiu esse novo da plataforma, vamos dizer assim, a gente tem tido poucos problemas mas isso também vem muito de uma evolução passada que a gente teve vários que o time também desempenhou no passado para poder chegar nessa maturidade a gente tem basicamente hoje aí contando basicamente quase 3.500 operações por segundo a gente tem um capacito de 10.000 a gente processa aí na casa dos 500B milhões de métricas por dia acredite esse é um número que a gente tem são mais ou menos 1.600 podes a gente atende hoje que a gente fez um balanço aí 810 contas e são 810 contas enviando métricas de diversos tipos de workload tanto de aplicação e a gente também tem alguns times que instrumentam aplicação para enviar métricas para o Thanos então isso é uma coisa muito bacana e enfim todo tipo de workload e mais de 2.000 containers aí rodando por cluster esses números aqui de podes container são por clusters trouxe algumas referências queria trazer uma live demo mas a gente não conseguiu trazer a gente está fazendo um trabalho grande de compartilhar esse case e compartilhar mais com a comunidade como o Pedro já falou mas a gente colocou aqui algumas referências que a gente colocou da própria comunidade cada componente para poder trazer um pouco mais insights para vocês é isso galera bom, aqui está aqui quem quiser falar discutir um pouco mais sobre esse case não dá para trazer tudo de bate pronto aqui senão a gente teria que usar mais tempo e então está aqui quem quiser pode me contatar nas redes sociais esse QR code leva diretamente ao perfil da rinquedinha lá podem me chamar mas para frente eu pretendo fazer algumas publicações lá no GitHub para a gente também ter um pouco mais de compartilhamento e não só esse case mas também com relação ao Thanos em si então fica uma vontade aí aqui também está o Pedro podem chamar ele aí cara fera, fera, fera e não essa parte de produto e é isso galera é só um último recadinho aqui gostaria de paramilizar também o pessoal aqui do evento vou agradecer a oportunidade de a gente estar falando aqui mostrando um pouco sobre como a gente está crescendo nesse mundo open source e trazendo isso para as grandes instituições vamos dizer assim e também falar que esse trabalho todo aqui é do nosso time eu fui escolhido aqui para poder falar mas tem toda uma galera foda por trás que também arrega essas bandas e sai um pouco da caixinha aí para trazer algumas soluções quer falar alguma coisa aí? não acho que isso mesmo tem algumas perguntas aqui no chat mas a gente responde já na sequência aqui o pessoal que está em cima do tempo já também isso agradecer todo mundo pela paciência aí e precisando entra em contato com a gente vamos bater um papo, vamos conversar sobre o assunto a gente quer contribuir bastante aí com a comunidade é isso fechou eu fechou valeu pessoal, obrigado hein valeu pessoal