Bom pessoal, agora a gente vai falar sobre o tal dos microserviços, a arquitetura baseada em microserviços. Disclaimer novamente galera, eu não quero olhar nos detalhes sobre microserviços agora. Eu quero te dar uma visão geral, a gente vai ter uma disciplina específica sobre microserviços. Mas uma coisa importante, o que são microserviços? Primeira coisa, microserviços escreve com dois s tudo junto tá a segunda coisa aqui pra você microserviços são sistemas que normalmente têm responsabilidades específicas tá e essas responsabilidades podem ser projetos totalmente diferentes dentro de uma organização legal alguns projetos eles podem ter relacionamento entre eles. Então, pode acontecer que um microserviço, ele tenha que chamar outros microserviços diretamente. Legal? Porém, o que acontece? Isso tem vantagens e desvantagens. A vantagem é que quando eu separo tudo isso, fica mais fácil, inclusive, organizacionalmente, eu criar diversas equipes, por exemplo, e tudo mais. Porém, quando um microserviço chama o outro e o outro estiver fora do ar, o microserviço que chamou também vai ficar fora do ar. E isso pode gerar um efeito dominó muito grande dentro da organização. Legal? Porém, um outro ponto importante é o seguinte. Se a gente pensar nesse lado, a coisa mais importante que a gente tem que fazer quando nós trabalhamos com microserviços é lutar contra o acoplamento. O que é o acoplamento? Fazer o microserviço depender de outro microserviço diretamente. Como que a gente evita esse tipo de acoplamento, galera? Primeira coisa, banco de dados. Se os microserviços compartilham o mesmo banco de dados, significa que se um microserviço, sei lá, encher um banco de dados de acesso e deixar esse banco de dados lento, outro microserviço que vai utilizar esse banco de dados também vai ficar lento. Se alguém mudou uma coluna inadvertidamente de um microserviço, vai quebrar um outro microserviço. Então, por isso que é muito comum nós termos um banco de dados por microserviço. Se você tiver vários utilizando um banco, saiba as consequências que você vai estar. Legal? Porém, mesmo assim, quando um microserviço chama o outro de forma síncrona, ou seja, diretamente, sei lá, uma requisição REST, você sempre vai ter a chance de receber um 404, um erro 500, qualquer coisa desse tipo. Então, você vai ter que ter mecanismos para você conseguir viver, mesmo fazendo chamadas que possam te atrapalhar. Uma das melhores formas para resolver esse tipo de problema é você trabalhar de forma assíncrona. O que isso significa? Significa que, ao invés de um microserviço chamar o outro diretamente, eles vão se falar através de mensagens, através de eventos. Então, o microserviço 1 fala assim fala assim olha compra realizada tá os dados do cartão estão aí aí o micro serviço 2 pega os eventos de compra realizada e fala a compra aprovada já fiz o pagamento do cartão daí ele manda falando a compra aprovada aí o micro serviço com quatro fala vou gerar nota fiscal da compra aprovada da ele retorna nota fiscal emitida aí o micro serviço com quatro fala vou gerar nota fiscal da compra aprovada da ele retorna nota fiscal emitida aí o micro serviço 3 aqui fala opa com a nota fiscal emitida eu vou permitir o caminhão sair para fazer entrega então olha só que interessante um micro serviço não falou diretamente com o outro e o mais interessante de tudo isso é o seguinte que se o micro serviço cair os outros micro serviços vão continuar funcionando funcionando normalmente e quando ele subir o que vai acontecer ele vai processar as mensagens pendentes que ele tinha legal então isso aqui é um dos pontos mais importantes quando nós estamos falando sobre micro serviços está pode acontecer de você trabalhar de forma um pouco mais mista como assim um micro serviço chama o outro mas eu tenho micro serviços que também falam diretamente por eventos legal isso pode acontecer mas novamente a gente sabe que o microserviço 1 e 3, eles dependem um do outro, logo, pode dar ruim aqui nesse nosso caso. Legal? Agora que você entendeu um pouco a ideia dos microserviços, eu acho que o mais importante de tudo isso é você entender as motivações desse cara, né? O porquê eu utilizaria uma arquitetura dessa forma ao invés de utilizar um único sistema um sistema monolítico para resolver todos os meus problemas dentro da minha organização essa é a grande pergunta muita gente fala um monte de coisa de vantagens que o micro serviço tem eu vou dar a minha opinião aqui. Provavelmente pode ter pessoas que discordem, concordem, etc. Mas a minha opinião aqui para você. A principal motivação para você utilizar o microserviço nos dias de hoje é organizacional, é equipe. O que isso significa? Imagina que a sua empresa tem mil desenvolvedores. Sei lá, a galera do Mercado Livre tem 12 mil desenvolvedores. Vocês imaginam 12 mil pessoas trabalhando num único sistema? Não, né? E é por isso que você consegue trabalhar em equipes. Quando você consegue trabalhar em equipes, você trabalha com microserviços. Cada equipe tem seu microserviço para cuidar. Cada equipe tem o seu projeto. Cada equipe consegue fazer deploys independentes. Cada equipe não vai afetar o seu vizinho quando ele fizer o seu deploy. Então, diversos projetos dentro da mesma organização, eles podem ser tocados e não afetar o que está acontecendo de forma geral em todas as áreas da organização. Então, o primeiro fator que você vai pensar quando você vai querer entrar numa situação aí trabalhando com micro serviços é uma motivação organizacional. Eu acho que é a que mais pesa. É a maior vantagem que você vai ter. é a que mais pesa. É a maior vantagem que você vai ter. Por outro lado, existem algumas vantagens também que estão atreladas a essa vantagem organizacional. Por exemplo, eu consigo escalar. Como assim? Se eu, por exemplo, tiver um único sistema e uma área desse meu sistema tiver muito acesso, eu vou ter que escalar o meu sistema inteiro se eu tiver micro serviços eu escala somente o micro serviço está tendo muito acesso se eu tenho um único sistema o melhor que ele esteja arquitetado vai ter tanta responsabilidade no mesmo sistema que uma coisa vai começar a afetar outra invariavelmente então quando você tem micro serviços, você consegue criar diversos micro serviços para diversas responsabilidades. Outra coisa, eventualmente, você vai querer utilizar tecnologias diferentes para soluções diferentes. Sei lá, você quer mais performance e vai usar Go, você vai querer trabalhar com Machine Learning, etc., você vai botar um Python e você consegue criar serviços diferentes. Então, isso também, se você olhar, é uma vantagem, sim. E você também tem a opção de trabalhar de forma com baixo acoplamento. Então, você consegue, sim, ter baixo acoplamento, desde que você consiga trabalhar de forma decente. Legal? Por outro lado, o que você tem que levar em conta aqui é o seguinte. Microserviços é uma parada complexa pra caramba. Não é algo simples e é isso que muita gente acaba não entendendo. Vou dar um exemplo aqui pra você. Pra você trabalhar com microserviços, a sua organização tem que ter um nível de maturidade. Por quê? Porque a gestão da equipe, as gestões das equipes vão ser diferentes, a gestão dos projetos vão ser diferentes. A forma de você conseguir disponibilizar esses ambientes para os desenvolvedores vão ser diferentes, ou seja, muda muita coisa. Outra coisa, os times têm que ser mais maduros. Por quê? Cada time tem que se especializar naquele domínio que aquele microserviço vai resolver. Aquele time tem que conseguir entender outras formas de comunicação. Porque eles não vão trabalhar mais só como REST, ficar chamando APIs. Eles vão ter que trabalhar com mensageria, eles vão ter que trabalhar com eventos. Outra coisa que vai acontecer, eles não vão ter todos os dados, né? Porque o banco de dados é separado, então muitas vezes é como que eu gero um relatório de dados que não estão totalmente no meu microserviço? Esses tipos de questão vão começar a acontecer e existem diversas estratégias para isso, claro, eu não quero me prender nesse momento, mas esses tipos de coisa vão acontecer. eu quero me prender nesse momento, mas esses tipos de coisa vão acontecer. Outra coisa, deployment. Você, hoje em dia, na sua empresa, eu espero que você tenha uma esteira de CI e de CD, ou seja, você sobe, faz code review, aí você faz code review, gera integração contínua, depois disso você faz o deployment, tem as estratégias de deployment e vai para o ar. Se você tem um sistema, você vai fazer uma esteira de CI e CD. Se você tem 10 sistemas, são 10 esteiras de CI e CD. São 10 aplicações diferentes rodando. Eventualmente, vão ser 10 instâncias diferentes. 10 pods diferentes. Eu não sei como você vai organizar na infraestrutura, mas você tem que saber que você vai ter que ter uma cultura mais voltada pra DevOps, por parte de sre porque senão a coisa vai pegar legal outra coisa importante também é a parte de observabilidade quando tem um único sistema quando dá um erro eu olho stack trace ali eu vi da onde que aconteceu quando eu tenho um monte de micro serviço chamando o outro quando dá um problema eu vou saber qual o micro serviço chamando o outro, quando dá um problema, eu vou saber qual micro serviço deu problema. Em qual momento? Com qual usuário? Como que eu consigo rastrear? Um chamou o outro, chamou o outro, chamou o outro, deu erro. Como que eu sei qual que deu erro? Então, eu tenho que ter a parte de observabilidade muito mais em dia. E para eu mexer com observabilidade, desenvolvedores têm que saber, a gente tem que fazer instrumentação, a gente tem que ter ferramentas certas, observabilidade é caro, então a gente tem que pensar nesses aspectos aqui. Então, quando nós vamos trabalhar com micro serviços, tudo acaba sendo um pouco mais complexo. Troubleshooting, quando dá um problema, como que eu tenho certeza que esse problema foi gerado pelo meu microserviço? E se o meu está gerando esse problema, esse problema está sendo por quê? Porque a mensagem do evento que o cara mandou para o sistema de mensageria está errada o padrão? Será que mudaram alguma coisa? Então, assim, as possibilidades aumentam muito. E quanto mais possibilidades tem mais sênior né a sua equipe vai ter que ser para conseguir detectar esses tipos de problema então assim galera micro serviços não é bala de prata ele não é resolver sua vida mas definitivamente você tem que saber como é que funciona tá você tem que ter uma experiência real aí com micro serviços né e a nossa ideia aqui inclusive é conseguir gerar pra você experiências desse tipo para que você consiga se sentir mais preparado mas de uma forma ou de outra é importante você saber que não são todos os casos que você vai ter que trabalhar com micro serviço legal próximo passo a gente vai falar sobre crs então vamos lá