Bom pessoal, no vídeo anterior eu coloquei uma provocação aqui para você. Arquiteturas distribuídas são necessárias em grandes ambientes. Eu não conheço nenhum grande ambiente mesmo que não trabalhe com arquiteturas distribuídas. Ah Wesley, eu conheço uns sites, uns sistemas aí que rodam um monol, com poucas máquinas e conseguem trabalhar. Se você pensar, por exemplo, no Stack Overflow, eles são um case muito grande, onde os caras trabalham com monolitos, conseguem otimizar com algumas máquinas, conseguem escalar o banco de dados verticalmente e consegue ter por exemplo uma super velocidade e ainda conseguiram tirar o cache das aplicações deles, pela última vez que eu ouvi falar, né? Então isso que você está falando como que eu posso dizer? Não condisco com essa afirmação. Galera quando eu estou falando de arquiteturas distribuídas são necessárias eu estou falando em aplicações que não tem 70 sem desenvolvedores estou falando em aplicações em ecossistemas que tem mil, dois mil dez mil, quinze mil desenvolvedores onde você tem uma empresa tão gigante onde os desenvolvedores, onde você tem uma empresa tão gigante, onde os desenvolvedores nem se conhecem, onde eles usam sistemas de terceiros que foram criados, que eles nem conhecem a equipe que eles desenvolvem. Então, arquiteturas distribuídas, elas são necessárias. A gente vai falar um pouco mais sobre isso, mas para a gente esquentar esse processo, eu quero conseguir trazer aqui para vocês uma espécie de um resumo que eu criei. E lembrando que muito do que eu estou falando aqui é minha opinião. Obviamente depois eu vou passar algumas bibliografias que vão ser super importantes para vocês lerem. Legal? Então, o seguinte, pessoal, olha só que bacana. Quando optar por um monolito deixa só diminuir um pouco esses um aqui beleza então o seguinte quando que eu vou optar por um sistema monolítico a a na hora de tomar decisão na hora que eu for trabalhar com a minha empresa, ou na hora que eu for argumentar com o meu líder, com o meu chefe, não interessa. Quando que eu opto? Bom, primeiramente, não tem nada melhor do que um monolito para você criar uma prova de conceito de um sistema que tenha a possibilidade de crescer. Você tem um sistema, você não sabe se esse sistema vai crescer, você não sabe se esse sistema vai sercer, você não sabe se esse sistema ele vai ser uma virada de chave para a empresa, pode ser uma experiência de uma nova unidade de negócio que a empresa está criando, pode ser uma promoção ou um teste que essa empresa está fazendo e, obviamente, se é um teste, você não vai querer fazer tudo isso em microserviços. Normalmente, quando você está fazendo isso, ou até mesmo modernizando uma parte do seu sistema, você vai criar algo que a gente chama normalmente de arquitetura de transição, que é uma arquitetura que você cria até aquele momento para testar aquele conceito. E, depois disso, se bobearbear você pode até jogar o código fora tá porque porque toda vez que você está trabalhando em qualquer tipo de projeto você tem algo chamado de risco tá e o risco das coisas darem errado normalmente é muito maior do que eles darem certo ok então para evitar esse tipo de ris, normalmente você cria provas de conceito. Essas provas de conceito são feitas de forma mais simples. E o importante de tudo é que se ela der errada, você joga fora. E se ela der certa, eventualmente você joga fora e faz da forma como você pensa que vai fazer sentido. Então, trabalhar com provas de conceito é uma grande sacada para você trabalhar com ambientes monolíticos. Legal? Outra coisa. Toda vez que você vai criar um novo sistema, a própria empresa, os próprios experts de domínio, eles não conhecem todos os contextos. O próprio cliente não sabe o que ele quer. E não é culpa dele. O ponto é que quando a gente está falando em negócio, tudo vem através de uma nova descoberta. E cada descoberta que você faz é um contexto diferente, é uma necessidade diferente. Você tem uma necessidade de mudar completamente o modelo de negócios. Então, quando você tem certeza, a única certeza que você tem é que você não sabe tanto do sistema quanto você deveria, raramente eu vou falar para você trabalhar com microserviços. deveria raramente eu vou falar pra você trabalhar com micro serviços porque mudar é pivotar micro serviços dá muito trabalho os contratos mudam os sistemas mudam a quantidade de micro serviços crescem porque você não vai querer jogar aquele micro serviço que você fez fora né então nesse caso trabalhar com sistemas monolíticos normalmente vai ser uma boa pegada. E se você conseguir criar de uma forma muito bem feita esse sistema monolítico, ele vai estar um pouco mais pronto para você quebrar esse cara em microserviços. Não conhece todos os contextos. Seu cliente não conhece todos os contextos. Vocês estão num processo de descoberto. Meu amigo, minha amiga, fuja de micro serviços. Legal? E a gente tem um outro ponto importante aqui, que é o seguinte, necessidade de realizar mudanças bruscas nas regras de negócio e funcionalidades do sistema. Quando a gente está desenvolvendo um sistema e esse sistema é novo, a empresa tem uma necessidade muito grande de fazer mudanças bruscas nessas regras de negócio. Quando você está falando em startups, então, essa parada é exponencial. Às vezes você começa a trabalhar com uma startup onde o foco dela é atender pessoas físicas. Aí, de repente, você cria todos os microserviços, faz todo aquele negócio para atender pessoas físicas, consultam, cria um microserviço para consultar no Serasa, cria um outro microserviço para negativar o cara, cria um outro microserviço para fazer diversas coisas e de repente a empresa percebe que o melhor mercado para ela ganhar dinheiro não vai ser atendendo pessoa física, vai ser atendendo pessoa jurídica. E aí você tem 10 microserviços feitos para manter cada vez mais coeso o ambiente para validar o modelo de negócios em pessoa física o que significa que vai ter que jogar metade do que você fez fora e o problema não é jogar fora o problema é o setup de novo as esteiras de se a exigir os testes é criar o projeto do zero, é o troubleshooting, é tudo aquilo que você precisa. Então, quando você tem regras de negócio mudando bruscamente, não comece a mexer com micro serviços. Você fazendo isso, você vai ter um baita problema, porque você vai conseguir perceber que mudar diversos microserviços dá muito mais trabalho do que mudar um monolito. Bacana? Por último, e não digo por último, mas agrupando um pouco essas partes, governança simplificada. O que isso significa? Significa que muitas vezes você não está trabalhando em uma empresa muito grande ou a área de tecnologia dessa empresa não é muito grande, onde ela não tem uma governança, uma arquitetura corporativa clara para todos os desenvolvedores. Isso significa que uma vez que você não tem clareza disso, provavelmente o ambiente que você vai criar de microserviços vai ser um caos. Então trabalhar com monolitos, nesse caso, vale muito mais a pena. Por quê? Você tem um único sistema, uma única linguagem, um processo muito claro de desenvolvimento, as equipes organizadas, tudo para conseguir trabalhar com aquele processo. Então se você não tem uma ótima estrutura para garantir que todo mundo consiga se falar e etc provavelmente a monolitos vai mais a pena outra coisa também aqui e aqui pode ser um pouco controverso assumo eu dei uma força dia na hora de colocar isso aqui que as restrições de orçamento o que significa normalmente trabalhar com sistemas monolíticos você gasta menos em relação a orçamento em relação à infraestrutura está em relação a colocar o seu software no ar em relação à observabilidade a lodes a cache tá a tracing a Cache, a Tracing, a Monitoramento, normalmente é muito mais barato, porque você vai ter apenas um sistema para fazer isso. E se você tem uma restrição em orçamento, pode ser que se você criar um monte de microserviços, o custo operacional disso vai ser muito maior e você vai estourar esse orçamento. Isso não significa que você também não pode estourar um orçamento de um monolito. Mas se você estourar vai ser por outros motivos. Agora, esses motivos dos microserviços são motivos claros e escancarados que vão cheirar para você que você vai poder sim estourar esses orçamentos. E quando você também vai optar para o monolito, é quando você tem uma baixa quantidade de desenvolvedores. Como assim? Eu não tenho muitos desenvolvedores na minha empresa. Eu não vou criar ali 10 microserviços por desenvolvedor. É muito complexo. Ou se você não tem uma governança, uma equipe de plataforma, cada vez isso vai ficar mais inviável. Então, se você tem poucos desenvolvedores, vocês não vão ter grandes problemas de conflito, vocês não vão ter grandes problemas de deploy, vocês não vão ter grandes problemas de um invadir o contexto do outro. Tanto porque muitas pessoas vão poder trabalhar em diversos contextos. Então, se você tem baixa quantidade de desenvolvedores e você está começando a pensar em migrar para microserviços, a sua equipe tem que ter uma baita maturidade para conseguir trabalhar com isso. Se nenhuma pessoa da sua equipe já trabalhou ou tem maturidade para trabalhar com microserviços, jamais coloque microserviços em um tipo desse ambiente. Beleza? Então, é isso aí. E no próximo vídeo a gente vai falar quando que a gente pode optar por microserviços. Vamos nessa!