Oi pessoal, escrevi um artigo agregando um pouco dos meus estudos recentes sobre arquitetura de microserviços e como nas minhas experiências tenho notado um pouco do abuso da arquitetura.
https://berilo.dev/porque-nao-usar-microservicos-para-todos-desafios
O único problema nisso é que você disse que é um pouco abusado. É muito abusado. O resto está de parabéns.
A vantagem da fácil escalabilidade esconde a dificuldade da distribuição, que é imensa, e as pessoas não percebem isso ou aceitam vários problemas. Vi alguns casos que não dá problema, mas a pessoa nem estava usando a arquitetura, discursava sobre algo que ela conhecia tão pouco que fez outra coisa. Tem como escalar o monolito bem. Que o diga o Stack Overflow que chegou estar entre os 30 sites mais acessados do mundo e consegue atender tudo isso com muita folga no servidor.
As outras vantagens citadas também podem ser obtidas com arquitetura monolítica, e de forma geral, da mesma forma. Mesmo outras vantagens não citadas só mudam um pouco a forma.
Arquitetura monolítica não é o mesmo que executável monolítico. Assim como usar um microsserviço (que pode ser útil aqui e ali em muitas aplicações), não é o mesmo que arquitetura de microsserviços.
Tem gente dizendo que faz isso em desenvolvimento solo. Isso é insano. O problema é que todo mundo quer aprender porque está na moda. E dpois vai querer apllicar. E colocar no currículo que já fez, mesmo que seja um porcaria e só trouxe prejuízos. É uma moda como tantas outras, as pessoas fazem porque outras estão fazendo e falando sobre, não porque precisam, porque é a melhor escolha.
Se o Instagram ou a Wikipedia não precisam, por que você precisa?
Todos os relatos de sucesso de microsserviços são subjetivos e sem dados reais que mostrem que vale a pena. Até por ser difícil comprovar isso.
Não estou dizendo que nunca deva usar, mas são raros os projetos que são interessantes de fato. As pessoas deveriam gastar o tempo em coisas mais produtivas, até mesmo a aprender programar certo. Tem gente que precisa dessa arquitetura pela tragédia que faz. E vai sugando dinheiro. Eu já peguei um sistema que levava mais de 3 meses para fazer um processamento e eu reduzi para alguns poucos minutos. E demorei 2 dias para fazer isso, a maior parte do tempo para entender a bobagem. Tá cheio de sistema assim, e o cara quebra em vários para conseguir responder em horas, através de dezenas de máquinas, em vez de usar uma em minutos, sabendo programar.
As pessoas sempre vão achar uma desculpa para "justificar" porque o caso delas é especial e precisa de arquitetura de microsserviços. É disso que eu estou falando. Ela fz isso porque ouve os relatos da moda em vez de estudar a computação e tomar a decisão certa.
Faz sentido para você?
Espero ter ajudado.
Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente. Para saber quando, me segue nas suas plataformas preferidas. Quase não as uso, não terá infindas notificações (links aqui).
Outro ponto eh a propria organizacao dos times, provavelmente quando vc esta numa startup voce nao tem muitos times (muitos casos o conceito de time ainda nao foi nem criado kk). Se voce tem varios microservicos e poucos devs/times para trabalhar neles, acaba gerando pra eles uma troca de contexto complicada que vai reduzir a produtividade do time que vai acabar gerando outros problemas.
Adorei o título "Cosplay de Big Tech", só ele diz muita coisa e não apenas sobre microserviços.
Quando li o título do post, a primeira coisa que me veio à mente foi exatamente essa decisão da Prime de transformar tudo em um monólito. É bastante comum observar empresas de pequeno porte adotando arquiteturas e tecnologias que normalmente são utilizadas por empresas gigantes, muitas vezes sem uma real necessidade para tal abordagem.
Concordo contigo, mas vou dar uma de advogado do diabo porque arquitetura é algo que gosto bastante.
Pensa pelo seguinte ponto, empresas que não continuam em crescimento simplesmente minguam e acabam por deixar de existir, tanto as grandes como as pequenas. Caso a empresa realmente tenha o objetivo de ser tornar uma gigante do mercado que ela ocupa não faria sentido começar a se preparar para tal ? tipo ok, não precisa estar com 100% do teu sistema distribuido em microserviços, mas uma parte o outra e ja deixando pronto pra que consiga fragmentar sem grandes custos.
Também concordo com o Berilo e em partes contigo.
Faz sentido o que comentou, porém quando uma pequena empresa ainda não tem um produto ela precisa dele o mais rápido possível para vender. Fora que muitas não tem muita verba para investir no desenvolvimento no ínicio, então ao adotar uma arquitetura mais simples ganhamos em tempo e em orçamento como o artigo do Berilo deixa claro. O know-how da empresa nesse momento também será maior sobre o produto e o que precisa ser feito e isso irá guiar devs/arquitetos nos requisitos corretos. Digo isso pois estou vivendo o que o Berilo comenta no artigo rsrs.
Sim, acho que o artigo esta completamente correto. O que eu fiz foi apenas um parentese no assunto(partindo do pressuposto de que talvez não houvesse de errado em começar de forma parcialmente fragmentada).Mas fica nisso apenas um parentese do assunto.
Inicie com modéstia, progrida de maneira gradual e, acima de tudo, proporcione valor. Se o crescimento se tornar uma realidade, nesse momento, aprimorar sua infraestrutura será fundamental.
Já tive a oportunidade de vi alguns projetos que se estenderam por meses (mais de 6), devido à construção de arquiteturas ambiciosas (que podem se transformar em pesadelos quando mal executadas). No entanto, ao final, o produto não prosperava não por conta da tecnologia, mas porque não solucionava eficazmente um problema.
Ter investido em um MVP monolítico apenas para validar a ideia e testar a adesão dos clientes teria poupado uma quantidade significativa de tempo e recursos. A célebre máxima "é melhor errar rápido e corrigir, do que planejar para o futuro, investir enormes quantias de dinheiro e não obter sucesso quando estiver pronto."
Acontece casos até do sistema ir para frente (ter adesão de clientes) mas não ter volumes de acesso absurdo, necessidade de SLA altos para justificar usar microserviços.
Não estou dizendo que sou contra, mas já vi mais casos de falhas do que sucesso.