Microservices: A Systematic Mapping Study

Claus Pahl1 and Pooyan Jamshidi2

1 Faculty of Computer Science, Free University of Bozen-Bolzano, Bolzano, Italy
2 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 classified 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 ture directions. Given the growing interest in con-

tainers and microservices in cloud, there is a need
Recently, microservice architectures have been pro- to explore a research agenda. SLRs and SMS iden-
posed to break up application architectures into in- tify, classify and synthesize a comparative overview
dependently deployable services that can be rapidly of state-of-the-research and enable (Petersen et al.,
deployed to any infrastructure resource as required 2008; Kitchenham et al., 2009). We opt for a system-
(Newman, 2015; Lewis and Fowler, 2014). Mi- atic mapping study as it is more suitable in mapping
croservices are independently deployable, usually out and structuring new areas of investigation.
supported by a deployment and orchestration frame- We aim here to identify, taxonomically clas-
work, e.g., in the cloud, enabling them to deploy of- sify and systematically compare the existing research
ten and independently at arbitrary schedules. Mi- body on microservices and their application in the
croservice deployment and orchestration across the cloud. We have conducted a systematic mapping
distributed and stacked nature of the cloud are cen- study of 21 selected studies, published over the last
tral architecture concerns. Clouds provide a manage- two years since the emergence of the microservices
ment tool for their flexible deployment schedules and pattern. We classified and compared the selected stud-
provisioning orchestration needs, particularly, if these ies based on a characterization framework.
are to be PaaS-provisioned. The research mapping study resulted in a knowl-
Research on microservices has addressed both the edge base of current research approaches, methods,
architectural principles and support as well as the techniques, best practices and experiences used in mi-
application of the architectural pattern in the cloud. croservices architecture, with a particular attention to
In the cloud, microservices are linked to contain- cloud application. This review reveals that microser-
ers, which are a lightweight virtualisation mechanism vices research is still in a formative stage. More ex-
used for application packaging, distribution and or- perimental and empirical evaluation of the benefits is
chestration at the PaaS layer (Pahl, 2015), even to- needed. This study also showed a lack of tool support
wards edge clouds with smaller resource environ- to automate and facilitate cloud microservice.
ments (Pahl and Lee, 2015). The results of this study aim to benefit, firstly,
There has not been a systematic literature review researchers in software engineering and cloud com-
(SLR) or mapping study (SMS) of research on mi- puting, who need an identification of relevant stud-
croservices that would allow to assess the maturity in ies. Secondly, practitioners interested in understand-
general and identifying trends, research gaps and fu- ing the available methods and techniques with tool

137
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
Copyright c 2016 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved
CLOSER 2016 - 6th International Conference on Cloud Computing and Services Science

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 findings, implications Figure 1: Cloud Reference Architecture Model.
and trends followed by an analysis of its limitations.
through a characterization framework. Some technol-
ogy reviews exist (and also classified as such later),
but these concentrated on technology and do not cap-
2 BACKGROUND ture research efforts and directions systematically.
Based on (Newman, 2015; Lewis and Fowler, 2014),
microservices are about functional decomposition of-
ten in a domain-driven design context. They are char- 3 RESEARCH METHODOLOGY
acterised by well-defined and explicitly published in-
terfaces. Each service is fully autonomous and full- SMSs reduce bias through rigorous sequence of
stack. Consequently, changing a service implementa- methodological steps to research literature. They rely
tion has no impact to other services as communication on well-defined and evaluated review protocols to ex-
takes place using interfaces only. Functional decom- tract, analyze and document results. We follow the
position of an application and the team is the key to process presented in (Petersen et al., 2008) with a
building a successful microservices architecture. This three-step review that includes planning, conducting
achieves loose coupling (REST interfaces) and high and documenting. The review is complemented by an
cohesion (multiple services can compose with each evaluation of each step’s outcome. Furthermore, we
other to define higher level services or application). provide an additional characterization framework for
Functional decomposition enables for instance agility, the study context.
flexibility, scalability.
Table 1: Research Process.
2.1 Lightweight Architectures, Services, Step Activity
Containers and Microservices plan identify need, specify RQs, define protocol
conduct select primary studies, extract/synthesize data
Microservices are an architectural pattern emerging document document observations, analyze threats, report
out of Service-Oriented Architecture (SOA), empha-
sising self-management and lightweightness. While Now the individual steps will be outlined. Based
this is an architectural principle, container technol- on the objectives, we specify the research questions
ogy has emerged in parallel in cloud computing to and the review scope in order to formulate search
provide a lightweight virtualisation mechanism that strings for literature extraction.
can serve as an application packaging mechanism for
PaaS clouds. Microservice can ideally be packaged, 3.1 Planning the Review
provisioned and orchestrated through cloud.
The cloud can be seen as a distributed and tiered Step 1 – Identify the Need for SLR. We have already
architecture, see Figure 1. The core infrastruc- discussed the need for a SMS in the previous section.
ture, platform and software application tiers can dis- We can also make explicit the general goal and scope
tributed across multi-cloud environments – based on of the study using the PICO (Population, Intervention,
container-based microservices. Comparison, Outcome) criteria, see Table 2.
Step 2 – Specifying the Research Questions. As
2.2 Need for a Secondary Study the next activity, we define the research questions to
help shaping the review protocol, see Table 3.
The need for a SLR or SMS entails to identify, Step 3 – Define and Evaluate Review Protocol. We
classify and compare existing evidence on the use developed a protocol for a mapping study based on
of microservices specifically in cloud environments (Petersen et al., 2008) and our experience with SLRs

138
 Microservices: A Systematic Mapping Study

Table 2: PICO criteria. Table 4: Selection Terms.

Concern Explanation microservice micro-service
Population RQ1: Practical motivation, RQ2: Ar-
chitecture tasks, RQ3: Methods and
vant studies, which were further refined with a sec-
techniques, RQ4: Research challenges
and future dimensions [all detailed be- ondary search – focusing on title occurrences only
low] and resulting then in 21 studies.
Intervention Characterization, Internal/external vali- Step 1a – Initial Selection. This step includes screen-
dation; Extracting data and Synthesis ing of titles and abstracts of potential primary studies
Comparison A comparison by mapping the primary
studies to a characterization framework
– performed against inclusion/exclusion criteria
Outcome A characterization framework
Table 5: Inclusion/exclusion criteria.
Table 3: Research Questions. In/Excl Criteria
Research Question Motivation Inclusion • Abstract/keywords include key terms
RQ1 What are the main The aim is to get insight • From the abstract it is clear that a con-
practical motivations be- in what are the main rea- tribution towards microservices and their
hind using microservices? sons for organizations to management is made
architect in a microser- Exclusion • Type: literature only in the form of ab-
vices style.
stract, blog, presentation are excluded
RQ2 What are the differ- The aim is to investigate
ent types of microservice what are the possibilities • Papers with microservices terms only in
architectures involved? for architecting in a mi- abstract or with different meaning
croservice style.
RQ3 What are the existing The aim is to identify and Step 1b – Final Selection. This is based on a val-
methods, techniques and compare existing methods
tool support to enable mi- and techniques that sup-
idation scan of the studies, methods for microser-
croservice architecture de- port microservice architec- vices and tool support and details of the evaluation
velopment and operation? ture. approach. At the end, 21 studies were selected.
RQ4 What are the ex- The aim is to understand Step 1c – Qualitative Assessment of Included Studies.
isting research issues and and reveal the research
what should be the future gaps and identify future di-
For the 27 included studies, we primarily focused on
research agenda? rections. the technical rigor of content presented. We based
our qualitative assessment on factors like General As-
(Jamshidi et al., 2013a; Jamshidi et al., 2013b) that is sessment (G) and Specific Assessment (S). Quality
outlined in this section. scores provided us with a numerical quantification to
rank the selected studies, but given the recency of
3.2 Conducting the Review the development, we also included books and the-
ses/dissertations as long as there is evidence of a re-
view being carried out.
Conducting starts with study selection and resulting
in extracted data and synthesized information. Steps 2 and 3 – Data Extraction and Synthesis. In
order to record extracted data from the selected stud-
Step 1 – Select Primary Studies (Study Selection
ies, we follow (Petersen et al., 2008) using a struc-
and Qualitative Assessment). The search terms
tured format based on characterization dimensions.
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 4 A MICROSERVICE
term ’microservice’ (and variations such as ’micro-
service’ as search terms, cf. 4, to avoid excluding any
ARCHITECTURE
studies in this emerging context. We extracted ini- FRAMEWORK
tially 243 studies from years 2014 to 2015 (incl.) – as
of 3 Nov. 2015. The year 2014 was chosen as the term We first introduce a reference model for an
microservice as an architectural pattern is only consis- architecture-centric classification of microservices
tently used since then. Earlier occurrences referred to that helps to demonstrate current research at a concep-
microservices as somehow small in scale, but without tual level and identify trends and research directions.
a clear reference to an architectural style or pattern, We follow (Zimmermann, 2009) in his definition of
and were thus excluded. an architectural style and present the microservices
Since we used our primary search criteria on title style as a collection of principles and patterns. We
and abstract, this resulted in a high number of irrele- then present a framework to characterize individual

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

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- • decentralized control of data.

cally classify and compare the primary studies. • design for failure.
4.1 Microservice Reference Model Except the first two items, the other point directly re-
late to the platform on which the architecture is de-
While we do not include blogs in the study as there ployed on – the cloud in our context.
is no formal, independent quality control in place, we Patterns. Based on these principles, patterns emerge
use this section to extract an industry perspective on to compose microservices. Arun Gupta proposes a
microservices from these. number of patterns in his blogs1 . Recommended pat-
Principles. A Microservice Architecture is a way terns on how to compose microservices together
of architecting software applications as independently • Aggregator Microservice Design Pattern – e.g., a
deployable services. Based on (Lewis and Fowler, service invoking others to retrieve / process data.
2014), microservices can be characterise through a • Proxy Microservice Design Pattern – a variation
number of principles: of the Aggregator with no aggregation.
• organization around business capability. • Chained Microservice Design Pattern – produces
• evolutionary design. a single consolidated response to a request.
• deployment / infrastructure automation. • Branch Microservice Design Pattern – extends
• intelligence in the endpoints. the Aggregator and allows simultaneous re-
• heterogeneity and decentralized control 1 http://blog.arungupta.me/microservice-design-patterns/.

140
 Microservices: A Systematic Mapping Study

sponse processing from possibly mutually exclu- – Microservice identification – tool support
sive chains of microservices. • Applications – application domains/sectors
• Shared Data Microservice Design Pattern – to-
– Types: e.g., Web apps, (smart) grids
wards autonomy through full-stack services with
control of all components. – Domains: e.g., financial services, transport
• Asynchronous Messaging Microservice Design
Pattern – use message queues instead of REST re-
quest/response pattern. 5 RESULTS
Looking at blogs2 shows that coupling vs. autonomy
We categorise of the results in terms of concerns such
in microservices is an open question on what messag-
as publication format, forum and technical contribu-
ing patterns to choose for microservices. Interaction
tion. We also present the key terms extracted from the
pattern, e.g., Request-Reply vs. Publish-Subscribe are
studies. The results are discussed and the validity of
also discussed, as are event vs. command/query-based
the results and their discussion is addressed.
information exchange. Putting these latter two dimen-
sions in a matrix would result in four options to realise
couplings between microservices. Microservices are 5.1 Overview of the Primary Studies
important for clouds and software architecture for the
cloud as the cloud can ideally support microservices In order to examine the state of research on microser-
through services at different layers in different for- vices, the following questions are considered:
mats and the cloud can provide mechanisms to deal • When did research on microservices become ac-
with the inherent challenges (uncertainty caused by tive in computing community?
heterogeneity, multi-tenancy etc).
• What are the fora in which work on microservices
has been published? On which communities does
4.2 A Characterisation Framework the focus lie?
We propose a classification framework that we will • How is microservices research reported and what
use to categorise the primary studies. This frame- is the maturity level of the research in this field?
works uses common terms from software engineering 1) Temporal overview of studies. With only a few
methods with methodological support, architecture, studies in 2014, there has been a dramatic increase
tool support and applications. The subheadings were in 2015, signaling a significant concern (Fig. 2). No
identified after a first-round scans of selected studies relevant publications were found prior to 2014, as the
in order to ensure the validity of the framework. terms has not been used as understood today.
• Methodological support
– Design – architecture-level software design 2) Publication fora and formats. We have categorised
the publication fora into the computing fields as fol-
– Testing – quality assurance / test methods lows (Figure 3):
– Configuration and management – deployment
and quality related (e.g. scalability) • software engineering
– Migration – refactor/re-engineer legacy into • service engineering
microservices • cloud computing
– Microservice identification – identify microser-
• networks, telecomms and distributed systems
vices in existing solutions
• wider computing/IT/science context
• Architectural support – software architecture
– reference architectures
– architectural modelling and specification
• Platform/tool support
– Testing – and test beds and other tool support
– Deployment/Provisioning platform – container
repositories and engines
2 Such as the blog https://www.voxxed.com/blog/2015/
04/ coupling- versus-autonomy-in-microservices/ Figure 2: Trend Graph for Microservices.

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

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 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:
Figure 3: Study Distribution by Field. • these have been categorised by following a com-
mon upper ontology (Pease et al., 2002) with
3) Research methods for microservices. Typically, the 3 central concepts object (computational entity,
contribution type (Solution Proposal, Evaluation Re- activity (purpose) and property (quality), which
search, Validation Research, Experience Report, Re- has been supplemented by additional dimensions
view) and the evaluation method (Case Study, Mathe- technology, research approach, application con-
matical Proof, Experience Report, Example Applica- text and application.
tion, Controlled Experiment) are distinguished. • for each term, we recorded the number of occur-
In Figure 4, the primary studies are organised ac- rences – higher numbers of occurrences indicate a
cording to their contribution type. Given the relative stronger research concern and/or stronger consen-
immaturity of the domain, the evaluations lack de- sus on the importance of the aspect.
tailed experience reports and proofs, while equally
controlled experiments, sample implementation as Some observations can be deduced from the key
experience reports and some controlled experiments terms distribution and frequency. In terms of key ben-
have been reported. Figure 5 complements this by efits that characterise microservices, we can observe:
looking more specifically at the technical contribution • Architecture: Microservice architectures are dis-
(categorising non-solution studies such as experience tributed. Microservices are component/service
reports, evaluations and reviews as ’other’). More in- style entities, specifically characterised by be-
teresting here is the 3:2 split between an architecture ing independently deployable and scalable in dis-
perspective and a method perspective. 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),
Figure 4: Study Distribution by Contribution Type. nonetheless, the key term prove the importance of
the cloud and containers as independent deploy-
Table 7 lists extracted keywords by frequency and ment, autoscaling, Docker, container are very fre-
Table 8 compares studies based on the core categories. quently mentioned.
There is agreement that this is a new architectural
5.2 Discussion style. Microservices have been emerging out of ser-
vices, but the link to containers is obvious. While at
The key terms extracted from all selected studies help the deployment level, there is a clear focus on cloud,
to categorise them in terms of individual focus and and container technologies in particular, the current

142
 Microservices: A Systematic Mapping Study

Table 7: Key terms extracted after two rounds of extraction and keyword frequency.
Q Quality # E Entity # P Activity # T # C Context # R Research # A #
Technology Approach Application
scalability 6 architectural 5 testing 6 Docker 3 Monolithic 4 Experiment 2 Financial 3
style Enterpr Syst services
independently 6 pattern 3 self- 5 SerfNode 1 IoT 1 Case Study 2 Transport 1
deployable manage
maintainable 3 Container 3 distribution 4 Spring 1 SOA 1 Analysis/ 1 Learning 1
Comparison Technology
interoperable 2 smart grid 2 componentise 3 Libraries 1
reusable 2 Web app 2 semantic 3 Middleware 1
modelling
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 1 validation 1
paradigm
mobile 1 adoption 1
reliable 1 packaging 1
smart 1 replication 1
flexibility 1 security 1
monitoring 1

application domains are more traditional. Here, fi- Figure 6, where we mapped the generic contribution
nancial services (in a hybrid on-premise/private cloud types (Solution, Evaluation, Experience Report, Re-
scenario) and transport (more an edge cloud scenarios view) to more specific technical contributions rele-
with the need to support lightweight virtualisation on vant in the microservices context (Architecture and
smaller devices/sensors) have been investigated. Method), makes the distribution of technical contribu-
Another important perspective is the application tions more clear. The bubble size indicates the num-
of microservices in a long-term software evolution ber of studies of that type.
and modernisation context: (i) Microservices are of- Solutions and their experimental validation dom-
ten discussed in software and IT systems migration. inate (the 2 left-most columns Sol and Val). We can
(ii) Their SOA inheritance emphasises their suitabil- also see that Architecture is more prevalent (the lower
ity for modernising monolithic legacy systems. 3 rows AI, AM, AV) than the process-centric Method
The forums in which microservices are discussed perspective (the 2 rows MD and MV above) – see
are – in this order – the following: software engi- Figure caption for acronym definition. In the upper
neering, service engineering, cloud computing, fol- right corner, non-solution/validation studies are sum-
lowed by others such as networks, operating systems marised. Here systematic evaluations and experience
and distributed systems. This demonstrates the na- reports on the one hand (Eval, Exp) and technology
ture of microservices as a service-oriented architec- reviews (Rev) are equally frequent.
tural style. Most of these include some reference to
cloud computing, even if not published in this forum. 5.4 Threats to Validity
5.3 Classification of Microservice We discuss threats to the validity of this work in the
Methods and Techniques different mapping study steps.
Threats to the Identification of Primary Stud-
ies. A challenge was to determine the scope of our
In Table 8, we compared the studies based on the
study, since microservices relate to different comput-
core classification categories. As already stated, mi-
ing and IT communities including software engineer-
croservices are considered as an architectural style, in
ing, information systems and cloud. These communi-
which we can distinguish two technical perspectives
ties use different terminologies for the same concepts.
(see column ’Technical Contribution, which refines
To cover all and avoid bias, we searched for the mi-
the ’Contribution Type’):
croservice term in different contexts. While this ap-
• Architecture: architecture implementation and proach decreases bias, it significantly increases search
validation, but also architecture design methods. effort. To identify relevant studies and ensure an un-
• Methods: a more process-centric view with biased selection, a review protocol was developed.
method definitions and validations.

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

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 Definition, MV:Method Validation, Oth:Others] .

Threats to Selection and Data Extraction Con- Regarding the contribution formats, there is also a
sistency. The formulation of the research questions notice imbalance compared to more mature domains:
has helped in selecting studies of relevance, as did the • Larger number of thesis (BSc/MSc level) and
Reference Model and Characterisation Framework in magazine article – pointing at an emerging topic
Section 3. However, we did include magazine con- through initial experimental and explorative work
tributions and thesis here (as along as a review took particularly at Bachelor or Master level, and also
place) to include all trends and activities. in magazines providing early technology reviews.
Threats to Data Synthesis and Results. This re- The number of journal publications is low (with
liability threat is mitigated as far as possible by hav- short communications published only).
ing a unified characterization scheme and following
a standard protocol where several steps were piloted • Higher number of use cases in comparison with
and externally evaluated. 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.
6 RESEARCH IMPLICATIONS
We can note specifically a lack of proven tech-
AND FUTURE DIRECTIONS nologies to realize a microservices architecture, un-
derstanding to differentiate SOA from microservices,
While the maturity is low, valuable insights into
monitoring tools for microservices, architectural pat-
trends can be identified that are of benefit to re-
tern for microservices, experimental approaches to
searchers and practitioners alike.
empirically compare microservices with other styles
(for example using architecture evaluation mathods
6.1 Maturity like ATAM), tools to enable performance-driven De-
vOps for microservice architecture development, soft-
The actual scientific contributions are a mix of tech-
ware enigneering methods (methodologies, design
nology reviews, test environments and use case archi-
patterns, best practices, quality assurance, system ver-
tectures (conceptual and implemented). As a good
sioning, change management) for microservice archi-
part of this is still conceptual, it can be seen as a sign
tecture development, and successful/unsuccessful ex-
of immaturity. This interpretation is strengthened by
amples of microservices development (only a few ex-
the fact that some use case validations and no larger-
ist, c.f. Netflix).
scale empirical evaluations exist.

144
 Microservices: A Systematic Mapping Study

Table 8: Study comparison in terms of characterisation framework (focussing on architecture and method support – column
Technical Contribution).
ID Title Format Field Contrib Technical Contribution Details
Type Contribution
1 Distribution of microservices for hardware in- Thesis Telecoms Sol Architecture microservice-based smart grid impl
teroperability in the Smart Grid Implement
2 Evaluation of Microservices as an Extension of Thesis Soft Eng Eval Concept conceptual evaluation
Component Technologies (in German) Evaluation
3 Location and Context-Based Microservices for Conf/WorkshopMobile Eval Concept 3 sample use cases (microserv)
Mobile and Internet of Things Workloads Comp Evaluation
4 Learning-Based Testing of Microservices: An Thesis Soft Eng Val Architecture microservice test bed
Exploratory Case Study Using LBTest Validation
5 Distributed Systems of Microservices Using Conf/WorkshopScience Rev Review review of container tech
Docker and Serfnode
6 Towards a Technique for Extracting Microser- Conf/WorkshopSoft Eng Sol Service technique for ms identification in en-
vices from Monolithic Enterprise Systems terprise arch
7 Migrating to Cloud-Native Architectures Us- Conf/WorkshopCloud Exp Experience migration experience report
ing Microservices: An Experience Report Report
8 From Microservices to SOA Magazine Services Rev Review technology review
9 A Reusable Automated Acceptance Testing Conf/WorkshopServices Val Architecture testing architecture for ms
Architecture for Microservices in Behavior- Validation
10 Learning-Based Testing of Microservices Conf/WorkshopSoft Eng Val Architect microservice test bed
Validation
11 On Micro-Services Architecture Journal Science/ Rev Review technology review
Engineer
12 Microservice-based Architecture for the Conf/WorkshopSystems Exp Experience data centre architecture using mi-
NRDC Report croservices
13 Microservices validation: Mjolnirr platform Conf/WorkshopCloud Val Method Vali- testing for ms review + validation
case study dation method for ms
14 An Ecosystem of User-facing Microservices Conf/WorkshopWeb/ Se- Sol Architecture abstract architecture for ms for Web
supported by Semantic Models mantics Method apps
15 An architecture for self-managing microser- Conf/WorkshopCloud Sol Architect (concept) architecture for self-
vices Method management of microservices
16 Microservices: Patterns and Applications Book Soft Eng Sol Method Def- design methods and patterns
inition
17 Microservice-based Architecture for the Conf/WorkshopSystems Exp Experience data centre architecture using mi-
NRDC Report croservices
18 Synapse: a microservices architecture for Conf/WorkshopSystems Sol Architecture (implement) architecture for mi-
heterogeneous-database web applications Implement croservices for web DB apps
19 About Microservices, Containers and their Un- Conf/WorkshopCloud Sol Method Def- analysis and design recommenda-
derestimated Impact on Network Performance inition tions
20 Microservices Magazine Soft Eng Rev Review technology review
21 Building Microservices Book Soft Eng Sol Method Def- full lifecycle methodology (design,
inition testing, impl/devops)
21 Auto-Scaling of Micro-Services Using Con- Journal Science/ Val Architecture conceptual architecture and scaling
tainerization Engineer Method approach
23 A Microservice Approach for Near Real-Time Conf/WorkshopWeb/ Se- Val Architecture microservices use case in learning
Collaborative 3D Objects Annotation mantics Validation technology

6.2 Research Trends • Resulting from independence, self-manageability

enabled by the deployment platform.
In terms of a perceived need for research, the follow- Further trends can be added: microservices migration,
ing aspects are important regarding methodological autonomous healing, runtime architecture change, ar-
and tool support: chitectural patterns, DevOps and microservices, mi-
• Testing is of particular importance (microservices croservice monitoring, auto-scaling in the context
as design artefact towards satisfying an integra- of microservices, configuration optimization for mi-
tion need) croservices, and architectural refactoring.

• Intelligent semantic technologies for their man-

agement for instance for discovery in repositories.

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

6.3 Benefits for Researchers and REFERENCES

Practitioners
Antonopoulos, N. and Gillam, L. (2010). Cloud computing:
Principles, systems and applications. Springer.
The characterization framework provides a holistic Brunnert et al., A. (2015). Performance-oriented devops: A
view of different microservices concerns to be con- research agenda. Technical Report: SPEC-RG-2015-
sidered. The classification and comparison of stud- 01, SPEC RG DevOps Performance Working Group.
ies, which contains overall 6 comparison attributes Erl, T. (2005). Service-oriented architecture: concepts,
presented across the figures and tables, provides use- technology, and design. Pearson Education.
ful information. For the 21 papers and 6 compari- Fehling, C., Leymann, F., Retter, R., Schupeck, W., and
son attributes, it creates a collection with 21*6 = 126 Arbitter, P. (2014). Cloud computing patterns.
data points. This is beneficial for researchers who Fitzgerald, B. and Stol, K.-J. (2014). Continuous software
require a quick identification of relevant studies and engineering and beyond: Trends and challenges. In
detailed insight into state-of-the-art that supports mi- 1st Intl Workshop on Rapid Continuous Software En-
gineering, RCoSE 2014, pages 1–9.
croservices, but also for practitioners interested in un-
Jamshidi, P., Ahmad, A., and Pahl, C. (2013a). Cloud mi-
derstanding existing methods, architectures and tools gration research: a systematic review. Cloud Comput-
for microservice development and deployment. 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.
7 CONCLUSIONS In 7th European Conference on Software Maintenance
and Reengineering (CSMR), 2013, pages 305–314.
Microservices have only received attention very re- Kitchenham, B., Brereton, O. P., Budgen, D., Turner, M.,
cently (Lewis and Fowler, 2014; Newman, 2015), Bailey, J., and Linkman, S. (2009). Systematic litera-
driven by two factors. Firstly, they address limitations ture reviews in software engineering–a systematic lit-
of the SOA style (Erl, 2005), specifically linking it to erature review. Information and software technology,
independent deployability and lightweightness. Com- 51(1):7–15.
panies such as Netflix and Thoughworks have been at Lewis, J. and Fowler, M. (2014). Microservices.
http://martinfowler.com/articles/microservices.html.
the forefront of this.
Mell, P. and Grance, T. (2011). The NIST definition of
This brings this discussion also into the context of cloud computing.
continuous development approaches (Fitzgerald and Newman, S. (2015). Building Microservices. O’Reilly.
Stol, 2014) such as DevOps (Brunnert et al., 2015).
Pahl, C. (2015). Containerization and the paas cloud. IEEE
Furthermore, cloud technology (Mell and Grance, Cloud Computing, 2(3):24–31.
2011; Antonopoulos and Gillam, 2010) and container Pahl, C. and Jamshidi, P. (2015). Software architecture
technology in this context in particular (Pahl and Lee, for the cloud - a roadmap towards control-theoretic,
2015; Pahl, 2015) provide a mechanism to deploy mi- model-based cloud architecture. In Europ Conference
croservices consistent with the style principles. Mi- on Software Architecture ECSA’15.
croservice patterns need to be mapped onto cloud pat- Pahl, C. and Lee, B. (2015). Containers and clusters for
terns (Pahl and Jamshidi, 2015; Fehling et al., 2014). edge cloud architectures - a technology review. In 3rd
International Conference on Future Internet of Things
While the maturity of the research work is quite
and Cloud (FiCloud-2015). IEEE.
low, given the recent emergence of the topic, a con-
Pease, A., Niles, I., and Li, J. (2002). The suggested upper
clusive summative analysis is not possible, but good merged ontology: A large ontology for the semantic
pointers towards research gaps and directions can be web and its applications. In AAAI-2002 workshop on
derived that can be seen as a contribution of a more ontologies and the semantic web.
formative investigation of the domain. Petersen, K., Feldt, R., Mujtaba, S., and Mattsson, M.
In conclusion, from our mapping study, microser- (2008). Systematic mapping studies in software en-
vices emerge as an architectural style, but one that gineering. In 12th Intl Conference on Evaluation and
extends from the ’design-stage architecture’ into de- Assessment in Software Engineering, volume 17.
ployment and operations as a continuous development Zimmermann, O. (2009). An architectural decision mod-
eling framework for service oriented architecture de-
style – the ’method’ dimension. It also seem from a sign. PhD thesis, Universität Stuttgart.
significant part of the studies reviewed to be intrin-
sicly linked to cloud-based containers for deployment
and dynamic management - the ’dynamic architec-
ture’ dimension.

146