Ao desenvolver um sistema sozinho, devo usar microsserviços?

Estou iniciando um novo projeto no trabalho e provavelmente será o único desenvolvedor do projeto, embora um ou dois outros desenvolvedores precisem integrar aplicativos existentes ou scripts simples no projeto principal. O projeto precisa lidar com a ingestão / processamento de dados em massa e em fluxo em pequena escala e a execução de código orientado a eventos e sob demanda. Algumas partes da estrutura serão fortemente vinculadas à CPU e outras poderão ser fortemente vinculadas à E / S; a maioria dos dados deve residir em uma única máquina, mas podemos criar um cluster e conectar VMs para aumentar a energia de computação disponível. Provavelmente, haverá um ou mais aplicativos da Web pequenos que dependem dos serviços fornecidos nessa estrutura principal. A linguagem principal será o Python para praticamente tudo.

Minha pergunta é se devo ou não adotar uma abordagem de microsserviços para um esforço como esse ou me ater a um aplicativo monolítico, já que estarei fazendo a maior parte do desenvolvimento sozinho. Meu pensamento é que os microsserviços (usando Nameko) fornecem uma separação natural entre elementos da estrutura que possuem diferentes modelos de execução (pipelines de dados, aplicativos de lançamento de eventos, sob demanda, aplicativos da web etc.) e uma maneira clara de distribuir a carga de trabalho e comunicação através de múltiplos processos. Minha preocupação é que eu provavelmente acabaria com um cluster Kubernetes para gerenciar (eu estou familiarizado com o Docker, mas ainda relativamente novo para o Kubernetes), vários serviços (rabbitmq, redis etc.) necessários apenas para facilitar a execução do sistema, e potencialmente muitos pequenos pedaços de código para realmente implementar todos os recursos necessários que nós '

Para um projeto com pouco mais que um desenvolvedor, os microsserviços ainda simplificam o desenvolvimento e a manutenção de um sistema complicado como esse? Existem métodos / sistemas / estruturas que eu deveria considerar usar ou reduzir a sobrecarga envolvida na criação do sistema dessa maneira?

Os microsserviços geralmente são indesejáveis ​​porque transformam seu software em um sistema distribuído - e sistemas distribuídos tornam tudo muito mais difícil. Mas uma arquitetura orientada a serviços tem alguns benefícios importantes:

• serviços diferentes podem ser desenvolvidos e implantados independentemente por equipes diferentes
• serviços diferentes podem ser escalados independentemente

Como você será o único desenvolvedor, não precisará da flexibilidade para desenvolver os serviços de forma independente.

Mas você observa que algumas partes podem estar ligadas à CPU. Portanto, pode ser desejável dimensionar aqueles independentemente do restante do aplicativo. Se for esse o caso, isso não significa que você precisa transformar todo o projeto em uma arquitetura de microsserviço. Você só precisa mover essa parte que consome muita CPU para seu próprio serviço e pode manter o restante em um monólito conveniente. É difícil dizer ao longo de quais linhas o sistema deve ser dividido, mas, em geral, a idéia do DDD de "contextos limitados" é uma boa orientação.

Observe que os monólitos não são ruins. Monólitos não são iguais a um projeto imenso e desorganizado. Onde você pode dividir o sistema em diferentes microsserviços, também é possível dividir o sistema em diferentes componentes dentro de um monólito. A separação entre esses componentes é apenas mais visível e mais claramente aplicada em uma arquitetura orientada a serviços. Isso também significa que, para um sistema bem projetado, deve ser bastante fácil transformar um componente em um serviço em algum momento posterior. Portanto, você não precisa decidir agora, pode migrar para microsserviços se e quando um monólito se provar inadequado.

Considere também o conceito de Martin Fowler do Microservice Premium (2015): os microsserviços introduzem uma complexidade substancial própria, além da complexidade básica do seu sistema. Você precisa pagar esse "prêmio" em termos de produtividade reduzida. Isso significa que, para projetos simples, os microsserviços tornam você menos produtivo. Isso muda para projetos mais complexos: enquanto uma solução monolítica pode se tornar cada vez mais difícil de trabalhar, uma arquitetura de microsserviços aumenta muito melhor e requer um esforço aproximadamente constante. Você precisa saber se o esforço inicial extra dos microsserviços vale a pena, considerando o seu sistema de software. Como você está fazendo essa pergunta, a resposta provavelmente é "não". Fowler continua:

Portanto, minha principal orientação seria nem considerar microsserviços, a menos que você tenha um sistema complexo demais para gerenciar como monólito. A maioria dos sistemas de software deve ser construída como um único aplicativo monolítico. Preste atenção à boa modularidade dentro desse monólito, mas não tente separá-lo em serviços separados.