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.
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.
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.
Então quer dizer que são um programa com aplicações separadas, por exemplo tenho o sistema de gestão mas tenho uma aplicação de emissão de notas e outra aplicação do financeiro, mas ambos faz parte do mesmo projeto e se comunicam entre sim?
6 หลายเดือนก่อน +3
então nesse contexto uma aplicação baseada em microserviços é um FIAT com uma escada encima...kkkkk
Acredito que a ideia de Monolítico ser bagunçado é por conta da qualificação do desenvolvedor. Monolíticos também podem respeitar Design Patters e Clean Architecture, reduzindo o nível de acoplamento. O grande problema no meu ver é a escalabilidade de um monolítico e a manutenibilidade a longo prazo, principalmente porque existe uma grande chance de que outros Devs contribuam com o projeto. Aliás, teu conteúdo é muito bom.
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.
Associar arquitetura monolítica com código "spaghetti" está totalmente equivocado, infeliz comparação(recomendo estudar sobre arquiteturas concêntricas). Entenda: acoplamento de código está relacionado com o "code design" e não especificamente com a arquitetura usada. É perfeitamente possível criar código acoplado usando microserviços, a diferença é que você não consegue ver pois está tudo espalhado em cada microserviço.
![SAFEPLANET - ดาวเคราะห์ [ THE PLANET ]](http://i.ytimg.com/vi/4X1XL3I_k3c/mqdefault.jpg)
Esculhambasse o fusca, mas eu entendi o que são microservices. Obrigado
@RodrigoAmaral-fx2hl eu disse que entendi, mano.
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!
Top @Michelli Brito, vc é fora curva, jovem e muito expert! Parabéns!!
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!
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.
Simplesmente a melhor explicação do TH-cam sobre esse assunto
Muito boa a explicação.
Muito bom. Há alguma sugestão para uso de microservices em Python?
muito bom
Então quer dizer que são um programa com aplicações separadas, por exemplo tenho o sistema de gestão mas tenho uma aplicação de emissão de notas e outra aplicação do financeiro, mas ambos faz parte do mesmo projeto e se comunicam entre sim?
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
Acredito que a ideia de Monolítico ser bagunçado é por conta da qualificação do desenvolvedor. Monolíticos também podem respeitar Design Patters e Clean Architecture, reduzindo o nível de acoplamento. O grande problema no meu ver é a escalabilidade de um monolítico e a manutenibilidade a longo prazo, principalmente porque existe uma grande chance de que outros Devs contribuam com o projeto.
Aliás, teu conteúdo é muito bom.
3:20 - agora bota um uno com escada, kk
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.
Promo>SM 💕
Associar arquitetura monolítica com código "spaghetti" está totalmente equivocado, infeliz comparação(recomendo estudar sobre arquiteturas concêntricas). Entenda: acoplamento de código está relacionado com o "code design" e não especificamente com a arquitetura usada. É perfeitamente possível criar código acoplado usando microserviços, a diferença é que você não consegue ver pois está tudo espalhado em cada microserviço.
Cada caso é um caso, microsservices por ser modinha daqui a pouco TODO list vai nascer como microsservices
Isso não precisa ser assim não, vc pode tranquilamente lidar com um bando de dados só.