Bom pessoal, no vídeo anterior a gente falou sobre o que são sistemas monolíticos, quando vale a pena utilizar e principalmente trazer clareza para você que sistemas monolíticos na maioria das vezes vão atender muito bem o seu negócio. sobre micro serviços tá eu não tô querendo falar para você sobre a arquitetura baseado em micro serviço eu quero falar especificamente sobre micro serviço então vamos lá vamos falar sobre esse camarada aqui deixa eu colar para um pouquinho deixa eu colar esse cara aqui somente para deixar mais claro aqui para vocês e organizar para eu deixar esse material também disponível tá primeira coisa que eu quero trazer aqui pra vocês é o seguinte o que são micro serviços tá micro serviços são aplicações comuns com propósitos e escopo tá bem definidos o que isso significa significa que micro serviço um sistema como outro qualquer ponto tá quando você cria um monolito quando você cria um mesmo micro serviço basicamente você está criando a mesma coisa a diferença é o tamanho é o nível de responsabilidade do sistema enquanto me há enquanto sistemas monolíticos está em diversos escopos, têm diversas responsabilidades, têm diversos motivos para mudar, os microserviços normalmente têm apenas um motivo para mudança. Eu não sei se você já ouviu falar o S do SOLID do Uncle Bob. E ele normalmente fala o seguinte, que o sólido no final do dia ele tem o s net ao single responsibility principal e esse cara significa que o seu sistema o seu componente ele tem apenas um como uma apenas um motivo para a mudança e eu sei que isso normalmente quando ele se refere a isso ele se refere isso dentro de uma classe principalmente mas se você trouxer isso para o macro com micro serviços é a mesma coisa se você tem muitas razões para mudar um micro serviço é que talvez esse micro serviço ele esteja mal dividido ele esteja fazendo parte de muitos contextos, e aí nesse caso, ou ele vira um monolito, ou você arranca de fora esses outros contextos para ele realmente virar um microserviço. Eu acho que poucas pessoas pensam em microserviços fazendo essa comparação do s do sol e né então se o seu micro serviço vai atender apenas cliente suporte toda vez que você mudar ele vai ter que ter a única razão é mudar algo referente à cliente suporte se ele tiver mudando algo referente à vendas provavelmente tem algo errado com esse micro serviço e ele está acessando um outro escopo. Por isso que quando nós falamos, inclusive, sobre Domain Driven Design, a gente consegue mapear bounded context, ou seja, contextos delimitados e normalmente esses contextos delimitados trazem para a gente um ponto de partida para você criar o seu microserviço. Isso não significa que um contexto delimitado é um para um em relação a microserviços, mas é um ótimo começo para você trabalhar. Então, se a sua aplicação tem um propósito bem definido, apenas um escopo para resolver um tipo de problema, normalmente isso aí vai ser um microserviço. Beleza? Outro ponto importante. Microserviços, eles têm que ser independentes e autônomos. O que isso significa? Significa que se todos os outros microserviços caírem, o seu micro serviço ele tem que estar no ar tá e aí que é o ponto mais complexo tá porque porque é muito complexo você criar um micro serviço sem dependência ao mundo externo é complexo mas é possível tá e você deve estar se perguntando, Wesley, como assim eu consigo me manter no ar se o cara que eu dependo está fora do ar? O ponto é o seguinte, você não pode depender diretamente, você não pode, entre aspas, depender diretamente de um outro micro serviço. diretamente de um outro micro serviço o que você precisa naquele momento é criar mecanismos de fallback caso o micro serviço que você dependa diretamente tiver fora do ar você vai degradar tá a entrega que você vai dar para o usuário final eu vou dar um exemplo aqui pra você vamos imaginar que nós estamos fazendo um sistema de um banco e você tem um micro serviço responsável para mostrar o saldo do usuário então na hora que você vai mostrar o saldo do usuário cara entrou lá no internet banking na hora que você vai consultar o saldo um micro serviço que gera toda a conta para trazer o saldo para você está fora do ar. O que vai acontecer naquele momento? Você vai retornar ali para o cara um erro 500? Você vai retornar ali falando, não consigo trazer seu saldo? Então perceba que a experiência que você está trazendo para o usuário é muito ruim. Como que você pode manter esse microserviço funcionando? Você pode pegar o saldo que você consultou pela última vez, sei lá, 10 minutos atrás, 50 segundos atrás, e mostrar para o cara. Saldo atualizado a 15 segundos. Quando o usuário acessar, ele vai ver que ele está vendo o saldo atualizado em 15 segundos, em um minuto atrás, e você conseguiu pelo menos gerar valor para o usuário final. Entende qual a diferença entre você ser autônomo, independente, entre você ser autônomo, independente, do que necessariamente você ficar fora do ar por conta de outro microserviço que você depende. Então, quando nós estamos falando de microserviços, independência de microserviços, significa que você vai fazer o possível e o impossível para ficar no ar, mesmo que você degrade as suas funcionalidades. É muito interessante. Isso normalmente a gente chama de graceful degradation. Ou seja, você graciosamente degrada sua função, mas consegue ainda entregar valor. É difícil fazer? É difícil. É impossível fazer? Não. Você vai fazer isso todas as vezes talvez não mas com certeza em sistemas em momentos críticos informações críticas você tem que ter essa estratégia para não estourar um erro na cara do cliente legal e normalmente quando a gente está falando em micro serviços significa que você está criando um sistema que faz parte de um sistema maior ele ajuda uma engrenagem maior a rodar legal então micro serviço sempre vai ser parte de uma engrenagem maior se você está criando um sistema mesmo que esse sistema esteja seja muito pequeno mas em volta dele não tem um ecossistema não está criando um micro serviço está criando um sistema monolítico que é pequeno e que tem pouca responsabilidade naquele momento legal então toda vez que a gente vai falar sobre micro serviços é inerente a gente falar sobre a arquitetura baseada em micro serviços que a gente já vai falar logo em seguida mas pense sempre dessa forma o micro serviço tem um escopo definido é independente autônomo e faz parte de um sistema maior ele faz parte de uma engrenagem maior e normalmente a comunicação desse cara é mais complexa e é super importante você degradar o serviço quando as dependências dele estejam fora. Bacana? Espero que eu tenha trazido algum insight aqui para vocês. Muita gente que já trabalha com microserviços pode pensar que eu tô chovendo no molhado mas sempre tem algo que vai você vai fazer você pensar duas vezes maravilha um grande abraço pra você e até o nosso próximo vídeo