A arquitetura de transição, acho que aqui eu vou colocar alguns tópicos, a gente já conversou um pouco aqui, mas só juntando tudo num slide só. A arquitetura de transição tem que existir porque quando você vai fazer uma modernização, você tem uma mudança muito complexa e muito demorada para fazer. E gerar valor durante o percurso, de forma progressiva, vai ser necessário. Senão você não vai conseguir deixar de pé o que você está vendendo, o que você está contando e que faz sentido. É muito bonito você chegar e falar que o sistema, usando mensageria e com resiliência, etc., é bem melhor para o seu cliente. Mas enquanto o seu cliente não estiver vendo isso, para ele, é só ruim. Você só não está conseguindo fazer o que você quer. Então, tenha claro que durante a sua arquitetura de transição, você vai ter desperdício, você vai construir coisas e vai jogar fora, e não só tenha claro, deixe isso claro, e deixe isso claro de forma bem parceira, não dá para você falar para as pessoas assim, ah, não vamos construir e jogar fora, é, ó, a gente vai construir, a gente vai construir, a gente vai gerar esse valor, a gente vai experimentar isso, depois a gente vai ter que jogar um pouco fora e fazer uma coisa melhorada. Isso é um conceito de construção contínua e não de, puta, construir e acabou, já era, nunca mais mexe. Então, tenha isso claro. Desapega das soluções perfeitas no primeiro momento. É bem isso. Ah, dá pra eu fazer uma solução que não tem teste? Não, não dá, você tem que testar. Dá pra fazer uma solução que não tem observabilidade? Não dá. Se você tiver observabilidade em D mais 1, der problema, você vai rodar. Mas, você precisa fazer a primeira solução com todos os pontos de resiliência possíveis, com todos os dashboards possíveis. Meu, se você tiver que decidir entre um dashboard e um alerta, deixa um alerta, cara, porque o dashboard você vai olhar, mas o alerta vai te falar se você estiver de madrugada dormindo, se você tem que entrar para resolver aquele negócio ou não. Então, é importante você pensar no que é crucial para aquilo, e eu não consigo dar a receita do bolo, porque vai depender do que você está fazendo, qual risco você quer tomar, porque sim, é sobre tomada de risco, e decida quais são as soluções mínimas e possíveis de serem tratadas no primeiro momento e depois vai gerando mais coisas em cima dela. E não esquece, uma solução depois que ela for colocada, se ela não estiver no seu melhor de resiliência, de observabilidade, etc., você tem que voltar nela. Se você não tem uma maturidade no seu time para voltar e ir refazendo e arrumando, primeiro você tem que ter essa maturidade antes de fazer isso. Outra coisa, é muito importante você conseguir separar quais são as funções do negócio, as funções sistêmicas que vão ser entregues na primeira rodada, quais são as da próxima rodada, cada sprint, a cada tempo de entrega, quais são as funções que você vai deixar entrega, quais são as funções que você vai deixar de fora e quais são as funções que você vai entregar. Normalmente, quando a gente tem times com menos maturidade, eles querem entregar tudo de uma vez só, e isso é horrível. Tudo é, eu costumo brincar, tudo é prioridade, não é da prioridade, né? Então, pensa nisso. Tem que ter uma prioridade. Tem que ter uma função prioritária. Não duas funções. Uma função prioritária. A segunda, qual que é? Esta é a segunda. Se são todas prioritárias, já para a conversa e você vai ter que ter um papo ainda sobre maturidade antes de sair fazendo o trânsito. Abuso de abstrações. Você vai ter que jogar abstrações no lixo, você vai ter que criar várias abstrações durante uma transição. Eu acho que esse é o item 1 que eu falaria de arquitetura mesmo, quando você estiver fazendo desenho, a cada ponto de transição, possivelmente você vai ter uma abstração. Cada vez que você tiver um ponto de entrega e que faz uma transição para uma arquitetura anterior, ou seja, ainda não é onde você queria chegar, normalmente você vai ter uma mistração. Controla as expectativas de todo mundo, deixa claro que tem experiências intermediárias, tem coisas que vão dar certo e tem coisas que não vão dar, que você vai ter que ir experimentando ali no dia a dia, não tenha medo de pivotar uma estratégia, puta, criei essa mistração, mas ela está trazendo o maior gargalo, então vou ter que voltar meu TURGO. Não tem problema. Isso é um assunto complexo e se você tentar acertar tudo de primeira, vai dar errado e você vai ficar dando um reponto de fato. Não abra mão de qualidade, observabilidade, resiliência e testes tem que ter. Puta, tem que ter 100% de tudo. Você tem que saber tomar a decisão de o quanto de risco você quer assumir em cada um. Mas você tem que ter observabilidade suficiente para você saber se o seu sistema está ok e conseguir tratar problemas caso não esteja. Você tem que ter resiliência suficiente para conseguir fazer ele voltar ao normal, se ele não estiver. E você tem que testar. Testar eu acho mais difícil da gente até discutir de abrir alguma mão. Você tem que testar, não tem como subir sem testar. É muito difícil de você aceitar uma implementação que não precisa testar. Normalmente, sendo bem honesto, eu aceitaria se fosse para algum relatório que vai ser de consumo interno e que não gera nenhum impacto ou alguma coisa desse tipo. A gente fala pouco de relatório hoje, mas imagina que é um dashboard de negócio para tomar as decisões de BI. Talvez, talvez, se fizer muito sentido, você pode conversar para ver se dá para seguir sem e experimentar. Mas também toma muito cuidado para você não gerar um impacto gigantesco. Ainda mais quando a gente está falando de AWS, que são contas AWS, Azure, Cloud. Você está falando de contas que podem, por exemplo, subir máquina, subir processamento, subir muita coisa ali rápido e você pode acabar até gastando dinheiro. É legal você pensar bastante que teste não é só sobre a funcionalidade, mas é sobre FinOps, teste é sobre observabilidade, é sobre resiliência, teste ele tem que pegar tudo. Então, muito cuidado para abrir mão, tá? Não se apaixone pelas soluções. Acho que muitas das soluções você vai ter que pivotar, então não fica apaixonado, não fala, puta, mas essa foi a minha ideia, teve gente que discordou e eu quis fazer, beleza, da hora, eles estavam certos. Larga a mão e vai em frente, não fica apaixonado por uma solução, não. Aqui eu coloquei uma coisa simples, só pra gente não esquecer, tá, gente? Mas o básico que você tem que pensar pra fazer uma aplicação moderna aqui, você tem que deixar o seu sistema escalável, não dá pra você não deixar o sistema escalável, se vier uma carga maior de requisição, um monte de coisa você tem que conseguir ter velocidade pra subir ou pra descer e lembrar de fazer downscale muita gente esquece do downscale e gasta um dinheiro desnecessário, então lembrar que tem que saber fazer downscale também disponibilidade, o seu sistema deixando indo para uma arquitetura nova, uma visão diferente de arquitetura, você tem que deixar ele disponível, não adianta você pensar só numa entrega, mas você tem que pensar também e como a sua cloud vai te providenciar uma disponibilidade ali, seu desempenho a velocidade de entrega, a velocidade de requisição, igual eu falei putz, não dá pra eu pensar num sistema que tá demorando 14 segundos pra fazer alguma coisa, ou 15, ou 20, 30 meu, olha pra isso, faz teste de performance entende como é que as coisas estão funcionando tuna direitinho as aplicações pra você conseguir ter uma performance boa porque você pode fazer o melhor desenho do mundo se você chegar lá e entregar e o seu desempenho estiver ruim, possivelmente os seus stakeholders vão achar uma porcaria o que você fez. E, meu, segurança. A gente fala pouco de segurança, eu acho que a gente tem que falar muito mais de segurança. Cybercrime está crescendo muito. Se a gente olhar para os últimos anos, a gente está tendo um aumento exponencial de cybercrime, cyberataque no Brasil. O Brasil está sendo muito foco, não sei se vocês acompanham isso, mas está sendo muito foco de cyberataque. A gente precisa pensar e falar sobre segurança, que a gente fala pouco, ter planos de segurança muito bem preparados e planos, uma coisa muito importante, planos para derrubar o seu sistema se você precisar. Se você tiver um cyber-attack, você tem que ter um plano para tirar aquilo do ar. A gente dificilmente fala sobre isso. É legal ter isso, tá? Outra coisa, eu deixei um slide aqui para a gente falar sobre dados. Quando a gente está fazendo uma migração desse tipo, onde eu mais sofri, sendo bem honesto, onde eu mais sofro normalmente não é no desenho da aplicação e na mudança das aplicações. Isso é difícil, mas eu acho que talvez já está muito mais na minha veia e já é uma coisa que eu consigo resolver mais fácil, vejo que os times conseguem resolver também. Mas falar de dados durante uma arquitetura de transição é extremamente complexo. Porque você está falando de trabalhar com dados que estão numa visão antiga de dados, que não estão pensando em data mesh, que não estão pensando em uma visão de analytics e de visão de estrutura de dados que a gente tem hoje em dia, de catalogação. Você tem muita replicação de dado com o mesmo conceito, só que de formas diferentes. É muito dado trabalhado dentro de tabela que deveria ter dado bruto. Então, a sua visão de dados, normalmente, numa arquitetura mais antiga, ela não vai ser uma revisão requintada. Então, você precisa ter muito cuidado, porque na hora que você estiver fazendo a sua arquitetura nova, você vai estar trabalhando com dados da morfologia antiga e dados da morfologia nova. Então, essa conversa é muito complexa, é muito difícil. Para você ter essa replicação de dados, pensando em qual vai ser o seu golden source, qual vai ser a fonte de dados que você vai consumir quando você precisar resolver um problema e ter uma resposta que é, putz, nisso eu confio, esse é um dado confiável dentro do sistema consistente, é bom você ter essa base muito bem declarada, é daqui que eu vou tirar a minha verdade, é isso aqui que vai me contar a realidade de tudo que acontece e você pensar em como que você faz para essa base, ela ter sua morfologia ao longo do tempo para chegar na visão final. Isso é o mais difícil, quando você tem que trabalhar com essas morfologias de dados, é o mais difícil, então é bastante cuidado. Pessoal, era isso que eu tinha para mostrar aqui para vocês, queria agradecer aí muito o convite, agradecer o papo. Espero que eu tenha conseguido ajudar de alguma forma. E fique à vontade aí. Estão aqui meus contatos. Fiquem à vontade para me adicionar, me seguir, buscar, chamar para conversar, trocar um pouco o que vocês gostaram, o que não gostaram. Fiquem à vontade. E muito obrigado mais uma vez, Wesley, pelo convite. Obrigado por me dar essa oportunidade de contar um pouco da história. Espero que eu tenha realmente ajudado de alguma forma a carreira de vocês.