Microsserviços na implementação do Docker

Estamos escrevendo nossos primeiros microsserviços usando contêineres Docker usando o fargate da Amazon. Temos muitas dúvidas sobre o nível de implementação usando o Spring Boot

Teremos vários microsserviços no projeto. É uma boa prática escrevermos todos os microsserviços em um único contêiner ou preciso criar um contêiner Docker separado para microsserviços separados. De uma maneira econômica, usamos contêiner único, mas isso causa problemas para a estrutura do nosso projeto no futuro?

Planejamos implantar o aplicativo no AWS fargate e nosso aplicativo terá uma grande opção de extensão no futuro, esperando entre 100 e 150 microsserviços diferentes. Nesse caso, é rentável se estivermos carregando todos esses microsserviços em contêineres diferentes também?

O mais importante a ser lembrado com os microsserviços é que não se trata principalmente de solucionar problemas técnicos, mas de problemas organizacionais. Portanto, quando analisamos se uma organização deve usar microsserviços e como esses serviços são implantados, precisamos verificar se a organização tem os problemas que o estilo dos microsserviços resolve.

A resposta para sua pergunta sobre sua arquitetura, portanto, dependerá principalmente do tamanho da sua equipe de tecnologia, da estrutura organizacional, da idade do seu produto, de suas práticas atuais de implantação e de como elas provavelmente mudarão no médio prazo.

Como exemplo, se sua organização:

• tem menos de 25 funcionários técnicos,
• organizado em 1 ou 2 equipes,
• cada um dos quais funciona em qualquer parte do produto,
• com menos de 12 meses,
• e é implantado todos de uma vez regularmente (por exemplo, diariamente, semanalmente, mensalmente),
• e a organização não está prestes a crescer rapidamente,

então você quase definitivamente deseja esquecer os microsserviços por enquanto. Em uma situação como essa, a equipe ainda é nova em aprender sobre o domínio, portanto, provavelmente não sabe tudo o que precisa saber para realmente entender qual seria uma ótima maneira de dividir o sistema em uma arquitetura distribuída. Isso significa que se eles dividirem agora, provavelmente vão querer mudar os limites mais tarde, e isso se torna muito caro quando você já possui um sistema distribuído, sendo muito mais simples em um monólito. Além disso, com apenas uma equipe pequena que pode trabalhar (e dar suporte) a qualquer parte do sistema, há poucas razões para investir na construção de uma plataforma na qual equipes individuais podem implantar e manter serviços individuais. Uma organização nesse estágio normalmente estará muito mais preocupada em encontrar clientes e iterar o produto rapidamente, talvez até girando o produto, em vez de tornar as equipes autônomas e construir uma arquitetura resiliente e de alto escalonamento. Uma arquitetura monolítica faz sentido neste momento, mas ummonólito bem projetado , com limites claros de componentes aplicados pelas APIs e acesso a dados encapsulados, facilitando a retirada de serviços em processos separados posteriormente.

Vamos analisar um pouco mais e considerar uma organização que é ...

• mais de 50 funcionários técnicos,
• organizado em 7 equipes,
• cada um dos quais funciona apenas em áreas específicas do produto,
• que tem 3 anos,
• e tem equipes que desejam implantar seu trabalho independentemente do que outras equipes estão fazendo.

Essa organização definitivamente deveria estar construindo uma arquitetura distribuída. Se não o fizerem, e todas essas equipes estiverem trabalhando em um monólito, enfrentarão todos os tipos de problemas organizacionais, com as equipes precisando coordenar seu trabalho, as liberações sendo adiadas enquanto a equipe termina o controle de qualidade em seu novo recurso, patch implanta ser um grande aborrecimento para funcionários e clientes. Além disso, com um produto maduro, a organização deve saber o suficiente sobre o domínio para poder dividir sensivelmente o domínio e as equipes (nessa ordem; veja a Lei de Conway) em unidades autônomas e sensatas que podem progredir enquanto minimizam a coordenação.

Parece que você já escolheu microsserviços. Dependendo de onde você está sentado na balança acima, talvez você queira revisar essa decisão.

Se você deseja continuar desenvolvendo com microsserviços, mas implantando todos em um contêiner, saiba que não há nada de errado nisso.se for adequado ao modo como sua organização trabalha no momento. Isso causará problemas para a estrutura do seu projeto no futuro? Bem, se você for bem-sucedido e sua organização crescer, provavelmente chegará um momento em que essa implantação em um único contêiner não será mais a melhor opção, especialmente quando as equipes começarão a possuir serviços e desejarem implantar apenas seus serviços sem implantar todo o aplicativo . Mas essa autonomia terá um custo extra de trabalho e complexidade, e pode não lhe trazer benefícios neste momento. Só porque não será a abordagem correta para o seu sistema no futuro, não significa que não seja a abordagem correta para hoje. O truque é ficar de olho nisso e saber quando fazer o investimento extra.

Não há problema se você estiver usando um contêiner único para seus microsserviços, mas o principal objetivo dos microsserviços é manter cada serviço separadamente, cada serviço deve ser fracamente acoplado e cada serviço deve ter banco de dados separado (se você deseja obter banco de dados por arquitetura de serviço). Portanto, tente fazer isso executar seus serviços em um contêiner separado e orquestrá-los com o docker swarm ou o Kubernetes. Sei que os custos são importantes, mas se você fizer isso da maneira correta, verá o poder da arquitetura de microsserviços.