Classificação de Antipadrões em Microsserviços ‐ Parte 02

YAN JUSTINO
MSc. Software Engineering · PhD. Student
AWS · MCSD · OCA · ORCID · Tech Lead at ITAÚ Unibanco

1. CONTEXTO

Olá, Dev! Neste post estamos listando um catálogo de antipadrões associados a implementação de Microsserviços. Esse catálogo contém uma breve descrição de cada antipadrão, os problemas que eles podem causar e as possíveis soluções que podem ser aplicadas para sanar possíveis problemas de design.

Na primeira parte, listamos 5 antipadrões do catálogo de antipadrões de microsserviços apresentado pelos pesquisadores Taibi, D. and Lenarduzzi, V. (2018)[6] e Tighilt at al (2023)[5]. Os antipadrões apresentados foram Wrong Cuts (WC); Cyclic Dependencies (CD); Mega Service (MS); Nano Service (NS); e Shared Librararies (SL).

2. ANTIPADRÕES

Nesta parte 02 apresentaremos os antipadrões Multiple Service Instances Per Host (MSIPH); Shared Persistence (SP); No API Versioning (NAV); No API Gateway (NAG).

PROBLEMAS

• Impacto na autonomia: com o antipadrão MSIPH, a autonomia é comprometida, pois a falha de um serviço no host pode impactar outros serviços compartilhando o mesmo ambiente.
• Impacto na Escala: no contexto do MSIPH, a escalabilidade é afetada, pois escalar um serviço pode exigir mais recursos do host, potencialmente afetando o desempenho de outros serviços que compartilham o mesmo ambiente
• Possíveis conflitos dentro do host: Com múltiplos serviços compartilhando o mesmo host, há um risco aumentado de conflitos de recursos, como uso de CPU, memória e I/O. .

SOLUÇÃO

Para evitar os problemas associados ao MSIPH, é recomendável adotar estratégias como:

• Containerização: Utilizar containers para encapsular cada serviço individualmente, garantindo que eles operem em ambientes isolados mesmo quando implantados na mesma máquina física ou virtual.

• Orquestração de Containers: Usar sistemas de orquestração, como Kubernetes, que gerenciam a implantação, escalonamento e operação de containers de forma eficiente, garantindo que os serviços não interfiram uns com os outros.

• Escalonamento Dinâmico: Implementar políticas de escalonamento automático que permitam que cada serviço escale baseado em suas próprias demandas de recursos, sem afetar outros serviços.

• Monitoramento e Gerenciamento de Recursos: Adotar ferramentas avançadas de monitoramento e gerenciamento de recursos para detectar e mitigar problemas de contenção de recursos rapidamente.

LEITURAS RECOMENDADAS

• Multiple service instances per host
• Microservices Deployment Patterns

PROBLEMAS

• Acoplamento via banco de dados
• Diminuição da autonomia da equipe e do serviço

SOLUÇÃO

Isso antipadrão pode levar a uma série de problemas, principalmente relacionados ao acoplamento e à perda de autonomia, como mecionado. Aqui estão algumas das principais soluções para superar este antipadrão:

• Bancos de Dados Independentes: A solução mais alinhada com os princípios de microsserviços é que cada serviço tenha seu próprio banco de dados, garantindo assim a total autonomia dos dados. Isso reduz o acoplamento e permite que cada equipe seja responsável por sua parte da infraestrutura de dados, facilitando escalabilidade e manutenção.

• Banco Compartilhado com Tabelas Privadas:
  Uma alternativa menos isolada, mas ainda viável, é utilizar um banco de dados compartilhado onde cada serviço tem seu próprio conjunto de tabelas. Essas tabelas não são acessíveis por outros serviços, o que ajuda a manter certo grau de isolamento e controle sobre os dados.

• Uso de Esquemas de Banco de Dados:
  Outra abordagem é o uso de esquemas dentro de um banco de dados compartilhado, onde cada esquema é dedicado a um microsserviço específico. Isso ajuda a manter o isolamento lógico dentro de um mesmo banco de dados físico, facilitando a gestão de permissões e visibilidade de dados.

• Integradores de granularidade:
  Para casos em que a granularidade vá contra a integridade de dados em um processo que deveria ser transacionalmente simples, a equipe pode deliberar sobre a doção de estratégias integradoras de granularidade.

LEITURAS RECOMENDADAS

• Shared-database-per-service pattern
• Shared database

PROBLEMAS

• Complexidade para os Clientes: Sem um API Gateway, os clientes precisam conhecer e gerenciar os pontos de acesso de todos os microsserviços que precisam consumir, aumentando a complexidade do lado do cliente.
• Dificuldades de Autenticação e Autorização: Cada serviço pode precisar implementar seu próprio mecanismo de autenticação e autorização, o que pode levar a inconsistências e brechas de segurança.
• Gestão de Carga e Falhas: Em uma configuração NAG, a lógica para balanceamento de carga e tratamento de falhas pode precisar ser implementada em cada serviço ou no lado do cliente, o que pode complicar o desenvolvimento e a manutenção.
• Versionamento de APIs: Gerenciar diferentes versões de API diretamente nos serviços pode tornar-se problemático, especialmente em um ambiente com muitos serviços que evoluem rapidamente.

SOLUÇÃO

Implementar um API Gateway é uma prática comum em arquiteturas de microsserviços modernas devido às suas vantagens em simplificar a gestão de APIs, segurança, e resiliência. Ferramentas populares para este propósito incluem Kong, Apigee e AWS API Gateway, cada uma oferecendo conjuntos robustos de funcionalidades para lidar com as necessidades complexas de microsserviços em ambientes de produção.

• Implementação de um API Gateway: A solução mais direta para o antipadrão NAG é introduzir um API Gateway na arquitetura. O API Gateway atua como um ponto de entrada único para todas as chamadas de API, simplificando a interação do cliente com os microsserviços.

• Centralização de Autenticação e Autorização: Com um API Gateway, é possível centralizar processos de autenticação e autorização, proporcionando um mecanismo consistente e seguro para controlar o acesso aos serviços.

• Balanceamento de Carga e Resiliência: O API Gateway pode gerenciar o balanceamento de carga e implementar padrões de resiliência, como circuit breakers e retries, para lidar com falhas nos serviços de forma transparente.

• Gestão de Tráfego e Versionamento: O Gateway permite a gestão eficiente do tráfego e facilita a implementação de estratégias de versionamento de API, permitindo que diferentes versões de serviços sejam acessadas sem impactar os clientes existentes.

LEITURAS RECOMENDADAS

• Overcoming the Common Microservices Anti-Patterns
• Using an API Gateway in Your Microservices Architecture

PROBLEMAS

• Mudanças Que Quebram a Compatibilidade: Sem versionamento, qualquer atualização ou modificação pode potencialmente quebrar as aplicações existentes que dependem da API, levando a malfuncionamentos de software e interrupções no serviço.
• Dificuldade na Manutenção: A falta de versionamento torna desafiador manter a compatibilidade com versões anteriores, forçando os clientes a se adaptarem rapidamente às mudanças ou enfrentarem problemas de incompatibilidade.
• Barreiras à Adoção: Novos usuários podem hesitar em adotar a API se perceberem que ela muda frequentemente sem um gerenciamento claro de versões, pois isso pode implicar em custos de manutenção mais altos.

SOLUÇÃO

Abordar o antipadrão NAV é crucial para garantir que as APIs permaneçam robustas, confiáveis e fáceis de usar, melhorando assim a sustentabilidade geral dos sistemas de software. Os itens a seguir podem auxiliar a lidar com os problemas listados anteriormente.

• Implementar Estratégia de Versionamento: Introduza uma estratégia sistemática de versionamento, como o Versionamento Semântico (SemVer), onde as versões são incrementadas com base na natureza das alterações (maior, menor, correção) para comunicar claramente o impacto das atualizações.

• Política de Depreciação de Versões: Estabeleça uma política clara de depreciação para versões antigas, fornecendo aos usuários bastante aviso e orientação sobre a transição para versões mais novas.

• Suportar Múltiplas Versões: Mantenha suporte para múltiplas versões de API simultaneamente para permitir que os usuários façam a transição em seu próprio ritmo sem interromper seus sistemas atuais.

LEITURAS RECOMENDADAS

• A Mixed-Method Approach to Recommend Corrections and Correct REST Antipatterns

REFERÊNCIAS

1. MENDONCA, N. C. et al. The monolith strikes back: Why istio migrated from
   microservices to a monolithic architecture. IEEE Software, Institute of Electrical and
   Electronics Engineers (IEEE), v. 38, n. 5, p. 17–22, set. 2021. ISSN 1937-4194.

2. BOGNER, J. et al. Industry practices and challenges for the evolvability assurance of
   microservices: An interview study and systematic grey literature review. Empirical
   Software Engineering, Springer Science and Business Media LLC, v. 26, n. 5, jul. 2021.

3. FORD, N. Software architecture: The hard parts : modern trade-off analyses for
   distributed architectures. First edition. Cambridge, Massachusetts: The MIT Press, 2021.
   Made available through: Safari, an O’Reilly Media Company. ISBN 1492086843.

4. NEWMAN, S. Building microservices: Designing fine-grained systems. Second edition.
   Beijing: O’Reilly, 2021. ISBN 9781492033998.

5. Tighilt, R., Abdellatif, M., Trabelsi, I., Madern, L., Moha,
   N., and Guéhéneuc, Y.-G. (2023). On the maintenance
   support for microservice-based systems through the
   specification and the detection of microservice antipatterns.
   Journal of Systems and Software, 204:111755. DOI:
   https://doi.org/10.1016/j.jss.2023.111755.

6. Taibi, D. and Lenarduzzi, V. (2018). On the definition of microservice
   bad smells. IEEE Software, 35(3):56–62. DOI:
   10.1109/MS.2018.2141031.

Caros leitores,

Espero que tenham encontrado insights valiosos na discussão sobre a co-localização de arquivos de teste e código de produção, uma prática que pode transformar significativamente o desenvolvimento de software.

Se você já experimentou essa metodologia em seus projetos, como foi? Quais vantagens e obstáculos você encontrou? Se ainda não tentou, consideraria implementá-la após essa leitura?