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.
1
3
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.
1
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.
3
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.