Conversando em um coletivo de amigos, emergiu uma perspectiva pragmática que comenta essa jornada de desenvolvimento de software.

No desenvolvimento de software, profissionais debatem se iniciar com um monolito ou microsserviços, impactando complexidade, custos e agilidade. Uma visão pragmática recomenda uma jornada de desenvolvimento evolutiva.

O Ponto de Partida: Monolito

O consenso geral favorece começar o desenvolvimento com uma arquitetura monolítica, devido à sua simplicidade, custo inicial mais baixo e facilidade de manutenção. Um monolito integra todos os componentes do software, facilitando testes e desenvolvimento, o que é ideal para startups e projetos nas fases iniciais.

A Transição: De Monolito para Microsserviços

Conforme a aplicação expande em usuários, funcionalidades ou equipe, as restrições do monolito surgem, sugerindo a mudança para microsserviços, que promovem escalabilidade e desenvolvimento modular independente, facilitando a gestão de grandes equipes e necessidades de escalabilidade.

Observamos alguns pontos de restrição:

• Escalabilidade Limitada
• Acoplamento Forte
• Tempo de Implantação Prolongado
• Dificuldade na implementação de novas tecnologias
• Comlpexidade do código
• Limitação na Disponibilidade
• Desafios na escalabilidade do time
• Testes complicados
• Problemas de desempenho
• Gerenciamento de dependencias
• Atualizações de segurança podem ser uma dor de cabeça

A Decisão por Microsserviços: Quando e Por quê?

A transição para microsserviços deve ser motivada por necessidades específicas, como escalabilidade e trabalho de múltiplas equipes em diferentes seções do projeto, que um monolito não atende bem. É crucial considerar os custos extras e a complexidade adicional em infraestrutura e manutenção.

Práticas para uma Transição Suave

Uso de Containers: Adote Docker e Kubernetes para desenvolver, testar e implantar partes da aplicação de forma independente, alinhando a operação do monolito à dos microsserviços.

APIs Restful: Utilize APIs Restful para separação lógica e comunicação entre partes do sistema, facilitando a adaptação para serviços distintos.

Separação de Dados: Organize o banco de dados por serviço para minimizar o acoplamento e facilitar a migração para microsserviços.

Design Orientado ao Domínio: Aplique princípios de DDD para organizar o código modularmente e definir limites para futuros serviços.

Comunicação Baseada em Eventos: Integre filas e mensageria para uma comunicação assíncrona e desacoplada, preparando para a arquitetura de microsserviços e facilitando a transição com um acoplamento frouxo.

O Veredicto: Uma Abordagem Evolutiva

A abordagem evolutiva é ideal na arquitetura de software. Começar com um monolito ajuda startups e projetos iniciais a serem ágeis e a minimizar custos. Com o crescimento, pode-se considerar a mudança para microsserviços conforme as necessidades específicas, mas se atenha à necessidade do resultando, não à satisfações pessoais ou do time. Muito cuidado com o Hype, um bom meio de provar os Hypes e satisfazer a necessidade do time é aplicar pocs baseados nos interesses pessoais do time, é um bom meio de reciclar energia e motivar.

Para desenvolvedores experientes, preparar o terreno para essa possível transição, mesmo enquanto trabalham em um monolito, é uma estratégia astuta. Isso não apenas facilita uma futura migração para microsserviços, como também instila boas práticas de desenvolvimento desde o início.