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


30

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?


10
Você usa microsserviços quando precisa dos benefícios que eles proporcionam, e esses benefícios superam os custos. Pessoalmente, não vejo por que você precisaria de microsserviços em um aplicativo individual escrito por uma pessoa, a menos que você estivesse ensinando a si mesmo ou tivesse uma perspectiva de longo prazo para um aplicativo maior.
21415 Robert

Respostas:


49

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.


31
Versão TL; DR: adicione complexidade apenas quando resolver os problemas que você realmente possui.
Jpmc26

1
Arquitete-o de maneira que você possa migrar mais facilmente para uma arquitetura de microsserviço posteriormente. Por exemplo, separação de preocupações versus uma grande bola de lama, e será mais fácil manter agora e mais fácil mover partes para serviços separados mais tarde. Você ainda pode ter a divisão de tarefas / domínios inspirada em microsserviços sem fazer chamadas / enviar mensagens para outros serviços.
Ps2goat 5/1018

1
Primeira Lei de Fowler de Objetos Distribuídos: Não
K. Alan Bates

1
Há um terceiro benefício, embora seja igualmente inútil para o OP: se você tiver que construir um sistema distribuído de qualquer maneira e se já tiver ou planeja criar boas ferramentas para o seu sistema distribuído, um microsserviço se integrará mais facilmente a essas ferramentas. e permitir um controle mais refinado em muitos aspectos. Isso pode simplificar a solução de problemas, criação de perfil, teste de integração, rastreamento etc. Mas isso obviamente depende das ferramentas existentes e do suporte à sua arquitetura de microsserviço. Sem esse ecossistema de suporte, os microsserviços são apenas mais complexidade.
Kevin

2
Sim, boa resposta. As pessoas parecem esquecer que os microsserviços realmente acrescentam complexidade - portanto, a menos que eles removam mais complexidade, não vale a pena. E em quase todos os casos, um único desenvolvedor não terá benefícios suficientes para executar o MSA.
Enderland 6/10
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.