YAN JUSTINO
MSc. Software Engineering · PhD. Student
AWS · MCSD · OCA · ORCID · Tech Lead at ITAÚ Unibanco
1. CONTEXTO
Microsserviços tornou-se uma prática no design, construção e entrega de serviços de software baseados em Cloud Computing.
Impulsionada por grandes companhias de tecnologia como Amazon, Netflix e Spotify etc, a Arquitetura de Microsserviços tem sido considerada uma abordagem desejada por startups, pequenas empresas e organizações que cresceram na ordem de centenas de engenheiros. A transição para essa abordagem arquitetural é motivada pela crescente necessidade de escala, robustez dos sistemas, diversificação na adoção de tecnologia e aprimoramentos do paralelismo no desenvolvimento de software.
Ao migrar para Microsserviços, empresas têm buscado uma melhor qualidade de Desempenho, Escalabilidade e Manutenibilidade por meio da decomposição e distribuição de seus sistemas monolíticos em partes que são fáceis de compreender e de manter.
Relatos recentes da indústria têm apresentado diversos casos nos quais equipes de desenvolvimento de software conduziram um processo de reengenharia adotando a Arquitetura de Microsserviços como estratégia de modernização de seus sistemas.
Esses casos revelam que equipes que passam por esse difícil processo, precisam definir qual o nível de granularidade consegue administrar, levando em consideração as necessidades específicas do projeto. Esse passo é importante pois, uma vez o sistema migrado, a equipe precisará lidar com uma série de desafios técnicos como a garantia de disponibilidade; operações transacionais em um sistema distribuído; o aumento da latência; a tolerância a falhas de comunicação entre serviços; o controle de versão; a gestão de uma grande quantidade de recursos e automações etc.
Contudo, determinar uma clara definição de fronteiras na concepção de um Microsserviço tem sido apontado como um dos principais desafios por equipes de desenvolvimento. Isso porque, decompor um sistema e tentar definir “corretamente” sua granularidade, além de ser uma tarefa complexa e extremamente contextual, pode impactar diretamente o uso de recursos computacionais e os atributos de qualidade da aplicação. Nesse contexto, e considerando as vastas interpretações possíveis dos conceitos ligados a Microsserviços, é possível que equipes de desenvolvimento modelem ou construam soluções baseando-se em antipadrões (antipatterns – conhecidos e recorrentes problemas de design).
Investigando os processos de migração para Microsserviços e analisando os resultados alcançados, pesquisadores da França e Canadá [5] apresentaram um catálogo de vários antipadrões de microsserviços, construído através de uma revisão sistemática da literatura, que identificou mais 1.195 artigos através de uma consulta nas principais bases de dados científicas. Nessa mesma linha, uma dupla de pesquisadores filandeses [6] coletaram evidências de más práticas entrevistando 72 profissionais com experiência no desenvolvimento de sistemas baseados em microsserviços.
Com base nessas pesquisas, listaremos um catálogo de antipadrões contendo uma breve descrição de cada um deles, as consequências de sua adoção e possíveis soluções que podem ser aplicadas. Dado o número de itens desse catálogo, dividiremos o conteúdo desse artigo em 3 partes. Na parte 01 exploraremos os antipadrões: Wrong Cuts (WC); Cyclic Dependencies (CD); Mega Service (MS); Nano Service (NS); e Shared Librararies (SL).
2. ANTIPADRÕES
✍️ Wrong Cuts (WC)
Equipes de software tendem a priorizar aspectos de runtime (desempenho e escala) e infraestrutura quando segmentam uma capacidade de negócio em serviços. Essa abordagem pode ser precoce e impactar a qualidade do sistema. Nesse contexto, esse antipadrão ocorre quando microsserviços são divididos com base em camadas técnicas (Presentation, Business e Data) em vez de uma divisão por capacidade de negócio.
PROBLEMAS
Separação errada de responsabilidades
Aumento da complexidade na divisão de dados
SOLUÇÃO
A adoção de métodos de modelagem, como Domain-Driven Design (DDD) e Business Capability Analysis, somados a adoção de métodos de avaliação arquitetural, como o Architectural Trade-off Analysis Method (ATAM) são apontados como estratégias para auxiliar às equipes, ainda nas fases iniciais do projeto, na identificação de possíveis fronteiras de negócio e na validação da proposta arquitetural do sistema.
LEITURAS RECOMENDADAS
Para entender os tipos de design e organização do código sugiro a leitura do post Além dos Templates: Uma Crítica Construtiva à Arquitetura Limpa e a Adaptação Pragmática no Design de Software
✍️ Cyclic Dependecies (CD)
Esse antipadrão ocorre quando múltiplos serviços são circularmante co-dependente e não autônomos, o que vai de encontro diretamente a definição de Microsserviço. Isso pode ser detectado pela existência de chamada circulares entre microsserviços. Por exemplo, A chama B, B chama C, e C chama de volta A.
PROBLEMAS
Dificuldades na manutenção
Problemans no reuso e isolamento
SOLUÇÃO
Revisão e refinamento das formas de relação entre serviços e adoção de API Gateway.
LEITURAS RECOMENDADAS
Qual a diferença entre uma Fachada e um API Gateway?
Esse vídeo do José Roberto Araújo da Emergin Code demonstra a Implementanto AGREGAÇÃO em um API GATEWAY usando OCELOT.
✍️ Mega Service (MS)
Esse antipadrão ocorre quando um microsserviço fornece multiplas capacidades de negócio. Um serviço que possui um número excessivo de responsabilidades de negócio deveria ser decomposto.
PROBLEMAS
Dificuldades na manutenção
Alto acoplamento
Orquestração de equipes
Dificuldades de escala
SOLUÇÃO
Reavaliar decomposição funcional do serviço que possui um número excessivo de responsabilidades de negócio.
LEITURAS RECOMENDADAS
Microservices: Decomposição de Aplicações para Implantação e Escalabilidade
Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith.
✍️ Nano Service (NS)
Ao contrário do Mega Service, esse antipadrão resulta de uma decomposição de um sistema em uma granularidade muito fina. Isso pode ocorrer quando uma unica capacidade de negócio requer muitos microsserviços trabalhando juntos.
PROBLEMAS
Dificuldades na manutenção
Explosão no número de componentes
Alta complexidade
SOLUÇÃO
Afim de evitar uma “explosão” no número de componentes no sistema, equipes devem ponderar se novos Microsserviços são de fato necessários. Nesse sentido, equipes podem considerar a adoção de estratégias como Monolitch first aproach ou Coarse-grained Microsserviço. Em caso de gargalos de desempenho em serviços já decompostos, ou em que a adoção de Microsserviço não trouxe os benefícios esperados, a equipe pode deliberar sobre a doção de estratégias integradoras de granularidade [Ford et al., 2021] e seguir por uma abordagem “Monolith Strikes
Back” [Mendonça et al., 2021].
LEITURAS RECOMENDADAS
The Monolith Strikes Back: Why Istio Migrated From Microservices to a Monolithic Architecture
Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%
✍️ Shared Libraries (SL)
Esse antipadrão ocorre quando múltiplos microsserviços compartilham bibliotecas e arquivos e esse compartilhamento quebra a autonomia da equipe, fazendo com que ela dependa de uma única fonte para cumprir sua capacidade de negócio.
PROBLEMAS
Acoplamentos excessivos
Coordenação e dependência entre equipes
Controle de dependências mais rigoroso
SOLUÇÃO
Para obter os benefícios do reuso de software, equipes podem ter que lidar com o compartilhamento software através de monorepos, bibliotecas ou a redundância de código clonados em repositórios distintos. Nesse contexto, equipes devem controlar essa redundância e lidar com a necessidade de uma maior coordenação e dependência entre elas. Uma forma de monitorar esse reuso é a adoção de automações para identificação e quantificar a taxa de crescimento de duplicação de código. Uma possibilidade para lidar com o reuso de software é a extração do código duplicado como um serviço autônomo.
LEITURAS RECOMENDADAS
The “I Was Taught to Share” AntiPattern
REFERÊNCIAS
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.
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.
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.
NEWMAN, S. Building microservices: Designing fine-grained systems. Second edition.
Beijing: O’Reilly, 2021. ISBN 9781492033998.
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.
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.
Continua…
Caros leitores,
Espero que tenham encontrado insights valiosos na discussão sobre microsserviços e práticas que podem transformar significativamente o desenvolvimento de software.
Você já conhecia esses antipadrões? Identificou algum deles em seu projeto? Deixe seu comentário
