Microservice Chassis
Spring Boot e Spring Cloud
Preocupações Transversais
Cada microsserviço precisa de diversas funcionalidades comuns para rodar corretamente em produção. Essas funcionalidades não pertencem ao domínio do negócio, mas são essenciais para operação, observabilidade, segurança e suporte.
Essas funcionalidades são chamadas de Cross-Cutting Concerns, pois atravessam todos os microsserviços da arquitetura, independentemente de sua responsabilidade de negócio.
Elas incluem, por exemplo, controle de configuração, logging, métricas, monitoramento, health check, segurança e lógica de build.
O diagrama com três microsserviços independentes, cada um contendo internamente:
Lógica de negócio
Lógica de build
Preocupações transversais
Embora os serviços resolvam problemas de negócio diferentes, todos acabam implementando as mesmas responsabilidades técnicas internas.
Não agregam valor ao negócio
reocupações transversais e lógica de build são necessárias, mas não entregam valor direto ao negócio. Elas existem para viabilizar o funcionamento do serviço em produção, não para diferenciar funcionalidades do sistema.
Quando cada microsserviço trata essas responsabilidades de forma isolada, surgem duplicações, inconsistências e aumento do custo operacional. O esforço técnico cresce sem impacto proporcional na entrega de valor.
O conceito de Chassi
O conceito de chassi surge para resolver esse problema. A proposta é concentrar e padronizar tudo aquilo que não pertence ao domínio do negócio, mas que é necessário para todos os microsserviços.
Um único chassi reduz duplicidade, melhora a consistência técnica e otimiza custos. Os times deixam de resolver repetidamente os mesmos problemas estruturais e passam a focar no que realmente importa.
Um único chassi otimiza os custos e padroniza
Microservice Chassis Pattern
O Microservice Chassis Pattern formaliza essa abordagem.
Nesse modelo, as preocupações transversais e a lógica de build padrão são extraídas dos microsserviços e disponibilizadas por meio de um chassi comum, geralmente distribuído como biblioteca ou dependência compartilhada.
Os microsserviços continuam responsáveis pela sua lógica de negócio, mas passam a incorporar funcionalidades técnicas de forma padronizada, com menor acoplamento operacional e maior previsibilidade arquitetural.
O diagrama representa um chassi central contendo lógica de build padrão e preocupações transversais comuns. Três microsserviços dependem desse chassi e incorporam essas funcionalidades de forma consistente, mantendo apenas suas particularidades de negócio e eventuais customizações específicas.
Spring Boot e Spring Cloud como Chassis
Sob essa ótica, Spring Boot e Spring Cloud podem ser encarados como um Microservice Chassis.
Esse ecossistema resolve nativamente diversas preocupações transversais comuns em arquiteturas de microsserviços, oferecendo uma base sólida e amplamente adotada para construção de serviços produtivos.
Mais do que frameworks, eles funcionam como uma fundação técnica que impõe padrões e boas práticas de maneira consistente.
Trade-offs
A adoção de um chassi traz ganhos relevantes, mas também impõe restrições.
Existe maior dependência estrutural: mudanças no chassi impactam múltiplos microsserviços. A evolução precisa ser controlada, versionada e bem governada.
Os times perdem liberdade para decisões técnicas individuais, mas em troca ganham padronização, previsibilidade e menor custo de manutenção.
Em ambientes pequenos, a adoção de um chassi pode representar complexidade desnecessária. Ele se justifica principalmente quando o custo da repetição começa a comprometer a escala.
Consideração final
O Microservice Chassis Pattern não é uma solução de curto prazo. Ele emerge naturalmente conforme a arquitetura cresce.
Em ambientes com múltiplos microsserviços e equipes, a ausência de um chassi resulta em desgaste técnico progressivo.
Arquitetura madura não busca inovação constante. Busca estabilidade, disciplina e capacidade de evoluir sem atrito.
Last updated