Microservices: A Systematic Mapping Study

Claus Pahl

and Pooyan Jamshidi

Faculty of Computer Science, Free University of Bozen-Bolzano, Bolzano, Italy

Department of Computing, Imperial College London, London, U.K.

Keywords:

Mircoservices, Container, Cloud, Systematic Literature Review, Systematic Mapping Study.

Abstract:

Microservices have recently emerged as an architectural style, addressing how to build, manage, and evolve

architectures out of small, self-contained units. Particularly in the cloud, the microservices architecture ap-

proach seems to be an ideal complementation of container technology at the PaaS level However, there is

currently no secondary study to consolidate this research. We aim here to identify, taxonomically classify and

systematically compare the existing research body on microservices and their application in the cloud. We

have conducted a systematic mapping study of 21 selected studies, published over the last two years until end

of 2015 since the emergence of the microservices pattern. We classiﬁed and compared the selected studies

based on a characterization framework. This results in a discussion of the agreed and emerging concerns

within the microservices architectural style, positioning it within a continuous development context, but also

moving it closer to cloud and container technology.

1 INTRODUCTION

Recently, microservice architectures have been pro-

posed to break up application architectures into in-

dependently deployable services that can be rapidly

deployed to any infrastructure resource as required

(Newman, 2015; Lewis and Fowler, 2014). Mi-

croservices are independently deployable, usually

supported by a deployment and orchestration frame-

work, e.g., in the cloud, enabling them to deploy of-

ten and independently at arbitrary schedules. Mi-

croservice deployment and orchestration across the

distributed and stacked nature of the cloud are cen-

tral architecture concerns. Clouds provide a manage-

ment tool for their ﬂexible deployment schedules and

provisioning orchestration needs, particularly, if these

are to be PaaS-provisioned.

Research on microservices has addressed both the

architectural principles and support as well as the

application of the architectural pattern in the cloud.

In the cloud, microservices are linked to contain-

ers, which are a lightweight virtualisation mechanism

used for application packaging, distribution and or-

chestration at the PaaS layer (Pahl, 2015), even to-

wards edge clouds with smaller resource environ-

ments (Pahl and Lee, 2015).

There has not been a systematic literature review

(SLR) or mapping study (SMS) of research on mi-

croservices that would allow to assess the maturity in

general and identifying trends, research gaps and fu-

ture directions. Given the growing interest in con-

tainers and microservices in cloud, there is a need

to explore a research agenda. SLRs and SMS iden-

tify, classify and synthesize a comparative overview

of state-of-the-research and enable (Petersen et al.,

2008; Kitchenham et al., 2009). We opt for a system-

atic mapping study as it is more suitable in mapping

out and structuring new areas of investigation.

We aim here to identify, taxonomically clas-

sify and systematically compare the existing research

body on microservices and their application in the

cloud. We have conducted a systematic mapping

study of 21 selected studies, published over the last

two years since the emergence of the microservices

pattern. We classiﬁed and compared the selected stud-

ies based on a characterization framework.

The research mapping study resulted in a knowl-

edge base of current research approaches, methods,

techniques, best practices and experiences used in mi-

croservices architecture, with a particular attention to

cloud application. This review reveals that microser-

vices research is still in a formative stage. More ex-

perimental and empirical evaluation of the beneﬁts is

needed. This study also showed a lack of tool support

to automate and facilitate cloud microservice.

The results of this study aim to beneﬁt, ﬁrstly,

researchers in software engineering and cloud com-

puting, who need an identiﬁcation of relevant stud-

ies. Secondly, practitioners interested in understand-

ing the available methods and techniques with tool

Pahl, C. and Jamshidi, P.

Microservices: A Systematic Mapping Study.

In Proceedings of the 6th International Conference on Cloud Computing and Services Science (CLOSER 2016) - Volume 1, pages 137-146

ISBN: 978-989-758-182-3

137

support as well as their constraints and maturity level

in supporting microservice architectures.

The remainder of this paper is structured as fol-

lows. Section 2 describes background and related re-

search to position contributions of this work. Sec-

tion 3 explains our research methodology, research

questions and scope. Section 4 provides a reference

model for state-of-the-research and a characterization

scheme. Section 5 presents the results of the mapping

study. Section 6 discusses the ﬁndings, implications

and trends followed by an analysis of its limitations.

2 BACKGROUND

Based on (Newman, 2015; Lewis and Fowler, 2014),

microservices are about functional decomposition of-

ten in a domain-driven design context. They are char-

acterised by well-deﬁned and explicitly published in-

terfaces. Each service is fully autonomous and full-

stack. Consequently, changing a service implementa-

tion has no impact to other services as communication

takes place using interfaces only. Functional decom-

position of an application and the team is the key to

building a successful microservices architecture. This

achieves loose coupling (REST interfaces) and high

cohesion (multiple services can compose with each

other to deﬁne higher level services or application).

Functional decomposition enables for instance agility,

ﬂexibility, scalability.

2.1 Lightweight Architectures, Services,

Containers and Microservices

Microservices are an architectural pattern emerging

out of Service-Oriented Architecture (SOA), empha-

sising self-management and lightweightness. While

this is an architectural principle, container technol-

ogy has emerged in parallel in cloud computing to

provide a lightweight virtualisation mechanism that

can serve as an application packaging mechanism for

PaaS clouds. Microservice can ideally be packaged,

provisioned and orchestrated through cloud.

The cloud can be seen as a distributed and tiered

architecture, see Figure 1. The core infrastruc-

ture, platform and software application tiers can dis-

tributed across multi-cloud environments – based on

container-based microservices.

2.2 Need for a Secondary Study

The need for a SLR or SMS entails to identify,

classify and compare existing evidence on the use

of microservices speciﬁcally in cloud environments

Figure 1: Cloud Reference Architecture Model.

through a characterization framework. Some technol-

ogy reviews exist (and also classiﬁed as such later),

but these concentrated on technology and do not cap-

ture research efforts and directions systematically.

3 RESEARCH METHODOLOGY

SMSs reduce bias through rigorous sequence of

methodological steps to research literature. They rely

on well-deﬁned and evaluated review protocols to ex-

tract, analyze and document results. We follow the

process presented in (Petersen et al., 2008) with a

three-step review that includes planning, conducting

and documenting. The review is complemented by an

evaluation of each step’s outcome. Furthermore, we

provide an additional characterization framework for

the study context.

Table 1: Research Process.

Step Activity

plan identify need, specify RQs, deﬁne protocol

conduct select primary studies, extract/synthesize data

document document observations, analyze threats, report

Now the individual steps will be outlined. Based

on the objectives, we specify the research questions

and the review scope in order to formulate search

strings for literature extraction.

3.1 Planning the Review

Step 1 – Identify the Need for SLR. We have already

discussed the need for a SMS in the previous section.

We can also make explicit the general goal and scope

of the study using the PICO (Population, Intervention,

Comparison, Outcome) criteria, see Table 2.

Step 2 – Specifying the Research Questions. As

the next activity, we deﬁne the research questions to

help shaping the review protocol, see Table 3.

Step 3 – Deﬁne and Evaluate Review Protocol. We

developed a protocol for a mapping study based on

(Petersen et al., 2008) and our experience with SLRs

CLOSER 2016 - 6th International Conference on Cloud Computing and Services Science

138

Table 2: PICO criteria.

Concern Explanation

Population RQ1: Practical motivation, RQ2: Ar-

chitecture tasks, RQ3: Methods and

techniques, RQ4: Research challenges

and future dimensions [all detailed be-

low]

Intervention Characterization, Internal/external vali-

dation; Extracting data and Synthesis

Comparison A comparison by mapping the primary

studies to a characterization framework

Outcome A characterization framework

Table 3: Research Questions.

Research Question Motivation

RQ1 What are the main

practical motivations be-

hind using microservices?

The aim is to get insight

in what are the main rea-

sons for organizations to

architect in a microser-

vices style.

RQ2 What are the differ-

ent types of microservice

architectures involved?

The aim is to investigate

what are the possibilities

for architecting in a mi-

croservice style.

RQ3 What are the existing

methods, techniques and

tool support to enable mi-

croservice architecture de-

velopment and operation?

The aim is to identify and

compare existing methods

and techniques that sup-

port microservice architec-

ture.

RQ4 What are the ex-

isting research issues and

what should be the future

research agenda?

The aim is to understand

and reveal the research

gaps and identify future di-

rections.

(Jamshidi et al., 2013a; Jamshidi et al., 2013b) that is

outlined in this section.

3.2 Conducting the Review

Conducting starts with study selection and resulting

in extracted data and synthesized information.

Step 1 – Select Primary Studies (Study Selection

and Qualitative Assessment). The search terms

used were developed using (Petersen et al., 2008)

and guided by research questions. While we ini-

tially considered to include terms like ’architecture’

or ’lightweight’, however, ultimately we only used the

term ’microservice’ (and variations such as ’micro-

service’ as search terms, cf. 4, to avoid excluding any

studies in this emerging context. We extracted ini-

tially 243 studies from years 2014 to 2015 (incl.) – as

of 3 Nov. 2015. The year 2014 was chosen as the term

microservice as an architectural pattern is only consis-

tently used since then. Earlier occurrences referred to

microservices as somehow small in scale, but without

a clear reference to an architectural style or pattern,

and were thus excluded.

Since we used our primary search criteria on title

and abstract, this resulted in a high number of irrele-

Table 4: Selection Terms.

microservice micro-service

vant studies, which were further reﬁned with a sec-

ondary search – focusing on title occurrences only

and resulting then in 21 studies.

Step 1a – Initial Selection. This step includes screen-

ing of titles and abstracts of potential primary studies

– performed against inclusion/exclusion criteria

Table 5: Inclusion/exclusion criteria.

In/Excl Criteria

Inclusion

• Abstract/keywords include key terms

• From the abstract it is clear that a con-

tribution towards microservices and their

management is made

Exclusion

• Type: literature only in the form of ab-

stract, blog, presentation are excluded

• Papers with microservices terms only in

abstract or with different meaning

Step 1b – Final Selection. This is based on a val-

idation scan of the studies, methods for microser-

vices and tool support and details of the evaluation

approach. At the end, 21 studies were selected.

Step 1c – Qualitative Assessment of Included Studies.

For the 27 included studies, we primarily focused on

the technical rigor of content presented. We based

our qualitative assessment on factors like General As-

sessment (G) and Speciﬁc Assessment (S). Quality

scores provided us with a numerical quantiﬁcation to

rank the selected studies, but given the recency of

the development, we also included books and the-

ses/dissertations as long as there is evidence of a re-

view being carried out.

Steps 2 and 3 – Data Extraction and Synthesis. In

order to record extracted data from the selected stud-

ies, we follow (Petersen et al., 2008) using a struc-

tured format based on characterization dimensions.

4 A MICROSERVICE

ARCHITECTURE

FRAMEWORK

We ﬁrst introduce a reference model for an

architecture-centric classiﬁcation of microservices

that helps to demonstrate current research at a concep-

tual level and identify trends and research directions.

We follow (Zimmermann, 2009) in his deﬁnition of

an architectural style and present the microservices

style as a collection of principles and patterns. We

then present a framework to characterize individual

Microservices: A Systematic Mapping Study

139

Table 6: Publications selected.

1 Rodrguez Molina, J. (2015). Distribution of microservices for hardware interoperability in the Smart Grid (Disser-

tation, ETSIS Telecomunicacion).

2 Scholz, N. J. (2015). Evaluation of Microservices as Extension of Established Component Technologies. (Diss

RWTH Aachen).

3 Bak, P., Melamed, R., Moshkovich, D., Nardi, Y., Ship, H., and Yaeli, A. (2015). Location and Context-Based

Microservices for Mobile and Internet of Things Workloads. IEEE Intl Conf on Mobile Services (MS), pp. 1-8.

4 Nycander, P. (2015). Learning-Based Testing of Microservices: An Exploratory Case Study Using

LBTest.(Dissertation KTH Stockholm)

5 Stubbs, J., Moreira, W., and Dooley, R. (2015). Distributed Systems of Microservices Using Docker and Serfnode.

In International Workshop on Science Gateways (IWSG), 2015.

6 Levcovitz, A., Terra, R., and Valente, M. T. (2015). Towards a Technique for Extracting Microservices from Mono-

lithic Enterprise Systems. Brazilian Workshop on Software Visualization, Evolution and Maintenance (VEM).

7 Balalaie, A., Heydarnoori, A., and Jamshidi, P. (2015). Migrating to Cloud-Native Architectures Using Microser-

vices: An Experience Report. CloudWays Workshop.

8 Ouertani, S. (2015). From Microservices to SOA. Service Technology Magazine.

9 Rahman, M., and Gao, J. (2015). A Reusable Automated Acceptance Testing Architecture for Microservices in

Behavior-Driven Development. IEEE Symp on Service-Oriented System Engineering (SOSE), pp. 321-325.

10 Nycander, P. (2015). Learning-Based Testing of Microservices. Workshop on Automating Test case design, Selec-

tion and Evaluation.

11 Namiot, D., Sneps-Sneppe, M. (2015) On Micro-Services Architecture. Intl Jrnl of Open Information Technologies

12 Microservice-based Architecture for the NRDC. International Conference on Industrial Informatics (INDIN), 2015

13 Savchenko, D. I., Radchenko, G. I., and Taipale, O. (2015). Microservices validation: Mjolnirr platform case study.

Intl Conf on Cloud Computing and Services Science.

14 Versteden, A., Pauwels, E., and Papantoniou, A. (2015). An Ecosystem of User-facing Microservices supported by

Semantic Models. 5th International USEWOD Workshop: Using the Web in the Age of Data.

15 Toffetti, G., Brunner, S., Blchlinger, M., Dudouet, F., and Edmonds, A. (2015). An architecture for self-managing

microservices. Proceedings 1st Intl Workshop on Automated Incident Management in Cloud (pp. 19-24). ACM.

16 Krause, L. (2014). Microservices: Patterns and Applications.

17 Kukade, P. P., and Kale, G. (2015). Auto-Scaling of Micro-Services Using Containerization. International Journal

of Science and Research.

18 Viennot, N., Lcuyer, M., Bell, J., Geambasu, R., and Nieh, J. (2015). Synapse: a microservices architecture for

heterogeneous-database web applications. Proceedings 10th European Conference on Computer Systems.

19 Kratzke, N. (2015). About Microservices, Containers and their Underestimated Impact on Network Performance.

Cloud Computing Conf. 2015.

20 Thones, J. (2015). Microservices. IEEE Software, 32(1).

21 Newman, S. (2015). Building Microservices. O’Reilly Media, Inc.

microservices approaches that helps us to taxonomi-

cally classify and compare the primary studies.

4.1 Microservice Reference Model

While we do not include blogs in the study as there

is no formal, independent quality control in place, we

use this section to extract an industry perspective on

microservices from these.

Principles. A Microservice Architecture is a way

of architecting software applications as independently

deployable services. Based on (Lewis and Fowler,

2014), microservices can be characterise through a

number of principles:

• organization around business capability.

• evolutionary design.

• deployment / infrastructure automation.

• intelligence in the endpoints.

• heterogeneity and decentralized control

• decentralized control of data.

• design for failure.

Except the ﬁrst two items, the other point directly re-

late to the platform on which the architecture is de-

ployed on – the cloud in our context.

Patterns. Based on these principles, patterns emerge

to compose microservices. Arun Gupta proposes a

number of patterns in his blogs

. Recommended pat-

terns on how to compose microservices together

• Aggregator Microservice Design Pattern – e.g., a

service invoking others to retrieve / process data.

• Proxy Microservice Design Pattern – a variation

of the Aggregator with no aggregation.

• Chained Microservice Design Pattern – produces

a single consolidated response to a request.

• Branch Microservice Design Pattern – extends

the Aggregator and allows simultaneous re-

http://blog.arungupta.me/microservice-design-patterns/.

CLOSER 2016 - 6th International Conference on Cloud Computing and Services Science

140

sponse processing from possibly mutually exclu-

sive chains of microservices.

• Shared Data Microservice Design Pattern – to-

wards autonomy through full-stack services with

control of all components.

• Asynchronous Messaging Microservice Design

Pattern – use message queues instead of REST re-

quest/response pattern.

Looking at blogs

shows that coupling vs. autonomy

in microservices is an open question on what messag-

ing patterns to choose for microservices. Interaction

pattern, e.g., Request-Reply vs. Publish-Subscribe are

also discussed, as are event vs. command/query-based

information exchange. Putting these latter two dimen-

sions in a matrix would result in four options to realise

couplings between microservices. Microservices are

important for clouds and software architecture for the

cloud as the cloud can ideally support microservices

through services at different layers in different for-

mats and the cloud can provide mechanisms to deal

with the inherent challenges (uncertainty caused by

heterogeneity, multi-tenancy etc).

4.2 A Characterisation Framework

We propose a classiﬁcation framework that we will

use to categorise the primary studies. This frame-

works uses common terms from software engineering

methods with methodological support, architecture,

tool support and applications. The subheadings were

identiﬁed after a ﬁrst-round scans of selected studies

in order to ensure the validity of the framework.

• Methodological support

– Design – architecture-level software design

– Testing – quality assurance / test methods

– Conﬁguration and management – deployment

and quality related (e.g. scalability)

– Migration – refactor/re-engineer legacy into

microservices

– Microservice identiﬁcation – identify microser-

vices in existing solutions

• Architectural support – software architecture

– reference architectures

– architectural modelling and speciﬁcation

• Platform/tool support

– Testing – and test beds and other tool support

– Deployment/Provisioning platform – container

repositories and engines

Such as the blog https://www.voxxed.com/blog/2015/

04/ coupling- versus-autonomy-in-microservices/

– Microservice identiﬁcation – tool support

• Applications – application domains/sectors

– Types: e.g., Web apps, (smart) grids

– Domains: e.g., ﬁnancial services, transport

5 RESULTS

We categorise of the results in terms of concerns such

as publication format, forum and technical contribu-

tion. We also present the key terms extracted from the

studies. The results are discussed and the validity of

the results and their discussion is addressed.

5.1 Overview of the Primary Studies

In order to examine the state of research on microser-

vices, the following questions are considered:

• When did research on microservices become ac-

tive in computing community?

• What are the fora in which work on microservices

has been published? On which communities does

the focus lie?

• How is microservices research reported and what

is the maturity level of the research in this ﬁeld?

1) Temporal overview of studies. With only a few

studies in 2014, there has been a dramatic increase

in 2015, signaling a signiﬁcant concern (Fig. 2). No

relevant publications were found prior to 2014, as the

terms has not been used as understood today.

2) Publication fora and formats. We have categorised

the publication fora into the computing ﬁelds as fol-

lows (Figure 3):

• software engineering

• service engineering

• cloud computing

• networks, telecomms and distributed systems

• wider computing/IT/science context

Figure 2: Trend Graph for Microservices.

Microservices: A Systematic Mapping Study

141

Regarding the sources, we recognise and distin-

guish the following publication formats: journal

[11,22], magazines [8,20], conferences and work-

shops [3,4,5,6,7,10,12,13,14,15,17,18,19] and theses

[1,2,4] and books [16,21].

Figure 3: Study Distribution by Field.

3) Research methods for microservices. Typically, the

contribution type (Solution Proposal, Evaluation Re-

search, Validation Research, Experience Report, Re-

view) and the evaluation method (Case Study, Mathe-

matical Proof, Experience Report, Example Applica-

tion, Controlled Experiment) are distinguished.

In Figure 4, the primary studies are organised ac-

cording to their contribution type. Given the relative

immaturity of the domain, the evaluations lack de-

tailed experience reports and proofs, while equally

controlled experiments, sample implementation as

experience reports and some controlled experiments

have been reported. Figure 5 complements this by

looking more speciﬁcally at the technical contribution

(categorising non-solution studies such as experience

reports, evaluations and reviews as ’other’). More in-

teresting here is the 3:2 split between an architecture

perspective and a method perspective.

Figure 4: Study Distribution by Contribution Type.

Table 7 lists extracted keywords by frequency and

Table 8 compares studies based on the core categories.

5.2 Discussion

The key terms extracted from all selected studies help

to categorise them in terms of individual focus and

Figure 5: Study Distribution by Technical Contribution.

contribution (Figures 3 to 5) and to obtain an under-

standing of key research concerns. In order to address

the latter concern, Table 7 shows the terms extracted:

• these have been categorised by following a com-

mon upper ontology (Pease et al., 2002) with

3 central concepts object (computational entity,

activity (purpose) and property (quality), which

has been supplemented by additional dimensions

technology, research approach, application con-

text and application.

• for each term, we recorded the number of occur-

rences – higher numbers of occurrences indicate a

stronger research concern and/or stronger consen-

sus on the importance of the aspect.

Some observations can be deduced from the key

terms distribution and frequency. In terms of key ben-

eﬁts that characterise microservices, we can observe:

• Architecture: Microservice architectures are dis-

tributed. Microservices are component/service

style entities, speciﬁcally characterised by be-

ing independently deployable and scalable in dis-

tributed architectures as primary concerns.

• Method/Process: Furthermore, maintainability

and evolvability are further characteristics. Mi-

croservices need to be seen in a wider continuous

development context (e.g., DevOps).

• Deployment/Operation: a third import concern

emerges that refers to the deployment of microser-

vices. While we limited the study selection to

those clearly focusing on microservices (by se-

lecting those with ’microservice’ in the title),

nonetheless, the key term prove the importance of

the cloud and containers as independent deploy-

ment, autoscaling, Docker, container are very fre-

quently mentioned.

There is agreement that this is a new architectural

style. Microservices have been emerging out of ser-

vices, but the link to containers is obvious. While at

the deployment level, there is a clear focus on cloud,

and container technologies in particular, the current

CLOSER 2016 - 6th International Conference on Cloud Computing and Services Science

142

Table 7: Key terms extracted after two rounds of extraction and keyword frequency.

Q Quality # E Entity # P Activity # T

Technology

# C Context # R Research

Approach

# A

Application

scalability 6 architectural

style

5 testing 6 Docker 3 Monolithic

Enterpr Syst

4 Experiment 2 Financial

services

independently

deployable

6 pattern 3 self-

manage

5 SerfNode 1 IoT 1 Case Study 2 Transport 1

maintainable 3 Container 3 distribution 4 Spring 1 SOA 1 Analysis/

Comparison

1 Learning

Technology

interoperable 2 smart grid 2 componentise 3 Libraries 1

reusable 2 Web app 2 semantic

modelling

3 Middleware 1

user-facing 2 architecture 2 migration 3 Data Centre 1

performance 2 network 1 auto-scale 2

context-based 1 arch pattern 1 development 1

heterogeneous 1 architecture

paradigm

1 validation 1

mobile 1 adoption 1

reliable 1 packaging 1

smart 1 replication 1

ﬂexibility 1 security 1

monitoring 1

application domains are more traditional. Here, ﬁ-

nancial services (in a hybrid on-premise/private cloud

scenario) and transport (more an edge cloud scenarios

with the need to support lightweight virtualisation on

smaller devices/sensors) have been investigated.

Another important perspective is the application

of microservices in a long-term software evolution

and modernisation context: (i) Microservices are of-

ten discussed in software and IT systems migration.

(ii) Their SOA inheritance emphasises their suitabil-

ity for modernising monolithic legacy systems.

The forums in which microservices are discussed

are – in this order – the following: software engi-

neering, service engineering, cloud computing, fol-

lowed by others such as networks, operating systems

and distributed systems. This demonstrates the na-

ture of microservices as a service-oriented architec-

tural style. Most of these include some reference to

cloud computing, even if not published in this forum.

5.3 Classiﬁcation of Microservice

Methods and Techniques

In Table 8, we compared the studies based on the

core classiﬁcation categories. As already stated, mi-

croservices are considered as an architectural style, in

which we can distinguish two technical perspectives

(see column ’Technical Contribution, which reﬁnes

the ’Contribution Type’):

• Architecture: architecture implementation and

validation, but also architecture design methods.

• Methods: a more process-centric view with

method deﬁnitions and validations.

Figure 6, where we mapped the generic contribution

types (Solution, Evaluation, Experience Report, Re-

view) to more speciﬁc technical contributions rele-

vant in the microservices context (Architecture and

Method), makes the distribution of technical contribu-

tions more clear. The bubble size indicates the num-

ber of studies of that type.

Solutions and their experimental validation dom-

inate (the 2 left-most columns Sol and Val). We can

also see that Architecture is more prevalent (the lower

3 rows AI, AM, AV) than the process-centric Method

perspective (the 2 rows MD and MV above) – see

Figure caption for acronym deﬁnition. In the upper

right corner, non-solution/validation studies are sum-

marised. Here systematic evaluations and experience

reports on the one hand (Eval, Exp) and technology

reviews (Rev) are equally frequent.

5.4 Threats to Validity

We discuss threats to the validity of this work in the

different mapping study steps.

Threats to the Identiﬁcation of Primary Stud-

ies. A challenge was to determine the scope of our

study, since microservices relate to different comput-

ing and IT communities including software engineer-

ing, information systems and cloud. These communi-

ties use different terminologies for the same concepts.

To cover all and avoid bias, we searched for the mi-

croservice term in different contexts. While this ap-

proach decreases bias, it signiﬁcantly increases search

effort. To identify relevant studies and ensure an un-

biased selection, a review protocol was developed.

Microservices: A Systematic Mapping Study

143

Figure 6: Study Distribution by Technical Contribution over Contribution Type (bubble plot).

[Sol:Solution, Val:Validation, Eval:Evaluation, Exp: Experience Report, Rev: Review; AI:Architecture Implementation,

AM:Architecture Method, AV:Architecture Validation, MD:Method Deﬁnition, MV:Method Validation, Oth:Others] .

Threats to Selection and Data Extraction Con-

sistency. The formulation of the research questions

has helped in selecting studies of relevance, as did the

Reference Model and Characterisation Framework in

Section 3. However, we did include magazine con-

tributions and thesis here (as along as a review took

place) to include all trends and activities.

Threats to Data Synthesis and Results. This re-

liability threat is mitigated as far as possible by hav-

ing a uniﬁed characterization scheme and following

a standard protocol where several steps were piloted

and externally evaluated.

6 RESEARCH IMPLICATIONS

AND FUTURE DIRECTIONS

While the maturity is low, valuable insights into

trends can be identiﬁed that are of beneﬁt to re-

searchers and practitioners alike.

6.1 Maturity

The actual scientiﬁc contributions are a mix of tech-

nology reviews, test environments and use case archi-

tectures (conceptual and implemented). As a good

part of this is still conceptual, it can be seen as a sign

of immaturity. This interpretation is strengthened by

the fact that some use case validations and no larger-

scale empirical evaluations exist.

Regarding the contribution formats, there is also a

notice imbalance compared to more mature domains:

• Larger number of thesis (BSc/MSc level) and

magazine article – pointing at an emerging topic

through initial experimental and explorative work

particularly at Bachelor or Master level, and also

in magazines providing early technology reviews.

The number of journal publications is low (with

short communications published only).

• Higher number of use cases in comparison with

technology solutions – again pointing at an

emerging topic by aiming to formatively validate

the technology through use cases, rather than a

more systematic summative evaluation.

We can note speciﬁcally a lack of proven tech-

nologies to realize a microservices architecture, un-

derstanding to differentiate SOA from microservices,

monitoring tools for microservices, architectural pat-

tern for microservices, experimental approaches to

empirically compare microservices with other styles

(for example using architecture evaluation mathods

like ATAM), tools to enable performance-driven De-

vOps for microservice architecture development, soft-

ware enigneering methods (methodologies, design

patterns, best practices, quality assurance, system ver-

sioning, change management) for microservice archi-

tecture development, and successful/unsuccessful ex-

amples of microservices development (only a few ex-

ist, c.f. Netﬂix).

CLOSER 2016 - 6th International Conference on Cloud Computing and Services Science

144

Table 8: Study comparison in terms of characterisation framework (focussing on architecture and method support – column

Technical Contribution).

ID Title Format Field Contrib

Type

Technical

Contribution

Contribution Details

1 Distribution of microservices for hardware in-

teroperability in the Smart Grid

Thesis Telecoms Sol Architecture

Implement

microservice-based smart grid impl

2 Evaluation of Microservices as an Extension of

Component Technologies (in German)

Thesis Soft Eng Eval Concept

Evaluation

conceptual evaluation

3 Location and Context-Based Microservices for

Mobile and Internet of Things Workloads

Conf/WorkshopMobile

Comp

Eval Concept

Evaluation

3 sample use cases (microserv)

4 Learning-Based Testing of Microservices: An

Exploratory Case Study Using LBTest

Thesis Soft Eng Val Architecture

Validation

microservice test bed

5 Distributed Systems of Microservices Using

Docker and Serfnode

Conf/WorkshopScience Rev Review review of container tech

6 Towards a Technique for Extracting Microser-

vices from Monolithic Enterprise Systems

Conf/WorkshopSoft Eng Sol Service technique for ms identiﬁcation in en-

terprise arch

7 Migrating to Cloud-Native Architectures Us-

ing Microservices: An Experience Report

Conf/WorkshopCloud Exp Experience

Report

migration experience report

8 From Microservices to SOA Magazine Services Rev Review technology review

9 A Reusable Automated Acceptance Testing

Architecture for Microservices in Behavior-

Conf/WorkshopServices Val Architecture

Validation

testing architecture for ms

10 Learning-Based Testing of Microservices Conf/WorkshopSoft Eng Val Architect

Validation

microservice test bed

11 On Micro-Services Architecture Journal Science/

Engineer

Rev Review technology review

12 Microservice-based Architecture for the

NRDC

Conf/WorkshopSystems Exp Experience

Report

data centre architecture using mi-

croservices

13 Microservices validation: Mjolnirr platform

case study

Conf/WorkshopCloud Val Method Vali-

dation

testing for ms review + validation

method for ms

14 An Ecosystem of User-facing Microservices

supported by Semantic Models

Conf/WorkshopWeb/ Se-

mantics

Sol Architecture

Method

abstract architecture for ms for Web

apps

15 An architecture for self-managing microser-

vices

Conf/WorkshopCloud Sol Architect

Method

(concept) architecture for self-

management of microservices

16 Microservices: Patterns and Applications Book Soft Eng Sol Method Def-

inition

design methods and patterns

17 Microservice-based Architecture for the

NRDC

Conf/WorkshopSystems Exp Experience

Report

data centre architecture using mi-

croservices

18 Synapse: a microservices architecture for

heterogeneous-database web applications

Conf/WorkshopSystems Sol Architecture

Implement

(implement) architecture for mi-

croservices for web DB apps

19 About Microservices, Containers and their Un-

derestimated Impact on Network Performance

Conf/WorkshopCloud Sol Method Def-

inition

analysis and design recommenda-

tions

20 Microservices Magazine Soft Eng Rev Review technology review

21 Building Microservices Book Soft Eng Sol Method Def-

inition

full lifecycle methodology (design,

testing, impl/devops)

21 Auto-Scaling of Micro-Services Using Con-

tainerization

Journal Science/

Engineer

Val Architecture

Method

conceptual architecture and scaling

approach

23 A Microservice Approach for Near Real-Time

Collaborative 3D Objects Annotation

Conf/WorkshopWeb/ Se-

mantics

Val Architecture

Validation

microservices use case in learning

technology

6.2 Research Trends

In terms of a perceived need for research, the follow-

ing aspects are important regarding methodological

and tool support:

• Testing is of particular importance (microservices

as design artefact towards satisfying an integra-

tion need)

• Intelligent semantic technologies for their man-

agement for instance for discovery in repositories.

• Resulting from independence, self-manageability

enabled by the deployment platform.

Further trends can be added: microservices migration,

autonomous healing, runtime architecture change, ar-

chitectural patterns, DevOps and microservices, mi-

croservice monitoring, auto-scaling in the context

of microservices, conﬁguration optimization for mi-

croservices, and architectural refactoring.

Microservices: A Systematic Mapping Study

145

6.3 Beneﬁts for Researchers and

Practitioners

The characterization framework provides a holistic

view of different microservices concerns to be con-

sidered. The classiﬁcation and comparison of stud-

ies, which contains overall 6 comparison attributes

presented across the ﬁgures and tables, provides use-

ful information. For the 21 papers and 6 compari-

son attributes, it creates a collection with 21*6 = 126

data points. This is beneﬁcial for researchers who

require a quick identiﬁcation of relevant studies and

detailed insight into state-of-the-art that supports mi-

croservices, but also for practitioners interested in un-

derstanding existing methods, architectures and tools

for microservice development and deployment.

7 CONCLUSIONS

Microservices have only received attention very re-

cently (Lewis and Fowler, 2014; Newman, 2015),

driven by two factors. Firstly, they address limitations

of the SOA style (Erl, 2005), speciﬁcally linking it to

independent deployability and lightweightness. Com-

panies such as Netﬂix and Thoughworks have been at

the forefront of this.

This brings this discussion also into the context of

continuous development approaches (Fitzgerald and

Stol, 2014) such as DevOps (Brunnert et al., 2015).

Furthermore, cloud technology (Mell and Grance,

2011; Antonopoulos and Gillam, 2010) and container

technology in this context in particular (Pahl and Lee,

2015; Pahl, 2015) provide a mechanism to deploy mi-

croservices consistent with the style principles. Mi-

croservice patterns need to be mapped onto cloud pat-

terns (Pahl and Jamshidi, 2015; Fehling et al., 2014).

While the maturity of the research work is quite

low, given the recent emergence of the topic, a con-

clusive summative analysis is not possible, but good

pointers towards research gaps and directions can be

derived that can be seen as a contribution of a more

formative investigation of the domain.

In conclusion, from our mapping study, microser-

vices emerge as an architectural style, but one that

extends from the ’design-stage architecture’ into de-

ployment and operations as a continuous development

style – the ’method’ dimension. It also seem from a

signiﬁcant part of the studies reviewed to be intrin-

sicly linked to cloud-based containers for deployment

and dynamic management - the ’dynamic architec-

ture’ dimension.

REFERENCES

Antonopoulos, N. and Gillam, L. (2010). Cloud computing:

Principles, systems and applications. Springer.

Brunnert et al., A. (2015). Performance-oriented devops: A

research agenda. Technical Report: SPEC-RG-2015-

01, SPEC RG DevOps Performance Working Group.

Erl, T. (2005). Service-oriented architecture: concepts,

technology, and design. Pearson Education.

Fehling, C., Leymann, F., Retter, R., Schupeck, W., and

Arbitter, P. (2014). Cloud computing patterns.

Fitzgerald, B. and Stol, K.-J. (2014). Continuous software

engineering and beyond: Trends and challenges. In

1st Intl Workshop on Rapid Continuous Software En-

gineering, RCoSE 2014, pages 1–9.

Jamshidi, P., Ahmad, A., and Pahl, C. (2013a). Cloud mi-

gration research: a systematic review. Cloud Comput-

ing, IEEE Transactions on, 1(2):142–157.

Jamshidi, P., Ghafari, M., Ahmad, A., and Pahl, C.

(2013b). A framework for classifying and compar-

ing architecture-centric software evolution research.

In 7th European Conference on Software Maintenance

and Reengineering (CSMR), 2013, pages 305–314.

Kitchenham, B., Brereton, O. P., Budgen, D., Turner, M.,

Bailey, J., and Linkman, S. (2009). Systematic litera-

ture reviews in software engineering–a systematic lit-

erature review. Information and software technology,

51(1):7–15.

Lewis, J. and Fowler, M. (2014). Microservices.

http://martinfowler.com/articles/microservices.html.

Mell, P. and Grance, T. (2011). The NIST deﬁnition of

cloud computing.

Newman, S. (2015). Building Microservices. O’Reilly.

Pahl, C. (2015). Containerization and the paas cloud. IEEE

Cloud Computing, 2(3):24–31.

Pahl, C. and Jamshidi, P. (2015). Software architecture

for the cloud - a roadmap towards control-theoretic,

model-based cloud architecture. In Europ Conference

on Software Architecture ECSA’15.

Pahl, C. and Lee, B. (2015). Containers and clusters for

edge cloud architectures - a technology review. In 3rd

International Conference on Future Internet of Things

and Cloud (FiCloud-2015). IEEE.

Pease, A., Niles, I., and Li, J. (2002). The suggested upper

merged ontology: A large ontology for the semantic

web and its applications. In AAAI-2002 workshop on

ontologies and the semantic web.

Petersen, K., Feldt, R., Mujtaba, S., and Mattsson, M.

(2008). Systematic mapping studies in software en-

gineering. In 12th Intl Conference on Evaluation and

Assessment in Software Engineering, volume 17.

Zimmermann, O. (2009). An architectural decision mod-

eling framework for service oriented architecture de-

sign. PhD thesis, Universit

at Stuttgart.

CLOSER 2016 - 6th International Conference on Cloud Computing and Services Science

146