Microservice Transition and its Granularity Problem: A Systematic Mapping Study

TL;DR

This systematic mapping study explores the transition to microservices, defining key activities, highlighting the granularity problem, and reviewing approaches for reasoning about microservice size and adaptation.

Contribution

It provides a comprehensive definition of microservitization and analyzes current approaches to microservice granularity reasoning, identifying research opportunities.

Findings

Defines microservitization and its activities

Highlights the granularity problem in microservices

Reviews modeling approaches and guidelines for granularity reasoning

Abstract

Microservices have gained wide recognition and acceptance in software industries as an emerging architectural style for autonomic, scalable, and more reliable computing. The transition to microservices has been highly motivated by the need for better alignment of technical design decisions with improving value potentials of architectures. Despite microservices' popularity, research still lacks disciplined understanding of transition and consensus on the principles and activities underlying "micro-ing" architectures. In this paper, we report on a systematic mapping study that consolidates various views, approaches and activities that commonly assist in the transition to microservices. The study aims to provide a better understanding of the transition; it also contributes a working definition of the transition and technical activities underlying it. We term the transition and technical activities leading to microservice architectures as microservitization. We then shed light on a fundamental problem of microservitization: microservice granularity and reasoning about its adaptation as first-class entities. This study reviews state-of-the-art and -practice related to reasoning about microservice granularity; it reviews modelling approaches, aspects considered, guidelines and processes used to reason about microservice granularity. This study identifies opportunities for future research and development related to reasoning about microservice granularity.

Tables

Table 1. Table 1. Inferred classification framework used to classify the included publications in our study

Research Question	Category	Keywords
What activities are undertaken to adopt microservices?	Architectural design	architectural style, communication mechanism, boundaries, orchestration, service choreography, service registration, service discovery, design patterns, proxy, bulkhead, circuit breaker, router, routing
	Organisation	Conway’s law, decentralised governance, cross-functional teams, hierarchical teams
	Operation	Devops, NoOps, configuration settings, operation
	Deployment	Continuous integration, CICD, continuous deployment, deployment pipeline, automated deployment, virtualisation, hypervisors, containerisation, configuration provider
	Development	Heterogenous tools, agile development, extreme programming
	Monitoring	Regression unit testing, health monitoring, cluster monitoring, troubleshooting, debugging, failure
	Logging	central logging, decentralised logging, profiling, tracing
What modelling approaches are used to define the granularity of a microservice?	Structural	Domain-driven, classes, instances, resources, components, message format, data item, topology, service dependency, nodes, type definition
	Behavioural	Event flow, message stream, activity flow, communication flow, event triggers, execution timeline, use cases
Which quality attributes are considered when reasoning about microservice granularity and how are they captured?	Performance	QoS, efficiency, service contracts, SLA, performance, response time, throughput, performance bottleneck, invocation duration, transaction duration, customer value
	Reliability	Fault tolerance, disaster recovery, single point of failure, resilience, robustness, failure rate, error rate
	Scalability	Auto-scale, scalable, scaling, load balancing, load distribution, completed transactions per second
	Maintainability	Maintainable, changeable, maintenance cost, maintenance overhead, adaptability, changeability, effort cost, expandability, dynamicity
	Complexity	Communication overhead, complexity cost, development cost, tight coupling, low cohesion
How is reasoning about microservice granularity described?	Guidelines	Two-pizza team, lines of code, half-life, agile manifesto, one task, single responsibility, fine-grained functionality, separation of business concerns, high cohesion, loose coupling
	Processes	Iterative, strangler pattern

Table 2. Table 2. Representative examples of publications included in the systematic mapping study

Research Question	Category	Representative Examples
What activities are undertaken to adopt microservices?	Architectural design	(162; 133; 104; 105; 150; 263; 179; 170; 221; 207; 77; 8)
	Organisation	(272; 124; 184; 18; 203; 172; 264; 68; 261; 10)
	Operation	(27; 80; 76; 37; 217; 58; 243; 175; 49; 83; 249; 18)
	Deployment	(123; 154; 269; 31; 78; 47; 262; 205; 242; 267)
	Development	(191; 174; 222; 198; 156; 239; 74; 98; 230; 7; 9)
	Monitoring	(110; 219; 95; 84; 36)
	Logging	(213)
What modelling approaches are used to define the granularity of a microservice?	Structural	(75; 116; 228; 245; 196; 167; 89; 119; 86)
	Behavioural	(202; 88; 96; 19)
Which quality attributes are considered when reasoning about microservice granularity and how are they captured?	Performance	(168; 113; 135; 33; 224)
	Reliability	(161; 64; 197; 32)
	Scalability	(121; 142; 103; 128; 3)
	Maintainability	(173; 2)
	Complexity	(157; 246; 55; 127)
How is reasoning about microservice granularity described?	Guidelines	(35; 250; 199; 226; 201; 216; 140; 26; 236)
	Processes	(87; 86; 204; 185; 192; 193; 225; 112)

Table 3. Table 3. Analysing publications that attempt to define the transition to microservices included in the systematic mapping study; a check means the publication includes the activity in the corresponding column

Microservice Adoption Activity
Publication	Architectural design	Organisation	Operation	Deployment	Development	Monitoring	Logging
(241)	✓	✓		✓
(141)				✓
(195)	✓	✓	✓
(265)	✓					✓	✓
(85)	✓	✓		✓		✓	✓
(130)				✓
(70)					✓
(212)	✓	✓				✓
(160)	✓	✓			✓
(17)	✓		✓	✓	✓	✓	✓
(107)	✓
(91)	✓				✓	✓
(120)		✓		✓
(117)	✓		✓		✓
(4)				✓	✓
(236)	✓

Full text

Microservices, software economics, systematic mapping study, design decision support, granularity

††doi: 0000001.0000001††ccs: General and reference Surveys and overviews††ccs: Software and its engineering Extra-functional properties††ccs: Software and its engineering Designing software††ccs: Software and its engineering Software design tradeoffs††ccs: Software and its engineering Abstraction, modeling and modularity††ccs: Software and its engineering Software design engineering††ccs: Software and its engineering Agile software development††ccs: Software and its engineering Publish-subscribe / event-based architectures††ccs: Software and its engineering Model-driven software engineering††ccs: Software and its engineering Ultra-large-scale systems††ccs: Software and its engineering Rapid application development††ccs: Software and its engineering Design patterns

1. Introduction

Several industries have migrated their applications (or actively considering migrating) to microservices (63; 232; 99; 199; 108; 194; 218; 255; 39; 194; 102). The transition to microservices has not been purely driven by technical objectives; the transition requires careful alignment of the technical design decisions with the business ones. The ultimate objective of this alignment is to enhance utilities of the application’s software architecture and to improve its value potentials. For example, among the technical design decisions is isolating business functionalities into microservices that interact through standardised interfaces. Isolation motivated only by technical objectives can lead to aggressive decomposition of functionalities favouring service autonomy without considering its impact on value potentials. However, isolation motivated by technical and business objectives can be more informed. It can enhance utilities such as autonomy, replaceability and decentralised governance (among other utilities) to improve the microservice architecture’s ability in coping with operation, maintenance and evolution uncertainties. Ultimately, this can also relate to improved maintenance costs and cost-effective quality of service (QoS) provision to end users; these are examples of improved value potentials in the architecture.

Due to the recency of microservices, they have a multitude of definitions; each definition captures different properties of microservices. Definitions mostly agree that the fundamental properties of microservices include enabling facilitated improvement of component characteristics — autonomy, replaceability, independent deployability — and of architectural characteristics — improved reliability, scalability, resilience to failure, availability, and evolvability (146; 132; 211; 102; 90; 17; 109; 141; 166; 164; 134; 212). In essence, these definitions capture some drivers of the transition to microservices aimed at enhancing utility in the application’s software architecture. The utility enhanced through the transition can render benefits that can cross-cut architectural design, testing, maintenance and service management (61). For example, microservice autonomy allows the architects to easily locate, implement and test necessary service amendments (102). Microservice replaceability allows architects to confidently and independently add and/or manage new business functionalities over the system lifetime (102).

The transition to microservices can help the application in better meeting its quality of services (QoS) requirements; this may consequently result into improved compliance with service level agreements for QoS, potential economics gains, and better alignment with the business objectives of microservice adopters (102). Because of their “micro” character, microservices can be mobilised to the benefit of several service-oriented applications that can require “lighter weight” processing (e.g., mobile services and Internet-of-Things (IoT)) (102).

Despite the industrial push towards microservices, there is no disciplined understanding of their transition nor consensus on the principles and activities underlying the transition (96). A disciplined understanding of the transition is of paramount importance to inform and/or to justify its technical activities by aligning them with their added value and cost. Currently however, the state-of-the-practice in microservice adoption lacks appropriate methods and techniques that can justify value added of technical design decisions. For example, the software architect can be equipped with mechanisms and tools that can enhance replaceability by standardising the communication paradigms across microservices (171; 255). Reasoning about the added value and possible cost becomes essential to justify this technical design decision regarding communication paradigms.

This paper is an attempt for a better understanding of the transition to microservices. It conducts a systematic study to consolidate various views about microservices; it then uses the study results to contribute to a well-rounded working definition describing the transition and technical activities of the transition to microservice architectures. We term the transition and technical activities leading to microservice architectures as microservitization.

This working definition has explicitly considered a fundamental problem of microservitization: reasoning about the granularity of a microservice (i.e. whether a microservice should be decomposed/merged further or not). A granularity level determines ”the service size and the scope of functionality a service exposes (136, p.426).” Granularity adaptation entails merging or decomposing microservices thereby moving to a finer or more coarse grained granularity level.

Determining the granularity level too early in the software architecture’s lifetime can lead to problems in reasoning about microservices (120; 5). This problem is of significance both in brownfield and greenfield development (63). In both fields, a suitable granularity level is paramount to inform choosing concrete services from a plethora of COTS microservices.

”A systematic mapping study allows the evidence in a domain to be plotted at a high level of granularity. This allows for the identification of evidence clusters and evidence deserts to direct the focus of future systematic reviews and to identify areas for more primary studies to be conducted (125, p.5).” Directing the focus of future systematic reviews aligns with our aforementioned objectives. Ultimately, our attempt at defining the transition to microservices (Objective 1 above) will pave the way for future development and research related to microservice transition. Furthermore, understanding the problem of reasoning about microservice granularity (Objective 2 above) allows identifying areas for future primary studies. Since the examined literature regarding microservices spanned a broad variety of aspects, we found a systematic mapping study to be suitable given the amount of reviewed literature (125).

In Section 2 we describe the steps we followed in the systematic mapping study. In Section 3 we report and briefly analyse our mapping study results. In Section 4 we use this analysis to: (1) present our working definition for the transition to microservices (Section 4.1) and (2) identify gaps in the state-of-the-art and -practice related to reasoning about microservice granularity (Section 4.2). Overall, the identified gaps motivate the need for:

• •

Microservice-specific modelling support potentially using an architecture definition language (ADL) that ”treats microservice boundaries as adaptable first-class entities (101, p.2)” thereby facilitating runtime analysis of microservice granularity in a systematic architecture-oriented manner (101).

• •

A dynamic architectural evaluation approach that captures two dimensions under uncertainty at runtime: added value to be introduced and cost to be incurred if the granularity of microservice architectures is adapted.

• •

Effective decision support that should systematically guide the software architects towards suitable granularity adaptation strategies at runtime or suggest re-visiting their expectations of the architecture’s runtime environment.

In Section 6 we compare and contrast related literature reviews, studies and surveys in the field of microservices against our systematic mapping study. In Section 5 we reflect on threats to the validity of our study. In Section 7 we summarise contributions that are not directly linked to microservices but can be relevant to their emergence and development. In Section 8 we conclude by summarising the results of our systematic mapping study.

2. Systematic Mapping Study Process

The process we follow in our mapping study is inspired by guidelines from (125). In the subsections below, we describe our application of each stage of this process.

2.1. Research Questions

Overall, this paper conducts a systematic mapping study to address the following objectives:

• •

Objective 1: providing a better understanding of the transition to microservices — we consolidate various views (industrial, research/academic) of the principles, methods and techniques that are commonly adopted to assist the transition to microservices. This consolidation allows us to reach a working definition for the transition to microservices; we term this transition microservitization.

• •

Objective 2: understanding a fundamental problem of the transition to microservices related to reasoning about their granularity — we review state-of-the-art and -practice related to reasoning about microservice granularity. This review allows us to understand the state-of-the-art and -practice in the modelling approaches, aspects considered, guidelines and processes used to reason about microservice granularity.

Given these objectives, we reify them into the following research questions. Along with each question we outline the rationale behind it.

Objective 1: Providing a better understanding of the transition to microservices

• •

What are the activities undertaken to adopt microservices? This question helps understand the principles, methods and techniques of the transition to microservices by digesting experiences of microservice adopters in industry and in academic research.

Objective 2: Understanding a fundamental problem of the transition to microservices related to reasoning about their granularity

• •

What are the modelling approaches used to define the granularity of a microservice? The aim of this question is to identify the support provided by microservice-specific models for reasoning about granularity and to investigate how systematic (i.e. standardised and methodological) these models are.

• •

Which quality attributes are considered when reasoning about microservice granularity and how are they captured? The aim of this question is to elicit the possible trade-offs which software architects need to balance when reasoning about microservice granularity and/or how these trade-offs can be captured objectively.

• •

How is reasoning about microservice granularity described? The aim of this question is to explore the state of the art regarding triggers and steps of microservice granularity adaptation and their suitability to the dynamic microservice environment.

2.2. Search Strategy

The terms used when searching for English publications were ”microservice” and ”micro-service”; Google Scholar, ACM Digital Library, IEEE Xplore, ScienceDirect, SpringerLink and Wiley InterScience were used during this search. Our scope of publications includes journals, theses, books, conferences, workshops, blog articles, presentations, and videos. For academic publications, snowballing was applied (190) to further extract relevant literature. Non-academic publications were included since most industrial experiences regarding microservices were published in these forms. We made our best effort however to only include articles that either transcribe the view of adopters or ones where the author is the opinion holder. We believe answering the research questions above comprehensively requires examining both academic and non-academic experiences with microservices. This broad scope also aligns with a property of systematic mapping studies — aiming for broad coverage rather than narrow focus (125). Our search was restricted to publications between 2013 and 2018, since the microservice trend had not emerged prior to that; non-academic literature started to appear in 2013 (244) while peer-reviewed publications started to appear in 2014 (91). Meta-data of the search results was maintained using a tool called ”Publish or Perish” (186).

2.3. Selection of Primary Studies

Initially, the search results were examined for relevance according to inclusion and exclusion criteria below. Each research question elicited in Section 2.1 has corresponding inclusion/exclusion criteria (their structure is inspired by (189)). Along with each criterion is the rationale justifying it italicised.

*What activities are undertaken to adopt microservices?

***Inclusion Criteria:

**

• •

Publications generically presenting the challenges of adopting microservices since they can be used to infer the activities comprising the transition to microservices.

• •

Case studies of adopting microservices are used to complement and verify the activities in generic publications.

• •

Publications comparing specific development tools in the microservice industry because they can be used to infer activities comprising the transition.

**Exclusion Criteria:

**

• •

Publications without any reference to microservices. Including such publications would confuse rather than clarify understanding the transition to microservices. This is against Objective 1 of our study.

• •

Publications that refer to servitization in the business not the software context since we are only concerned about the activities of shifting a software system from another architectural style to microservices.

*What modelling approaches are used to define the granularity of a microservice?

***Inclusion Criteria:

**

• •

Publications defining formal notations/diagrams for modelling microservices. Such publications can be used to assess how systematic the state-of-the-art is for modelling microservice granularity.

• •

Proposals of modelling concepts for microservices. Even when unverified, a proposed modelling concept can provide an insight for the building units of reasoning about microservice granularity.

• •

Publications presenting industrial case studies for modelling microservices. Such publications would verify and illustrate the expressiveness of proposed modelling concepts to microservice granularity.

**Exclusion Criteria:

**

• •

Papers which provide binding and re-configuration solutions for SOAs/web-services/mobile services only are excluded since they do not capture the properties specific to microservices, hence they are not suited for reasoning about microservice-specific decision problems (in this case microservice granularity).

• •

Papers which provide modelling approaches for SOAs/web-services/mobile services are excluded since they do not capture properties specific to microservices, hence they are not suited for reasoning about microservice-specific decision problems (in this case microservice granularity).

*Which quality attributes are considered when reasoning about microservice granularity and how are they captured?

***Inclusion Criteria:

**

• •

Publications presenting metrics used when reasoning about microservice granularity. Such publications would help assess how objectively the trade-offs affecting microservice granularity are captured in academia and/or industry.

• •

Case studies involving the quality drivers considered when reasoning about granularity. Such publications would realistically capture the significance of specific trade-offs when reasoning about granularity adaptation.

• •

Publications focused on vendor-specific comparisons between platforms supporting reasoning about microservice granularity. This can help derive the quality attributes and metrics considered when reasoning about granularity.

**Exclusion Criteria:

**

• •

Case studies that do not explicitly relate a challenge to its impact on microservice granularity. Since case studies report concrete challenges and trade-offs impacting them, it is unreasonable to claim an impact of a reported trade-off on granularity if that is not reported explicitly in a case study.

*How is reasoning about microservice granularity described?

***Inclusion Criteria:

**

• •

Publications including guidelines for reasoning about microservice granularity. This helps to identify the state-of-the-art regarding triggers and/or steps for granularity adaptation.

• •

Publications showing a sequence of when and how granularity is reasoned about in the application’s lifecycle. These publications help assess how much the state-of-the-practice considers dynamicity in microservice environments when reasoning about granularity adaptation.

**Exclusion Criteria:

**

• •

Publications that provide generic best practices for the granularity of applications with no reference to microservices (e.g. related to web services, SOA, mobile services). Such best practices are not targeted specifically at microservices, so it would not be reasonable to use them in the context of microservice granularity.

2.4. Keywords and Classification

”The purpose of this stage is to classify papers with sufficient detail to answer the broad research questions and identify papers for later reviews without being a time consuming task (125, p.44).” Here we classify the included publications according to two classification frameworks. Initially, we classify them according to the following research approaches, elicited from (260):

• •

Evaluation research: these investigate the significance of a problem and/or investigate the feasibility of a contribution in practice.

• •

Opinion papers: ”these contain the author’s opinion about what is wrong or good about something, how we should do something, etc (260, p.105)”.

• •

Solution proposals: these ”propose a solution technique and argue for its relevance, without a full-blown validation. The technique must be novel, or at least a significant improvement of an existing technique. A proof-of-concept may be offered by means of a small example, a sound argument, or by some other means (180, p.86).”

• •

Experience paper: in these publications ”the emphasis is on what and not on why. The experience may concern one project or more, but it must be the author’s personal experience (260, p.105).” Such papers should ”contain a list of lessons learned by the author from his or her experience. Papers in this category will often come from industry practitioners or from researchers who have used their tools in practice, and the experience will be reported without a discussion of research methods. The evidence presented in the paper can be anecdotal (260, p.106).”

• •

Validation research: such papers validate solution proposals which ”may have been proposed elsewhere, by the author or by someone else. The investigation uses a thorough, methodologically sound research setup. Possible research methods are experiments, simulation, prototyping, mathematical analysis, mathematical proof of properties, etc (260, p.105).”

• •

Philosophical paper: ”these papers sketch a new way of looking at things, a new conceptual framework, etc (260, p.105).”

The second classification framework entails categorising the publications under categories derived from our research questions of concern. A publication belongs in a category if it contains any of the corresponding keywords identified in Table LABEL:categories.

The identification of the keywords is inspired by a microservice-specific systematic mapping study (5) and refined iteratively as more publications were examined. It is worth noting that for all the included publications, we manually categorised them to ensure that synonyms or partial matches of these keywords are accurately handled. We justify the keywords (italicised below) under each category as follows: What activities were undertaken to adopt microservices?

• •

Architectural design: publications in this category are concerned with all the technical activities which comprise adopting microservices. We use this category to verify whether or not microservice adopters call microservices an architectural style and/or design pattern. Choosing the generic communication paradigm of the architecture (e.g., orchestration, choreography) and the more concrete message exchange pattern (e.g., using a router/proxy) are also among the technical activities of microservice adoption. In addition, the boundaries of the system and individual components of the system is a technical design decision when moving to microservices. The fault tolerance mechanisms of the system also need to be identified (e.g. bulkhead and circuit breaker patterns). Because microservice applications are highly distributed and scalable, 2 additional technical decisions are critical in microservitization: service registration and service discovery.

• •

Organisation: in this category we are concerned with the organisational impact of adopting microservices. The state-of-the-practice in the microservice industry is to motivate decentralised governance (i.e. holding the responsibility of building and running (22)) through microservitization (146). The three most common means of achieving that is through following Conway’s law (146), cross-functional teams, or hierarchical teams (109). Conway’s law states ”organisations which design systems … are constrained to produce designs which are copies of the communication structures of these organisations (57).”

• •

Operation: publications in this category are concerned with identifying how the system will be governed post-deployment. This includes defining who is responsible for this governance to begin with. The state-of-the-practice is in the microservice industry is 2 alternative approaches: DevOps where the governance is shared across a development team and an operations team; and NoOps, where the governance is fully the responsibility of the development team. In addition, operational activities include defining the configuration settings and configuration provider which the governor of the microservice application needs to follow or in different runtime situations.

• •

Deployment: this category includes publications that define the activities constituting the deployment pipeline of the microservice application. The state-of-the-practice in the microservice industry is 2 alternative approaches (257; 53): continuous integration and continuous delivery (abbreviated as CICD), and automated deployment. ”Continuous integration is a coding philosophy and set of practices that drive development teams to implement small changes and check in code to version control repositories frequently (210).” ”Continuous delivery picks up where continuous integration ends. CD automates the delivery of applications to selected infrastructure environments (210).” ”Deployment automation allows applications to be deployed across the various environments used in the development process, as well as the final production environments (71).” Regardless of the deployment pipeline, the host on which this pipeline is enforced is another critical decision in this category. The 3 most common approaches for deploying microservices are virtualisation, using hypervisors and/or containerisation.

• •

Development: publications in this category describe how the transition to microservices impacts software development practices. The state-of-the-practice in microservice development is adopting extreme programming and agile practices using heterogenous tools (e.g., Kubernetes, Istio, Springboot, fabric8).

• •

Monitoring: publications in this category are concerned with identifying the alternative rationales of runtime monitoring (e.g. health, cluster) of microservice application and the alternative approaches which support monitoring (e.g. regression unit testing, troubleshooting, debugging and failure identification).

• •

Logging: in this category we are concerned with where the monitoring results are to be stored (alternatively called profiling and tracing). The 2 alternative approaches to this in the microservice industry as we have examined are central or decentralised logging.

What modelling approaches are used to define the granularity of a microservice?

• •

Structural: publications in this category are concerned about contributions that capture the structure (alternatively called topology) of the microservice architecture. Depending on the nature of the contribution (e.g., domain-driven (75)), the units of this structure differ (e.g. classes, instances, resources, components, data items, messages, and/or nodes). Modelling these units includes capturing the dependencies across those units and their types.

• •

Behavioural: alternative to the approach above, publications in this category capture the sequence of actions in the microservice application rather the structure of the units constituting the application. This sequence can be in the form of events, messages, activities, communication, execution steps and/or use cases.

Which quality attributes are considered when reasoning about microservice granularity and how are they captured?

• •

Performance: wherever the main driving force of reasoning about granularity is performance (alternatively called QoS, long-term value, efficiency or customer value), the publication is put under this category. There means of capturing this objectively include response time, throughput, invocation duration, identifying the performance bottlenecks and/or transaction duration. Thresholds on these metrics are captured in service contracts, service level agreements (abbreviated as SLAs). We subsume service contracts as ”an agreement between the a consumer and provider service about the format of data that they transfer between each other. Normally, the format of the contract is defined by the consumer and shared with the corresponding provider. Afterwards, tests are being implemented in order to verify that the contract is being kept (169).”

• •

Reliability: publications that imply or explicitly focus on enhancing reliability as the primary driving force when reasoning about granularity are included in this category. Reliability entails exhibiting fault tolerance, disaster recovery, resilience, eliminating single points of failure and/or robustness. Reliability is captured objectively in terms of failure/error rate.

• •

Scalability: publications that reason about granularity in terms of how it enhances the scalability of the architecture are included in this category. Exhibiting scalability entails employing strategies such as auto-scaling, load balancing and/or load distribution. Measuring scalability objectively can be done by looking at the number of completed transactions per second (or per unit of time more generally).

• •

Maintainability: exhibiting maintainability entails exhibiting adaptability, changeability, expandability and/or dynamicity. These properties are objectively captured in terms of maintenance cost, maintenance overhead, and/or effort cost. Publications concerned with reasoning about granularity in terms of enhancing maintainability are included in this category.

• •

Complexity: minimising complexity entails following 2 crucial design principles: tight coupling and/or low cohesion. This is measured in terms of communication overhead, complexity cost, and/or development cost. Publications where reasoning about granularity considers and/or measures its complexity are included in this category.

How is reasoning about microservice granularity described?

• •

Guidelines: publications under this category provide decision-making strategies for reasoning about granularity regardless of the steps of applying these strategies. The keywords under this category capture the state-of-the-practice guidelines.

• •

Processes: publications under this category are more elaborate in the sense that they enrich the granularity adaptation strategies with a sequence for applying them. The keywords under this category capture the alternative state-of-the-practice processes encountered for reasoning about microservice granularity.

2.5. Data Synthesis

RSS feeds and manual search were used to obtain publications complying with the strategy defined in Section 2.2. The results were then manually examined for inclusion and categorised according to the criteria and frameworks described above (Sections 2.3 and 2.4 respectively).

3. Result Reporting and Analysis

In this section we present graphs summarising distributions of the included publications along the categories described in Table LABEL:categories. For each graph, we discuss how it helps serve the objectives outlined in Section 1.

3.1. Publication Distribution Overview

A total of 560 publications met the inclusion criteria in Section 2.3. Table LABEL:examples lists representative examples of the included publications categorised according to Table LABEL:categories. Figure 1 shows the overall distribution of the publications according to the publication type.

As justified in Section 2, we widened the scope of our study to include both academic and industrial publications. Broadly, we consider a publication type to be academic if it has gone through editing or peer-revision (the red bars in Figure 1); about 62% of the included publications. On the other hand, non-academic publications account for about 38% of the total. Although the majority of publications are academic, non-academic literature still comprises a significant percentage. Had we excluded these publications, attempting a definition for microservitization (Objective 1 in Section 1) would have been biased. The exclusion of non-academic sources would lead to missing relevant keywords related to each category and the coverage of industrial opinions and experiences related to microservice adoption would be narrower.

We further classify peer-reviewed publications according to a highly-cited paper classification framework (260) which targets IEEE papers. This framework classifies papers according to their research approach; a brief description of each approach is presented in Section 2. This framework has been applied before in the context of microservices (5), so we consider it a neat fit for our study. To match the target context of the framework, we only apply it to peer-reviewed publications (Figure 2).

Solution proposals by far comprise the largest number of peer-reviewed publications. Solution proposals present novel, significant techniques without a full-blown validation. A proof-of-concept may be offered in solution proposals by means of a small example, a sound argument, or by some other means (260). Therefore, the microservices trend is a thriving field for novelty but it is still lacking maturity. Validation research publications — which thoroughly investigate solution proposals (260) — only amounted to 43 publications, which further proves the lack of maturity in the field. The large difference between the solutions proposals and validation research publications proves the need for disciplining the transition to microservices. The following subsections further discuss this need then focus on one of the fundamental problems of the transition — reasoning about microservice granularity.

3.2. Objective 1: Providing a Better Understanding of the Transition to Microservices

Figure 3 classifies the publications which include keywords related to: what are the activities undertaken to adopt microservices? Architectural design and managing deployment are the most popular activities undertaken when adopting microservices. Therefore, we infer they are crucial activities in the transition to microservices. Nevertheless, there is a significant number of publications in the other categories of Figure 3. The variation in number of publications across categories of Figure 3 implies there is no consensus in describing the transition to microservices. This leaves room for us to contribute the microservitization term which attempts to provide a better understanding of the transition to microservices.

3.3. Objective 2: Understanding the Microservice Granularity Problem

One of the fundamental problems of the transition to microservices is finalising their level of granularity (241; 85; 105; 150; 170; 63). Architecture definition language (ADL) classification frameworks (149) indicate that structural (or ”topological (149, p.26)”) as well behavioural aspects of an architecture need to be modelled. Figure 4 helps to clearly identify the state-of-the-practice in modelling microservices; to answer what are the modelling approaches used to define the granularity of a microservice? The structural modelling approaches proposed for microservices are almost double the behavioural approaches. Structural approaches capture the topology and/or dependencies across building units of the microservice architecture. On the other hand, behavioural approaches capture the actions of these units in several runtime scenarios in which the modelled microservice operates. Therefore, a systematic, architecture-oriented modelling approach for microservice architectures which facilitates reasoning about granularity needs to capture the architecture’s structural and behavioural aspects. The difference in numbers between structural- and behavioural-oriented publications in Figure 4 indicates that there is a lack in modelling approaches that capture both aspects of a microservice architecture.

Figure 5 classifies publications according to the quality attributes they aim to optimise when reasoning about microservice granularity; to answer which quality attributes are considered when reasoning about microservice granularity and how are they captured? In other words, they can be the most common means to introduce utility through cost-effective microservitization. Scalability is the most common quality considered in the examined literature. This is reasonable given the dynamic, large-scale environment in which microservices operate (99; 255; 109; 39; 199; 96; 34; 218; 56; 232). Therefore, we infer that scalability can introduce added value to most microservice architectures. Relatively few publications have considered complexity/cost when reasoning about microservice granularity. Therefore, there is room for contributing to dynamic decision support which objectively considers both the potential value and cost of decisions related to microservice granularity (i.e. adapting granularity by decomposing or merging microservices).

Figure 6 classifies proposed approaches for reasoning about microservice granularity according to how they are described; this answers how is reasoning about microservice granularity described? Most of the proposed approaches are ad-hoc guidelines that could be applied differently at various points of the microservice application’s lifecycle. However, effective decision support for microservice granularity should comprise a clear sequence of distinct steps to be triggered under clear conditions. We have not found such effective support even in the 30 publications proposing a process to reason about microservice granularity. Therefore, we infer that there is a lack in effective decision support for reasoning about microservice granularity in terms of clear adaptation steps and triggers.

4. Addressing Systematic Mapping Study Objectives

In Section 4.1 we contribute to an empirically grounded working definition for the transition to microservices; we call this transition microservitization. In Section 4.2, we identify the gaps in state-of-the-art and -practice related to reasoning about microservice granularity (inferred from Section 3) and discuss how they can be addressed.

4.1. Objective 1: Providing a Better Understanding of the Transition to Microservices

We have not found in the surveyed publications an empirically grounded definition which characterises the transition to microservices, but rather several conflicting, informal attempts coming from industry and academia. Table LABEL:definitions analyses these attempts in terms of whether or not they explicitly include the activities derived from the microservice-specific systematic mapping study (5) and described in Section 2.4. It is worth noting that the attempts analysed in this table are just a fraction of the publications summarised in Figure 3. In Table LABEL:definitions we focus on the explicit attempts to define the transition to microservices, while Figure 3 includes both explicit attempts to define the transition and case studies of microservice adoption which do not explicitly attempt to define the transition.

Observing Table LABEL:definitions, we introduce a definition for the transition to microservices (adapted from the activities included in (5)) which we call microservitization to cover all the relevant activities of the transition to microservices. This definition is adapted from activities included in (5) and inspired by a trending concept in business and manufacturing domains (153) — servitization.

In the manufacturing and business domains, servitization is seen as a paradigm shift entailing “manufacturers growing their revenues and profits through services (15)” rather than tangible functional products. A service in this context is any feature that helps the business to (1) “really make money” and (2) deliver new outcomes to customers. Examples of services in servitization include software applications, customer support, and self-service capabilities (248).

Servitization “embraces business model innovation, organisational change, and new technology adoption. Services exist in various forms, and represent differing values to both the customer and provider (15)”. To benefit from these values, servitization involves developing new relationships with customers, innovating customer value propositions, forming new value chain relationships, and adapting business models (15; 227; 16; 60). The key to successful servitization is “choosing the right technology, picking the appropriate moment to invest, and ensuring successful implementation (14)” which aligns with the business objectives (248).

We liken the transition to microservices to servitization because of the following resemblances:

• •

Servitization is driven by delivering new outcomes to customers which can translate into revenues and profits. Similarly, the transition to microservices is driven by improving QoS provision to end users and translating that into an economic gain.

• •

Servitization entails embracing innovation in the manufacturing activities (e.g., building business models and defining customer value propositions) are carried out. Similarly, the transition to microservices entails a dramatic change (motivated by value creation) to the way technical activities manifested in the software architecture are carried out.

Therefore, we define microservitization as a form of servitization where ”services/components are transformed into microservices — a more fine-grained and autonomic form of services (101, p.1)” — to introduce added value to the architecture (102). ”Microservitization is also an example of a paradigm shift (101, p.1)” since it involves dramatically changing how the following technical activities are carried out to align them with a microservice adopter’s business objectives:

• •

Architectural design: microservitization introduces the following critical architectural design activities:

• –

Choosing light-weight communication mechanisms: microservitization can increase the distribution of functionalities across the architecture thereby introducing extra communication calls between microservices (96). Therefore, rather than relying on enterprise service buses (which are the state-of-the-practice in SOA architectures), more light-weight mechanisms such as pipes and filters, event-based queues, and correlation identifiers are critical to avoid very high communication costs in microservice architectures. The large number of microservices can lead to a large volume of message exchange and hence high communication costs.

• –

Reasoning about microservice granularity levels: a suitable granularity level is paramount to inform buying commercial-off-the-shelf (COTS) concrete services or developing them in-house (102). Choosing these services correctly is critical to introducing added value to the microservice architecture.

• –

Adopting fault tolerance design patterns: although striving for fault tolerance is a best practice in any architecture, investing in fault tolerance design patterns is all the more critical to microservitization. The criticality is due to the scale of industries adopting microservices (e.g., retail (240), entertainment (243; 99)) where microservices span different continents with a wide variety of end users. Microservice-specific fault tolerance design patterns include circuit breakers and bulkheads.

• –

Incorporating microservice registration and discovery mechanisms: microservices are typically developed, deployed and replaced at a very quick rate (96). Therefore, it is critical to incorporate robust registry and discovery mechanisms in microservice architectures to ensure an up to date record of the currently “alive” microservices.

• •

Managing the organisational hierarchy: microservitization has a direct impact on the organisational hierarchy (163). In particular, the autonomy and independent deployability enhanced in the architecture through microservitization facilitate decentralised governance by breaking “silos” (based around strict separation of job roles) in the organisation.

• •

Operation: microservitization aligns operation management with breaking organisational “silos”. DevOps and NoOps are among the state-of-the-practice operation management approaches in microservitization; they involve ”a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality (21)”. Decentralised operation management can reduce the risk of bottlenecks that can materialise into economic losses to the microservice adopter. Reducing this risk is conditional upon development operation teams adhering to service level agreements between them.

• •

Deployment: microservitization introduces a critical challenge of determining the hosts on which a deployment pipeline is implemented (163). This is critical to balancing between the added value of microservitization and cost that can be introduced by a deployment pipeline implementation choice (e.g., physical link installation, server rental and maintenance costs). Virtualisation and containerisation are among the common deployment pipeline implementation choices. They can enable swift auto-scaling the microservice architecture in response to changes in its runtime environment; this can materialise into economic gains for competitive microservice adopters.

• •

Development: unlike other software development paradigms, microservitization enables freedom in choosing development tools which can in turn introduce more added value to the architecture (5). This freedom is a bi-product of the decentralised governance enabled by microservitization. It is worth noting that communication and knowledge sharing across teams using different development tools needs to be carefully managed to ensure this freedom actually introduces added value.

• •

Monitoring: microservitization requires much more robust, decentralised and customisable monitoring than that of classical SOAs due to the heterogeneity of tools used to develop microservices and scale at which they typically operate (96). These requirements are critical to cater for the heterogeneity, scale and dynamism of microservice architectures.

• •

Logging: maintaining logs of the monitoring data needs to be more customisable and distributable than logging classical SOAs due to the heterogeneity of tools used to develop microservices and scale at which they typically operate (96). This requirements are aligned with the aforementioned monitoring challenges introduced by microservitization.

4.2. Objective 2: Understanding the Microservice Granularity Problem

Based on our definition above, microservitization introduces the challenge of reasoning about the suitable granularity level of a microservice.

To formalise the microservice granularity problem, the gap we identified is the lack of an architecture-oriented modelling approach that captures a microservice’s granularity behaviour, thereby supporting runtime analysis of this behaviour. The approach should treat microservice boundaries as the primitives for formulating the microservice granularity decision problem and actuators of microservice granularity adaptation decisions. These decisions include merging multiple microservices into a single boundary and decomposing a microservice into multiple ones encapsulated by multiple boundaries. In other words, this approach should treat microservice boundaries as adaptable first-class entities to ensure that both the structural and behavioural aspects of the microservice architecture are captured; we contribute to this approach in (101). While conducting our study, we have seen architecture-oriented modelling approaches that treat the notion of boundaries statically (e.g., (233)), or provide support for adaptability but without explicitly capturing the notion of adaptable boundaries (e.g., (129)). Because the role of microservices is to encapsulate functionality, it is intuitive to use boundaries as adaptable first-class entities in the modelling approach. By contrast, if the decision problem was to determine the optimal physical infrastructure to host the microservice for example, the adaptable first-class entity would be different (e.g., microservice configuration variables).

To reason about microservice granularity objectively and dynamically, the gap we identified is the lack for an architectural evaluation approach that captures two aspects explicitly: added value to be introduced and cost to be incurred by pursuing granularity adaptation.

To effectively support reasoning about granularity adaptation, the gap we identified is the need for a decision support tool for reasoning about this problem at runtime. It is seen as a runtime problem since the suitable granularity level highly depends on the current scenario in which the microservice architecture is operating (102; 253). For example, if a certain functionality in a microservice-based application is continuously receiving a large volume of requests at runtime, it makes sense to decompose this functionality in a separate microservice to manage its load separately. On the other hand, if two microservices are continuously communicating across a network at runtime causing latency, then merging these microservices is sensible to help reduce such latency. Overall, uncertainties related to the expected environment and behaviour (215; 50) of the microservice architecture can not be fully captured at design time. Therefore, a runtime decision support tool is necessary to track and analyse this uncertainty. The tool should systematically guide the software architects towards suitable granularity adaptation strategies at runtime or suggest re-visiting their expectations of the microservice runtime environment. Each candidate granularity adaptation strategy must be systematically described as a sequence of merging/decomposition steps accompanied by triggers on them. Moreover, the tool’s suggestions need to be justified objectively while leaving the final decision to the architects for adopting the suggested strategies; approaches such as (100) can inspire the design of this tool.

5. Threats to Validity

In this subsection we acknowledge the threats to validity in the process we use in our systematic mapping study as well as the application of each stage. Threats to validity are ”influences that may limit our ability to interpret or draw conclusions from the study’s data (188, p.351)”.

When defining our search strategy in Section 2.2, we considered blog articles, presentations, and videos as the means of reporting first-hand industrial experiences with microservice adoption. We acknowledge that an alternative means could be interviews with microservice adopters in the industry. However, published blog articles, presentations and videos are arguably more trusted since they present a more responsible and objective view than interviews. Though they can enrich the study with diverse opinions, interviews tend to suffer from bias, subjectivity and irresponsible answers (126). Moreover, our search strategy yields publications that explicitly mention microservices. Nevertheless, we acknowledge that there are publications prior without direct mention of microservices that could be relevant to their emergence and thereby to our research (e.g., web service composition and agile development). We attempt to address this threat briefly in Section 7.

We acknowledge that the inclusion and exclusion criteria might have led to missing contributions that can inspire the microservices field. However, since our study was motivated by studying the state-of-the-art and -practice in the microservices trend we based the criteria on publications which already have a link to microservices. Nevertheless, we briefly outline the research areas that can inspire the microservice trend in Section 7. On a more technical level, we excluded publications that could not be translated to English which might have affected the study results.

We iteratively built Table LABEL:categories to include all the relevant keywords and made our best effort to justify them (Section 2). However, we acknowledge that some keywords might have been missed related to each research question.

When extracting videos and presentation for inclusion in the study results, we made our best effort to include videos whose content contained keywords from each category. The keywords are either mentioned by the speaker in the video or in the slides presented in the presentation. We acknowledge however that this might have biased the study results and that in the future transcription of the videos/presentations would be a more accurate means of determining their relevance.

When categorising publications according to Table LABEL:categories, we made our best effort to considers synonyms of the keywords in each category. However, since we categorised the publications by manual examination, we acknowledge that their distributions might have been skewed. In particular, we acknowledge that subjective interpretation of keywords might need to be complemented with more systematic approaches of categorising the yielded publications. For example, the context in which a keyword or a fragment is mentioned needs to be considered before putting each publication under a certain category. A more systematic categorisation of the publications can ensure the reproducibility of our results.

We acknowledge that skewed distributions might lead to biassed inferences regarding gaps in the literature related to each objective of our study. For example, the variation in numbers of publications across categories in Figure 3 might be due to the inadequacies in keywords under each category. It might also indicate interest in architectural design across practitioners (i.e. in non-academic publications); this might not be as accurate for academic publications. Nevertheless, we argue that our mapping study results give a strong insight into the microservice trend and opens directions for more detailed research down each direction. For example, a systematic mapping study can be conducted which focusses specifically on microservice architectural design and/or development — the most dense categories in Figure 3.

6. Related Studies

Motivated by disciplining the understanding of microservices, several studies have been conducted to examine the existing literature in this young yet trending field. They analyse existing literature with a variety of focuses. In this section, we compare and contrast the examined studies against the systematic study we conducted.

The closest to our study are (5; 179) since they both adopt a systematic mapping study process when examining the literature. However, the motivations in these studies are different from ours. In (5) for example, the research questions motivating the study are related to challenges, modelling approaches and quality attributes considered when adopting microservices. These questions do overlap partially with both objectives of our study but they do not focus on reasoning about microservice granularity as we do in our study. In (94), the activities comprising the transition to microservices are inferred through a literature review (aligned to Objective 1 of our study). However, it does not focus on microservice granularity so our study is significant to understanding this microservitization challenge.

Several systematic literature reviews and surveys focus on defining the fundamental properties of microservices and the challenges of adopting them. They range in their rigour: some follow a rigorous search protocol (47; 46; 272; 107; 254; 120; 91; 229) while others are less formal (69). These studies overlap partially with Objective 1 of our study; they present activities related to microservices thereby contributing to a better understanding of the transition. However, they do not define on the transition to microservices nor can they be used to understand the microservice granularity problem. In (160), the transition to microservices is partially described in terms of design patterns that can be applied to microservices. However, the scope of activities comprising the transition is not clearly defined.

Some studies mainly focus on modelling microservices (6; 45). Their focus partially overlaps with our following research question: what are the modelling approaches used to define the granularity of a microservice?

On the other hand, (138) aims to ”construct knowledge of quality attributes in architecture through a Systematic Literature Review (SLR), (an) exploratory case study and (an) explanatory survey (138, p.1).” In essence, this study can be used to partially address our question: what are the quality attributes considered when reasoning about microservice granularity and how are they captured? Nevertheless, the other research questions of our study were not answered in this study.

Overall, the examined studies can complement this paper to discipline the understanding of the transition to microservices. In this paper, our research questions are formulated with focus on a specific problem of this transition — reasoning about microservice granularity.

7. Relevant Research Fields

Although we focus on publications that have direct links to microservices in our study, we acknowledge that there are publications prior to the time period considered in this mapping study that could be relevant to the emergence of microservices and thereby to our research. Such publications do not fit our search strategy because they do not make direct reference to microservices. Nevertheless, in this section we briefly summarise the examined literature in these areas indicating how they can be relevant to our systematic mapping study objectives.

7.1. Research Fields Relevant to Understanding the Microservice Transition

Even among microservice adopters, there are still debates over distinguishing service-oriented architectures (SOA) from microservice architectures (160; 4; 43; 235; 146; 221; 234; 170). Therefore, we infer that contributions defining the properties and challenges of adopting SOA architectures can be relevant to understanding the transition to microservices.

Seminal work defines SOA as an architectural style which can guide business process definition (73; 72; 144; 209; 187; 273) and support ”rapid, low-cost composition of distributed applications (182; 181; 183, p.1).” The SOA style was introduced to address architectural complexity, redundant programming and inconsistent interfaces (48; 28). In SOAs a service is a self-describing unit that ”consists of a contract, one or more interfaces and an implementation (131, p.57).” SOAs in turn comprise an application frontend, services, a service repository and enterprise service bus.

Despite the resemblance between microservices and SOAs, there is a subtle distinction we infer from our microservitization definition. The distinction comes from (102): 1) the potential of microservices as autonomous fine-grained computational units with lightweight communication mechanisms rather than service buses and, 2) the operational and organisational flexibility enhanced by microservitization. Further elaboration of these points is presented in (200).

7.2. Research Fields Relevant to Understanding the Microservice Granularity Problem

Modelling microservice granularity can be inspired by architectural modelling approaches — a wide research field, where contributions capture different notions of the architecture at varying levels of abstraction (13). Domain-driven modelling is the most relevant to the modelling approach we describe in Section 4.2 because it strives for logical isolation of business functionalities (75; 165). However, domain-driven modelling is more concerned about the relationships between functional boundaries rather than their scope. In essence, domain-driven modelling can inform the structural rather than behavioural aspect of modelling microservices.

The Zachman framework (266) provides a comprehensive guide to the different dimensions and perspectives for architectural modelling. Two dimensions in this framework are aligned with the modelling approach we call in Section 4.2: what the model units are and where these units are located relative to each other. We call for a modelling approach that explicitly captures what each microservice is concerned about and helps define where the business functionalities encapsulated by the microservice are located relative to each other.

A more dynamic architectural modelling approach is feature modelling (259), where an architecture is defined as a set of variability points, the candidates for each variability point and the rules constricting the dependencies across variability points. We appreciate this modelling technique is useful for formulating architectural decision-making problems. However, we would need to leverage such concept to focus on microservice boundaries being the variability point. While dependency rules in a feature model can give an insight about microservice granularity, they do not explicitly model it. EUREMA (251) provides a yet more powerful dynamic modelling technique. Here an adaptation engine contains a runtime model which represents the evolution of the system as well as adaptation activities to be executed on that model. The link between the adaptation activities and the runtime model is expressed using runtime mega-models. Similar to feature modelling, EUREMA needs to capture the notion of microservice boundaries more explicitly.

Boundaries are modelled more explicitly in design structure matrices (DSMs) (59). Modularity metrics (151) can be used to assess the degree of interdependence across these boundaries. We have not seen a dynamic application of DSMs that captures the changes in these dependencies across a time unit (e.g., release cycles).

Since we call for objective reasoning about microservice granularity adaptation, design metrics can inspire this requirement since they provide an objective way to capturing attributes of a design decision. Effort-based metrics (223) evaluate software development and maintenance efforts when a transition is made from centralised to distributed system architectures (208). By analogy, an objective way is needed to evaluate development and maintenance costs when microservice granularity is adapted. Metrics related to cohesion, coupling and visibility of system components are presented and visualised in (208; 30), which can be used to assess the impact of granularity adaptation on the microservice architecture’s modularity.

Since reasoning about microservice granularity is in essence a dynamic architectural design decision problem, several software engineering fields can be relevant to it. Architectural analysis methods, architectural design patterns, service composition and orchestration approaches, runtime architectural adaptation, architectural refactoring and feedback control loops are only some of the relevant fields. In the following subsections we categorise contributions in these fields according to their level of autonomy:

• •

Manual contributions with full reliance on the software architect and/or stakeholders (e.g., architectural design patterns)

• •

Partially autonomous contributions where there is an autonomous agent but the software architect still makes the final decision regarding the optimal architecture (e.g., interactive service orchestration and/or composition)

• •

Fully autonomous contributions where the decision-making process and executing the decision are fully handled by an autonomous agent (e.g., feedback control loops, online architectural refactoring)

7.2.1. Manual Contributions

Out of the approaches in this subsection, the most cost- and value-aware approaches we examined are (178; 237; 238). Refactoring the architecture according to patterns (178) or to introduce modularity (238) are regarded as value-bearing investments (237). However, these approaches are only applied statically at design time. In this paper, we call for a similar view for reasoning about microservice granularity.

In (12), a cost benefit analysis method (CBAM) is proposed as a generic architecture evaluation method which utilises techniques in decision analysis, optimisation, and statistics to evaluate architectural design decisions. However, CBAM does not dynamically track and update the added value of architectural decisions. These dynamic updates are critical to the nature of the microservice granularity problem.

In (206), the net benefit of a software is calculated by deducting its total costs from the total benefit. These are manually elicited and monetised from software architects through a series of questions (e.g., “what is the status of the environment without the system?”). To our knowledge, this approach however does not consider the uncertainty in the answers to these questions nor does it update them at runtime. In (52) the predictive analysis of design captures the value-driven impact of architectural decisions as multi-dimensional normalised, weighted cost and value vectors. Therefore, it can only provide static objective decision support for reasoning about microservice granularity.

The techniques in (66) present different architectural evaluation methods and their motivations. Software Architecture Analysis for Evolution and Reusability (SAAMER), Scenario-Based Architecture Re-engineering (SBAR) and Architecture Level Prediction of Software Maintenance (ALPSM) in particular take an objective approach to architectural evaluation.

SBAR captures the runtime nature of decision-making by providing different quality attribute evaluation techniques depending on whether the quality attribute is concerned with the “development” of the system (i.e. design time, such as reusability, which is handled by scenario-based evaluation) or the “operation” of the system (i.e. runtime, such as performance, which is handled by simulation-based evaluation). SAAMER on the other hand partially addresses granularity problem by analysing the level of interaction between different scenarios of the system as a means of assessing the level of functionality isolation in the system. Nevertheless, both methods have not been explicitly applied in a dynamic environment to our knowledge.

ALPSM takes a more value-driven approach to the evaluation, similar to the Cost Benefit Analysis Method (CBAM) (12), which makes them more systematic architectural evaluation approaches than SAAMER and SBAR above. Furthermore, ALPSM uses probabilities to capture the likelihood of the impact of scenarios and CBAM captures the uncertainty the architectural analysis. ALPSM and CBAM therefore partially capture uncertainty, although they do not operate at runtime and thereby they suffer from the limitation of design-time analysis.

Classical design patterns presented in (92) extensively study creational (concerned with object instantiation), structural (concerned with relationships between objects) and behavioural patterns (concerned with coordination between objects). These patterns are further categorised according to their static or runtime nature. In that context, reasoning about microservice granularity can benefit from runtime creational design patterns. However, the design patterns of that category in (92) do not capture the scope — boundary — where a pattern can be enforced. Service workflow patterns have been presented in a seminal work (42) which implicitly discussed the issue of granularity is SOAs. However, we envision that the distinction between microservices and SOAs calls for explicitly addressing granularity adaptation decisions in the context of microservice constraints.

7.2.2. Partially Autonomous Contributions

In (44; 214), pattern-based engines are proposed to synthesize a composition of atomic and composite services. However, we envision that reasoning about microservice granularity needs to be grounded on objective rather than pattern-based evaluation. In (158; 159), a microservice-specific approach for addressing the microservice granularity problem is proposed which relies on microservice web application log mining to extract the usage pattern and then making adaptive decisions regarding microservice granularity to ensure an economically sustainable architecture. We acknowledge this work is very closely related to the decision support called for in this paper. Nevertheless, it does not explicitly analyse the value-driven implications of such adaptive decisions as we call for in Section 4.2.

7.2.3. Fully Autonomous Contributions

The closest fully autonomous contribution to the effective decision support we call for in Section 4.2 is the ASTRO-CAptEvo orchestration framework (122). It is a runtime framework that allows partial definition of business processes for service-based systems at design-time. Subsequently, the framework orchestrates ”automatically composing the currently available services, provided by other actors and systems, according to the execution context and the goal of the process to be refined” using state transition systems. This framework takes a runtime approach to decision-making. However, the decision problem targeted by ASTRO-CAptEvo is service composition rather than microservice granularity. Moreover, ASTRO-CAptEvo does not consider objectively reason about composing the available services.

The Self-Serv framework presented in (23) facilitates composite web service execution through peer-to-peer message exchange between coordination agents, which manage the service composition according to a static state chart. This framework can be utilised to address microservice granularity adaptation, but the knowledge that drives the service composition is static, meaning the runtime nature of the granularity problem is not captured in this framework.

Reputation-based dynamic service configuration techniques such as (147) use a policy language to capture service consumers’ and providers’ profiles and then utilise these profiles to dynamically configure an optimal concrete service architecture. The work in (256) leverages on the concept of reputation by capturing trust in the feedback given regarding the services. In particular, a model is proposed to aggregate feedback from several consumers of a service to reduce the effect of biased feedback. In both cases, a subjective user profile is used to drive the composition rather than an objective value- and cost-driven approach.

Case-based reasoning about concrete service composition is presented in (139) where a solution space of composite services is formalised using recursive tuples of services. An agent then synthesises the optimal service decomposition given a request for services from the user which are then bound at runtime to concrete services fetched from a registry. A distinction is therefore made here between concrete service selection and the higher level composition of services; this can be utilised to address the granularity problem. However, this solution does not capture the dynamic nature of the microservice granularity problem.

Service composition techniques based on model checking (79; 41; 40) dynamically adapt probabilistic models of the system according to runtime changes in the scenarios surrounding the system or runtime changes in the requirements of the system. In (40) Bayesian learning improves service composition synthesis process through runtime knowledge updates about the system’s behaviour over its lifetime. In (41) an abstract service composition is mapped to a concrete service composition at runtime. The field of model-checking therefore is an attractive one for runtime decision-making. Such contributions however need to be leveraged for the specific problem we are concerned with (i.e. the granularity of microservices).

Similar to the field of model checking is runtime architecture modelling. Several contributions in this field manifest runtime changes to the architecture (25; 29; 268; 11; 176; 20; 118; 251; 81; 155). Other contributions are catered for systems which exhibit a similar level of dynamism to microservices (82; 152; 106). However, these contributions would need to be leveraged with objective reasoning that considers both the added value and cost of granularity adaptation.

Another approach of an autonomous solution is dynamic service formation rather than dynamic service composition. Frameworks such as (247; 137) provide means to dynamically produce web service specifications conforming to a service composition. These approaches can be utilised to complement the decision support we call for in this paper.

The runtime, uncertain context of microservice granularity adaptation calls for support similar to that provided by engineering self-adaptivity (102; 50) into an architecture. The role of a self-adaptive solution is to refine and update at runtime the architects’ design-time expectations about the architecture’s behaviour. There are several mechanisms which can be adopted in this solution (24; 51; 93; 111; 62). Underlying most of them is the concept of feedback control loops (67; 38) which can be used ”to monitor, analyse, plan and execute adaptations (54, p.16)” in a system regarding trade-offs of concern; the knowledge learnt about the system needs to be maintained in a knowledge base (MAPE-K loop (93)).

Control loops can be composed in a centralized, hierarchical, master-slave, or fully decentralized pattern (62). Each pattern varies in which components of the architecture carry out which phase(s) of the control loop. The centralized pattern is more suitable for monolithic architectures. In a hierarchical pattern, the full MAPE loop is effected at individual services, with higher level services having a more general view of the architecture. The individual service MAPE loops pass information to the higher level loops at short time intervals. Although this pattern is well-suited to addressing the trade-offs of concern here, its only shortcoming is deciding what the higher level component with the global view of the architecture should comprise and the possibility of this service creating a bottleneck. A variant of the hierarchical pattern is the master-slave pattern where the individual services only monitor and execute while a higher level service comprises the analysis and planning phases. Although more lightweight than the hierarchical pattern, the master/slave pattern suffers from the same shortcomings as the hierarchical pattern. The decentralized pattern (97; 145; 252; 258) on the other hand takes away the need for a service with a global view of the control loop. The MAPE loop is implemented in each service and information is passed across the services for decentralized management. The major challenge of this pattern is guaranteeing a consistent view of the system and its environment across all the control loops (62). However, this pattern is the most aligned with the autonomy of microservice architectures and the scale at which microservices operate.

Runtime architectural adaptation approaches have been proposed before in the Rainbow framework (93) which is the most aligned with the concept of feedback loops. The Rainbow framework provides a reusable solution to induce self-adaptivity into a system in a cost-aware manner. However, it is debatable whether dynamically adapting the level of granularity of a microservice can be captured using the Rainbow framework. This is because the solution space here varies regarding the number of services used and the interaction patterns between them. To our knowledge, the Rainbow framework has not been applied to such a setting before. Another prominent approach is the architectural refactoring approach (65) where a set of anti-patterns is proposed which can be detected dynamically and used to trigger refactoring an architecture. This approach has as its main motive enhancing the modularity of the architecture rather than reasoning about modularity in a objective manner.

Realising microservice granularity adaptation involves changes to a deployed architecture. These activities are similar to those underlying the field of online architectural refactoring. Several contributions in this field pave the way to automated online architectural refactoring (271; 143; 231; 220; 115; 270; 177) and modelling transformations (59; 114). These contributions are driven by meeting a specific architectural design pattern, but they do not objectively reason about granularity adaptation.

In the field of AI planning, an ontology-based approach to architectural adaptation is proposed (148). A shared ontology of generic “procedures” (or templates) is produced which the stakeholder can choose from at run-time. An agent then executes this procedure customizing it depending on the scenario in which the system will operate. It is appreciated that the use of ontologies promotes sharing knowledge across across architects. However, we envision that the decision support we are calling for in this paper can promote knowledge sharing and profiling to inform reasoning about microservice granularity.

8. Conclusion

In this paper we report on a systematic mapping study to consolidate various views, principles, methods and techniques that are commonly adopted to assist the transition to microservices. We systematically describe the study’s process and report its results. We contribute a working definition capturing the fundamentals of the transition; we term it as microservitization. Microservitization is a form of servitization (15; 14) where services/components are transformed into microservices — a more fine-grained and autonomic form of services — to introduce added value to the architecture (102). Microservitization is also an example of a paradigm shift since it involves a dramatic change to the way technical activities are carried out and aligned with a microservice adopter’s business objectives. We then shed light on a fundamental problem of microservitization: microservice granularity and reasoning about its adaptation as first-class entities. This study has reviewed and identified gaps in the state-of-the-art and -practice that relate to the modelling approaches, aspects considered, guidelines and processes used to reason about microservice granularity. The identified gaps pave the way to opportunities for future research and development related to reasoning about microservice granularity. In particular, we identify there is room for: (1) systematic architecture-oriented modelling support for microservice granularity, (2) a dynamic architectural evaluation approach to reason about the cost and added value of granularity adaptation and (3) effective decision support to inform reasoning about microservice granularity at runtime.