Dust in the wind: um modelo de espectro de granularidade em Microsserviços

Considerando as particularidades contextuais de cada projeto e a vasta interpretação dos conceitos ligados a Microsserviços, é possível que desenvolvedores, ao migrarem seus sistemas, não consigam identificar de forma precisa o tamanho e o escopo de cada serviço. Nesse contexto, a equipe pode ser induzida a construir componentes excessivamente pequenos, implementando uma granularidade muito fina. Para Sam Newman, à medida que houver mais serviços, a granularidade pode se tornar inadequada, elevando a complexidade global, dificultando o trabalho paralelo dos desenvolvedores e aumentando o esforço necessário para manutenção do sistema.

De certa forma, a granularidade de um Microsserviço é resultado de um certo paradoxo: ao segmentar em partes um sistema e lhes conferir ampla independência para mantê-los isolados uns dos outros, se faz necessário a adição de funcionalidades extras na camada de infraestrutura para criar mecanismos de comunicação. Essa ambiguidade pode ser um reflexo da dificuldade em determinar a granularidade adequada para um Microsserviço.

Pesquisas na área de engenharia de software (ver referências) afirmam que obter uma clara definição de tamanho e escopo tem sido um dos grandes desafios no design e construção de Microsserviços: não existem acordos sobre o tamanho correto; e o que venha ser uma granularidade “adequada”, demonstra-se um tópico em construção, no qual existem poucos padrões, métodos, modelos e ferramentas para auxiliar equipes de desenvolvimento na definição de quão granular um Microsserviço deve ser.

Talvez um ponto de partida para lidar com essa complexidade seja aceitar que cada implementação é contextual e que a granularidade deve ser pensada estratégicamente, visando os aspectos necessários de qualidade sob os quais o sistema deve operar. Essa visão estratégica passa pela compreensão dos possíveis tipos de organização no espectro de granularidades que existem em uma arquitetura orientada a serviços. Nesse sentido, esse post propõe um modelo de espectro de granularidade de serviços. Para isso, abordaremos primeiramente os conceitos de Funcionalidade e Capacidade de Negócio, em seguida ilustraremos e detalharemos o modelo proposto.

Esse modelo proposto de espectro de granularidade é fruto de leituras recentes e da compilação de uma série de artigos especializados no tema de Microsserviços.

Funcionalidade & Capacidade de Negócio

No contexto de arquitetura de Microsserviços, “Funcionalidade” (FUNCTIONALITY) e “Capacidade” (CAPABILITY) podem parecer sinônimos em muitos casos, mas há nuances que podem diferenciá-los dependendo do nível de abstração e da perspectiva adotada:

Funcionalidade

Refere-se a uma tarefa ou ação específica que um serviço ou componente executa. Foca em “o que” o serviço faz. Por exemplo, a funcionalidade de processar um pagamento, a funcionalidade de adicionar um item ao carrinho de compras.

Capacidade de Negócio

Refere-se a um conjunto de funcionalidades que juntas oferecem uma capacidade completa e autônoma de negócio. Foca em “o que” o serviço pode alcançar em termos de valor de negócio. Por exemplo, a capacidade de gerenciar pedidos inclui funcionalidades como adicionar itens ao carrinho, processar pagamentos, calcular frete, e confirmar o pedido.

Comparação e Diferenças

Comparação	Funcionalidade	Capacidade de Negócio
Nível de Abstração	Geralmente mais granular e específica. Pode ser considerada uma unidade menor de uma capacidade.	Geralmente mais ampla e de maior nível. Pode englobar várias funcionalidades que juntas fornecem um valor de negócio completo.
Perspectiva de Negócio vs. Técnica	Pode ser vista mais do ponto de vista técnico, descrevendo ações específicas que o sistema executa.	Pode ser vista mais do ponto de vista de negócio, descrevendo o que a organização é capaz de realizar com suas tecnologias e processos.
Escopo	Limitada a ações específicas e detalhadas.	Abrange um conjunto mais amplo de ações e resultados de negócio.

Exemplo no Contexto de E-commerce:

• Funcionalidade:

  • Calcular imposto sobre vendas
  • Atualizar o status do pedido
  • Gerar fatura

• Capacidade de Negócio:

  • Processamento de Pedidos: Inclui funcionalidades de calcular impostos, atualizar status do pedido, gerar fatura, validar métodos de pagamento etc.

Embora “Funcionalidade” e “Capacidade de Negócio” possam ser usados de forma intercambiável em alguns contextos, entender as diferenças em termos de escopo e perspectiva pode ajudar a desenhar e organizar melhor os serviços dentro de uma arquitetura de microsserviços. A Capacidade geralmente é uma agregação de várias Funcionalidades, fornecendo um valor de negócio completo e autônomo.

Espectro de Granularidade

Para entender a granularidade dos microsserviços, podemos traçar um espectro que vai dos serviços menos granulares (COARSE-GRAINED) ao mais granulares (FINE-GRAINED).

Figura 1. Modelo de espectro de granularidade (própria)

A Figura 1. ilustra uma estrutura hierárquica de componentes de software, começando pela fronteira do domínio até chegar às tasks. Na primeira parte do diagrama, temos a fronteira do domínio (BOUNDARY), que contém diversas capacidades (CAPABILITIES). Essas capacidades representam conjuntos de funcionalidades específicas que a fronteira do domínio pode realizar. Na segunda etapa, vemos que cada uma dessas capacidades é composta por várias funcionalidades (FUNCTIONALITIES). As funcionalidades, por sua vez, são conjuntos de ações ou processos que realizam tarefas específicas dentro de uma capacidade. Na terceira e última etapa, cada funcionalidade é decomposta em várias tarefas (TASKS). As tarefas são os menores componentes de trabalho, responsáveis por executar as ações específicas necessárias para completar uma funcionalidade.

Com base nessa hierariquia, apresentaremos a seguir mais detalhes de como esses componentes de software podem ser agrupados e compreendidos, partindo de formas maiores e mais abrangentes (COARSE-GRAINED) para formas menores e mais especializadas (FINE-GRAINED):

1. Monolito / Monolito Modular

	Granularidade	Descrição	Exemplo
	⦿ EXTREMAMENTE BAIXA	Uma aplicação monolítica tradicional que CONTÉM TODOS OS MÓDULOS e funcionalidades de um sistema em um ÚNICO DEPLOYABLE. Embora possa ser modular internamente, todo o sistema é implantado e escalado como uma unidade.	Uma aplicação de e-commerce completa que gerencia produtos, carrinho de compras, pagamentos, usuários, pedidos e inventário em um único código base e deploy.

2. Macrosserviços

	Granularidade	Descrição	Exemplo
	⦿⦿ MUITO BAIXA	Serviços grandes que podem abranger MÚLTIPLOS DOMÍNIOS DE NEGÓCIO. Eles são mais próximos de uma aplicação monolítica em termos de tamanho e escopo, mas ainda são independentes e implantáveis separadamente.	Um serviço de pedidos que gerencia o processo completo de um pedido, desde a adição ao carrinho, checkout, pagamento, até a confirmação do pedido.

3. Microsserviços

	Granularidade	Descrição	Exemplo
	⦿⦿⦿ BAIXA	MICROSSERVIÇOS AMPLIADOS Serviços que englobam UM CONJUNTO MAIS AMPLO DE FUNCIONALIDADES DENTRO DE UM MESMO DOMÍNIO (CAPABILITY) de negócio. Eles são maiores e podem ser comparados a componentes de aplicações modulares.	Um microsserviço de inventário que gerencia o estoque, rastreamento de produtos, e alertas de reabastecimento.
	⦿⦿⦿⦿ MÉDIA	MODERADAMENTE GRANULARES Serviços que agrupam FUNCIONALIDADES RELACIONADAS DENTRO DE UM DOMÍNIO ESPECÍFICO. Eles são maiores que os microsserviços altamente granulares, mas ainda são relativamente pequenos e coesos.	Um microsserviço de pagamento que inclui processamento de cartões de crédito, PayPal e outras formas de pagamento.
	⦿⦿⦿⦿⦿ ALTA	MICROSSERVIÇOS FOCADOS Serviços independentes que realizamUMA FUNCIONALIDADE DE NEGÓCIO ESPECÍFICA E BEM DEFINIDA. Cada microsserviço é pequeno e altamente coeso.	Um microsserviço de carrinho de compras que gerencia os itens adicionados ao carrinho.

4. Funções Únicas (Serverless / Functions as a Service - FaaS)

	Granularidade	Descrição	Fonte
	⦿⦿⦿⦿⦿⦿ MUITO ALTA	Em serviços como AWS Lambda, Google Cloud Functions e Azure Functions, uma função é um bloco de código que executa UMA AÇÃO (TASK) ESPECÍFICA EM RESPOSTA A UM EVENTO. Cada função é autônoma e pode ser escalada independentemente.	AWS Lambda Overview, Google Cloud Functions Overview

4.1 Exemplos Práticos

1. AWS Lambda:

   • Função: Processar um arquivo de imagem quando ele é carregado em um bucket S3.
   • Tarefas: Redimensionar a imagem, aplicar filtros, salvar a nova versão da imagem.
   • Fonte: AWS Lambda Use Cases

2. Google Cloud Functions:

   • Função: Enviar uma notificação quando uma nova entrada é adicionada ao Firestore.
   • Tarefas: Ler a nova entrada, formatar a mensagem de notificação, enviar a notificação via Firebase Cloud Messaging.
   • Fonte: Google Cloud Functions Examples

3. Azure Functions:

   • Função: Atualizar o banco de dados de inventário quando uma compra é realizada.
   • Tarefas: Deduzir a quantidade do produto comprado, registrar a transação, enviar um email de confirmação.
   • Fonte: Azure Functions Documentation

Conclusão

Este artigo abordou os desafios na determinação do tamanho e escopo adequados para microsserviços, um aspecto crucial na migração de sistemas monolíticos para arquiteturas baseadas em microsserviços. A principal dificuldade reside na definição da granularidade apropriada, que pode resultar em componentes excessivamente pequenos e complexos de gerenciar. Diante desse desafio propomos um modelo de espectro de granularidade para auxiliar equipes de desenvolvimento nessa tarefa.

É importante ressaltar que cada nível de granularidade tem suas vantagens e desvantagens. A escolha do tamanho apropriado de um microsserviço depende de vários fatores, incluindo a complexidade do domínio, as necessidades de escalabilidade, a capacidade de manutenção e a organização da equipe de desenvolvimento.

Autor

YAN JUSTINO

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

Referências

• TAIBI, D.; LENARDUZZI, V. On the definition of microservice bad smells. IEEE Software, Institute of Electrical and Electronics Engineers (IEEE), v. 35, n. 3, p. 56–62, maio 2018. ISSN 1937-4194.

• TUSJUNT, M.; VATANAWOOD, W. Refactoring orchestrated web services into microservices using decomposition pattern. In: 2018 IEEE 4th International Conference on Computer and Communications (ICCC). [S.l.]: IEEE, 2018.

• NUNES, L.; SANTOS, N.; SILVA, A. R. From a monolith to a microservices architecture: An approach based on transactional contexts. In: . Lecture Notes in Computer Science. [S.l.]: Springer International Publishing, 2019. p. 37–52. ISBN 9783030299835.

• FRITZSCH, J. et al. Microservices migration in industry: Intentions, strategies, and challenges. In: 2019 IEEE International Conference on Software Maintenance and Evolution (ICSME). [S.l.]: IEEE, 2019.

• 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. ISSN 1573-7616.

• HASSAN, S.; BAHSOON, R.; KAZMAN, R. Microservice transition and its granularity problem: A systematic mapping study. Software: Practice and Experience, Wiley, v. 50, n. 9, p. 1651–1681, jun. 2020. ISSN 1097-024X.