Sempre que tiver uma conversa com uma IA potencialmente estará prestes a tomar uma das piores decisões. Infelizmente algumas pessoas já não conseguem ter essa ideia e aceitam como verdade que a IA sabe alguma coisa corretamente. Ela é só baseada em estatísticas com uma dose de aleatoriedade para não parecer mecânico demais e por isso ela só falará o que é mais falado na internet, ou seja, se o erro for muito falso é ele que você obterá. A IA não achará nada que não está presente na internet ou que esteja relativamente "escondido". Por isso é um método investigativo falho. Não quer dizer que ela não dará algum resultado e pode prestar para alguma coisa, mas o fato de poder ser falho e as pessoas acreditarem que não é um enorme problema.

Claro, muitos humanos fariam pior, mas ainda não é desculpa. Obviamente que ela serve de ajuda, mas poucas pessoas sabem como usar de forma adequada, inclusive eu não sei, mesmo tendo esse pensamento bastante questionador.

A definição sobre microsserviços está errada, começando pelo título. Não é necessário microsserviços para alcançar nada daquilo e ele pode não alcançar qualquer uma dessas coisas se feito errado, embora ainda seja microsserviços.

Também não é verdade o que se fala sobre monólitos, sabendo fazer ele escala do jeito que precisa e temos diversas provas disso. Não conheço e já procurei bastante, parece não haver nenhuma prova que qualquer aplicação precisa de microsserviços para escalar, embora alguma pode ser um pouco mais fácil (pagando o preço geral para ter algo tão complexo, também precisaria de uma prova que os problemas compensam os benefícios).

As pessoas confundem arquitetura monolítica com executável monolítico, o que em algumas tecnologias nem faz sentido.

Da mesma forma que podemos separar funções em um monólito, podemos escalar só as que queremos.

Está correto os problemas sobre microsserviços, ainda que não seja completo.

Microsserviços nunca foi sobre tamanho, então ele ser pequeno ou grande não muda nada.

DDD pode ajudar ou atrapalhar a execução de uma aplicação, já vi muitos casos de terror adotando essa técnica e a verdade é que se feito como manda o manualzinho praticamente já temos microsserviços, ainda que funcione de forma mais monolítica. Inclusive um dos problemas é que as pessoas não sabem onde achar a borda do contexto, especialmente quando eles se interseccionam.

A tabela sobre microsserviços da Netflix são megaserviços. Ok, pode ser só para ilustrar que deveriam ter menos. Mas aí é que está não é assim que se define contextos, não se pode olhar para o tamanho.

A tentativa de fazer menos serviços conseguirá o pior dos dois mundos.

Tudo isso mostra que o foco está sendo em usar uma tecnologia complexa sem se preocupar com o valor que isso apresenta, algo que quase todo mundo faz quando pensa em microsserviços. Em vez de fazer o simples até que se prove que tem um motivo para fazer diferente.

Quando se faz isso quase sempre, para não dizer sempre, até porque até os grandes que usam microsserviços provavelmente não precisam disso, e alguns dão mostram que estão pagando um preço alto pela escolha errada há 10 anos, outros até estão voltando atrás, o monólito é muito melhor por diversas razões.

Mas é claro que algum ponto pode se tornar uma dificuldade e aí nesse ponto específico pode-se fazer um serviço separado. Note que não importa o tamanho dele, e a arquitetura não é de microsserviços, apenas que esse ponto você precisa de algo completamente desacoplado como se fosse uma outra empresa sem comunicação fácil com o resto trabalhando nisso, assim podem fazer o deploy do jeito que quiserem, usar a tecnologia que acharem mais adequada, escalar de forma diferente ou fpenas fazer bico para os demais que mexer no sistema.

A IA só consolidará mais o erro, validará quem precisa disso mesmo quando for algo errado, só dará argumentos falhos para quem não entende oque está fazendo e criar seu próprio conhecimento, o que tornará a vida difícil para quem entende. Vamos viver épocas bem complicadas.

Microsserviços já é aceito por cada vez mais pessoas, até os primeiros proponentes, embora esteja longe de aceitação total, como algo apenas para se adequar à lei de Conway quando a empresa já é micro equipes com independência total.

Outra coisa que passa batido é que só faz sentido em equipes de pelo menos centenas de pessoas, o que é bem raro.

E essa coisa de meio termo pode ser o pior de tão artificial que é.

A tabela tem informações inventadas, algumas eu já falei como a ideia que monólito só escala tudo. Não é algo matemático que você só faz a média e tá tudo certo.

A curva de aprendizado do tal do "macro" é essencialmente igual ao do micro, e mesmo monólito bem feito, se for muito grande também não é tão fácil assim, ele é mais fácil de manter. Em ado momento ter 10 ou 100 dá quase na mesma, até mesmo pode ser 2. Ter 1 é diferente, tem seus custos e benefícios.

Monólito não precisa falhar tudo, tem diversas técnicas, algumas até mais simples para resolver isso. Essas visões são de pessoas que não entendem a computação, que aprenderam com blogs e vídeos de Youtube. Uma das coisas que eu mais vejo acontecer é microsserviços falhar, porque existem duas formas de fazer isso, uma delas faz haver falhas em cascata e a outra é de extrema ineficiência, na prática você não tem microsserviços, você tem um monte de "pequenas" aplicações completas.

Só é difícil dividir equipe por responsabilidade por incompetência gerencial, o que vai dar na mesma ou pior quando separa de forma mais forte, inclusive porque passa ter que lidar com egos mais inflados pela independência que receberam. De qualquer forma cada caso é um caso. Pode ser sim ser a melhor solução, mas depende do caso concreto.

Não é verdade que monólito só pode usar uma stack, embora tenha limitações no que pode flexibilizar, e novamente, se uma parte precisa de algo diferente, dá para fazer só isso. Separar para todo mundo usar coisas diferentes não resolve problema real algum, pelo contrário, traz problema novo.

Não há nenhuma informação que indique que microsserviços são mais rápidos de dar manutenção. Minha observação é a oposta. Ele começa criar uma quantidade monstruosa de dívida técnica.

E o pior, para saber de tudo isso precisa de uma experiência que ninguém tem.

Ah, existe uma diferença entre fazer uma arquitetura de microsserviços e ter várias aplicações. Nunca fez sentido ter uma única aplicação dentro de uma empresa.

Eu tenho experiência com monólitos rodando em milhares de empresas em ambientes enormes e não é como alguns vendem, funciona muito bem e não a tragédia que manter e escalar como dizem, inclusive quando tem muita gente ruim na equipe. Eu nunca vi um sistema em microsserviços funcionando maravilhosamente como alguns dizem. Eu jamais vou trocar o certo pelo incerto, isso não é engenharia.

O final é o que tem de melhor no texto, pena que muitos vão achar uma justificativa falsa para dividir o que não precisa, já vi uma quantidade inacreditável assim.

Uma das maiores justificativas que eu recebo para as pessoas irem para microsserviços, que é computação distribuída, considerada por muitos o problema mais difícil de se resolver, é que elas não possuem bons profissionais, como o pessoal do Instagram, Shopify, Wikipedia e Stack Overflow tem. Ora, se não tem gente boa para fazer monólito, para microsserviço é pior ainda, só que mesmo que fique uma porcaria, vai aos trancos e barrancos, vai botando hardware, vai aumentando a equipe como um todo. Isso não é só incompetência é mau-caratismo.

Uma das coisas que eu, exagerando, falo quase como um axioma, é que quem adota microsserviços é sempre aquela que não entende ele. Ou seja, desastre à frente.

Eu acho que estou aprendendo alguns cenários que microsserviços parciais podem ser realmente muito úteis e pode trazer mais vantagem que prejuízo, mas não é da forma que a maioria usa. Um dia talvez eu formalize, quem sabe execute e coloque em público.

S2

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui no perfil também).