Resumo Executivo

Lucas Penna Gonçalves; Alain Domínguez Fuentes

Resumo elaborado pela ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege voltada à síntese e redação.

Nos últimos anos, o cenário de desenvolvimento de software experimentou uma transformação significativa, impulsionada pela necessidade de maior agilidade, escalabilidade e resiliência nas entregas tecnológicas. A transição de sistemas monolíticos tradicionais para arquiteturas de microsserviços tornou-se uma tendência central em organizações que buscam modernizar suas infraestruturas para suportar demandas variáveis e complexas (Hunt; Kwong, 2017). Enquanto o modelo monolítico concentra toda a lógica de negócio, interface de usuário e acesso a dados em uma única unidade implantável, a arquitetura de microsserviços propõe a decomposição do sistema em um conjunto de serviços pequenos, autônomos e independentes. Cada um desses serviços é responsável por uma funcionalidade específica e comunica-se com os demais por meio de protocolos leves, geralmente HTTP ou mensageria assíncrona (Newman, 2021). Essa mudança de paradigma não é apenas técnica, mas também organizacional, permitindo que equipes multidisciplinares trabalhem com maior autonomia e reduzam as dependências que frequentemente atrasam o ciclo de vida de desenvolvimento de software (Richardson, 2018).

A fundamentação teórica que sustenta a adoção de microsserviços baseia-se em princípios de modularidade e baixo acoplamento. Segundo a literatura especializada, a capacidade de escalar componentes de forma independente é uma das maiores vantagens desse modelo, pois permite que recursos computacionais sejam direcionados especificamente para as partes do sistema que apresentam maior carga de processamento (Thönes, 2015). Além disso, a flexibilidade tecnológica possibilita que cada serviço seja desenvolvido com a linguagem de programação ou o banco de dados mais adequado para sua função específica, rompendo com a rigidez das pilhas tecnológicas únicas dos monólitos (Fowler; Lewis, 2014). No entanto, a pluralidade de abordagens dentro do ecossistema de microsserviços exige uma compreensão profunda das diferentes estratégias de implementação. Entre os modelos mais difundidos, destacam-se as arquiteturas baseadas em API Gateway, sistemas orientados a eventos, e os modelos de coordenação conhecidos como orquestração e coreografia. Cada uma dessas abordagens oferece um equilíbrio distinto entre complexidade, performance e facilidade de manutenção, tornando a escolha do modelo um fator estratégico crítico para o sucesso de sistemas distribuídos (Dragoni et al., 2017).

A arquitetura baseada em API Gateway atua como um ponto central de entrada para todas as requisições externas, funcionando como uma fachada que intermedia a comunicação entre os clientes e os microsserviços internos. Essa camada é responsável por tarefas transversais, como autenticação, autorização, roteamento de requisições, controle de carga e, em alguns casos, a agregação de dados de múltiplos serviços em uma única resposta (Newman, 2021). Por outro lado, a arquitetura orientada a eventos (Event-Driven) foca na comunicação assíncrona, onde os serviços reagem a mudanças de estado ou notificações publicadas em um barramento de mensagens. Essa abordagem promove um nível superior de desacoplamento, permitindo que o sistema continue operando mesmo que alguns componentes estejam temporariamente indisponíveis, o que aumenta a resiliência global da aplicação (Fowler, 2017). Já os modelos de orquestração e coreografia lidam com a lógica de processos de negócio que envolvem múltiplos serviços. Na orquestração, um componente central controla o fluxo, decidindo a ordem das execuções, enquanto na coreografia, cada serviço conhece sua responsabilidade e reage aos eventos de forma descentralizada (Wohltmann, 2020). O objetivo deste estudo é realizar uma análise comparativa detalhada entre essas arquiteturas, identificando critérios técnicos e operacionais que orientem a escolha mais adequada para diferentes contextos organizacionais, sem antecipar conclusões precipitadas sobre a superioridade de um modelo sobre o outro.

Para alcançar os objetivos propostos, a metodologia foi estruturada em duas etapas complementares e rigorosas. A primeira etapa consistiu em uma revisão sistemática da literatura, focada na coleta de dados secundários em bases de referência científica e técnica, incluindo IEEE Xplore, ACM Digital Library, Scopus e Google Scholar. O processo de seleção dos estudos foi orientado por critérios de inclusão que priorizaram publicações recentes que discutissem modularidade, escalabilidade, independência de serviços e performance em arquiteturas distribuídas. A análise de conteúdo permitiu categorizar as informações em três eixos principais: contextos de aplicação, benefícios e limitações, e desafios operacionais específicos. Essa fase teórica forneceu a base necessária para a construção de um quadro comparativo robusto, capaz de evidenciar as nuances entre os modelos de API Gateway, eventos, orquestração e coreografia, servindo como guia para a fase subsequente da pesquisa.

A segunda etapa metodológica envolveu a aplicação prática de uma arquitetura de microsserviços, selecionada com base nos achados da revisão literária. Optou-se pela implementação de um sistema de gerenciamento de tarefas (to-do list), utilizando o padrão de API Gateway. A escolha desse padrão justificou-se pela sua ampla aplicabilidade em sistemas que exigem controle centralizado de acesso e simplificação da interface para o cliente. O ambiente de desenvolvimento foi configurado de forma minuciosa, utilizando a linguagem Java 17 como base principal. O ecossistema Spring Boot foi empregado para a criação dos microsserviços independentes, aproveitando a facilidade de exposição de endpoints RESTful e a integração nativa com ferramentas de nuvem. Para a camada de gateway, utilizou-se o Spring Cloud Gateway, que permitiu a configuração de regras de roteamento dinâmico e a centralização da segurança.

A estrutura operacional do sistema prático foi dividida em três componentes fundamentais. O primeiro, denominado Serviço de Usuários, ficou responsável pela criação, autenticação e gerenciamento de perfis, operando com um banco de dados relacional H2 em memória para garantir a persistência local durante os testes. O segundo componente, o Serviço de Tarefas, foi isolado logicamente e tecnicamente, lidando exclusivamente com as operações de criação, edição, exclusão e listagem de atividades. O terceiro componente foi o API Gateway, que serviu como a interface única para o consumidor externo. A infraestrutura foi simulada utilizando Docker e Docker Compose, garantindo que cada serviço fosse executado em um contêiner isolado, com sua própria rede e recursos limitados, mimetizando um ambiente de produção distribuído. O processo de coleta de dados durante a implementação prática envolveu a realização de testes de requisições HTTP via Postman, monitoramento de logs de inicialização e verificação da latência na comunicação entre o gateway e os serviços de backend.

O detalhamento técnico da implementação incluiu a configuração de arquivos de propriedades específicos para cada serviço, onde foram definidas as portas de comunicação e as rotas de acesso. No API Gateway, as regras de roteamento foram estabelecidas para interceptar chamadas direcionadas a caminhos específicos e encaminhá-las para as instâncias correspondentes dos serviços de usuários ou tarefas. A utilização do Docker Compose foi essencial para orquestrar a inicialização da rede virtual, permitindo que os serviços se descobrissem mutuamente por meio de nomes de host internos. Durante a fase de testes, o foco recaiu sobre a validação do desacoplamento: verificou-se se a interrupção de um serviço afetava a disponibilidade do outro e como o gateway gerenciava falhas de conexão. Essa etapa prática não buscou apenas validar o funcionamento do software, mas sim observar os desafios reais de configuração, como o ajuste fino de regras de URI, a resolução de erros de serialização JSON e a padronização de respostas de erro entre diferentes serviços.

Os resultados obtidos a partir da análise comparativa e da demonstração prática revelam que não existe uma arquitetura de microsserviços universalmente superior, mas sim modelos que se adaptam melhor a requisitos específicos. No critério de modularidade, as arquiteturas orientadas a eventos e de coreografia apresentaram os níveis mais elevados, uma vez que o desacoplamento é quase total, permitindo que novos serviços sejam adicionados ao ecossistema sem a necessidade de alterar componentes existentes (Fowler, 2017). Em contrapartida, o modelo de API Gateway e a orquestração centralizada oferecem uma modularidade média, pois ainda dependem de um ponto central que precisa ser atualizado conforme a interface dos serviços internos evolui. No que diz respeito ao acoplamento, a coreografia destaca-se por apresentar um acoplamento muito baixo, enquanto a orquestração tende a um acoplamento mais alto devido à dependência do orquestrador em relação à lógica de cada serviço que ele coordena (Richardson, 2018).

Quanto à escalabilidade, o modelo orientado a eventos demonstrou ser o mais robusto para cenários de grandes volumes de dados e fluxos dinâmicos, atingindo uma classificação de “muito alta” na análise comparativa. Isso ocorre porque a natureza assíncrona da comunicação evita gargalos de espera por respostas síncronas, permitindo que o sistema processe informações conforme a disponibilidade de recursos. O modelo de API Gateway também oferece alta escalabilidade, especialmente para APIs públicas, mas exige uma atenção redobrada à infraestrutura do próprio gateway, que pode se tornar um ponto único de falha ou um gargalo de performance se não for devidamente balanceado (Newman, 2021). A observabilidade, por sua vez, mostrou-se facilitada nos modelos centralizados, como o API Gateway e a orquestração, onde o rastreamento de requisições e a geração de logs podem ser consolidados em um único ponto. Já em sistemas de coreografia e eventos, a observabilidade é classificada como complexa ou difícil, exigindo ferramentas avançadas de rastreamento distribuído para reconstruir o fluxo de uma transação que atravessa múltiplos serviços de forma assíncrona (Wohltmann, 2020).

A aplicação prática do sistema de gerenciamento de tarefas corroborou diversos pontos identificados na teoria. A centralização do controle de acesso no API Gateway mostrou-se extremamente eficaz, permitindo que o cliente interagisse com uma única interface unificada, independentemente da complexidade interna do sistema. Durante os testes com o Postman, observou-se que o gateway interceptava as requisições com baixa latência, encaminhando-as corretamente para os serviços de usuários ou tarefas. A independência dos serviços foi comprovada quando alterações no esquema de dados do Serviço de Tarefas foram realizadas sem a necessidade de reiniciar ou reconfigurar o Serviço de Usuários, demonstrando a eficácia do isolamento de responsabilidades. No entanto, a complexidade de gestão foi visivelmente superior à de um sistema monolítico equivalente. A necessidade de gerenciar múltiplos Dockerfiles, configurações de rede e a sincronização de inicialização dos contêineres evidenciou que a arquitetura de microsserviços demanda uma maturidade operacional significativa e o uso de ferramentas de automação (Bass et al., 2015).

A discussão dos resultados também aponta para a importância do gerenciamento de dados distribuídos. Enquanto em um monólito a consistência é garantida por transações ACID em um único banco de dados, nos microsserviços a consistência eventual torna-se a norma, especialmente em modelos orientados a eventos. A implementação de padrões como Sagas torna-se necessária para garantir que operações complexas que envolvem múltiplos serviços sejam concluídas com sucesso ou devidamente compensadas em caso de falha (Fowler, 2017). Na prática realizada, a ausência de transações distribuídas simplificou o desenvolvimento, mas em um cenário empresarial real, essa seria uma limitação crítica. Outro ponto relevante discutido foi a curva de aprendizado e a mudança cultural necessária nas equipes. A transição para microsserviços exige que os desenvolvedores compreendam não apenas a lógica de negócio, mas também conceitos de redes, segurança distribuída e infraestrutura como código (Wohltmann, 2020).

As limitações do estudo prático devem ser reconhecidas para contextualizar os achados. A aplicação foi desenvolvida em ambiente local, com um número reduzido de serviços e carga simulada, o que não permitiu avaliar o comportamento do sistema em cenários de altíssima concorrência ou em infraestruturas de nuvem pública. Além disso, não foram integradas ferramentas avançadas de observabilidade, como Prometheus ou Grafana, que seriam essenciais para o monitoramento em larga escala. A ausência de testes automatizados de integração contínua também limitou a avaliação da agilidade na entrega, um dos pilares teóricos dos microsserviços. No entanto, essas limitações não invalidam a relevância dos resultados, mas apontam caminhos para pesquisas futuras, que poderiam explorar a implementação de padrões de resiliência como Circuit Breaker e a utilização de malhas de serviço (Service Mesh) para gerenciar a comunicação leste-oeste entre os serviços.

A análise comparativa entre orquestração e coreografia trouxe insights valiosos sobre a gestão de fluxos de trabalho. A orquestração, ao centralizar a lógica em um “maestro”, facilita o monitoramento do estado do processo, sendo ideal para fluxos rígidos e complexos onde a ordem das operações é crítica. Contudo, o risco de sobrecarga no orquestrador e o aumento do acoplamento são desafios constantes (Richardson, 2018). Já a coreografia, ao distribuir a inteligência entre os serviços, promove uma agilidade superior e elimina o ponto central de falha, mas torna a compreensão do fluxo global do sistema muito mais difícil para os desenvolvedores e operadores. Essa dicotomia reforça a tese de que a escolha arquitetural deve ser guiada pela natureza do problema de negócio: sistemas com fluxos de trabalho altamente dinâmicos e necessidade de resposta em tempo real beneficiam-se da coreografia, enquanto processos de negócio regulados e sequenciais podem encontrar na orquestração uma solução mais segura e controlável (Wohltmann, 2020).

Em termos de aplicabilidade, observou-se que setores como o e-commerce e serviços financeiros são adotantes naturais de arquiteturas híbridas. Nesses contextos, o API Gateway é frequentemente utilizado para gerenciar a interface com aplicativos móveis e web, enquanto o backend utiliza uma combinação de eventos para processamento de pagamentos e orquestração para fluxos de aprovação de crédito. A pesquisa demonstrou que a modularidade permitida pelos microsserviços facilita a experimentação tecnológica, permitindo que empresas testem novas funcionalidades em serviços isolados sem colocar em risco a estabilidade de todo o ecossistema (Dragoni et al., 2017). Por fim, a discussão ressalta que a migração para microsserviços não deve ser vista como um objetivo em si, mas como um meio para atingir objetivos de negócio específicos, como a redução do tempo de colocação no mercado (time-to-market) e a melhoria da escalabilidade operacional (Villamizar et al., 2015).

Conclui-se que o objetivo foi atingido, uma vez que a análise comparativa e a implementação prática permitiram identificar com clareza as características, vantagens e limitações das principais arquiteturas de microsserviços. A escolha entre API Gateway, sistemas orientados a eventos, orquestração ou coreografia não deve ser baseada em preferências tecnológicas, mas sim em uma avaliação criteriosa dos requisitos de escalabilidade, complexidade de gestão e maturidade da equipe de desenvolvimento. A demonstração prática confirmou que, embora o modelo de API Gateway simplifique a comunicação e centralize o controle, ele introduz desafios operacionais que exigem automação e monitoramento constante. O estudo evidenciou que a modularidade e a independência de serviços são fundamentais para a agilidade organizacional, mas demandam uma infraestrutura robusta e uma mudança de paradigma na forma como os sistemas são projetados e mantidos. Assim, a arquitetura de microsserviços consolida-se como uma solução estratégica para sistemas distribuídos modernos, desde que sua implementação seja acompanhada por um planejamento rigoroso e uma compreensão profunda das trocas (trade-offs) inerentes a cada modelo arquitetural.

Referências Bibliográficas:

BASS, Len; WEBER, Ingo; ZHU, Liming. DevOps: A Software Architect’s Perspective. Addison-Wesley Professional, 2015.

DRAGONI, Nicola et al. Microservices: yesterday, today, and tomorrow. In: MURGANTE, Beniamino et al. (Org.). Present and Ulterior Software Engineering. Cham: Springer, 2017. p. 195–216.

FOWLER, Martin. What do you mean by “Event-Driven”? 2017. Disponível em: https://martinfowler.com/articles/201701-event-driven.html. Acesso em: 2 fev. 2025.

FOWLER, Martin; LEWIS, James. Microservices: a definition of this new architectural term. Martinfowler.com, 2014. Disponível em: http://martinfowler.com/articles/microservices.html. Acesso em: 16 out. 2024.

HUNT, Geoffrey C. R.; KWONG, Paul G. K. Microservices: A systematic mapping study. Proceedings of the International Workshop on Software Engineering for Systems-of-Systems, 2017, pp. 34-40.

NEWMAN, Sam. Building Microservices: Designing Fine-Grained Systems. 2. ed. Sebastopol: O’Reilly Media, 2021.

RICHARDSON, Chris. Microservices Patterns: With examples in Java. 1. ed. Manning Publications, 2018.

THÖNES, Johannes. Microservices. IEEE Software, v. 32, n. 1, p. 116-116, 2015.

VILLAMIZAR, Mario et al. Evaluating the monolithic and the microservice architecture pattern to deploy web applications in the cloud. Proceedings of the 10th Computing Colombian Conference (10CCC), 2015, p. 583-590.

WOHLTMANN, Andreas. Microservices Choreography vs. Orchestration. 2020. Disponível em: https://dev.to/andreasklinger/microservices-choreography-vs-orchestration-3e96. Acesso em: 2 fev. 2025.

Resumo executivo oriundo de Trabalho de Conclusão de Curso da Especialização em Engenharia de Software do MBA USP/Esalq

Para saber mais sobre o curso, clique aqui e acesse a plataforma MBX Academy