Microservice transition and its granularity problem: A systematic mapping study

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 that transition. 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 modeling 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.


INTRODUCTION
Several industries have migrated their applications (or actively considering migrating) to microservices [38,62,98,101,107,193,193,198,217,231,254].e 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.e ultimate objective of this alignment is to enhance utilities of the application's so ware 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-e ective 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 de nitions; each de nition captures di erent properties of microservices.De nitions mostly agree that the fundamental properties of microservices include enabling facilitated improvement of component characteristics -autonomy, replaceability, independent deployability -and of architectural characteristicsimproved reliability, scalability, resilience to failure, availability, and evolvability [16,89,101,108,131,133,140,145,163,165,210,211].In essence, these de nitions capture some drivers of the transition to microservices aimed at enhancing utility in the application's so ware architecture.
e utility enhanced through the transition can render bene ts that can cross-cut architectural design, testing, maintenance and service management [60].For example, microservice autonomy allows the architects to easily locate, implement and test necessary service amendments [101].Microservice replaceability allows architects to con dently and independently add and/or manage new business functionalities over the system lifetime [101].
e transition to microservices can help the application in be er meeting its quality of services (QoS) requirements; this may consequently result into improved compliance with service level agreements for QoS, potential economics gains, and be er alignment with the business objectives of microservice adopters [101].Because of their "micro" character, microservices can be mobilised to the bene t of several service-oriented applications that can require "lighter weight" processing (e.g., mobile services and Internet-of-ings (IoT)) [101].
Despite the industrial push towards microservices, there is no disciplined understanding of their transition nor consensus on the principles and activities underlying the transition [95].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 so ware architect can be equipped with mechanisms and tools that can enhance replaceability by standardising the communication paradigms across microservices [170,254].Reasoning about the added value and possible cost becomes essential to justify this technical design decision regarding communication paradigms.
is paper is an a empt for a be er 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 de nition 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.
is working de nition 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 [135, p.426]." Granularity adaptation entails merging or decomposing microservices thereby moving to a ner or more coarse grained granularity level.
Determining the granularity level too early in the so ware architecture's lifetime can lead to problems in reasoning about microservices [4,119].
is problem is of signi cance both in brown eld and green eld development [62].In both elds, 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 plo ed at a high level of granularity.
is allows for the identi cation 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 [124, p.5]." Directing the focus of future systematic reviews aligns with our aforementioned objectives.Ultimately, our a empt at de ning 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 [124].
In Section 2 we describe the steps we followed in the systematic mapping study.In Section 3 we report and brie y analyse our mapping study results.In Section 4 we use this analysis to: (1) present our working de nition 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 identi ed gaps motivate the need for: • Microservice-speci c modelling support potentially using an architecture de nition language (ADL) that "treats microservice boundaries as adaptable rst-class entities [100, p.2]" thereby facilitating runtime analysis of microservice granularity in a systematic architecture-oriented manner [100].• 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.• E ective decision support that should systematically guide the so ware 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 eld of microservices against our systematic mapping study.In Section 5 we re ect 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.

SYSTEMATIC MAPPING STUDY PROCESS
e process we follow in our mapping study is inspired by guidelines from [124].In the subsections below, we describe our application of each stage of this process.

Research estions
Overall, this paper conducts a systematic mapping study to address the following objectives: • Objective 1: providing a be er 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. is consolidation allows us to reach a working de nition 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.is 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 be er understanding of the transition to microservices • What are the activities undertaken to adopt microservices? is 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 de ne the granularity of a microservice?e aim of this question is to identify the support provided by microservice-speci c models for reasoning about granularity and to investigate how systematic (i.e.standardised and methodological) these models are.• Which quality a ributes are considered when reasoning about microservice granularity and how are they captured?e aim of this question is to elicit the possible trade-o s which so ware architects need to balance when reasoning about microservice granularity and/or how these trade-o s can be captured objectively.• How is reasoning about microservice granularity described?e 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.

Search Strategy
e terms used when searching for English publications were "microservice" and "micro-service"; Google Scholar, ACM Digital Library, IEEE Xplore, ScienceDirect, SpringerLink and Wiley Inter-Science 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 [189] 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 e ort 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. is broad scope also aligns with a property of systematic mapping studies -aiming for broad coverage rather than narrow focus [124].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 [243] while peer-reviewed publications started to appear in 2014 [90].Meta-data of the search results was maintained using a tool called "Publish or Perish" [185].

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 [188]).Along with each criterion is the rationale justifying it italicised.

1:5
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 speci c 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. is is against Objective 1 of our study.• Publications that refer to servitization in the business not the so ware context since we are only concerned about the activities of shi ing a so ware system from another architectural style to microservices.What modelling approaches are used to de ne the granularity of a microservice?Inclusion Criteria: • Publications de ning 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 unveri ed, 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-con guration solutions for SOAs/web-services/mobile services only are excluded since they do not capture the properties speci c to microservices, hence they are not suited for reasoning about microservice-speci c 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 speci c to microservices, hence they are not suited for reasoning about microservice-speci c decision problems (in this case microservice granularity).Which quality a ributes 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-o s a ecting 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 signi cance of speci c trade-o s when reasoning about granularity adaptation.
• Publications focused on vendor-speci c comparisons between platforms supporting reasoning about microservice granularity.is can help derive the quality a ributes 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-o s impacting them, it is unreasonable to claim an impact of a reported trade-o 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.is 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.ese 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 speci cally at microservices, so it would not be reasonable to use them in the context of microservice granularity.

Keywords and Classification
" e purpose of this stage is to classify papers with su cient detail to answer the broad research questions and identify papers for later reviews without being a time consuming task [124, p.44]." Here we classify the included publications according to two classi cation frameworks.Initially, we classify them according to the following research approaches, elicited from [259]: • Evaluation research: these investigate the signi cance of a problem and/or investigate the feasibility of a contribution in practice.e identi cation of the keywords is inspired by a microservice-speci c systematic mapping study [4] and re ned 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 pa ern.
Choosing the generic communication paradigm of the architecture (e.g., orchestration, choreography) and the more concrete message exchange pa ern (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.e fault tolerance mechanisms of the system also need to be identi ed (e.g.bulkhead and circuit breaker pa erns).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.e state-of-the-practice in the microservice industry is to motivate decentralised governance (i.e.holding the responsibility of building and running [21]) through microservitization [145].e three most common means of achieving that is through following Conway's law [145], cross-functional teams, or hierarchical teams [108].Conway's law states "organisations which design systems … are constrained to produce designs which are copies of the communication structures of these organisations [56]." • Operation: publications in this category are concerned with identifying how the system will be governed post-deployment.is includes de ning who is responsible for this governance to begin with.e 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 de ning the con guration se ings and con guration provider which the governor of the microservice application needs to follow or in di erent runtime situations.
• Deployment: this category includes publications that de ne the activities constituting the deployment pipeline of the microservice application.e state-of-the-practice in the microservice industry is 2 alternative approaches [52,256]: 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 [209]." "Continuous delivery picks up where continuous integration ends.CD automates the delivery of applications to selected infrastructure environments [209].""Deployment automation allows applications to be deployed across the various environments used in the development process, as well as the nal production environments [70]."Regardless of the deployment pipeline, the host on which this pipeline is enforced is another critical decision in this category.e 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 so ware development practices.e 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 identi cation).• Logging: in this category we are concerned with where the monitoring results are to be stored (alternatively called pro ling and tracing).e 2 alternative approaches to this in the microservice industry as we have examined are central or decentralised logging.
What modelling approaches are used to de ne 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 [74]), the units of this structure di er (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.is sequence can be in the form of events, messages, activities, communication, execution steps and/or use cases.Which quality a ributes 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, e ciency or customer value), the publication is put under this category.ere means of capturing this objectively include response time, throughput, invocation duration, identifying the performance bo lenecks and/or transaction duration.resholds 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 de ned by the consumer and shared with the corresponding provider.A erwards, tests are being implemented in order to verify that the contract is being kept [168]." 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.e 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.e keywords under this category capture the alternative state-of-the-practice processes encountered for reasoning about microservice granularity.

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

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

Publication Distribution Overview
A total of 560 publications met the inclusion criteria in Section 2.3.Table 2 lists representative examples of the included publications categorised according to Table 1. Figure 1 shows the overall distribution of the publications according to the publication type.As justi ed 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 signi cant percentage.Had we excluded these publications, a empting a de nition for microservitization (Objective 1 in Section 1) would have been biased.e 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.Guidelines [25,34,139,198,200,215,225,235,249] Processes [85,86,111,184,191,192,203,224] Table 2. Representative examples of publications included in the systematic mapping study Fig. 2. Academic (i.e.peer-reviewed) included publications between 2013 and 2018 as per the search strategy defined in Section 2.2 classified according to their research approach; the classification criteria are derived from [259]; We further classify peer-reviewed publications according to a highly-cited paper classi cation framework [259] which targets IEEE papers.is framework classi es papers according to their research approach; a brief description of each approach is presented in Section 2. is framework has been applied before in the context of microservices [4], so we consider it a neat t 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, signi cant techniques without a full-blown validation.A proof-of-concept may be o ered in solution proposals by means of a small example, a sound argument, or by some other means [259].erefore, the microservices trend is a thriving eld for novelty but it is still lacking maturity.Validation research publications -which thoroughly investigate solution proposals [259] -only amounted to 43 publications, which further proves the lack of maturity in the eld.e large di erence between the solutions proposals and validation research publications proves the need for disciplining the transition to microservices.e following subsections further discuss this need then focus on one of the fundamental problems of the transition -reasoning about microservice granularity.

Objective 1: Providing a Be er Understanding of the Transition to Microservices
Figure 3 classi es 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.erefore, we infer they are crucial activities in the transition to microservices.Nevertheless, there is a signi cant number of publications in the other categories of Figure 3. e variation in number of publications across categories of Figure 3 implies there is no consensus in describing the transition to microservices. is leaves room for us to contribute the microservitization term which a empts to provide a be er understanding of the transition to microservices.

Objective 2: Understanding the Microservice Granularity Problem
One of the fundamental problems of the transition to microservices is nalising their level of granularity [62,84,104,149,169,240]. Architecture de nition language (ADL) classi cation frameworks [148] indicate that structural (or "topological [148, 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 de ne the granularity of a microservice?e 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.erefore, a systematic, architecture-oriented modelling approach for microservice architectures which facilitates reasoning about granularity needs to capture the architecture's structural and behavioural aspects.
e di erence 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 classi es publications according to the quality a ributes they aim to optimise when reasoning about microservice granularity; to answer which quality a ributes 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-e ective microservitization.Scalability is the most common quality considered in the examined literature. is is reasonable given the dynamic, large-scale environment in which microservices operate [33,38,55,95,98,108,198,217,231,254].
erefore, we infer that scalability can introduce added value to most microservice architectures.Relatively few publications have considered complexity/cost when reasoning about microservice granularity.erefore, 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 classi es 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 di erently at various points of the microservice application's lifecycle.However, e ective decision support for microservice granularity should comprise a clear sequence of distinct steps to be triggered under clear conditions.We have not found such e ective support even in the 30 publications proposing a process to reason about microservice granularity.erefore, we infer that there is a lack in e ective decision support for reasoning about microservice granularity in terms of clear adaptation steps and triggers.

ADDRESSING SYSTEMATIC MAPPING STUDY OBJECTIVES
In Section 4.1 we contribute to an empirically grounded working de nition 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.

Objective 1: Providing a Be er Understanding of the Transition to Microservices
We have not found in the surveyed publications an empirically grounded de nition which characterises the transition to microservices, but rather several con icting, informal a empts coming from industry and academia.Table 3 analyses these a empts in terms of whether or not they explicitly include the activities derived from the microservice-speci c systematic mapping study [4] and described in Section 2.4.It is worth noting that the a empts analysed in this table are just a fraction of the publications summarised in Figure 3.In Table 3 we focus on the explicit a empts to de ne the transition to microservices, while Figure 3 includes both explicit a empts to de ne the transition and case studies of microservice adoption which do not explicitly a empt to de ne the transition.
Table 3. Analysing publications that a empt to define the transition to microservices included in the systematic mapping study; a check means the publication includes the activity in the corresponding column Observing Table 3, we introduce a de nition for the transition to microservices (adapted from the activities included in [4]) which we call microservitization to cover all the relevant activities of the transition to microservices. is de nition is adapted from activities included in [4] and inspired by a trending concept in business and manufacturing domains [152] -servitization.
In the manufacturing and business domains, servitization is seen as a paradigm shi entailing "manufacturers growing their revenues and pro ts through services [14]" 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 so ware applications, customer support, and self-service capabilities [247].
Servitization "embraces business model innovation, organisational change, and new technology adoption.Services exist in various forms, and represent di ering values to both the customer and provider [14]".To bene t from these values, servitization involves developing new relationships with customers, innovating customer value propositions, forming new value chain relationships, and adapting business models [14,15,59,226].e key to successful servitization is "choosing the right technology, picking the appropriate moment to invest, and ensuring successful implementation [13]" which aligns with the business objectives [247].
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 pro ts.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 de ning 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 so ware architecture are carried out.erefore, we de ne microservitization as a form of servitization where "services/components are transformed into microservices -a more ne-grained and autonomic form of services [100, p.1]" -to introduce added value to the architecture [101]."Microservitization is also an example of a paradigm shi [100, 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 [95].erefore, 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 lters, event-based queues, and correlation identi ers are critical to avoid very high communication costs in microservice architectures.e 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-o -the-shelf (COTS) concrete services or developing them in-house [101].Choosing these services correctly is critical to introducing added value to the microservice architecture.-Adopting fault tolerance design pa erns: although striving for fault tolerance is a best practice in any architecture, investing in fault tolerance design pa erns is all the more critical to microservitization.e criticality is due to the scale of industries adopting microservices (e.g., retail [239], entertainment [98,242]) where microservices span di erent continents with a wide variety of end users.Microservice-speci c fault tolerance design pa erns include circuit breakers and bulkheads.-Incorporating microservice registration and discovery mechanisms: microservices are typically developed, deployed and replaced at a very quick rate [95].erefore, 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 [162].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 commi ing a change to a system and the change being placed into normal production, while ensuring high quality [20]".Decentralised operation management can reduce the risk of bo lenecks 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 [162]. is 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.ey can enable swi 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 so ware development paradigms, microservitization enables freedom in choosing development tools which can in turn introduce more added value to the architecture [4]. is freedom is a bi-product of the decentralised governance enabled by microservitization.It is worth noting that communication and knowledge sharing across teams using di erent 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 [95].ese 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 [95]. is requirements are aligned with the aforementioned monitoring challenges introduced by microservitization.

Objective 2: Understanding the Microservice Granularity Problem
Based on our de nition above, microservitization introduces the challenge of reasoning about the suitable granularity level of a microservice.
To formalise the microservice granularity problem, the gap we identi ed is the lack of an architecture-oriented modelling approach that captures a microservice's granularity behaviour, thereby supporting runtime analysis of this behaviour.e approach should treat microservice boundaries as the primitives for formulating the microservice granularity decision problem and actuators of microservice granularity adaptation decisions.
ese 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 rst-class entities to ensure that both the structural and behavioural aspects of the microservice architecture are captured; we contribute to this approach in [100].While conducting our study, we have seen architecture-oriented modelling approaches that treat the notion of boundaries statically (e.g., [232]), or provide support for adaptability but without explicitly capturing the notion of adaptable boundaries (e.g., [128]).Because the role of microservices is to encapsulate functionality, it is intuitive to use boundaries as adaptable rst-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 rst-class entity would be di erent (e.g., microservice con guration variables).
To reason about microservice granularity objectively and dynamically, the gap we identi ed 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 e ectively support reasoning about granularity adaptation, the gap we identi ed 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 [101,252].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 [49,214] of the microservice architecture can not be fully captured at design time.erefore, a runtime decision support tool is necessary to track and analyse this uncertainty.e tool should systematically guide the so ware 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 justi ed objectively while leaving the nal decision to the architects for adopting the suggested strategies; approaches such as [99] can inspire the design of this tool.

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.reats to validity are "in uences that may limit our ability to interpret or draw conclusions from the study's data [187, p.351]".
When de ning our search strategy in Section 2.2, we considered blog articles, presentations, and videos as the means of reporting rst-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.
ough they can enrich the study with diverse opinions, interviews tend to su er from bias, subjectivity and irresponsible answers [125].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 a empt to address this threat brie y in Section 7.
We acknowledge that the inclusion and exclusion criteria might have led to missing contributions that can inspire the microservices eld.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 brie y 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 a ected the study results.
We iteratively built Table 1 to include all the relevant keywords and made our best e ort 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 e ort to include videos whose content contained keywords from each category.e 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 1, we made our best e ort 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 pu ing each publication under a certain category.A more systematic categorisation of the publications can ensure the reproducibility of our results.

1:19
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 speci cally on microservice architectural design and/or development -the most dense categories in Figure 3.

RELATED STUDIES
Motivated by disciplining the understanding of microservices, several studies have been conducted to examine the existing literature in this young yet trending eld.ey analyse existing literature with a variety of focuses.In this section, we compare and contrast the examined studies against the systematic study we conducted.
e closest to our study are [4,178] since they both adopt a systematic mapping study process when examining the literature.However, the motivations in these studies are di erent from ours.In [4] for example, the research questions motivating the study are related to challenges, modelling approaches and quality a ributes considered when adopting microservices.ese 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 [93], 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 signi cant to understanding this microservitization challenge.
Several systematic literature reviews and surveys focus on de ning the fundamental properties of microservices and the challenges of adopting them.ey range in their rigour: some follow a rigorous search protocol [45,46,90,106,119,228,253,271] while others are less formal [68].
ese studies overlap partially with Objective 1 of our study; they present activities related to microservices thereby contributing to a be er understanding of the transition.However, they do not de ne on the transition to microservices nor can they be used to understand the microservice granularity problem.In [159], the transition to microservices is partially described in terms of design pa erns that can be applied to microservices.However, the scope of activities comprising the transition is not clearly de ned.
Some studies mainly focus on modelling microservices [5,44].eir focus partially overlaps with our following research question: what are the modelling approaches used to de ne the granularity of a microservice?
On the other hand, [137] aims to "construct knowledge of quality a ributes in architecture through a Systematic Literature Review (SLR), (an) exploratory case study and (an) explanatory survey [137, p.1]."In essence, this study can be used to partially address our question: what are the quality a ributes 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 speci c problem of this transition -reasoning about microservice granularity.

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 t our search strategy because they do not make direct reference to microservices.Nevertheless, in this section we brie y summarise the examined literature in these areas indicating how they can be relevant to our systematic mapping study objectives.

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 [3,42,145,159,169,220,233,234].erefore, we infer that contributions de ning the properties and challenges of adopting SOA architectures can be relevant to understanding the transition to microservices.
Seminal work de nes SOA as an architectural style which can guide business process de nition [71,72,143,186,208,272] and support "rapid, low-cost composition of distributed applications [180-182, p.1]." e SOA style was introduced to address architectural complexity, redundant programming and inconsistent interfaces [27,47].In SOAs a service is a self-describing unit that "consists of a contract, one or more interfaces and an implementation [130, 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 de nition.e distinction comes from [101]: 1) the potential of microservices as autonomous ne-grained computational units with lightweight communication mechanisms rather than service buses and, 2) the operational and organisational exibility enhanced by microservitization.Further elaboration of these points is presented in [199].

Research Fields Relevant to Understanding the Microservice Granularity Problem
Modelling microservice granularity can be inspired by architectural modelling approaches -a wide research eld, where contributions capture di erent notions of the architecture at varying levels of abstraction [12].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 [74,164].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.
e Zachman framework [265] provides a comprehensive guide to the di erent 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 de ne where the business functionalities encapsulated by the microservice are located relative to each other.
A more dynamic architectural modelling approach is feature modelling [258], where an architecture is de ned 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 [250] provides a yet more powerful dynamic modelling technique.Here an adaptation engine contains a runtime model which represents the evolution of the system , Vol. 1, No. 1, Article 1. Publication date: January 2016.

1:21
as well as adaptation activities to be executed on that model.e 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) [58].Modularity metrics [150] 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 a ributes of a design decision.E ort-based metrics [222] evaluate so ware development and maintenance e orts when a transition is made from centralised to distributed system architectures [207].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 [29,207], 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 so ware engineering elds can be relevant to it.Architectural analysis methods, architectural design pa erns, service composition and orchestration approaches, runtime architectural adaptation, architectural refactoring and feedback control loops are only some of the relevant elds.In the following subsections we categorise contributions in these elds according to their level of autonomy: • Manual contributions with full reliance on the so ware architect and/or stakeholders (e.g., architectural design pa erns) • Partially autonomous contributions where there is an autonomous agent but the so ware architect still makes the nal 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 valueaware approaches we examined are [177,236,237].Refactoring the architecture according to pa erns [177] or to introduce modularity [237] are regarded as value-bearing investments [236].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 [11], a cost bene t 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.ese dynamic updates are critical to the nature of the microservice granularity problem.
In [205], the net bene t of a so ware is calculated by deducting its total costs from the total bene t. ese are manually elicited and monetised from so ware 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 [51] the predictive analysis of design captures the value-driven impact of architectural decisions as multi-dimensional normalised, weighted cost and value vectors.erefore, it can only provide static objective decision support for reasoning about microservice granularity.e techniques in [65] present di erent architectural evaluation methods and their motivations.So ware Architecture Analysis for Evolution and Reusability (SAAMER), Scenario-Based Architecture Re-engineering (SBAR) and Architecture Level Prediction of So ware Maintenance (ALPSM) in particular take an objective approach to architectural evaluation.
SBAR captures the runtime nature of decision-making by providing di erent quality a ribute evaluation techniques depending on whether the quality a ribute 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 di erent 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 Bene t Analysis Method (CBAM) [11], 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 su er from the limitation of design-time analysis.
Classical design pa erns presented in [91] extensively study creational (concerned with object instantiation), structural (concerned with relationships between objects) and behavioural pa erns (concerned with coordination between objects).ese pa erns are further categorised according to their static or runtime nature.In that context, reasoning about microservice granularity can bene t from runtime creational design pa erns.However, the design pa erns of that category in [91] do not capture the scope -boundary -where a pa ern can be enforced.Service work ow pa erns have been presented in a seminal work [41] 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.

Partially Autonomous Contributions.
In [43,213], pa ern-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 pa ern-based evaluation.In [157,158], a microservice-speci c approach for addressing the microservice granularity problem is proposed which relies on microservice web application log mining to extract the usage pa ern 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.

Fully Autonomous
Contributions. e closest fully autonomous contribution to the e ective decision support we call for in Section 4.2 is the ASTRO-CAptEvo orchestration framework [121].It is a runtime framework that allows partial de nition 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 re ned" using state transition systems. is 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.e Self-Serv framework presented in [22] 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.is 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 con guration techniques such as [146] use a policy language to capture service consumers' and providers' pro les and then utilise these pro les to dynamically con gure an optimal concrete service architecture.e work in [255] 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 e ect of biased feedback.In both cases, a subjective user pro le 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 [138] 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 [39,40,78] 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 [39] Bayesian learning improves service composition synthesis process through runtime knowledge updates about the system's behaviour over its lifetime.In [40] an abstract service composition is mapped to a concrete service composition at runtime.e eld of model-checking therefore is an a ractive one for runtime decision-making.Such contributions however need to be leveraged for the speci c problem we are concerned with (i.e. the granularity of microservices).
Similar to the eld of model checking is runtime architecture modelling.Several contributions in this eld manifest runtime changes to the architecture [10,19,24,28,80,117,154,175,250,267].Other contributions are catered for systems which exhibit a similar level of dynamism to microservices [81,105,151].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 [136,246] provide means to dynamically produce web service speci cations conforming to a service composition.ese approaches can be utilised to complement the decision support we call for in this paper.
e runtime, uncertain context of microservice granularity adaptation calls for support similar to that provided by engineering self-adaptivity [49,101] into an architecture.e role of a selfadaptive solution is to re ne and update at runtime the architects' design-time expectations about the architecture's behaviour.ere are several mechanisms which can be adopted in this solution [23,50,61,92,110].Underlying most of them is the concept of feedback control loops [37,66] which can be used "to monitor, analyse, plan and execute adaptations [53, p.16]" in a system regarding trade-o s of concern; the knowledge learnt about the system needs to be maintained in a knowledge base (MAPE-K loop [92]).
Control loops can be composed in a centralized, hierarchical, master-slave, or fully decentralized pa ern [61].Each pa ern varies in which components of the architecture carry out which phase(s) of the control loop.
e centralized pa ern is more suitable for monolithic architectures.In a hierarchical pa ern, the full MAPE loop is e ected at individual services, with higher level services having a more general view of the architecture.e individual service MAPE loops pass information to the higher level loops at short time intervals.Although this pa ern is well-suited to addressing the trade-o s 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 bo leneck.A variant of the hierarchical pa ern is the master-slave pa ern 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 pa ern, the master/slave pa ern su ers from the same shortcomings as the hierarchical pa ern.e decentralized pa ern [96,144,251,257] on the other hand takes away the need for a service with a global view of the control loop.e MAPE loop is implemented in each service and information is passed across the services for decentralized management.e major challenge of this pa ern is guaranteeing a consistent view of the system and its environment across all the control loops [61].However, this pa ern 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 [92] which is the most aligned with the concept of feedback loops.e 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.is is because the solution space here varies regarding the number of services used and the interaction pa erns between them.To our knowledge, the Rainbow framework has not been applied to such a se ing before.Another prominent approach is the architectural refactoring approach [64] where a set of anti-pa erns is proposed which can be detected dynamically and used to trigger refactoring an architecture.is 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.ese activities are similar to those underlying the eld of online architectural refactoring.Several contributions in this eld pave the way to automated online architectural refactoring [114,142,176,219,230,269,270] and modelling transformations [58,113].ese contributions are driven by meeting a speci c architectural design pa ern, but they do not objectively reason about granularity adaptation.
In the eld of AI planning, an ontology-based approach to architectural adaptation is proposed [147].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 pro ling to inform reasoning about microservice granularity.

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 de nition capturing the fundamentals of the transition; we term it as microservitization.Microservitization is a form of servitization [13,14] where services/components are transformed into microservicesa more ne-grained and autonomic form of services -to introduce added value to the architecture , Vol. 1, No. 1, Article 1. Publication date: January 2016.
1:25 [101].Microservitization is also an example of a paradigm shi 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 rst-class entities.
is study has reviewed and identi ed 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.e identi ed 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) e ective decision support to inform reasoning about microservice granularity at runtime.

Fig. 1 .
Fig. 1.Publications between 2013 and 2018 as per the search strategy defined in Section 2.2 included as per criteria from Section 2.3 classified according to their publication type; the red bars are the publications we consider as academic and the blue bars are those we consider non-academic

Fig. 3 .
Fig. 3. Included publications between 2013 and 2018 as per the search strategy defined in Section 2.2 that have keywords related to the first research question in Table 1

Fig. 4 .
Fig. 4. Included publications between 2013 and 2018 as per the search strategy defined in Section 2.2 which have keywords related to the second research question in Table 1

Fig. 5 .
Fig. 5. Included publications between 2013 and 2018 as per the search strategy defined in Section 2.2 that have keywords related the third research question in Table 1

Fig. 6 .
Fig. 6.Included publications between 2013 and 2018 as per the search strategy defined in Section 2.2 that have keywords related the fourth research question in Table 1 • 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).Complexity: minimising complexity entails following 2 crucial design principles: tight coupling and/or low cohesion.is 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.
• Maintainability: exhibiting maintainability entails exhibiting adaptability, changeability, expandability and/or dynamicity.eseproperties are objectively captured in terms of maintenance cost, maintenance overhead, and/or e ort cost.Publications concerned with reasoning about granularity in terms of enhancing maintainability are included in this category.•