Evidence Briefing – Monólito vs Microsserviços

Monólito ou microsserviços: por onde começar?

Decidir a arquitetura inicial de um sistema de software é uma das escolhas mais consequentes — e mais debatidas — no desenvolvimento de produtos digitais. Monólitos prometem simplicidade e velocidade; microsserviços prometem escala e autonomia. Mas em que contexto cada caminho faz mais sentido? Para ir além de opiniões e modismos, conduzimos uma revisão rápida de 23 estudos acadêmicos e aplicados, sintetizando evidências sobre vantagens, desvantagens e critérios de decisão de cada abordagem. O que encontramos reforça uma ideia central: não existe arquitetura universalmente superior — existe a arquitetura mais adequada ao problema, à equipe e ao momento do produto. Neste post, compartilhamos os principais achados e os trade-offs que toda equipe deveria considerar antes de tomar essa decisão.

1.Contexto

A consolidação da Internet como principal meio de oferta de serviços digitais impulsionou o desenvolvimento de sistemas distribuídos, capazes de atender grandes volumes de usuários, operar continuamente e evoluir de forma incremental. Nesse contexto, a arquitetura de software passou a exercer papel central na sustentação de atributos como escalabilidade, confiabilidade, desempenho e capacidade de evolução, tornando as decisões arquiteturais elementos estruturantes no ciclo de vida dos sistemas (BASS; CLEMENTS; KAZMAN, 2013).

A decisão entre iniciar um sistema como monólito ou como microsserviços constitui uma das escolhas arquiteturais mais críticas no desenvolvimento de software, podendo influenciar atributos não funcionais relevantes, como escalabilidade, confiabilidade e custo de manutenção ao longo do tempo. Arquiteturas monolíticas são tradicionalmente associadas à simplicidade estrutural e à centralização do controle, enquanto arquiteturas de microsserviços propõem a decomposição do sistema em serviços pequenos e implantáveis de forma independente, frequentemente alinhados a capacidades de negócio (LEWIS; FOWLER, 2014; DRAGONI et al., 2017).

Embora o debate sobre microsserviços tenha se intensificado tanto na indústria quanto na academia, estudos apontam que os resultados associados a esse estilo arquitetural variam significativamente conforme o contexto de aplicação. Aspectos como tamanho do sistema, organização das equipes, práticas de desenvolvimento e requisitos não funcionais influenciam de forma decisiva a adequação de cada abordagem arquitetural (DI FRANCESCO; LAGO; MALAVOLTA, 2019). Ainda assim, observa-se uma lacuna de entendimento prático e acadêmico sobre como iniciar sistemas de software, especialmente nos estágios iniciais, quando decisões arquiteturais precisam ser tomadas diante de incertezas quanto à evolução futura do produto e da organização.

Essa lacuna se manifesta na dificuldade de estabelecer critérios claros para a escolha da arquitetura inicial, bem como na ausência de consensos consolidados na literatura sobre quais fatores devem ser priorizados nesse momento. Como resultado, arquiteturas monolíticas e de microsserviços são frequentemente discutidas de forma comparativa, mas sem diretrizes suficientemente explícitas sobre em quais contextos cada alternativa tende a ser mais adequada (DI FRANCESCO et al., 2018; TAIBI; LENARDUZZI; PAHL, 2017).

Diante desse contexto, este trabalho tem como objetivo analisar e sintetizar evidências existentes sobre arquiteturas monolíticas e de microsserviços, buscando responder às seguintes questões:

• Quais são as vantagens e desvantagens de optar por uma arquitetura monolítica e por uma arquitetura de microsserviços?
• Quais requisitos não funcionais influenciam decisões relacionadas às arquiteturas monolítica e de microsserviços?
• Em quais contextos é mais adequado selecionar uma arquitetura monolítica ou uma arquitetura de microsserviços?

2. Método

Para a realização desta pesquisa foi utilizado a metodologia de Revisão Rápida. Uma revisão rápida é uma forma estruturada e transparente de reunir e resumir evidências sobre uma pergunta específica para apoiar decisões (CARTAXO et al. 2018). Isso quer dizer que, em vez de depender só de opinião ou experiências isoladas, a equipe segue um processo organizado para identificar o que já foi estudado na literatura acadêmica e transformar esses achados em insights acionáveis.

2.1 Condução da pesquisa

Inicialmente, foi realizada uma busca manual no Google Scholar para gerar conhecimento da área para os pesquisadores e aperfeiçoar as questões de pesquisa. Nesta etapa o objeto era entender as pesquisas da área e sair com background suficiente para gerar uma boa string de busca. Essa etapa resultou na seleção de 3 estudos, os quais compuseram o chamado Golden Set. Esses trabalhos foram utilizados como base de referência para validar a estratégia de busca automatizada, garantindo que os principais estudos do domínio fossem recuperados.

Em seguida, foi conduzida uma busca automatizada no IEEE, utilizando uma string de busca definida a partir dos termos-chave identificados no Golden Set. Essa busca retornou um total de 61 estudos

Na etapa seguinte, foi realizada a leitura dos resumos dos artigos encontrados, com aplicação dos critérios de inclusão e exclusão definidos no protocolo da revisão. Como resultado dessa triagem inicial, 13 estudos foram considerados aptos para a próxima fase.

Em seguida, esses estudos passaram por uma leitura completa, permitindo uma avaliação ao objetivo da pesquisa. Ao final dessa etapa, 6 estudos atenderam os critérios estabelecidos e foram selecionados a partir da busca automatizada.

Por fim, foi realizada uma busca manual no Google Scholar por artigos que citaram os 6 estudos da etapa anterior, na qual foram selecionados 14 estudos adicionais considerados relevantes para o escopo da pesquisa. Essa etapa teve como objetivo complementar a busca automatizada, garantindo a inclusão de trabalhos potencialmente relevantes que não foram recuperados pelas strings de busca definidas ou pela base selecionada. Totalizando 23 estudos identificados. Para mais informações sobre o processo, como string de busca, críterios de inclusão e exclusão, analisar o relatório de evidências.

3 Resultados

A análise dos estudos selecionados permitiu identificar um conjunto de achados relacionados à adoção da arquitetura monolítica, organizados segundo três dimensões principais: organizacional, arquitetural e relacionada às pessoas. Os resultados foram extraídos de estudos aplicados e revisões, conforme indicado nos identificadores associados a cada aspecto.

3.1 Monolito

3.1.1 Dimensão Organizacional

No que se refere à dimensão organizacional, os estudos indicaram que a arquitetura monolítica apresentou vantagens em contextos caracterizados por equipes menores e projetos de pequeno porte (GRAVANIS; KAKARONTZAS; GEROGIANNIS, 2022; VELEPUCHA; FLORES, 2023). Esses cenários foram associados a uma maior simplicidade de coordenação e menor sobrecarga organizacional, favorecendo a adoção do monolito em fases iniciais de desenvolvimento. Por outro lado, os resultados também evidenciaram que mudanças estruturais em sistemas monolíticos estiveram associadas a custos elevados, especialmente à medida que o sistema evoluiu e se tornou mais complexo (VELEPUCHA; FLORES, 2023). Esses custos foram relacionados à necessidade de modificações amplas no código e à dependência entre componentes, dificultando a adaptação organizacional ao longo do tempo.

3.1.2 Dimensão Arquitetural

Na dimensão arquitetural, os achados revelaram tanto vantagens quanto desvantagens associadas à arquitetura monolítica. Entre as vantagens, destacaram-se o desenvolvimento inicial mais simples, a centralização do código-fonte e a maior facilidade para atividades de depuração (VELEPUCHA; FLORES, 2023; MENARD, 2020; BAŠKARADA; NGUYEN; KORONIOS, 2020; CHATURVEDI et al., 2024 ). Os estudos também indicaram que os testes de construção simples, como testes de unidade, foram mais facilmente implementados nesse tipo de arquitetura, em comparação com arquiteturas distribuídas (MENARD, 2020; CHATURVEDI et al., 2024; VELEPUCHA; FLORES, 2021).

Entretanto, os resultados apontaram um conjunto consistente de desvantagens. A complexidade do sistema foi reportada como um problema recorrente, especialmente em aplicações de médio e grande porte (GRAVANIS; KAKARONTZAS; GEROGIANNIS, 2022; VELEPUCHA; FLORES, 2023; VELEPUCHA; FLORES, 2021). Questões relacionadas à escalabilidade foram frequentemente associadas à estrutura monolítica, limitando a capacidade de evolução independente dos componentes (GRAVANIS; KAKARONTZAS; GEROGIANNIS, 2022; MENARD, 2020; BAŠKARADA; NGUYEN; KORONIOS, 2020; SEEDAT; ABBAS; AHMAD, 2023). Além disso, os estudos relataram dificuldades relacionadas à manutenibilidade, alto acoplamento entre módulos e limitações na tolerância a falhas, uma vez que falhas em partes específicas do sistema puderam comprometer o funcionamento da aplicação como um todo (GRAVANIS; KAKARONTZAS; GEROGIANNIS, 2022; SEEDAT; ABBAS; AHMAD, 2023; VELEPUCHA; FLORES, 2021; CHATURVEDI et al., 2024). Outro achado relevante foi a dificuldade na realização de testes end-to-end, atribuída à dependência entre os componentes e à necessidade de execução integrada do sistema (VELEPUCHA; FLORES, 2023; BAŠKARADA; NGUYEN; KORONIOS, 2020; SEEDAT; ABBAS; AHMAD, 2023).

3.1.3 Dimensão Relacionada às Pessoas

No que diz respeito à dimensão relacionada às pessoas, o estudo indica que a adoção e manutenção de sistemas monolíticos estiveram associadas a desenvolvimento com conhecimento técnico da arquitetura, tornando a necessidade um profissional não tão especializado (MENARD, 2020).

3.2 Microserviços

3.2.1 Dimensão Organizacional

Na dimensão organizacional, a entrega mais rápida de software foi reportada como uma vantagem em dois estudos, indicando que arquiteturas de microsserviços estiveram associadas à redução do tempo de entrega em determinados contextos (MENARD, 2020; KÖNÖNEN, 2018). Em contraste, a percepção de que essa arquitetura não representou uma resposta para todos os problemas organizacionais foi identificada em um estudo (MENARD, 2020), assim como a constatação de que sua adoção foi ineficaz para software de pequeno porte, também reportada em um estudo (MENARD, 2020).

Problemas relacionados ao gerenciamento dos serviços foram reportados em dois estudos (KRUG; CHANIN; SALES, 2024; CHATURVEDI et al., 2024), evidenciando desafios associados à coordenação, monitoramento e operação de múltiplos serviços. Além disso, a falta de autonomia para deploys foi identificada em um estudo (KRUG; CHANIN; SALES, 2024), indicando limitações organizacionais em contextos específicos. Por outro lado, a autonomia de equipes foi apontada como uma vantagem em três estudos (MENARD, 2020, KÖNÖNEN, 2018; CHATURVEDI et al., 2024), sugerindo que a descentralização promovida pelos microsserviços favoreceu a independência das equipes de desenvolvimento em determinados cenários.

3.2.2 Dimensão Arquitetural

No âmbito arquitetural, a escalabilidade foi o aspecto mais frequentemente reportado, sendo identificada como vantagem em dezesseis estudos (KALSKE; MÄKITALO; MIKKONEN, 2017; GRAVANIS; KAKARONTZAS; GEROGIANNIS, 2022; NOGUEIRA et al., 2024; VELEPUCHA; FLORES, 2023; AUER et al., 2021; HMUE; PHYU; PAING, 2024; MENARD, 2020; KÖNÖNEN, 2018; HONCHARUK, 2025; BAŠKARADA; NGUYEN; KORONIOS, 2020; CHATURVEDI et al., 2024; SEEDAT; ABBAS; AHMAD, 2023; VELEPUCHA; FLORES, 2021), o que indica forte recorrência desse tema na literatura analisada. A diversidade de stacks para programar foi mencionada como vantagem em um estudo (BAŠKARADA; NGUYEN; KORONIOS, 2020), assim como a redução de código redundante, também reportada em um estudo (KÖNÖNEN, 2018). A flexibilidade na construção dos módulos foi identificada como vantagem em um estudo (KALSKE; MÄKITALO; MIKKONEN, 2017), associando a arquitetura de microsserviços à possibilidade de evolução independente dos componentes.

Por outro lado, a ambiguidade na definição e compreensão dos microsserviços foi reportada como desvantagem em um estudo(MENARD, 2020), indicando dificuldades conceituais ou de escopo. Questões relacionadas à tolerância a falhas foram identificadas como vantagem em quatro estudos (KÖNÖNEN, 2018; CHATURVEDI et al., 2024; SEEDAT; ABBAS; AHMAD, 2023; VELEPUCHA; FLORES, 2021), sugerindo que a arquitetura favoreceu o isolamento de falhas em determinados contextos. Em contrapartida, dificuldades relacionadas à realização de testes foram reportadas em três estudos (KÖNÖNEN, 2018; KRUG; CHANIN; SALES, 2024; AUER et al., 2021), indicando que a testabilidade representou um desafio recorrente em ambientes baseados em microsserviços.

3.2.3 Dimensão Relacionada às Pessoas

No que se refere à dimensão relacionada às pessoas, a falta de conhecimento técnico da equipe foi identificada como desvantagem em três estudos (MENARD, 2020; KÖNÖNEN, 2018; KRUG; CHANIN; SALES, 2024), indicando que a adoção de microsserviços esteve associada à necessidade de competências técnicas mais avançadas, tanto no desenvolvimento quanto na operação dos sistemas.

3.3 Requisitos Não Funcionais em Arquiteturas de Microsserviços

A análise dos estudos selecionados permitiu identificar um conjunto de requisitos não funcionais associados à adoção de arquiteturas baseadas em microsserviços. Esses requisitos foram extraídos de estudos aplicados e revisões, sendo classificados de acordo com sua recorrência na literatura analisada.

A escalabilidade foi o requisito não funcional mais frequentemente reportado, estando presente em 16 estudos (KALSKE; MÄKITALO; MIKKONEN, 2017; GRAVANIS; KAKARONTZAS; GEROGIANNIS, 2022; NOGUEIRA et al., 2024; VELEPUCHA; FLORES, 2023; AUER et al., 2021; HMUE; PHYU; PAING, 2024; MENARD, 2020; KÖNÖNEN, 2018; HONCHARUK, 2025; BAŠKARADA; NGUYEN; KORONIOS, 2020; CHATURVEDI et al., 2024; SEEDAT; ABBAS; AHMAD, 2023; VELEPUCHA; FLORES, 2021), o que indica forte consenso na literatura quanto à capacidade dessa arquitetura de suportar crescimento e variações de carga por meio da decomposição e escalonamento independente dos serviços. A orquestração foi identificada em dois estudos (HMUE; PHYU; PAING, 2024; BAŠKARADA; NGUYEN; KORONIOS, 2020), refletindo a necessidade de mecanismos específicos para coordenação e gerenciamento dos serviços distribuídos.

A disponibilidade foi reportada em um estudo (VELEPUCHA; FLORES, 2023), enquanto a tolerância a falhas foi identificada em quatro estudos (KÖNÖNEN, 2018; CHATURVEDI et al., 2024; SEEDAT; ABBAS; AHMAD, 2023; VELEPUCHA; FLORES, 2021 ), indicando que o isolamento de serviços contribuiu para a resiliência do sistema em determinados contextos. O reuso foi associado aos microsserviços em cinco estudos (NOGUEIRA et al., 2024; VELEPUCHA; FLORES, 2023; CARVALHO et al., 2019; HONCHARUK, 2025; GOUIGOUX; TAMZALIT, 2017), sugerindo que a modularização favoreceu a reutilização de componentes e funcionalidades. A segurança distribuída foi mencionada em dois estudos (HMUE; PHYU; PAING, 2024; VELEPUCHA; FLORES, 2021), evidenciando preocupações relacionadas à proteção de dados, autenticação e autorização em ambientes distribuídos.

O requisito de performance foi reportado em sete estudos (KALSKE; MÄKITALO; MIKKONEN, 2017; GRAVANIS; KAKARONTZAS; GEROGIANNIS, 2022; CARVALHO et al., 2019; BAŠKARADA; NGUYEN; KORONIOS, 2020; VELEPUCHA; FLORES, 2021; GOUIGOUX; TAMZALIT, 2017; BERRY et al., 2024), indicando que o impacto no desempenho foi um aspecto recorrente nas avaliações de microsserviços, tanto em termos de benefícios quanto de desafios decorrentes da comunicação entre serviços.

A refatoração foi reportada em dois estudos (KALSKE; MÄKITALO; MIKKONEN, 2017; GRAVANIS; KAKARONTZAS; GEROGIANNIS, 2022), sugerindo a necessidade de reestruturação do código durante a adoção ou evolução da arquitetura. O deploy contínuo (CI/CD) foi identificado em sete estudos (GRAVANIS; KAKARONTZAS; GEROGIANNIS, 2022; NOGUEIRA et al., 2024; VELEPUCHA; FLORES, 2023; AUER et al., 2021; HONCHARUK, 2025; BAŠKARADA; NGUYEN; KORONIOS, 2020; CHATURVEDI et al., 2024; GOUIGOUX; TAMZALIT, 2017), indicando forte associação entre microsserviços e práticas de automação de entrega. A manutenibilidade foi reportada em cinco estudos (NOGUEIRA et al., 2024; AUER et al., 2021; CHATURVEDI et al., 2024; SEEDAT; ABBAS; AHMAD, 2023; FRITZSCH et al., 2019), refletindo benefícios e desafios relacionados à evolução do sistema ao longo do tempo.

Aspectos relacionados às pessoas e à agilidade foram identificados em nove estudos (GRAVANIS; KAKARONTZAS; GEROGIANNIS, 2022; NOGUEIRA et al., 2024; AUER et al., 2021; MENARD, 2020; KÖNÖNEN, 2018; HONCHARUK, 2025; CHATURVEDI et al., 2024; SEEDAT; ABBAS; AHMAD, 2023; VELEPUCHA; FLORES, 2021), indicando que a arquitetura de microsserviços está frequentemente associada a mudanças organizacionais, maior autonomia de equipes e necessidade de adaptação de processos. Por fim, testes foram reportados em quatro estudos (VELEPUCHA; FLORES, 2023; HMUE; PHYU; PAING, 2024; BAŠKARADA; NGUYEN; KORONIOS, 2020; SEEDAT; ABBAS; AHMAD, 2023), evidenciando desafios específicos na validação de sistemas distribuídos, especialmente no que se refere a testes de integração e ponta a ponta.

3.4 Síntese dos Critérios para Seleção entre Arquitetura Monolítica e Microsserviços

A análise dos estudos selecionados permitiu sintetizar um conjunto de critérios decisórios associados à escolha entre arquitetura monolítica e arquitetura de microsserviços, considerando o tipo de problema a ser resolvido, o contexto organizacional e o estágio de maturidade da empresa. Os resultados indicaram que a decisão arquitetural esteve diretamente relacionada às características do negócio, da equipe e dos objetivos do sistema.

No caso da arquitetura monolítica, os estudos indicaram que sua adoção esteve associada a cenários nos quais o objetivo principal foi a validação de ideias, o desenvolvimento de projetos pequenos e a redução do tempo de entrada no mercado. Esses contextos foram caracterizados por equipes menores, estrutura técnica mais simples e custos iniciais reduzidos. A literatura analisada apontou que tais características tornaram a arquitetura monolítica particularmente adequada para startups e organizações em estágio inicial, especialmente quando houve necessidade de construção rápida de produtos mínimos viáveis (MVPs) com baixo investimento inicial.

Em contraste, a arquitetura de microsserviços foi associada a contextos nos quais requisitos como segurança, testes contínuos, crescimento do negócio, resiliência, observabilidade e escalabilidade organizacional e técnica foram mais relevantes. Os estudos indicaram que essa arquitetura foi mais frequentemente adotada por empresas consolidadas, caracterizadas por operações em larga escala, múltiplos domínios de negócio e disponibilidade de investimento para sustentar a complexidade arquitetural. Nesses cenários, a adoção de microsserviços esteve associada a custos mais elevados, tanto em termos técnicos quanto organizacionais, compensados pela capacidade de evolução independente dos serviços.

Os resultados também indicaram que, independentemente da arquitetura adotada, a decisão impactou a organização como um todo, exigindo alinhamento entre estrutura organizacional, processos de desenvolvimento e capacidades técnicas. A literatura destacou que a arquitetura selecionada demandou dinâmicas organizacionais específicas para que seus benefícios fossem efetivamente alcançados, incluindo adequações na forma de trabalho das equipes, nos processos de entrega e na governança técnica.

De modo geral, a síntese dos estudos analisados indicou que a escolha entre arquitetura monolítica e microsserviços não esteve associada exclusivamente a critérios técnicos, mas resultou de uma combinação de fatores organizacionais, estratégicos e humanos, os quais influenciaram diretamente a sustentabilidade da arquitetura ao longo do tempo.

4. Discussão

Os resultados deste briefing reforçam que a escolha entre monólito e microsserviços é, sobretudo, dependente de contexto e do “momento” do produto. No conjunto analisado (23 estudos), o monólito aparece mais associado a cenários de menor complexidade organizacional e técnica, com equipes menores e projetos pequenos, destacando benefícios como simplicidade de desenvolvimento, centralização do código, facilidade de depuração e testes mais simples quando comparados a cenários distribuídos.

Ao mesmo tempo, a literatura indica que, à medida que o sistema cresce, tendem a emergir limitações ligadas a complexidade, acoplamento, manutenaibilidade e escalabilidade, além do custo de mudanças que podem exigir reconstrução/redeploy de toda a aplicação.

Já os microsserviços são descritos principalmente como resposta a demandas de escalabilidade e evolução independente (desenvolver, implantar e escalar serviços separadamente), com benefícios adicionais frequentemente citados como isolamento de falhas e flexibilidade evolutiva.

Contudo, essa arquitetura introduz um custo de coordenação e operação: surgem desafios como definir e delimitar serviços (onde “cortar”), testes mais difíceis, gerência/observabilidade e maior dependência de expertise técnica para lidar com a complexidade distribuída.

Do ponto de vista de requisitos não funcionais e critérios de decisão, há uma diferença importante: para microsserviços, a síntese destaca concentração em escalabilidade e em capacidades organizacionais ligadas a entrega (agilidade, CI/CD e governança de deploy), enquanto no monólito aparecem com mais ênfase testes, arquitetura simples, time-to-market, custo, deploy fácil e depuração como critérios recorrentes.

Esse contraste sugere que “iniciar” com microsserviços tende a fazer mais sentido quando o problema já nasce com demandas claras de escala/resiliência e trabalho paralelo entre equipes, enquanto o monólito tende a favorecer fases de maior incerteza, validação (MVP) e foco em velocidade/custo.

Por fim, há um alerta metodológico relevante: a evidência utilizada é heterogênea e o relatório-base não inclui avaliação detalhada de qualidade metodológica por artigo; portanto, este briefing deve ser usado como apoio à decisão, não como regra universal.

Além disso, a própria revisão foi conduzida como revisão rápida, isto é, um processo estruturado e transparente para sintetizar evidências visando apoiar decisões, o que reforça a necessidade de interpretar os achados com pragmatismo e cautela. Vale salientar também que devido a escolha desse método, é possível que existam outros artigos que não foram capturados na busca. Para minimizar o impacto, foi realizado uma busca manual nas citações.

5. Conclusão

Com base na síntese dos 23 estudos, a decisão entre monólito e microsserviços deve ser orientada por (i) tipo de problema, (ii) requisitos não funcionais, (iii) contexto organizacional e (iv) Capacidade técnica da equipe, evitando adoção por “moda” e priorizando a capacidade real de operação e entrega.

Em estágios iniciais e contextos com equipes menores, alta incerteza e prioridade em simplicidade, velocidade e custo, o monólito tende a ser uma alternativa mais adequada, com ganhos em desenvolvimento, testes e depuração, ainda que possa exigir revisão arquitetural conforme o sistema cresce.

Quando o sistema já enfrenta (ou claramente enfrentará) demandas fortes de escalabilidade/resiliência, necessidade de deploy independente e trabalho paralelo entre equipes, os microsserviços tendem a ser mais adequados, desde que a organização consiga sustentar a complexidade adicional (delimitação de serviços, testes distribuídos e operação/observabilidade).

Por se tratar de uma revisão rápida e por a evidência ser heterogênea, recomenda-se usar este briefing como base para uma decisão consciente, complementando com análise do contexto local (produto, equipe e operação) e registrando explicitamente os trade-offs assumidos

Apêndice A – Estudos analisados (títulos e IDs)

Lista do relatório-base:

• ID1 – Challenges When Moving from Monolith to Microservice Architecture (Aplicado)
• ID2 – You don’t need a Microservices Architecture (yet) (Revisões)
• ID3 – Insights on Microservice Architecture Through the Eyes of Industry Practitioners (Aplicado)
• ID4 – A Survey on Microservices Architecture: Principles, Patterns and Migration Challenges (Revisões)
• ID5 – From monolithic systems to Microservices: An assessment framework (Aplicado)
• ID6 – Analysis of the Criteria Adopted in Industry to Extract Microservices (Aplicado)
• ID7 – Microservices vs Monolith: A Comparative Analysis and Problem-Solving Approach in Web Development Area (Aplicado)
• ID8 – Monolithic vs. Microservice Architecture: A Performance and Scalability Evaluation (Aplicado)
• ID9 – The Monolith Strikes Back: Why Istio Migrated From Microservices to a Monolithic Architecture (Aplicado)
• ID10 – Decision criteria between microservice and monolithic architecture (Revisões)
• ID11 – Microservices: Considerations before implementation (Revisões)
• ID12 – Do You Really Need Microservices Architecture? (Aplicado)
• ID13 – Exploring the Pros and Cons of Monolithic Applications versus Microservices (Aplicado)
• ID14 – Architecting Microservices: Practical Opportunities and Challenges (Aplicado)
• ID15 – Promises and challenges of microservices: an exploratory study (Aplicado)
• ID16 – Migrating Towards Microservice Architectures: An Industrial Survey (Aplicado)
• ID17 – From Monolith to Microservices : A Systematic Literature Survey (Revisões)
• ID18 – Systematic Mapping of Monolithic Applications to Microservices Architecture (Revisões)
• ID19 – Monolits to microservices - Migration Problems and Challenges: A SMS (Revisões)

• ID20 – Microservices Migration in Industry: Intentions, Strategies, and Challenges (Aplicado)

• ID21 - From Monolith to Microservices: Lessons Learned on an Industrial Migration to a Web Oriented Architecture (Aplicado)

• ID22 - Is it Worth Migrating a Monolith to Microservices? An Experience Report on Performance, Availability and Energy Usage (Aplicado)

• ID23 - Architecture Migration From Monolithic to Microservices: Developing Readiness Criteria (Aplicado)

Referências

BASS, Len; CLEMENTS, Paul; KAZMAN, Rick. Software Architecture in Practice. 3. ed. Boston: Addison-Wesley, 2013.

DI FRANCESCO, Paolo; LAGO, Patricia; MALAVOLTA, Ivano. Architecting with microservices: A systematic mapping study. Journal of Systems and Software, v. 150, p. 77–97, 2019.

DI FRANCESCO, Paolo et al. Migrating towards microservices: An industrial survey. In: Proceedings of the IEEE International Conference on Software Architecture (ICSA). 2018.

DRAGONI, Nicola et al. Microservices: Yesterday, today, and tomorrow. In: Present and Ulterior Software Engineering. Cham: Springer, 2017. p. 195–216.

LEWIS, James; FOWLER, Martin. Microservices. 2014. Disponível em: https://martinfowler.com/articles/microservices.html.

TAIBI, Davide; LENARDUZZI, Valentina; PAHL, Claus. Processes, motivations, and issues for migrating to microservices architectures: An empirical investigation. IEEE Cloud Computing, v. 4, n. 5, p. 22–32, 2017.

Cartaxo, B.; Pinto, G.; Soares, S. The Role of Rapid Reviews in Supporting Decision-Making in Software Engineering Practice. In: Proceedings of the 22nd International Conference on Evaluation and Assessment in Software Engineering (EASE’18). 2018. p. 24–34. DOI: 10.1145/3210459.3210462.

GRAVANIS, Dimitrios; KAKARONTZAS, George; GEROGIANNIS, Vassilis. You don’t need a Microservices Architecture (yet): Monoliths may do the trick. In: Proceedings of the 2021 European Symposium on Software Engineering (ESSE ’21). New York, NY, EUA: ACM, 2022. p. 39–44. DOI: 10.1145/3501774.3501780.

VELEPUCHA, Victor; FLORES, Pamela. A survey on microservices architecture: Principles, patterns and migration challenges. IEEE Access, v. 11, p. 88339–88358, 2023.

VELEPUCHA, Victor; FLORES, Pamela. Monoliths to microservices: Migration problems and challenges: A SMS. In: 2021 Second International Conference on Information Systems and Software Technologies (ICI2ST). IEEE, 2021.

MENARD, Niklas. Decision criteria between microservice and monolithic architecture. 2020.

BAŠKARADA, Saša; NGUYEN, Vivian; KORONIOS, Andy. Microservices architecture: opportunities and practical challenges. Journal of Computer Information Systems, 2020.

CHATURVEDI, Mayank et al. From monolith to microservices: A systematic literature review. In: 2024 IEEE 3rd International Conference on Data, Decision and Systems (ICDDS). IEEE, 2024. p. 1–6.

KALSKE, Miika; MÄKITALO, Niko; MIKKONEN, Tommi. Challenges when moving from monolith to microservice architecture. Cham: Springer International Publishing, 2017. p. 32–47.

NOGUEIRA, Vinicius L. et al. Insights on microservice architecture through the eyes of industry practitioners. In: 2024 IEEE International Conference on Software Maintenance and Evolution (ICSME). IEEE, 2024. p. 765–777.

AUER, Florian et al. From monolithic systems to microservices: An assessment framework. Information and Software Technology, v. 137, p. 106600, 2021.

CARVALHO, Luiz et al. Analysis of the criteria adopted in industry to extract microservices. In: 2019 IEEE/ACM CESI & SER&IP. IEEE, 2019. p. 22–29.

HMUE, Khant; PHYU, Myat Pwint; PAING, Aye Myat Myat. Microservices vs monolith: A comparative analysis and problem-solving approach in web development area. In: 2024 IEEE ICAIT. IEEE, 2024. p. 1–5.

BLINOWSKI, Grzegorz; OJDOWSKA, Anna; PRZYBYŁEK, Adam. Monolithic vs. microservice architecture: A performance and scalability evaluation. IEEE Access, v. 10, p. 20357–20374, 2022.

MENDONÇA, Nabor C. et al. The monolith strikes back: Why Istio migrated from microservices to a monolithic architecture. IEEE Software, v. 38, n. 5, p. 17–22, 2021.

KÖNÖNEN, Heini. Microservices: Considerations before implementation. 2018.

HONCHARUK, Vitalii. Do you really need microservices architecture? 2025.

KRUG, Daniel dos Santos; CHANIN, Rafael; SALES, Afonso. Exploring the pros and cons of monolithic applications versus microservices. In: ICEIS 2024 – Volume 2. 2024.

WANG, Yingying; KADIYALA, Harshavardhan; RUBIN, Julia. Promises and challenges of microservices: An exploratory study. Empirical Software Engineering, v. 26, n. 4, p. 63, 2021.

DI FRANCESCO, Paolo; LAGO, Patricia; MALAVOLTA, Ivano. Migrating towards microservice architectures: An industrial survey. In: 2018 IEEE ICSA. IEEE, 2018. p. 29–2909.

SEEDAT, Momil; ABBAS, Qaisar; AHMAD, Nadeem. Systematic mapping of monolithic applications to microservices architecture. arXiv:2309.03796, 2023.

FRITZSCH, Jonas et al. Microservices migration in industry: Intentions, strategies, and challenges. In: 2019 IEEE ICSME. IEEE, 2019. p. 481–490.

GOUIGOUX, Jean-Philippe; TAMZALIT, Dalila. From monolith to microservices: Lessons learned on an industrial migration to a web oriented architecture. In: 2017 IEEE ICSAW. IEEE, 2017. p. 62–65.

BERRY, Vincent et al. Is it worth migrating a monolith to microservices? An experience report on performance, availability and energy usage. In: 2024 IEEE ICWS. IEEE, 2024. p. 944–954.

HABIB, Pamungkas Imam et al. Architecture migration from monolithic to microservices: Developing readiness criteria. IEEE Access, v. 12, p. 194630–194645, 2024.

CHATURVEDI, Mayank et al. From Monolith to Microservices: A Systematic Literature Survey. In: 2024 IEEE 3rd International Conference on Data, Decision and Systems (ICDDS). IEEE, 2024. p. 1-6.

BAŠKARADA, Saša; NGUYEN, Vivian; KORONIOS, Andy. Architecting microservices: Practical opportunities and challenges. Journal of Computer Information Systems, 2020.

GOUIGOUX, Jean-Philippe; TAMZALIT, Dalila. From monolith to microservices: Lessons learned on an industrial migration to a web oriented architecture. In: 2017 IEEE international conference on software architecture workshops (ICSAW). IEEE, 2017. p. 62-65.