PaperlayerView exact revision on arXiv

Source-linked AI summary

From Monolithic Systems to Microservices: An Assessment Framework

Florian Auer, Valentina Lenarduzzi, Michael Felderer, Davide Taibi

arXiv:1909.08933v3cs.SE

TL;DR

Companies may migrate to Microservices for hoped-for maintainability and team benefits, but re-architecting has economic stakes and needs evidence. The paper combines mapping and practitioner interviews to build a framework of system characteristics and metrics; its findings identify maintainability as the leading migration reason and related metrics as especially important.

  • Problem

    Companies may choose Microservices for expected benefits or trend-following, but re-architecting is economically consequential and calls for evidence about whether benefits can be achieved.

    Source: §1 · p. 2

  • Method

    The study combines a systematic mapping with interviews of experienced practitioners and applies Grounded Theory to develop an evidence-based decision framework.

    Source: §1 · p. 2, §8 · p. 24

  • Results

    Maintainability was the most important migration reason, and maintainability-related metrics were highlighted as the most important metrics.

    Source: §6 · p. 23

  • Takeaways & Limitations

    The framework organizes surveyed characteristics and metrics into ISO/IEC 25010-aligned categories, including functional suitability, reliability, maintainability, cost, and process.

    Source: §6 · p. 22

    Future work includes validating the framework in industrial settings and identifying automatically applicable measures.

    Source: §8 · p. 24

Abstract

from arXiv · show

Context. Re-architecting monolithic systems with Microservices-based architecture is a common trend. Various companies are migrating to Microservices for different reasons. However, making such an important decision like re-architecting an entire system must be based on real facts and not only on gut feelings. Objective. The goal of this work is to propose an evidence-based decision support framework for companies that need to migrate to Microservices, based on the analysis of a set of characteristics and metrics they should collect before re-architecting their monolithic system. Method. We designed this study with a mixed-methods approach combining a Systematic Mapping Study with a survey done in the form of interviews with professionals to derive the assessment framework based on Grounded Theory. Results. We identified a set consisting of information and metrics that companies can use to decide whether to migrate to Microservices or not. The proposed assessment framework, based on the aforementioned metrics, could be useful for companies if they need to migrate to Microservices and do not want to run the risk of failing to consider some important information.

1. Introduction

Companies adopt Microservices for hoped-for maintenance and team benefits, sometimes following a trend, while migration is economically consequential. The paper proposes an evidence-based framework using objective system measures to support migration decisions.

1. Introduction

  • Companies cite improved maintainability and team-responsibility delegation as migration goals, while some migrate to follow a trend.Source: §1 · p. 2
  • Migration has non-negligible economic impact, so re-architecting should rely on solid information about whether expected benefits can be achieved.Source: §1 · p. 2
  • The proposed framework helps companies, especially software architects, decide about migration by evaluating objective system measures and discussing potential benefits and drawbacks.Source: §1 · p. 2
  • The authors interviewed experienced practitioners about characteristics and metrics considered or overlooked before migration, then used Grounded Theory to develop the framework.Source: §1 · pp. 2–3

2. Background

Microservices are independently deployable services, unlike the less autonomous SOA services described here. Their autonomy enables independent development and scaling, but changes system architecture and requires coordination.

2. Background

  • SOA services may share databases or depend on one another, so they cannot be turned on, off, or deployed independently.Source: §2 · p. 3
  • Microservices can use different technology stacks, scale independently, and be deployed on suitable hardware; a service failure need not disrupt the whole system.Source: §2 · p. 3
  • Breaking a monolith into full-stack Microservices changes the system architecture and environment, making coordination among services necessary.Source: §2 · p. 3

3. Related Work

Prior work leaves unclear when companies should migrate to Microservices and which system characteristics favor the move. This section reviews existing evidence, measures, and reported migration effects, then positions the framework as a response to that gap.

3.1. Microservice Migration

  • Prior reviews describe a practice-rooted but immature field, with no large-scale empirical evaluation identified in one review and few examples beyond large corporations.Source: §3.1 · p. 4
  • Related studies agree that when to migrate and which characteristics enable benefits remain unclear; this work responds with characteristics, measures, and an assessment framework.Source: §3.1 · p. 5

3.2. Characteristics and measures investigated in empirical studies on Microservices

  • Studies examine product characteristics, process characteristics, both, and costs; among product characteristics, performance is most frequently addressed, followed by scalability.Source: §3.2 · p. 5
  • The literature review identifies 13 product measures across performance, scalability, availability, and maintenance; response time, request rate, and waiting time are common performance measures.Source: §3.2 · p. 6
  • Process studies examine team independence, continuous delivery, and reusability as Boolean factors for assessing process fit; lacking continuous delivery removes most Microservices benefits.Source: §3.2 · p. 6

3.2.1. Microservices Migration Effects

  • Reported migration effects include reduced performance with containers and at least double CPU path length, while programming-language differences have negligible computational-time impact.Source: §3.2.1 · p. 8
  • Microservices can use resources more precisely under high scalability requirements, but maintenance effort and development effort may rise even as infrastructure costs are lower.Source: §3.2.1 · pp. 8–9

4. The Survey

The survey used interviews with experienced practitioners to examine migration motivations, metrics collected before and after migration, and the perceived usefulness of those metrics. Respondents most often cited maintainability, deployability, and team organization, and generally rated the proposed metrics useful for migration decisions.

4.3. Study Execution

  • The study interviewed 52 experienced practitioners whose Microservices systems were successfully developed and deployed in production; academic participants were excluded.Respondents included developers and project managers, and most reported teams had fewer than 50 members.Source: §4.3 · p. 12, §4.6 · pp. 12–13

4.4. Data Analysis

  • The interview answers were transcribed and coded through open and axial coding, with the authors discussing and resolving coding discrepancies.Ordinal responses were analyzed by scale value rather than converted to numbers; open answers were grouped by similarity.Source: §4.4 · p. 12

4.6.1. Migration Motivations (RQ1)

  • Maintainability (19 of 97 reasons), deployability (12 of 97), and team organization (11 of 97) were the three main migration motivations.Maintainability concerns included complexity, legacy technology, and codebase size; deployability expectations included shorter delivery times, while team organization concerns included autonomy and less synchronization.Source: §4.6.1 · pp. 14–15

4.6.2. Information/metrics collected before and after the migration (RQ2)

  • Before migration, interviewees mentioned 46 information or metric types 107 times; after migration, they mentioned 26 types 66 times.Bugs, complexity, and maintenance effort were the most frequently mentioned in both periods.Source: §4.6.2 · pp. 15–16
  • Four of 16 interviewees who tracked bugs in their monolith did not track the same information in the Microservices-based system.The authors suggest that some information needs may remain important throughout migration.Source: §4.6.2 · pp. 16–17

4.6.3. Information/metrics considered useful (RQ3)

  • Forty-one interviewees considered the proposed factors and measures easy to collect, while 10 did not.Complexity was the most frequently mentioned difficult metric to collect, cited by six interviewees.Source: §4.6.3 · p. 17
  • Forty-nine of 52 interviewees rated the metrics very or extremely useful, and all but three said they support a reasoned choice about whether to migrate.A majority also considered discussion of the metrics before migration very useful.Source: §4.6.3 · p. 17
  • Thirty-four of 52 interviewees said they would consider the proposed information and metrics before migrating another system to Microservices.Source: §4.6.3 · p. 17

5. The Assessment Framework

The framework organizes survey-derived information and metrics into an evidence-based process for assessing a monolith before migration. It structures discussion and measurement but leaves the migration decision to each company’s context.

5. The Assessment Framework

  • The framework draws on a systematic literature study and survey evidence, and is intended to help companies assess migration benefits and issues rather than prescribe a decision.Its categories follow ISO/IEC 25010, with cost and processes added as product-characteristic categories.Source: §5 · p. 19

5.1. Motivations reasons identification

  • Teams should clarify their migration motivation and use the listed quality characteristics as a checklist for problems they hope migration will address.The team should consider whether migration could solve those problems or create more issues than benefits.Source: §5.1 · pp. 19–20

5.2. STEP 2 - Metrics Identification

  • Teams should analyze the existing system using the framework’s metrics, starting with motivation-related measures but discussing the full set for completeness.The metric list is a reference guide, not a complete inventory; sub-characteristics can help investigate a problem such as poor performance.Source: §5.2 · p. 20

5.3. Migration Decisions

  • After discussing the metrics, teams decide whether to migrate; alternatives may address root causes without re-architecting, such as improving an inefficient algorithm or reallocating teams.The framework is tailored to each company’s context.Source: §5 · p. 19, §5.3 · pp. 20, 22

5.4. Migration

  • If a team proceeds, the framework recommends automating measurement and continuously collecting the relevant information identified during metric selection.Source: §5.4 · p. 22

6. Discussion

The discussion finds maintainability is the leading migration reason, while deployability, team organization, and cost also recur. Its framework organizes survey-informed characteristics and metrics, while acknowledging measurement gaps and the need for industrial evaluation.

6. Discussion

  • Interviewees most often cited maintainability, while deployability, team organization, and cost were also frequently mentioned but were less emphasized in previous work.Modularity, complexity, fault tolerance, scalability, and reusability were also mentioned several times.Source: §6 · p. 22
  • The framework aligns survey-informed characteristics with ISO/IEC 25010, using functional suitability, reliability, maintainability, cost, and process as top-level categories.Modularity is a maintainability sub-characteristic, while scalability is a performance-efficiency metric.Source: §6 · p. 22
  • The framework proposes concrete metrics for the identified characteristics, though testability’s effectiveness and efficiency aspects require approximation.Examples include degree of coverage and number of defects covered.Source: §6 · p. 22
  • Maintainability was the most important migration reason, and maintainability-related metrics were also the most important metrics.The most commonly mentioned metrics were number of bugs, complexity, and maintenance effort.Source: §6 · p. 23
  • Practitioners often lack product, process, and cost measurements before migration and discover missing information only during or after it.The framework still requires evaluation and refinement in industrial case studies.Source: §6 · p. 23

7. Threats to Validity

The study reports validity threats for both its Systematic Mapping Study and survey. The survey-related discussion addresses perception-based evidence, respondent scope, question coverage, and the subjectivity of qualitative coding alongside steps taken to support the analysis.

7. Threats to Validity

  • The paper treats validity threats across both parts of its mixed-methods study: the Systematic Mapping Study and the survey.Source: §7 · p. 23

7.1. Threats to Validity regarding the Survey

  • Survey responses reveal respondents’ perceptions, which may not fully represent reality; semi-structured interviews allowed follow-up on unclear statements.A team of four researchers analyzed and quality-checked the responses.Source: §7.1 · p. 23
  • The survey included 52 practitioners interviewed at XP 2018, with experienced respondents only and no academic interviewees; additional responses are needed.The authors considered the conference’s participants broad in domain and the external-validity threats reasonable.Source: §7.1 · pp. 23–24
  • Questions used standard terminology and covered relevant characteristics and metrics; interviews let participants and interviewers clarify uncertainties.Source: §7.1 · p. 24
  • A strict protocol supports replication of survey design, execution, and analysis, but qualitative analysis of open questions remains somewhat subjective.The resulting codes were documented.Source: §7.1 · p. 24

8. Conclusion

The paper proposes an assessment framework based on characteristics and metrics identified through interviews with 52 practitioners. It is intended to help companies discuss whether migration is necessary; industrial validation and automatically applicable measures remain future work.

8. Conclusion

  • The framework’s characteristics and metrics were identified through interviews asking practitioners what they adopted, found useful, or believed should have been considered.Open questions were used to avoid bias from predefined answers.Source: §8 · p. 24
  • The assessment framework supports discussion of whether migration is necessary and may help companies avoid unnecessary migration when refactoring or organizational restructuring could be better options.The interviews involved 52 practitioners with Microservices experience.Source: §8 · p. 24
  • Validation in industrial settings and identification of automatically applicable measures are future work.The proposed measures are intended to provide meaningful information and reduce decision subjectivity.Source: §8 · p. 24
  • The authors propose extending the framework to other cloud-native technologies, including serverless and Micro-Frontends.Source: §8 · p. 25

Appendix: The Survey

This appendix section introduces the questionnaire used in the interviews.

Appendix: The Survey

Demographic information

The demographic questionnaire asks about respondents’ organizational roles and the scale and domain of their work settings.

Demographic information

Project Information

The project-information questions cover the application being developed and the timing of its creation and migration decision.

Project Information

  • Respondents were asked which Microservices-based application their company was developing, when it was first created, and when the company decided to migrate.Source: Project Information · p. 30

Migration Motivations

The section asks why companies migrate and what information or metrics they consider before and after migration. It presents factors and measures for pre-migration assessment and questions whether they are useful, collectable, and suitable for supporting a reasoned choice.

Migration Motivations

Perceived usefulness of the collected Information/Metrics

Migration Information/Metrics

  • The assessment covers scalability and performance measures, including response time, CPU utilization, path length, waiting time, and requests per time interval.It also lists programming-language impact, container usage, and the number of features per microservice.Source: Perceived usefulness of the collected… · p. 31

Perceived usefulness of the collected Information/Metrics

Loading 1909.08933v3…