Em arquitetura de sistemas, não podemos deixar modismos ou tendências ficarem acima do contexto da necessidade do sistema. Em certos projetos, aplica-se melhor um tipo de arquitetura (hexagonal, monolitica, microserviços), muitas vezes usa-se um amálgama delas. Tudo depende da fase do projeto, se é uma POC, se tem deadline apertado, se a entrega é prioridade em uma fase do projeto em vima da oerformance e/ou do custo, etc. Refatorar, em muitas situações, é necessario.
Concordo plenamente, já vi casos onde foi escolhido usar arquitetura de microserviços (somente porque a Netflix estava usando) e foi um tiro no pé, projeto morreu antes mesmo de ser algo "entregável"
Sou time monolítico ou monolíticos dividido em poucas partes, para meu caso de uso é melhor e atende 100% com folga e menos complexidade, tipo pq vou dividir em sei lá 100 serviços, se posso com um sistema mais completo ter todos eles e menos complexidade para cuidar, mas claro cada caso é um caso. Sobre Serveless tenho usado por mais de um ano, porém não uso para lotar de N serviços, na verdade uso para um semi monolíticos rs, API leve para alguns sistemas e o API Gateway na frente, atende bem, igual fosse EC2, mas sendo realista daria para fazer mesma coisa no EC2 e com menos latência só não tão flexível em escala , mas não sendo cobrado por uso de requisições e tempo, algo que se tiver um ataque não sei como a AWS lidariam se me cobraria ou não, algo que me preocupar muito em Serverless. Outro ponto se o sistema tem umas 5 milhões de requisições ou algo assim de boa, mas se chega a um certo volume e tempo para rodar, o Serverless vai ficar absurdamente mais caro que um EC2/Cloud. O contexto do meu uso é para Ecommerce de pequeno e médio porte, algo na faixa de até uns 20 mil pedido por dia e focado na plataforma de Ecommerce Opensource Opencart feita em PHP. Um monolítico para este caso de uso atende facilmente 100% e escala muito bem, na real diria que o limite é muito maior que 20 mil pedidos por dia, mas não tenho caso de uso tão grande, o maior caso é de um cliente que transaciona até uns 10-15 mil pedidos por dia em pico e feita claramente otimizações de Cache, Index e algumas outras, assim o servidor dele que claramente é um bom servidor aguenta bem e isso que o mesmo tem uso excessivo de Cron Job para muitas tarefas extras que precisam ficar rodando quase que toda hora. Logo acredito que o limite teórico seria fácil 50 mil ou mais pedidos por dia que representaria uma loja com ticket médio de 100 faturando uns 150 milhões por mês que sendo sincero não é o foco do Opencart, mas que o mesmo na teoria atenderia relativamente facilmente com um servidor menor inclusive que do Magento que é focado em loja maior. Já outros usos que tenho é de API e sistemas auxiliares para auxiliar a criação e usos dos nossos Apps para o Opencart como nosso Painel, API de alguns serviços e etc que devido nossa demanda um sistema monolítico atende facilmente e mesmo assim é possível de ser rodado em Serverless usando o Bref e AWS Lambda.
Mas o headline nao estava errado, saiu de uma arquitetura distribuida para uma mais unificada e monolitica e conseguiu melhorar em todos os aspectos incluindo custos. Ai é querer deixar muito excepcional o que é regra geral e falar o que era obvio depois que deu problema, convenhamos é bem comodo. Distribuir em QUALQUER CASO é mais dificil, mais caro, mais complexo e o resto é so blablabla, a realidade mostra isso bem.
Concordo com a abordagem dos times, mas temos também o chamado “monólito distribuído” aonde cada time ou squad é responsável por um módulo e cada módulo tem um CI independente. Porém em runtime roda tudo em um único setup olhando para um único banco.
Um filme de 2h, tem 120 minutos, 7200 segundos com 24 frames por segundo, temos 172.800 imagens jpegs. Coisa pra caramba, imagina a quantidade de io e leitura de disco?!
Mais um grande vídeo, eu tenho aprendido muito com os seus conteúdos, muito boa análise, é como aquele velho ditado não existe bala de prata, cada caso é um caso, tudo depende
É tudo tão óbvio quando se vê no detalhe. Concordo muito com sua análise, em especial com o que você fala sobre considerar o contexto no qual algo assim (digamos pouco performático) foi criado. Eu acho que muito do auê que gerou tudo isso foi por conta do título do post no site do Prime Video, no qual eles mesmos deram uma inflada sem alertar que no fundo foi uma correção de arquitetura.
pessoal, é complexo fazer todo um planejamento, é a amazon, tem um dos times mais especialistas no assunto, e uma decisão de negócios não invalida uma tecnologia de uso geral...
É bem típico de brasileiro dar opiniões sem entender do que se está falando, apoiado puramente em achismos. Me faz lembrar de uma pegadinha que perguntava nas ruas o que as pessoas achavam sobre a revogação da lei da gravidade no futebol. A análise do Wesley vai dentro do contexto tentando ainda entender o momento crítico em que a solução foi aplicada. Estar imerso em uma comunidade assim só tem me feito crescer.
Ótimo video, não conhecia ainda o canal mas gostei, mas recomendo uma coisa, tente ser mais direto, em todos os sentido, por exemplo, vc começou o video de verdade depois só de 3 minutos, me faz quase desistir de verdade, mas de resto é ótimo
Numa das análises que vi, a aplicação analisa travamentos de vídeo no usuário (browser) durante o streaming. A forma como estava sobrecarregava e se limitava à rede para transferir esses dados entre os microserviços.
Será que o problema não foi mais de abstração, no sentido de nano-serviço em vez de micro-serviço, isto é, a primeira versão, o que eles chamaram de micro-serviço, na verdade, era um nano-serviço ocasionando os problemas citados, então, se eu aumento a coesão, eu tenho um micro-serviço mais robusto. Eu ainda não vejo, como monolito, e sim, um micro-serviço com um contexto/domínio bem definido.
Tem uma frase que resume muito bem todo esse clickbait, Não acho que quem ganhar ou quem perder, nem quem ganhar nem perder, vai ganhar ou perder. Vai todo mundo perder. Roussef, Dilma
Acho que essa situação demonstra a falta de maturidade ou ignorância da nossa área, pois nesse alvoroço todo, as pessoas esquecem que tecnologia sempre foi pros e contras e o contexto em qual o sistema é feito.
Acho que repassam a conta, tipo isolam, até para poderem medir os custos reais e retorno. Se usam o Lambda para isso é provavelmente um erro pq o custo realmente pode ficar absurdo.
Muito Boa sua analise! Já compartilhei com muita gente!
Mais uma saga de um MVP em produção a dez anos UAHUAHAUA
Legal que com esse caso da amazon prime toda a comunidade tech se tornou especialista em serviços de streaming
Em arquitetura de sistemas, não podemos deixar modismos ou tendências ficarem acima do contexto da necessidade do sistema. Em certos projetos, aplica-se melhor um tipo de arquitetura (hexagonal, monolitica, microserviços), muitas vezes usa-se um amálgama delas. Tudo depende da fase do projeto, se é uma POC, se tem deadline apertado, se a entrega é prioridade em uma fase do projeto em vima da oerformance e/ou do custo, etc. Refatorar, em muitas situações, é necessario.
Concordo plenamente, já vi casos onde foi escolhido usar arquitetura de microserviços (somente porque a Netflix estava usando) e foi um tiro no pé, projeto morreu antes mesmo de ser algo "entregável"
Sou time monolítico ou monolíticos dividido em poucas partes, para meu caso de uso é melhor e atende 100% com folga e menos complexidade, tipo pq vou dividir em sei lá 100 serviços, se posso com um sistema mais completo ter todos eles e menos complexidade para cuidar, mas claro cada caso é um caso.
Sobre Serveless tenho usado por mais de um ano, porém não uso para lotar de N serviços, na verdade uso para um semi monolíticos rs, API leve para alguns sistemas e o API Gateway na frente, atende bem, igual fosse EC2, mas sendo realista daria para fazer mesma coisa no EC2 e com menos latência só não tão flexível em escala , mas não sendo cobrado por uso de requisições e tempo, algo que se tiver um ataque não sei como a AWS lidariam se me cobraria ou não, algo que me preocupar muito em Serverless.
Outro ponto se o sistema tem umas 5 milhões de requisições ou algo assim de boa, mas se chega a um certo volume e tempo para rodar, o Serverless vai ficar absurdamente mais caro que um EC2/Cloud.
O contexto do meu uso é para Ecommerce de pequeno e médio porte, algo na faixa de até uns 20 mil pedido por dia e focado na plataforma de Ecommerce Opensource Opencart feita em PHP. Um monolítico para este caso de uso atende facilmente 100% e escala muito bem, na real diria que o limite é muito maior que 20 mil pedidos por dia, mas não tenho caso de uso tão grande, o maior caso é de um cliente que transaciona até uns 10-15 mil pedidos por dia em pico e feita claramente otimizações de Cache, Index e algumas outras, assim o servidor dele que claramente é um bom servidor aguenta bem e isso que o mesmo tem uso excessivo de Cron Job para muitas tarefas extras que precisam ficar rodando quase que toda hora.
Logo acredito que o limite teórico seria fácil 50 mil ou mais pedidos por dia que representaria uma loja com ticket médio de 100 faturando uns 150 milhões por mês que sendo sincero não é o foco do Opencart, mas que o mesmo na teoria atenderia relativamente facilmente com um servidor menor inclusive que do Magento que é focado em loja maior.
Já outros usos que tenho é de API e sistemas auxiliares para auxiliar a criação e usos dos nossos Apps para o Opencart como nosso Painel, API de alguns serviços e etc que devido nossa demanda um sistema monolítico atende facilmente e mesmo assim é possível de ser rodado em Serverless usando o Bref e AWS Lambda.
Mas o headline nao estava errado, saiu de uma arquitetura distribuida para uma mais unificada e monolitica e conseguiu melhorar em todos os aspectos incluindo custos. Ai é querer deixar muito excepcional o que é regra geral e falar o que era obvio depois que deu problema, convenhamos é bem comodo. Distribuir em QUALQUER CASO é mais dificil, mais caro, mais complexo e o resto é so blablabla, a realidade mostra isso bem.
Exatamente!
Wesley tu é mt brabo cara, faz um video dando orientações de um monolito para um MVP feito em go. Muito obrigado pelo seu trabalho tmj.
Como diz uma colega de trabalho "sem conexto é pretexto". Claramente a arquitetura estava errada. Ótimo conteúdo como de costume.
parabéns pelo vídeo, isso pode ficar de lição para muitos devs pesquisarem ou pelo menos lerem antes de sair por aí falando algo que nem sequer leu. 😅
Concordo com a abordagem dos times, mas temos também o chamado “monólito distribuído” aonde cada time ou squad é responsável por um módulo e cada módulo tem um CI independente. Porém em runtime roda tudo em um único setup olhando para um único banco.
Um filme de 2h, tem 120 minutos, 7200 segundos com 24 frames por segundo, temos 172.800 imagens jpegs. Coisa pra caramba, imagina a quantidade de io e leitura de disco?!
Mais um grande vídeo, eu tenho aprendido muito com os seus conteúdos, muito boa análise, é como aquele velho ditado não existe bala de prata, cada caso é um caso, tudo depende
É tudo tão óbvio quando se vê no detalhe. Concordo muito com sua análise, em especial com o que você fala sobre considerar o contexto no qual algo assim (digamos pouco performático) foi criado. Eu acho que muito do auê que gerou tudo isso foi por conta do título do post no site do Prime Video, no qual eles mesmos deram uma inflada sem alertar que no fundo foi uma correção de arquitetura.
tava procurando materia sobre esse assunto, otimo ser vc falando!
Vídeo maravilhoso, Wesley! Tô assistindo com a maior alegria do mundo
Para terem voltado atrás, o sistema deveria ter existido, na forma que se encontra hoje
pessoal, é complexo fazer todo um planejamento, é a amazon, tem um dos times mais especialistas no assunto, e uma decisão de negócios não invalida uma tecnologia de uso geral...
O mais engraçado é que eles não pararam de usar microserviços, só pararam de usar serverless
Eu havia entendido que eles tinham saído do microservico e focado no servelss, escalando o monolito inteiro
É bem típico de brasileiro dar opiniões sem entender do que se está falando, apoiado puramente em achismos. Me faz lembrar de uma pegadinha que perguntava nas ruas o que as pessoas achavam sobre a revogação da lei da gravidade no futebol.
A análise do Wesley vai dentro do contexto tentando ainda entender o momento crítico em que a solução foi aplicada.
Estar imerso em uma comunidade assim só tem me feito crescer.
Ótimo video, não conhecia ainda o canal mas gostei, mas recomendo uma coisa, tente ser mais direto, em todos os sentido, por exemplo, vc começou o video de verdade depois só de 3 minutos, me faz quase desistir de verdade, mas de resto é ótimo
Numa das análises que vi, a aplicação analisa travamentos de vídeo no usuário (browser) durante o streaming. A forma como estava sobrecarregava e se limitava à rede para transferir esses dados entre os microserviços.
A galera do micro serviço arrumando os "senão" para justificar essa insanidade, meu amigo micro servicos não é pra qualquer um, virou modinha
Boa Wesley, brabo demais!
Excelente conteúdo!
Eu trabalho com Microservices em um Projeto e-commerce.
Boa. Vi muita gente falando disso e sacrificando microservices. Não existe bala de prata.
Muito boa a análise.
Excelente!!!
Excelente vídeo!
Será que o problema não foi mais de abstração, no sentido de nano-serviço em vez de micro-serviço, isto é, a primeira versão, o que eles chamaram de micro-serviço, na verdade, era um nano-serviço ocasionando os problemas citados, então, se eu aumento a coesão, eu tenho um micro-serviço mais robusto. Eu ainda não vejo, como monolito, e sim, um micro-serviço com um contexto/domínio bem definido.
Eu achei incrível isso, como já haviam dito, não existe bala de prata.
Tem uma frase que resume muito bem todo esse clickbait, Não acho que quem ganhar ou quem perder, nem quem ganhar nem perder, vai ganhar ou perder. Vai todo mundo perder. Roussef, Dilma
Acho que essa situação demonstra a falta de maturidade ou ignorância da nossa área, pois nesse alvoroço todo, as pessoas esquecem que tecnologia sempre foi pros e contras e o contexto em qual o sistema é feito.
Conteúdo top !
Monolito vai ser a melhor solução para a maioria dos casos.
Famoso depende
@@JJbazaga1 de um exemplo
kkkkkkk
Se o Prime é da Amazon, então o uso da AWS deveria ser de graça kkkkk
Acho que repassam a conta, tipo isolam, até para poderem medir os custos reais e retorno.
Se usam o Lambda para isso é provavelmente um erro pq o custo realmente pode ficar absurdo.
Hahahhaha não é bem assim.
Trabalho com sistema monólito
Monolitos
Qual a linguagem, alguém sabe ?