Eu tenho um problema. Vamos usar microsserviços! Agora eu tenho 13 problemas distribuídos.
Dividir seu sistema em componentes encapsulados, coesos e dissociados é uma boa idéia. Ele permite que você lide com diferentes problemas separadamente. Mas você pode fazer isso perfeitamente bem em uma implantação monolítica (consulte Fowler: Microservice Premium ). Afinal, é isso que a OOP ensina há muitas décadas! Se você decidir transformar seus componentes em microsserviços, não terá nenhuma vantagem arquitetural. Você ganha alguma flexibilidade em relação à escolha de tecnologia e, possivelmente (mas não necessariamente!), Alguma escalabilidade. Mas você tem uma certa dor de cabeça decorrente da (a) natureza distribuída do sistema e (b) da comunicação entre os componentes. Escolher microsserviços significa que você tem outros problemas tão urgentes que deseja usar os microsserviços, apesar desses problemas.
Se você não conseguir projetar um monólito que esteja claramente dividido em componentes, também não poderá projetar um sistema de microsserviço. Em uma base de código monolítica, a dor será bastante óbvia. Idealmente, o código simplesmente não será compilado se estiver terrivelmente quebrado. Mas com microsserviços, cada serviço pode ser desenvolvido separadamente, possivelmente até em idiomas diferentes. Quaisquer problemas na interação dos componentes não serão evidentes até você integrar seus componentes e, nesse ponto, já é tarde demais para corrigir a arquitetura geral.
A fonte número 1 de erros é a incompatibilidade de interface. Pode haver erros flagrantes, como um parâmetro ausente, ou exemplos mais sutis, como esquecer de verificar um código de erro ou esquecer de verificar uma pré-condição antes de chamar um método. A digitação estática detecta esses problemas o mais cedo possível: no seu IDE e no compilador, antes que o código seja executado. Os sistemas dinâmicos não têm esse luxo. Ele não explodirá até que esse código com defeito seja executado.
As implicações para os microsserviços são aterradoras. Os microsserviços são inerentemente dinâmicos. A menos que você mude para um idioma formal de descrição de serviço, não poderá verificar nenhum tipo de correção do uso da interface. você tem que testar, testar, testar! Mas os testes são caros e geralmente não exaustivos, o que deixa a possibilidade de que ainda possam existir problemas na produção. Quando esse problema se tornará aparente? Somente quando esse caminho defeituoso é percorrido, em tempo de execução, na produção. A noção de que questões de produtos levariam a um feedback mais rápido éhilariamente perigosamente errado, a menos que você se divirta com a possibilidade de perda de dados.