Basicamente separa os serviços e banco de dados digamos que porçoes e cada um atendente sua respectiva regra de negócio mas eles se comunicam. Fácil encontrar aonde está o problema pois os serviços estão todos mapeados e fazer manutenção é uma beleza, diminui e mitiga erros! Espero ter ajudado!
Parabéns pelo vídeo, atuo como Jr na arquitetura da empresa e vindo de outra área, totalmente fora do universo de TI, preciso absorver todos esses conhecimentos.
Eu sempre tive um preconceito com Java que foi completamente eliminado com explicações do crescimento da linguagem, seus videos me fizeram dar um start incrível no spring e a maravilha que o java oferece eu te agradeço muito.
Michelli, parabéns pela qualidade dos vídeos. Tá fenomenal! Sobre o conteúdo desse vídeo em si, na minha visão, tem um probleminha sobre os pontos negativos citados nos monolítos: eles não necessariamente reflete o real motivo do porquê usar microsserviços! Na verdade, são problemas que se repetem até mesmo microsserviços por conta do mesmo motivo: Decisões técnicas/arquiteturais ruins. Esse tipo de conteúdo é bem difícil de se entender quando o desenvolvedor não sofreu na pele. É igual a design pattern, nós usamos porquê queremos evitar que, aquele tipo problema que nos "assombrou" no passado, venha a se repetir. Uma coisa que funciona muito bem para mim nessas horas é mostrar um caso real. E aí, vou pegar novamente o exemplo do design pattern! Por que a gente usa o padrão Adapter? Principalmente quando pensamos no universo JS, a quantidade de biblioteca que surge a cada dia não é brincadeira. Se tu tem uma biblioteca de horas, por exemplo, ela pode ser depreciada daqui a, sei lá, 2 - 3 anos? E se tu quiser substituir ela, qual é o procedimento mais fácil: alterar uma única classe que estará submetida a uma interface e testes de unidade, ou procurar em todo o projeto onde aquela ferramente está sendo utilizada e substituir (Eu falei JS anteriormente mas vamos ser sincero que dificilmente alguém quer tocar um projeto que não tem TS, correto?) Espero que eu tenha contribuído de alguma forma :)
Eu concordo com você. Adicionando ao seu comentário, já vi alguns videos da Michelli a gosto do conteúdo mas esse video me pareceu somente explorar os malefícios do monolítico e somente os benefícios de microserviço, o que na prática não é bem assim, esperava ver um contraponto entre os dois patterns. Um dos pontos positivos do monolítico, por exemplo, é que ao iniciar um projeto, seja ele um protótipo ou não, o desenvolvimento inicial acaba sendo mais rápido comparado ao microserviço, além de não se preocupar com coisas como, qual protocolo vou usar para a comunicação dos serviços? gRPC? GraphQL? Outra vantagem do monolítico é que o acesso a informação por vezes pode ser infinitamente mais rápido por ter fácil acesso a dados em memória, enquanto que em microserviço é tudo via rede/TCP (sem contar as camadas de segurança, como firewall e criptografia, e ainda NATs por estar atrás de LBs). Há um blog post da Amazon de um tempo atrás falando justamente como eles melhoraram a performance da aplicação e custo saindo de microserviço e indo para monolítico, quase que um post anti-pattern. Além disso monolítico não é sinônimo de bagunça, claro que pode acontecer, mas isso pode acontecer com qualquer aplicação, sendo monolítica ou não.
Oi, Michelli! Tudo bom? Muito legal a tua iniciativa de compartilhar o teu conhecimento. Em relação ao tema abordado, eu concordo parcialmente em alguns aspectos. O primeiro é em relação a questão organizacional de um sistema chamado de monolítico. O exemplo que você usou do emaranhado de fios, apesar de existirem muito projetos que realmente são uma verdadeira bagunça, isso não tem a ver com a arquitetura usada. Existem sistemas todos desenvolvido em microserviços que podem ser perfeitamente representados por aquele poste com o monte de fios rs. Além disso é muito importante destacarmos que ser monolítico não quer dizer que haja alto nível de acoplamento. Já trabalhei com projeto de sistemas monolíticos extremamente bem organizados, com entidades de negócio muito bem definidas e isoladas em um segmento de classes específicas e fazendo uso de alto nível de abstração por meio de interfaces e classes abstratas reduzindo enormemente o nível de acoplamento. De uns anos para cá venho percebendo que a modinha do momento são os tais micro serviços, que, na prática, não passam de webservices menores e que agora são tratados por muitos (não estou dizendo que seja o teu caso rs) como uma bala de prata que resolve todos os problemas. Embora eu veja inúmeras vantagens nessa abordagem de arquitetura, por outro lado entendo que deve ser usado com parcimônia para não desenvolver um sistema imenso, como um ERP de grande porte, todo baseados em micro serviços e criar um nível de dependencia muito grande entre serviços e no final, chegar a um cenário muito semelhante ao poste que você mostrou, extremamente complexo de gerenciar. Enfim, esse é um tema logo, mas, na minha opinião, quando o assunto é sistemas complexos de grande porte, eu ainda prefiro pensar em uma arquitetura híbrida, porque no frgir dos ovos, o empresário que está colocando um sistema de gestão, por exemplo, em sua empresa, ele não quer nem saber se o sistema usa técnicas modernas ou não, ele quer saber se o sistema é capas de sustentar as operações do seu negócio de forma robusta e entregar o valor que ele espera. Mas é só uma opinião, mais uma vez, parabéns pelo conteúdo.
Před 3 měsíci+2
então nesse contexto uma aplicação baseada em microserviços é um FIAT com uma escada encima...kkkkk
Esculhambasse o fusca, mas eu entendi o que são microservices. Obrigado
Basicamente separa os serviços e banco de dados digamos que porçoes e cada um atendente sua respectiva regra de negócio mas eles se comunicam.
Fácil encontrar aonde está o problema pois os serviços estão todos mapeados e fazer manutenção é uma beleza, diminui e mitiga erros!
Espero ter ajudado!
@@RodrigoAmaral-fx2hl eu disse que entendi, mano.
@@BrunoHenrique-oe5hb Respondi o comentário errado KKKKKKKKKKKK
Simplesmente a melhor explicação do CZcams sobre esse assunto
Top @Michelli Brito, vc é fora curva, jovem e muito expert! Parabéns!!
Muito boa a explicação.
Seu conteúdo é de extrema qualidade!!
Parabéns pelo vídeo, atuo como Jr na arquitetura da empresa e vindo de outra área, totalmente fora do universo de TI, preciso absorver todos esses conhecimentos.
Eu sempre tive um preconceito com Java que foi completamente eliminado com explicações do crescimento da linguagem, seus videos me fizeram dar um start incrível no spring e a maravilha que o java oferece eu te agradeço muito.
Excelente explicação. Parabéns!
Michelli, parabéns pela qualidade dos vídeos. Tá fenomenal! Sobre o conteúdo desse vídeo em si, na minha visão, tem um probleminha sobre os pontos negativos citados nos monolítos: eles não necessariamente reflete o real motivo do porquê usar microsserviços! Na verdade, são problemas que se repetem até mesmo microsserviços por conta do mesmo motivo: Decisões técnicas/arquiteturais ruins. Esse tipo de conteúdo é bem difícil de se entender quando o desenvolvedor não sofreu na pele. É igual a design pattern, nós usamos porquê queremos evitar que, aquele tipo problema que nos "assombrou" no passado, venha a se repetir.
Uma coisa que funciona muito bem para mim nessas horas é mostrar um caso real. E aí, vou pegar novamente o exemplo do design pattern! Por que a gente usa o padrão Adapter? Principalmente quando pensamos no universo JS, a quantidade de biblioteca que surge a cada dia não é brincadeira. Se tu tem uma biblioteca de horas, por exemplo, ela pode ser depreciada daqui a, sei lá, 2 - 3 anos? E se tu quiser substituir ela, qual é o procedimento mais fácil: alterar uma única classe que estará submetida a uma interface e testes de unidade, ou procurar em todo o projeto onde aquela ferramente está sendo utilizada e substituir (Eu falei JS anteriormente mas vamos ser sincero que dificilmente alguém quer tocar um projeto que não tem TS, correto?)
Espero que eu tenha contribuído de alguma forma :)
Eu concordo com você. Adicionando ao seu comentário, já vi alguns videos da Michelli a gosto do conteúdo mas esse video me pareceu somente explorar os malefícios do monolítico e somente os benefícios de microserviço, o que na prática não é bem assim, esperava ver um contraponto entre os dois patterns. Um dos pontos positivos do monolítico, por exemplo, é que ao iniciar um projeto, seja ele um protótipo ou não, o desenvolvimento inicial acaba sendo mais rápido comparado ao microserviço, além de não se preocupar com coisas como, qual protocolo vou usar para a comunicação dos serviços? gRPC? GraphQL? Outra vantagem do monolítico é que o acesso a informação por vezes pode ser infinitamente mais rápido por ter fácil acesso a dados em memória, enquanto que em microserviço é tudo via rede/TCP (sem contar as camadas de segurança, como firewall e criptografia, e ainda NATs por estar atrás de LBs). Há um blog post da Amazon de um tempo atrás falando justamente como eles melhoraram a performance da aplicação e custo saindo de microserviço e indo para monolítico, quase que um post anti-pattern. Além disso monolítico não é sinônimo de bagunça, claro que pode acontecer, mas isso pode acontecer com qualquer aplicação, sendo monolítica ou não.
@@marcofv um outro ponto também é a escrita de testes (integração/E2e). Se formos comparar a facilidade entre os dois, é indiscutível!
muito bom
Muito bom. Há alguma sugestão para uso de microservices em Python?
Oi, Michelli! Tudo bom? Muito legal a tua iniciativa de compartilhar o teu conhecimento. Em relação ao tema abordado, eu concordo parcialmente em alguns aspectos. O primeiro é em relação a questão organizacional de um sistema chamado de monolítico. O exemplo que você usou do emaranhado de fios, apesar de existirem muito projetos que realmente são uma verdadeira bagunça, isso não tem a ver com a arquitetura usada. Existem sistemas todos desenvolvido em microserviços que podem ser perfeitamente representados por aquele poste com o monte de fios rs. Além disso é muito importante destacarmos que ser monolítico não quer dizer que haja alto nível de acoplamento. Já trabalhei com projeto de sistemas monolíticos extremamente bem organizados, com entidades de negócio muito bem definidas e isoladas em um segmento de classes específicas e fazendo uso de alto nível de abstração por meio de interfaces e classes abstratas reduzindo enormemente o nível de acoplamento.
De uns anos para cá venho percebendo que a modinha do momento são os tais micro serviços, que, na prática, não passam de webservices menores e que agora são tratados por muitos (não estou dizendo que seja o teu caso rs) como uma bala de prata que resolve todos os problemas. Embora eu veja inúmeras vantagens nessa abordagem de arquitetura, por outro lado entendo que deve ser usado com parcimônia para não desenvolver um sistema imenso, como um ERP de grande porte, todo baseados em micro serviços e criar um nível de dependencia muito grande entre serviços e no final, chegar a um cenário muito semelhante ao poste que você mostrou, extremamente complexo de gerenciar.
Enfim, esse é um tema logo, mas, na minha opinião, quando o assunto é sistemas complexos de grande porte, eu ainda prefiro pensar em uma arquitetura híbrida, porque no frgir dos ovos, o empresário que está colocando um sistema de gestão, por exemplo, em sua empresa, ele não quer nem saber se o sistema usa técnicas modernas ou não, ele quer saber se o sistema é capas de sustentar as operações do seu negócio de forma robusta e entregar o valor que ele espera.
Mas é só uma opinião, mais uma vez, parabéns pelo conteúdo.
então nesse contexto uma aplicação baseada em microserviços é um FIAT com uma escada encima...kkkkk
Eu entendi isso tambem 😂
qual programa tu utilizou para desenhar a estrutura ?
Tenho a mesma curiosidade, precisando fazer uma documentação estrutural se puder compartilhar ☺️
queria a mesma coisa :(
Isso aí foi feito no PowerPoint
Cada caso é um caso, microsservices por ser modinha daqui a pouco TODO list vai nascer como microsservices
Promo>SM 💕