Cookie Consent by Free Privacy Policy Generator 📌 Classificação de Antipadrões em Microsserviços ‐ Parte 01


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


💡 Newskategorie: Programmierung
🔗 Quelle: dev.to

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

Static Badge

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

✍️ 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

✍️ 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

✍️ 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

✍️ 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

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.

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

...

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


📈 111.5 Punkte

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


📈 111.5 Punkte

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


📈 111.5 Punkte

✅ http://www.classificacao.turismo.gov.br/MTUR-classificacao/a.htm


📈 62.43 Punkte

✅ Arquitetura de Microsserviços


📈 28.56 Punkte

✅ 3 dicas para criar uma estratégia moderna de Testes para Microsserviços Spring Boot


📈 28.56 Punkte

✅ Observabilidade de microsserviços com OpenTelemetry e Amazon OpenSearch [Lab Session]


📈 28.56 Punkte

✅ Acelerando o desenvolvimento de microsserviços .NET / C# e Devprime


📈 28.56 Punkte

✅ Segunda parte: Definiciones/Conceptos del día a día


📈 19.09 Punkte

✅ Construindo um web server em Assembly x86, parte I, introdução


📈 19.09 Punkte

✅ Introdução ao Machine Learning (ML de Zero a 100, parte 1)


📈 19.09 Punkte

✅ Do React ao Hotwire - Parte I - [PT-BR]


📈 19.09 Punkte

✅ API completa em Golang - Parte 4


📈 19.09 Punkte

✅ Desvendando o Three-Way Handshake - Parte 1: A Engrenagem Invisível da Comunicação TCP


📈 19.09 Punkte

✅ Compilado dicas de carreira - parte 2


📈 19.09 Punkte

✅ Análise das reservas federais - parte 2


📈 19.09 Punkte

✅ Introducción a C++: parte 4 Funciones


📈 19.09 Punkte

✅ Introdução às redes neurais convolucionais (ML de Zero a 100, parte 3)


📈 19.09 Punkte

✅ Compilado dicas de carreira - parte 3


📈 19.09 Punkte

✅ API completa em Golang - Parte 3


📈 19.09 Punkte

✅ JHipster 8 - Analisando o código da nossa primeira aplicação monolítica - Parte 1/3


📈 19.09 Punkte

✅ Compilado dicas de carreira - parte 1


📈 19.09 Punkte

✅ MAUI - Por onde começar? Parte 1: Entendendo o MAUI


📈 19.09 Punkte

✅ Cebolas e camadas para padrões de projetos no Front-end — Parte I


📈 19.09 Punkte

✅ Percepções sobre análise dos reservatórios parte 1


📈 19.09 Punkte

✅ API completa em Golang - Parte 2


📈 19.09 Punkte

✅ Como foi fazer um decodificador do zero para o projeto final da 1ª parte do OracleONE


📈 19.09 Punkte

✅ Documentação técnica para iniciantes, parte 1: criando um bom README para o seu projeto


📈 19.09 Punkte

✅ Design: Monolitos Modulares - Parte 4


📈 19.09 Punkte

✅ Do React ao Hotwire - Parte II - [PT-BR]


📈 19.09 Punkte

✅ Análise das reservas federais - parte 1


📈 19.09 Punkte

✅ API completa em Golang - Parte 1


📈 19.09 Punkte

✅ Gestión de Entidades DPE (parte 2)


📈 19.09 Punkte

✅ Como instalar Gentoo Linux EFI paso a paso - Parte 1


📈 19.09 Punkte

✅ Documentação em toda parte


📈 19.09 Punkte











matomo

Datei nicht gefunden!