Exatamente meu caro. Esse erro sempre vai existir por conta do hype, infelizmente já passei por isso. Imagina se um médico prescrevesse antibiótico pra todas as doenças? 😅
Tudo verdade, mas vale reforçar. Microsserviços é uma necessidade em muitos contextos. Não deve ser uma decisão automática, como também não deve ser rejeitada nos cenários em que for aplicável. Criticar microsserviços também é um Hype.
Trabalho com microsserviços, e esse conteúdo agregou muito, realmente a questão de estrutura organizacional de várias squads ajuda muito, mas a quantidade de burocracia pra isso funcionar é uma loucura
Exatamente, não adianta o pequeno que mal fatura deus 500 mil por mês querer usar as mesmas coisas e metodologias que empresas bilionárias que atendem milhões de clientes, as vezes complicamos demais algo simples, pro pequeno no geral monolítico ou meio termo é a solução.
Eu já estou em Tecnologia a mais de 25 anos e quase 20 anos só em desenvolvimento de software. Eu não adoto Técnica ou Tecnologia nenhuma que já não esteja madura. Eu deixo os "Early Adopters" fazerem os testes😅 Acompanho de longe... E podem observar muito coisa vira Hype e depois de 2 ou 3 anos são substituídas por outro Hype, principalmente tecnologias de Front-End Web....
@@edmilson1178 26 anos na área, 18 como programador. Faço o mesmo. Não fazemos isso por preguiça. Maximizamos o retorno sobre o investimento. Além disso, adoto tecnologias que vão complementar o que eu já consigo fazer, e passo longe de tecnologias que fazem a mesma coisa que eu já sou capaz usando outras tecnologias. Isso impede que eu fique patinando.
Estou me debruçando sobre micro serviços agora.java/spring.... Ajudou muito, depois deste vídeo consigo falar com mais segurança sobre o assunto, obrigado
Wesley : trabalho sensacional este que vc desenvolve - transmitir conhecimento. Aprendi muito com vcs aqui ... (e olha que sou "Garoto de Programa" 🤭 há mais de 30 anos)
É difícil pra caramba e custoso implementar e manter os microserviços, e mais, a mão de obra qualificada para evoluir e manter essa estrutura é muito mais cara e estamos em um momento de taxas de juros altas e empresas focando em 'eficiência' (corte de gastos). O hype foi muito grande também pela abundância de recursos financeiros para esses experimentos, vamos ver de agora em diante como vai ser.
É uma bosta manter MS com equipe pequena, falo por experiência, não adianta, o acoplamento é certo, ai vc distribui um turbilhão de requisições http ou mensageria, o que torna mais complexo ainda.
O q vc explicou nesse vídeo é basicamente, a falta de um olhar mais estratégico e operacional dos arquitetos e do board da empresa. Quando o operacional começar a trabalhar sem um controle estratégico da empresa... Vai ter problemas. Trabalho em projeto em que se usa poucos mocroservices e um software gigante monolith. Mas deram liberdade para o gerente do projeto administrar do jeito que achou certo sem ver a estratégia da organização. Agora estamos com um problema que é algumas defasagens que estão prejudicando as entregas, as tools de monitoração de segurança e outros problemas. Muitos da equipe vem alertando isso a alguns anos, mas infelizmente só agora depois de alguns anos que viram o que fizeram de errado.
Trabalhei em um projeto como freelancer para uma empresa. Me pediram um front angular e mocroservices. Eles não trabalham com nada atual...somente com softwares baixo nível. Daí perguntei no início, vcs querem em python, nodejs, Java ou c#? Depois de muita conversa chegamos na decisão que para eles ficaria bom c#. Veja a diferença, o diretor e o arquiteto da empresa, já tinham a visão q precisavam administrar. Então eles definiram a arquitetura e a tecnologia. Essa é a diferença entre uma organização que administra o seu valor e aquelas que deixam o operacional fazer o que fizeram com hype dos mocroservices.
na N26 adotamos, desde o início a aplicação do DDD para definir os domínios e seus contextos delimitados, dão muito suporte para implementação de Monolitos Modulares. Com este conceito, adotamos um mono-repo que nos permite distribuir recursos dentro da infraestrutura. Ainda estamos na construção disso tudo e está sendo uma experiência bastante interessante. Se seu objetivo era uma breve introdução sobre o tema, acredito que cumpriu seu papel.
Gosto desses vídeos com contexto histórico e sobre experiência real de trabalho e de mercado. Vídeo sincero e com muita bagagem. Obrigado pelo bate bapo.
Wesley, parabéns! Vc focou a distorção bastante comum aos diferentes modismos. Há um momento em que todos "migram" e há um reverso da onda em que os problemas reais aparecem. Microsserviços é uma realidade sem volta. O que se impõe aos gestores em TIC é a adoção de boas práticas, planejamento e escolhas. No serviço público aplicações críticas gigantescas, em plataformas tecnológicas defasadas, tornam esforços de manutenção e/ou evolução tão ou mais caros do que a aquisição de novos sistemas. A cultura monolítica (na qual são característicos feudos de poder) também inviabiliza adoção de inovações e melhorias relevantes para o negócio. Há referenciais teórico práticos muito interessantes sobre métodos de análise e planejamento da decomposição de sistemas monolíticos. Há a questão complexa (desafiadora) sobre investimentos em preparação - que não mostram resultados em curto prazo - e é necessário convicção e visão estratégica para colher benefícios em médio / longo prazo. Importante observar que o resultado - além dos benefícios - é maior complexidade em governança, controles e operações. Há ainda as questões de segurança. Desafios!
[ 11:29 ]mim. Faltou colocar o nome do livro na caixa de informações! Espero que o livro seja este: " Team Topologies: Organizing Business and Technology Teams for Fast Flow " by Matthew Skelton.
Cada dor tem seu remédio. Por isso, nós arquitetos, precisamos pensar de acordo com o projeto, e não projetar por moda ou por vergonha de ir contra as modas.
Os serviços modulares são uma ótima opção aos microsserviços, não são perfeitos, mas eles podem conviver bem com microsservicos e monolitos, dependendo do caso de uso. Para a maioria das empresas, serviços modulares seriam o ideal.
@@daniloloko5 pra não escrever um texto enorme, vou tentar fazer uma analogia que não é tão precisa mas serve como idéia. Serviços modulares seria na idéia algo similar ao que a SAP faz com seus ERPs.
@@daniloloko5 O termo "Modular Monolith" refere-se a uma abordagem de arquitetura de software que combina a simplicidade de um monólito com a modularidade de uma arquitetura orientada a serviços. Em um sistema de "Modular Monolith", o código é dividido em módulos lógicos independentes, cada um dos quais é responsável por um conjunto específico de funcionalidades. Esses módulos são projetados para serem separáveis, substituíveis e escaláveis individualmente, mas eles são implantados em conjunto como um único aplicativo monolítico. Essa abordagem permite que os desenvolvedores se beneficiem da simplicidade e da facilidade de desenvolvimento de um monólito, enquanto ainda obtêm a flexibilidade e a modularidade de uma arquitetura orientada a serviços. Além disso, o fato de o aplicativo ser implantado como um único monólito simplifica a implementação, o gerenciamento e a operação do sistema. No entanto, é importante lembrar que essa abordagem não é uma solução para todos os problemas de arquitetura de software e pode não ser adequada para todos os casos de uso. Cada sistema deve ser avaliado individualmente para determinar a melhor abordagem arquitetônica para suas necessidades específicas.
@@daniloloko5 A diferença é que os microservices por natureza cada módulo tem uma implantação diferente bem isolado um do outro, já o monolito modular tem a mesma ideia de divisão de servicos/features/módulos do microservico, porém todos eles são implantados no mesmo processo e por isso se define como monolítico e não microservico
Conteúdo sensacional, no momento 15:15 é muito mais sobre soft skill (muito importante) e 100% verdade... Por incrível que parece é um déficit na formação de devs.
EXATOOO!!! ESCALAR O TIMEEEE!!! Microserviço me possibilita chegar pro cara do RH e falar: " Hey, pode buscar por dev python, php e node !! " O que cair na peixe é rede ! Dai o desenvolvimento do meu produto não fica parado por conta de mão de obra !
é oq vai acontecer quando vc nao tiver + desenvolvedor php pra mexer e tiver uns 50 de python??... é muito mais seguro desenvolver os mesmos ms na mesma linguagem pq se algum time sair.. o outro assume...
@@vitoragt O lance aqui é minimizar os danos por falta de mão de obra. De que forma eu consigo ter um melhor resultado ? Diversificando as linguagens de programação no desenvolvimento do meu produto ou desenvolver meu produto usando uma linguagem só ? Minimizar os danos e não zerar os danos. A ideia e fazer com que o desenvolvimento não pare por falta de mão de obra, agora, fazer tudo isso com zero tradeoff ? imposível. Quando eu falo em diversificar, eu falo sobre fazer um estudo analisando as principais linguagens que podem atender meu produto. Vamos supor que eu consiga desenvolver meu produto usando Php ou Node ou Python. Das 3, quais eu tenho um maior leque de mão de obra disponível ? Qual a melhor pra curva de aprendizado ? O meu comentário não é sobre " Ok, vamos desenvolver usando TODAS as linguagens " Eu posso ter o meu produto diversificado nas melhores linguagens possíveis, se não tiver mão de obra, não tem o que fazer.
Muito bom o vídeo, acho que teve hype demais para microserviços, na real acho mais útil para empresas grandes e tem que tomar cuidado para não dividir demais e complicar demais tb. Eu prefiro monolítico ou no máximo dividir só em uma ou outra parte, penso assim se a equipe é pequena não tem pq complicado e por mais N camadas de complexidade e ferramentas. Inclusive hoje em dia acho super lento as empresas grandes mesmo com tantos deploys, cansei de ver ERP e outros serviços alugados que tem os mesmos problemas e detalhes a anos e nada de arrumarem, mesmo coisas simples, já empresa pequena e projetos Opensource costumam evoluir muito mais rápido e melhor. Foi tanto tb o hype que a indústria padronizou o Kubernates como orquestrador, sendo que ele só é mesmo focado em microserviços, mas esqueceram que a grande maioria das empresas e sistemas são monokiticos e que não precisam escalar em milhares de container e máquinas, inclusive acho que devia ser mais usado o Nomad, pois atende muito mais caos de usos e é peso leve rs, enquanto o Kubernates é muito focado em Enterprise para empresas que ganham milhões por mês e atende milhões de clientes. Faltou uma solução para o pequeno e médio, o Docker Swarm poderia até ser e até é, mas nenhum Cloud tem ele gerenciado ou ferramentas mais focadas nele, todo o ecossistema focando só no gigante Kubernates 😅, acho que muita ferramenta e metodológicas foca demais em empresa gigante e poucas para a maioria dos casos de usos de empresas menores.
Bastante, Microsserviços são excelentes e é perfeito para negócios maduros e que há uma entrada de grana sim e se torna uma necessidade ao negócio quando o monolito não consegue escalar mais recursos tanto de forma horizontal quanto vertical, o problema que a galera quer iniciar implementando microsserviço em uma empresa que ta começando e não possui tanta grana pra manter, o ideal é manter um monolito bem modular para que o negócio for evoluindo, seja mais fácil quebrar esse monolito e criar microsserviços, até por que o monolito deixa você refém de uma linguagem e de uma pipeline apenas, tem um custo menor, mas se enviar algo cagado pra produção, tu derruba uma app inteira, se perguntam se micro é uma evolução dos monolitos? Sim, mas não quer dizer que você consiga trabalhar com ambos, hoje estão sendo cotados até mesmo nanosserviços e vejo como até uma evolução ao microsserviços, mas ainda ta pra vim algo que substitua os dois 100% de uma forma que seja escalável, menos custoso e que haja um time de sincronização alta de atualização de dados (que é uma desvantagem hoje dos microsserviços).
Que vídeo sensacional, Wesley! Muito bom ver você explorando as "partes não tão belas" do hype. Esse tipo de experiência vale ouro! Continue com o excelente conteúdo, por favor!
É uma coisa clássica da tecnologia: surge algo novo, já querem matar as coisas que existem e/ou começar a criticar, que não presta, a tecnologia nova é o futuro e bla bla bla Tinha que ensinar já na escola: "Nem todo problema é prego, e nem toda solução é martelo".
Ele mesmo vendeu muito curso batendo nessa tecla de microserviços. E não precisava ser um expert no assunto pra saber que esse tipo estrutura iria bater de frente com latência.
Acredito que o futuro é criar aplicações monolíticas modulares. Aí na hora do deploy ter algum jeito de separar e fazer o deploy desses módulos como se fossem microserviços separados. Tem um projeto do google para fazer isso já (google wave se não me engano, mas nunca usei)., transformando assim os "monolitos" em "grupos de microserviços" onde cada módulo pode ser "considerado" um MS. Isso vai facilitar também na questão de ownership, pois muitas vezes alguns MS são muito "relacionados" e acabam sendo da responsabilidade do mesmo time (nunca trabalhei/vi uma empresa que realmente tem 1 micro-serviço por time) Separando os bounded-contexto certinho, criando os módulos desse "monolito-agrupado" e usando event-based (um rabbitMQ da vida) acho que torna tudo isso bem intuitivo e o principal: viável
Microsserviços exigem MACROGESTÃO, e por incrível que possa parecer uma boa documentação e de fácil acesso pelos atuais e novos membros das equipes, e ainda mais uma gestão de obsoletos, pois para mim muitos microsserviços são descartáveis, atendem uma demanda imediata e logo são substituído por solução mais sólidas.
Acho fantástico os Microserviços, mas quando temos muitos serviços e times de produtos fica muito mais complicado para o time de Operações. O que quando algo dá errado temos que ficar correndo para tudo que é lado procurando o owner do produto e cada um joga pro outro o problema. Tu tem algum vídeo sobre como operações e desenvolvimento pode trabalhar da melhor maneira com product taxonomy?
Sou Dev Sêniro Full Stack, com 20 anos de experiência, desempregado, procurando faz mais de 2 meses e sim, tá muito complicado, mercado de TI tá bem esquisito.
A evolução disso..e na verdade algo que já existia e muita gente não prestava atenção. MÓDULOS +PROVIDERS! Ia Java (sou javeiro), hj no Java 19, desde o Java 9, se chama Modular JDK. E muita gente, nem disso sabe.
Meu lema e se eu posso evitar micro serviços eu evitarei ao máximo. Eu ate tenho alguns mas como os meus são na verdade micro serviços pagos de terceiro meu problema com micro serviços e zero ate hoje.
Acredito que ainda temos um longo caminho a percorrer na maturidade de micro-serviços desde o gestor até o desenvolvedor, tirando aquelas empresas que já vem investindo muito tempo e dinheiro nestas novas tecnologias e conceitos
o mesmo é para kubernetes, quase todo mundo quer aprender e usar o bendito, sem se preocupar para qual a finalidade ele foi desenvolvido e por quem ele foi desenvolvido, dai vem um monte de empresas e funcionarios (gestores, lideres etc...) querendo falar do assunto e tals, porr@ mas para que ? a empresa tem alguns microserviços rodando, sei la uns 30, caraca o google tem milhares, o ML tem milhares, a NFlix tambem, mas você não é nenhuma dessas empresas, dai depois vem o dito cujo e fala: A quer saber, bora ficar MONO mesmo, ta bom assim... legacy forever.
Microservico da uma trabalheira do caramba para manutenção, se for fazer uma alteração em um serviço que depende do outro tem que fazer alteração em tudo
Segregar um módulo em um outro processo e componetização distribuída já existe desde os primórdios da computação. No início dos anos 2000, desenvolvia módulos distribuídos com .NET Remoting(Hoje seria chamado de microsserviço). Isso tudo é justificativa para vender hora mais cara. Corba, DCOM, COM+, EJB, tudo isso já existia quando tudo era mato
Depende, voces conseguem quebrar o monolito mais para frente ? pois o comportamento de rede por exemplo muda bastante de micro serviço para monolito, mas depende muito do que o pessoal precisa e tambem do quanto realmente confiam no seu serviço em momentos de decisão
A criação de uma POC (Prova de Conceito) como um microserviço depende muito do escopo e dos objetivos da POC, bem como das habilidades e recursos da equipe de desenvolvimento. Em geral, para uma POC com um escopo pequeno e limitado, pode não ser necessário criar um microserviço completo. Nesse caso, é possível usar uma abordagem monolítica ou até mesmo uma arquitetura sem servidor para criar a POC de maneira mais eficiente. No entanto, se o escopo da POC for grande o suficiente para justificar o uso de uma arquitetura de microserviços, e se a equipe de desenvolvimento possuir as habilidades necessárias para projetar e implementar um microserviço, pode ser válido criar a POC como um microserviço. Nesse caso, a equipe de desenvolvimento pode usar a POC como uma oportunidade para aprender e experimentar com a arquitetura de microserviços. No entanto, é importante lembrar que a criação de um microserviço completo pode levar mais tempo e recursos do que uma abordagem monolítica ou sem servidor. Portanto, é necessário avaliar cuidadosamente os prós e contras antes de decidir pela abordagem mais adequada para a POC. Além disso, é sempre uma boa prática começar pequeno e iterar rapidamente para validar a viabilidade da ideia antes de investir recursos significativos na criação de um microserviço completo.
Nunca dei moral pra esse canal pois parece muito orientado a hype e com ads super agressivos. Com essa opinião eu até concordo. Espero poder acompanhar mais depois desse conteúdo.
Agora é só esperar que o hype do SSR será o próximo a cair. Se aplica muito bem a alguns cenários mas não é uma "bala de prata" como vendem em cursos pela internet.
@@brenoaugust0 Server Side Rendering, estratégia de renderização de front-end. É muito bom para aplicações que dependem de SEO, por exemplo, mas de fato não é necessária para todos tipos de uso
@@onurb941985 Pois é, e mesmo nos casos onde hoje se aplica, em um futuro próximo nem fará mais tanto sentido visto que os computadores, smartphones e a internet ficam mais rápidos a cada ano que passa e agora com as IAs as search engines é que deverão evoluir
Acredito que a grande vantagem do SSR hoje é a capacidade de tirar uma grande responsabilidade de processamento do cliente, visto que todo trabalho de gerar a interface através do JS e de fazer as requisições ficarão sob responsabilidade do servidor, que certamente possui uma infra muito mais robusta do que a maioria dos aparelhos utilizados. Os frameworks Front-end de hoje estão caminhando cada vez mais nessa direção. No decorrer dos próximos anos poderemos observar uma evolução expressiva ou apenas mais uma estagnação. Mas concordo plenamente com você que isso não seja uma bala de prata.
cara, bizarro esse efeito manada, tu vai implementar um negocio sem analisar melhor os pros e contras, ja cansei de ver projeto em que quase todo mundo so pensa no agora, nem quando vai subir um server povo pensa, tem gente que acha que subir um server em produção é so fazer o build e deixar rodando eternamente sem tunning, sem scan, sem patching.
Vídeo legal. Mas o discurso é muito enrolado. Eu pausei o vídeo e fui a sites específicos, nos quais aprendi em poucos minutos o que são micro serviços. Falta objetividade, antes de contar a história e tecer os comentários...
o problema de alguns devs é achar que a estrutura do sistema da lojinha do seu Zé tem que ter a mesma estrutura que o mercado livre.
Exatamente meu caro.
Esse erro sempre vai existir por conta do hype, infelizmente já passei por isso.
Imagina se um médico prescrevesse antibiótico pra todas as doenças? 😅
Tudo verdade, mas vale reforçar.
Microsserviços é uma necessidade em muitos contextos. Não deve ser uma decisão automática, como também não deve ser rejeitada nos cenários em que for aplicável.
Criticar microsserviços também é um Hype.
Comentário perfeito, analisar sempre o contexto vai ser mais importante em que tipo de arquitetura irá adotar.
Trabalho com microsserviços, e esse conteúdo agregou muito, realmente a questão de estrutura organizacional de várias squads ajuda muito, mas a quantidade de burocracia pra isso funcionar é uma loucura
Nem todo mundo é a Netflix ou o Spotify. A gente, da área de TI corre prá pisar em cima quando vê uma casca de banana, não é possível.
Exatamente, não adianta o pequeno que mal fatura deus 500 mil por mês querer usar as mesmas coisas e metodologias que empresas bilionárias que atendem milhões de clientes, as vezes complicamos demais algo simples, pro pequeno no geral monolítico ou meio termo é a solução.
@@okaniokani concordo, amigo. É preciso ficar atento à nossa realidade, com humildade e muita atenção.
Ia fazer um comentário desse, mas vc já representou. Vou só dá um up 🆙
Eu já estou em Tecnologia a mais de 25 anos e quase 20 anos só em desenvolvimento de software. Eu não adoto Técnica ou Tecnologia nenhuma que já não esteja madura. Eu deixo os "Early Adopters" fazerem os testes😅 Acompanho de longe... E podem observar muito coisa vira Hype e depois de 2 ou 3 anos são substituídas por outro Hype, principalmente tecnologias de Front-End Web....
@@edmilson1178 26 anos na área, 18 como programador. Faço o mesmo. Não fazemos isso por preguiça. Maximizamos o retorno sobre o investimento. Além disso, adoto tecnologias que vão complementar o que eu já consigo fazer, e passo longe de tecnologias que fazem a mesma coisa que eu já sou capaz usando outras tecnologias. Isso impede que eu fique patinando.
Tem que tomar cuidado para não sair criando trocentas mil APIzinhas a toa msm! Perfeito!
Estou me debruçando sobre micro serviços agora.java/spring.... Ajudou muito, depois deste vídeo consigo falar com mais segurança sobre o assunto, obrigado
Wesley : trabalho sensacional este que vc desenvolve - transmitir conhecimento. Aprendi muito com vcs aqui ... (e olha que sou "Garoto de Programa" 🤭 há mais de 30 anos)
@Filipe Cruz kkkkk
É difícil pra caramba e custoso implementar e manter os microserviços, e mais, a mão de obra qualificada para evoluir e manter essa estrutura é muito mais cara e estamos em um momento de taxas de juros altas e empresas focando em 'eficiência' (corte de gastos). O hype foi muito grande também pela abundância de recursos financeiros para esses experimentos, vamos ver de agora em diante como vai ser.
Ótimo relato, obrigado
com time pequeno é bem complicado manter mesmo
É uma bosta manter MS com equipe pequena, falo por experiência, não adianta, o acoplamento é certo, ai vc distribui um turbilhão de requisições http ou mensageria, o que torna mais complexo ainda.
O q vc explicou nesse vídeo é basicamente, a falta de um olhar mais estratégico e operacional dos arquitetos e do board da empresa. Quando o operacional começar a trabalhar sem um controle estratégico da empresa... Vai ter problemas. Trabalho em projeto em que se usa poucos mocroservices e um software gigante monolith. Mas deram liberdade para o gerente do projeto administrar do jeito que achou certo sem ver a estratégia da organização. Agora estamos com um problema que é algumas defasagens que estão prejudicando as entregas, as tools de monitoração de segurança e outros problemas. Muitos da equipe vem alertando isso a alguns anos, mas infelizmente só agora depois de alguns anos que viram o que fizeram de errado.
Trabalhei em um projeto como freelancer para uma empresa. Me pediram um front angular e mocroservices. Eles não trabalham com nada atual...somente com softwares baixo nível. Daí perguntei no início, vcs querem em python, nodejs, Java ou c#? Depois de muita conversa chegamos na decisão que para eles ficaria bom c#. Veja a diferença, o diretor e o arquiteto da empresa, já tinham a visão q precisavam administrar. Então eles definiram a arquitetura e a tecnologia. Essa é a diferença entre uma organização que administra o seu valor e aquelas que deixam o operacional fazer o que fizeram com hype dos mocroservices.
Acho que já trabalhei nessa empresa ai em hahahaha
na N26 adotamos, desde o início a aplicação do DDD para definir os domínios e seus contextos delimitados, dão muito suporte para implementação de Monolitos Modulares. Com este conceito, adotamos um mono-repo que nos permite distribuir recursos dentro da infraestrutura. Ainda estamos na construção disso tudo e está sendo uma experiência bastante interessante. Se seu objetivo era uma breve introdução sobre o tema, acredito que cumpriu seu papel.
Quais linguagens vocês usam?
Força aí, por que o app da N26 apresenta instabilidades dia sim e dia também.
Boa! Importante dar essas opniões como forma de experiência, principalmente para os mais JR's. Bons pontos e argumentos.
Gosto desses vídeos com contexto histórico e sobre experiência real de trabalho e de mercado. Vídeo sincero e com muita bagagem. Obrigado pelo bate bapo.
Excelente explicacao! Muito importante falar dos Hypes e de utilizar o que funciona o que nao. Contexto fundamental
Esse vídeo caiu como uma luva na minha vida. Obrigado por esse vídeo amigo!!!
As equipes esquecem do básico, aderir à padronização. Padrões de projeto. Gostei muito do vídeo, parabéns!
Wesley, parabéns! Vc focou a distorção bastante comum aos diferentes modismos. Há um momento em que todos "migram" e há um reverso da onda em que os problemas reais aparecem. Microsserviços é uma realidade sem volta. O que se impõe aos gestores em TIC é a adoção de boas práticas, planejamento e escolhas. No serviço público aplicações críticas gigantescas, em plataformas tecnológicas defasadas, tornam esforços de manutenção e/ou evolução tão ou mais caros do que a aquisição de novos sistemas. A cultura monolítica (na qual são característicos feudos de poder) também inviabiliza adoção de inovações e melhorias relevantes para o negócio. Há referenciais teórico práticos muito interessantes sobre métodos de análise e planejamento da decomposição de sistemas monolíticos. Há a questão complexa (desafiadora) sobre investimentos em preparação - que não mostram resultados em curto prazo - e é necessário convicção e visão estratégica para colher benefícios em médio / longo prazo. Importante observar que o resultado - além dos benefícios - é maior complexidade em governança, controles e operações. Há ainda as questões de segurança. Desafios!
Microserviços é um modelo arquitetural impressionante e poderosíssimo!
Esse vídeo é uma "Revelação" para o mundo dos microservices, só queria lembrar sobre usar ORM e não noSQL ou quando usar.
[ 11:29 ]mim. Faltou colocar o nome do livro na caixa de informações!
Espero que o livro seja este:
" Team Topologies: Organizing Business and Technology Teams for Fast Flow " by Matthew Skelton.
Cada dor tem seu remédio. Por isso, nós arquitetos, precisamos pensar de acordo com o projeto, e não projetar por moda ou por vergonha de ir contra as modas.
Os serviços modulares são uma ótima opção aos microsserviços, não são perfeitos, mas eles podem conviver bem com microsservicos e monolitos, dependendo do caso de uso. Para a maioria das empresas, serviços modulares seriam o ideal.
Qual a diferença de microservices e modulares?
@@daniloloko5 pra não escrever um texto enorme, vou tentar fazer uma analogia que não é tão precisa mas serve como idéia. Serviços modulares seria na idéia algo similar ao que a SAP faz com seus ERPs.
@@daniloloko5 pesquise por monólitos modulares, e se você e javeiro pesquise pro Servi Privet Interfaces e Modulea
@@daniloloko5 O termo "Modular Monolith" refere-se a uma abordagem de arquitetura de software que combina a simplicidade de um monólito com a modularidade de uma arquitetura orientada a serviços.
Em um sistema de "Modular Monolith", o código é dividido em módulos lógicos independentes, cada um dos quais é responsável por um conjunto específico de funcionalidades. Esses módulos são projetados para serem separáveis, substituíveis e escaláveis individualmente, mas eles são implantados em conjunto como um único aplicativo monolítico.
Essa abordagem permite que os desenvolvedores se beneficiem da simplicidade e da facilidade de desenvolvimento de um monólito, enquanto ainda obtêm a flexibilidade e a modularidade de uma arquitetura orientada a serviços. Além disso, o fato de o aplicativo ser implantado como um único monólito simplifica a implementação, o gerenciamento e a operação do sistema.
No entanto, é importante lembrar que essa abordagem não é uma solução para todos os problemas de arquitetura de software e pode não ser adequada para todos os casos de uso. Cada sistema deve ser avaliado individualmente para determinar a melhor abordagem arquitetônica para suas necessidades específicas.
@@daniloloko5 A diferença é que os microservices por natureza cada módulo tem uma implantação diferente bem isolado um do outro, já o monolito modular tem a mesma ideia de divisão de servicos/features/módulos do microservico, porém todos eles são implantados no mesmo processo e por isso se define como monolítico e não microservico
Esse canal é simplesmente fantástico.
Raro eu comentar e curtir um vídeo. Parabéns pelo conteúdo excepcional!
Muito bom , um micros-services chassi é fundamental para manter o ecossistema saudável.
Conteúdo sensacional, no momento 15:15 é muito mais sobre soft skill (muito importante) e 100% verdade... Por incrível que parece é um déficit na formação de devs.
Muito boa a apresentação ! Eu desenvolvo apps de mobilidade e uso micro serviços não tem como fugir mesmo !
EXATOOO!!! ESCALAR O TIMEEEE!!! Microserviço me possibilita chegar pro cara do RH e falar: " Hey, pode buscar por dev python, php e node !! " O que cair na peixe é rede ! Dai o desenvolvimento do meu produto não fica parado por conta de mão de obra !
é oq vai acontecer quando vc nao tiver + desenvolvedor php pra mexer e tiver uns 50 de python??... é muito mais seguro desenvolver os mesmos ms na mesma linguagem pq se algum time sair.. o outro assume...
Coitada da sua empresa.
@@vitoragt O lance aqui é minimizar os danos por falta de mão de obra. De que forma eu consigo ter um melhor resultado ? Diversificando as linguagens de programação no desenvolvimento do meu produto ou desenvolver meu produto usando uma linguagem só ?
Minimizar os danos e não zerar os danos. A ideia e fazer com que o desenvolvimento não pare por falta de mão de obra, agora, fazer tudo isso com zero tradeoff ? imposível.
Quando eu falo em diversificar, eu falo sobre fazer um estudo analisando as principais linguagens que podem atender meu produto.
Vamos supor que eu consiga desenvolver meu produto usando Php ou Node ou Python. Das 3, quais eu tenho um maior leque de mão de obra disponível ? Qual a melhor pra curva de aprendizado ?
O meu comentário não é sobre " Ok, vamos desenvolver usando TODAS as linguagens "
Eu posso ter o meu produto diversificado nas melhores linguagens possíveis, se não tiver mão de obra, não tem o que fazer.
Muito bom o vídeo, acho que teve hype demais para microserviços, na real acho mais útil para empresas grandes e tem que tomar cuidado para não dividir demais e complicar demais tb. Eu prefiro monolítico ou no máximo dividir só em uma ou outra parte, penso assim se a equipe é pequena não tem pq complicado e por mais N camadas de complexidade e ferramentas.
Inclusive hoje em dia acho super lento as empresas grandes mesmo com tantos deploys, cansei de ver ERP e outros serviços alugados que tem os mesmos problemas e detalhes a anos e nada de arrumarem, mesmo coisas simples, já empresa pequena e projetos Opensource costumam evoluir muito mais rápido e melhor.
Foi tanto tb o hype que a indústria padronizou o Kubernates como orquestrador, sendo que ele só é mesmo focado em microserviços, mas esqueceram que a grande maioria das empresas e sistemas são monokiticos e que não precisam escalar em milhares de container e máquinas, inclusive acho que devia ser mais usado o Nomad, pois atende muito mais caos de usos e é peso leve rs, enquanto o Kubernates é muito focado em Enterprise para empresas que ganham milhões por mês e atende milhões de clientes.
Faltou uma solução para o pequeno e médio, o Docker Swarm poderia até ser e até é, mas nenhum Cloud tem ele gerenciado ou ferramentas mais focadas nele, todo o ecossistema focando só no gigante Kubernates 😅, acho que muita ferramenta e metodológicas foca demais em empresa gigante e poucas para a maioria dos casos de usos de empresas menores.
Muito bom o vídeo, mas pelos comentários acredito que a mensagem não ficou clara ou o pessoal está precisando urgente do treinamento da fullcycle 🤫
Bastante, Microsserviços são excelentes e é perfeito para negócios maduros e que há uma entrada de grana sim e se torna uma necessidade ao negócio quando o monolito não consegue escalar mais recursos tanto de forma horizontal quanto vertical, o problema que a galera quer iniciar implementando microsserviço em uma empresa que ta começando e não possui tanta grana pra manter, o ideal é manter um monolito bem modular para que o negócio for evoluindo, seja mais fácil quebrar esse monolito e criar microsserviços, até por que o monolito deixa você refém de uma linguagem e de uma pipeline apenas, tem um custo menor, mas se enviar algo cagado pra produção, tu derruba uma app inteira, se perguntam se micro é uma evolução dos monolitos? Sim, mas não quer dizer que você consiga trabalhar com ambos, hoje estão sendo cotados até mesmo nanosserviços e vejo como até uma evolução ao microsserviços, mas ainda ta pra vim algo que substitua os dois 100% de uma forma que seja escalável, menos custoso e que haja um time de sincronização alta de atualização de dados (que é uma desvantagem hoje dos microsserviços).
Que vídeo sensacional, Wesley! Muito bom ver você explorando as "partes não tão belas" do hype. Esse tipo de experiência vale ouro! Continue com o excelente conteúdo, por favor!
É uma coisa clássica da tecnologia: surge algo novo, já querem matar as coisas que existem e/ou começar a criticar, que não presta, a tecnologia nova é o futuro e bla bla bla
Tinha que ensinar já na escola:
"Nem todo problema é prego, e nem toda solução é martelo".
Baita visão geral sobre o assunto parabéns pelo vídeo
Que vídeo top Wesley, é tudo isso que vc falou.
Ele mesmo vendeu muito curso batendo nessa tecla de microserviços. E não precisava ser um expert no assunto pra saber que esse tipo estrutura iria bater de frente com latência.
Acredito que o futuro é criar aplicações monolíticas modulares. Aí na hora do deploy ter algum jeito de separar e fazer o deploy desses módulos como se fossem microserviços separados. Tem um projeto do google para fazer isso já (google wave se não me engano, mas nunca usei)., transformando assim os "monolitos" em "grupos de microserviços" onde cada módulo pode ser "considerado" um MS.
Isso vai facilitar também na questão de ownership, pois muitas vezes alguns MS são muito "relacionados" e acabam sendo da responsabilidade do mesmo time (nunca trabalhei/vi uma empresa que realmente tem 1 micro-serviço por time)
Separando os bounded-contexto certinho, criando os módulos desse "monolito-agrupado" e usando event-based (um rabbitMQ da vida) acho que torna tudo isso bem intuitivo e o principal: viável
nesse caso os serviços rodam no mesmo processo ? teria de ser na mesma linguagem ?
Excelente conteúdo !
Parabéns pelo conteúdo! Continuem assim!
Microsserviços exigem MACROGESTÃO, e por incrível que possa parecer uma boa documentação e de fácil acesso pelos atuais e novos membros das equipes, e ainda mais uma gestão de obsoletos, pois para mim muitos microsserviços são descartáveis, atendem uma demanda imediata e logo são substituído por solução mais sólidas.
Show!
Você conversa como um pastor pentecostal. Nada contra. Apenas um comentário. Excelente video.
Acho fantástico os Microserviços, mas quando temos muitos serviços e times de produtos fica muito mais complicado para o time de Operações. O que quando algo dá errado temos que ficar correndo para tudo que é lado procurando o owner do produto e cada um joga pro outro o problema. Tu tem algum vídeo sobre como operações e desenvolvimento pode trabalhar da melhor maneira com product taxonomy?
Sou Dev Sêniro Full Stack, com 20 anos de experiência, desempregado, procurando faz mais de 2 meses e sim, tá muito complicado, mercado de TI tá bem esquisito.
Desde que eu trabalho com MS (+-10anos), acho que ficou claro que micro serviços com muitas linguagens era inviável.
Eu não consegui entender a indicação do livro 11:30. Poderia por na descrição ou no responder meu comentário? Obrigado.
da hora em
Mantenha assim!
obrigado pelo conteudo
Top, parabéns!!!
A evolução disso..e na verdade algo que já existia e muita gente não prestava atenção. MÓDULOS +PROVIDERS! Ia Java (sou javeiro), hj no Java 19, desde o Java 9, se chama Modular JDK. E muita gente, nem disso sabe.
Muito bom!
Meu primeiro desafio com MS foi na hora de gerar relatórios como fazer para juntar todos esse bancos de dados e relacionar eles.
Meu lema e se eu posso evitar micro serviços eu evitarei ao máximo. Eu ate tenho alguns mas como os meus são na verdade micro serviços pagos de terceiro meu problema com micro serviços e zero ate hoje.
Acredito que ainda temos um longo caminho a percorrer na maturidade de micro-serviços desde o gestor até o desenvolvedor, tirando aquelas empresas que já vem investindo muito tempo e dinheiro nestas novas tecnologias e conceitos
o mesmo é para kubernetes, quase todo mundo quer aprender e usar o bendito, sem se preocupar para qual a finalidade ele foi desenvolvido e por quem ele foi desenvolvido, dai vem um monte de empresas e funcionarios (gestores, lideres etc...) querendo falar do assunto e tals, porr@ mas para que ? a empresa tem alguns microserviços rodando, sei la uns 30, caraca o google tem milhares, o ML tem milhares, a NFlix tambem, mas você não é nenhuma dessas empresas, dai depois vem o dito cujo e fala: A quer saber, bora ficar MONO mesmo, ta bom assim... legacy forever.
Vlw!!
Microservico da uma trabalheira do caramba para manutenção, se for fazer uma alteração em um serviço que depende do outro tem que fazer alteração em tudo
Muito legal
Cara tô pegando raiva de você porque não importa quanto eu fale para o youtube parar de mostrar teu anuncio, ele mesmo assim continua aparecendo.
Esse lance de ownership em um eco sistema de Ms e complicado, o cara que trampa no Gateway é pai de tudo kk.
Qual é o livro que você recomendou neste ponto ua-cam.com/video/Zu-D9A_L5Qo/v-deo.html? Não consegui encontrá-lo
Deu trabalho entender o que ele falou mesmo, mas acho que foi "Team Topologies"
3:00
Clean code e design patterns são esquecidos várias vezes no meio do caminho, aí que mora o perigo.
A pior coisa da área de TI é justamente a velocidade como as coisas ficam ultrapassadas.
Segregar um módulo em um outro processo e componetização distribuída já existe desde os primórdios da computação. No início dos anos 2000, desenvolvia módulos distribuídos com .NET Remoting(Hoje seria chamado de microsserviço). Isso tudo é justificativa para vender hora mais cara. Corba, DCOM, COM+, EJB, tudo isso já existia quando tudo era mato
exatamente. tudo o que vendem hoje sempre existiu mas nao tinha nome, ai alguem foi la criou um nome, virou modinha e deu o efeito manada
A melhor forma de quebrar microserviços não é o DDD e sim o Event storming.
Também podemos "quebrar" uma aplicação utilizando monolitos modulares
Poderia, compartilhar o link do livro para compra?
Se você configurar um timeout 10000 mls em ms java, você não terá retorno nenhum das requisições. 😅
Vc acha que faz sentido a pessoa já criar uma POC como MS ? mesmo com 2 ou 3 desenvolvedores? na minha opinião é contra produtivo
se MS for um requisito nao funcional do sistema, sim
Depende, voces conseguem quebrar o monolito mais para frente ? pois o comportamento de rede por exemplo muda bastante de micro serviço para monolito, mas depende muito do que o pessoal precisa e tambem do quanto realmente confiam no seu serviço em momentos de decisão
@@brenoaugust0 Dependendo de como for feito é simples replicar e dividir o projeto em MS.
@@Oculterous Isso é vdd, depende do projeto e dos envolvidos a frente no final do dia
A criação de uma POC (Prova de Conceito) como um microserviço depende muito do escopo e dos objetivos da POC, bem como das habilidades e recursos da equipe de desenvolvimento. Em geral, para uma POC com um escopo pequeno e limitado, pode não ser necessário criar um microserviço completo. Nesse caso, é possível usar uma abordagem monolítica ou até mesmo uma arquitetura sem servidor para criar a POC de maneira mais eficiente.
No entanto, se o escopo da POC for grande o suficiente para justificar o uso de uma arquitetura de microserviços, e se a equipe de desenvolvimento possuir as habilidades necessárias para projetar e implementar um microserviço, pode ser válido criar a POC como um microserviço. Nesse caso, a equipe de desenvolvimento pode usar a POC como uma oportunidade para aprender e experimentar com a arquitetura de microserviços.
No entanto, é importante lembrar que a criação de um microserviço completo pode levar mais tempo e recursos do que uma abordagem monolítica ou sem servidor. Portanto, é necessário avaliar cuidadosamente os prós e contras antes de decidir pela abordagem mais adequada para a POC. Além disso, é sempre uma boa prática começar pequeno e iterar rapidamente para validar a viabilidade da ideia antes de investir recursos significativos na criação de um microserviço completo.
Poderia escrever o nome do livro por gentileza. Pela fala não consegui acessar😉
Topology teams
@@allanhebert398 muito obrigado!
Nunca dei moral pra esse canal pois parece muito orientado a hype e com ads super agressivos. Com essa opinião eu até concordo. Espero poder acompanhar mais depois desse conteúdo.
saudade do monolitao 😊
mano vc é o pudim da fatec de Santos?
Na empresa que eu trabalho nos usa microserviços e nos tem um template
Agora é só esperar que o hype do SSR será o próximo a cair. Se aplica muito bem a alguns cenários mas não é uma "bala de prata" como vendem em cursos pela internet.
SSR ??
Poderia dizer a este leigo nesta sigla se seria serverless meu caro ?
@@brenoaugust0 Server Side Rendering, estratégia de renderização de front-end. É muito bom para aplicações que dependem de SEO, por exemplo, mas de fato não é necessária para todos tipos de uso
@@onurb941985 obrigado pelo esclarecimento, de fato as coisas vão mudar com o tempo
@@onurb941985 Pois é, e mesmo nos casos onde hoje se aplica, em um futuro próximo nem fará mais tanto sentido visto que os computadores, smartphones e a internet ficam mais rápidos a cada ano que passa e agora com as IAs as search engines é que deverão evoluir
Acredito que a grande vantagem do SSR hoje é a capacidade de tirar uma grande responsabilidade de processamento do cliente, visto que todo trabalho de gerar a interface através do JS e de fazer as requisições ficarão sob responsabilidade do servidor, que certamente possui uma infra muito mais robusta do que a maioria dos aparelhos utilizados.
Os frameworks Front-end de hoje estão caminhando cada vez mais nessa direção. No decorrer dos próximos anos poderemos observar uma evolução expressiva ou apenas mais uma estagnação.
Mas concordo plenamente com você que isso não seja uma bala de prata.
cara, bizarro esse efeito manada, tu vai implementar um negocio sem analisar melhor os pros e contras, ja cansei de ver projeto em que quase todo mundo so pensa no agora, nem quando vai subir um server povo pensa, tem gente que acha que subir um server em produção é so fazer o build e deixar rodando eternamente sem tunning, sem scan, sem patching.
Exatamente, fazer é fácil, difícil é manter. 😂
Bacana. Gostei do vídeo, embora acho que poderia ser mais objetivo.
Vídeo legal. Mas o discurso é muito enrolado. Eu pausei o vídeo e fui a sites específicos, nos quais aprendi em poucos minutos o que são micro serviços. Falta objetividade, antes de contar a história e tecer os comentários...
Cartão perfurado... que saudade
✅
Nunca cai nesse conto do vigario
Mano 5 minutos para entrar no assunto.... a vontade de desinscrever cresce... 😑
O Wesley tem muito conhecimento, mas essas pausas que faz, toda vez fala o nome e o nome do canal, num da.
No final da história, o GPT vai acabar com tudo e com todos HAHAHA
"Aí quem quiser me consome". Resumo da minha vida