A Systematic Mapping Study in Microservice
Architecture
Nuha Alshuqayran, Nour Ali and Roger Evans
Computing Engineering and Mathematics
University of Brighton
Brighton, UK
{n.alshuqayran, n.ali2, r.p.evans}@brighton.ac.uk
Abstract—The accelerating progress of network speed, reliabil-
ity and security creates an increasing demand to move software
and services from being stored and processed locally on users’
machines to being managed by third parties that are accessible
through the network. This has created the need to develop new
software development methods and software architectural styles
that meet these new demands. One such example in software
architectural design is the recent emergence of the microservices
architecture to address the maintenance and scalability demands
of online service providers. As microservice architecture is a new
research area, the need for a systematic mapping study is crucial
in order to summarise the progress so far and identify the gaps
and requirements for future studies. In this paper we present
a systematic mapping study of microservices architectures and
their implementation. Our study focuses on identifying archi-
tectural challenges, the architectural diagrams/views and quality
attributes related to microsevice systems.
I. INTRODUCTION
A. The microservices architecture
The microservices architecture has become a dominant
architectural style choice in the service oriented software
industry. Microservices is a style of architecture which puts
the emphasis on dividing the system into small and lightweight
services that are purposely built to perform a very cohesive
business function, and is an evolution of the traditional service
oriented architecture style [23]. It is also defined in [8] as “the
minimal independent process that interact via messaging”, and
microservice architecture as “a distributed application where
all its modules are microservices”. The commonly agreed on
benefits of this style include: increase in agility, developer
productivity, resilience, scalability, reliability, maintainability,
separation of concerns, and ease of deployment. However,
those benefits come with challenges, such as discovering ser-
vices over the network, security management, communication
optimization, data sharing and performance. When addressed
appropriately, however, these challenges allow a system to
benefit from most of the aforementioned benefits [40].
Over the last decade, leading software consultancy firms
and product design companies have found the microservices
approach to be an appealing architecture that allows teams
and software organizations to be more productive in general,
and build frequently more successful software products. Many
organizations outside of the traditional software business have
also tried and tested this style of architecture and have found
it to be very beneficial. Microservices is also considered as
an appropriate architecture for systems deployed on cloud
infrastructures, as it can take advantage of the elasticity
and on-demand provisioning features of the cloud model.
Companies such as Netflix, and SoundCloud have adopted the
microservices style in the cloud and gained many benefits from
it [42] [6].
B. The need for a systematic mapping study
Even though microservices have emerged from the software
industry and have been the focus of practitioners in the
last decade[28][22], academic researchers have not kept with
the pace. Only recently, they have started investigating this
approach and providing original research to support it, such as
new methodologies, processes and tools [28]. The motivation
of this mapping study has its basis in the lack of available
studies regarding the research performed for the microservices
style. We have encountered one such study published in
[31], however the study was limited in providing a temporal
overview of microservice research.
As microservices is an architectural style, the objective of
our study is to explore how previous research has supported
microservices through architectural approaches. Secondly, our
study will follow a characterization framework that is based
on microsevice architectural challenges. The aim of the study
is to focus on the proposed research questions, closely link
and correlate the research questions to the mapping study
results and provide quantified evidence from the available
publications. Also, we will attempt to discover any specific
areas of the microservices-style architecture that have not been
explored yet and identify the areas where there is lack of
published research.
The rest of this paper is structured as follows: Section II
explains the research method that we have followed in this
study. Section III illustrates the results, in terms of stating
the popularity of microservice challenges in the selected
studies, architecture views/diagrams and quality attributes of
the microservices architecture. A discussion of these results
follows in section IV, then we finally conclude and summarize
all the outcomes of this exercise in section V.
II. RESEARCH METHOD
Systematic mapping studies are considered comprehensive
and rigorous reviews of specific research questions in an area
or a topic, which aim to identify the gaps in the literature and
identify where new or better primary studies are needed to be
put in place [18]. In this paper, a systematic mapping study in
“Microservices-style Architecture” is presented by following
the guidelines outlined in [5], [33], [18] and [9].
A. Planning stage
Initially, a set of research questions were drafted for inves-
tigation during the study. The motivation behind each research
question was reviewed and refined. Subsequently, selected pa-
pers were assessed against quality criteria and a classification
scheme was iteratively developed closely following a synthesis
method. In summary, the review was established by conducting
the following steps consecutively:
1) Research questions: The research questions and the
motivations are outlined in Table I.
2) Search Strategy: The terms “microservice”, “micro ser-
vice”, “micro-service” and “microservice architecture” were
researched in articles published in journals, conferences and
workshops. Sources from books, thesis, talks and blog posts
were excluded. The research was restricted to articles pub-
lished between 2014 and 2016, as there was no consensus
on the term microservice architecture in the field prior to
that date, according to [31]. Three online libraries were used
IEEExplore, ACM DL and Scopus (which includes Springer).
3) Selection of primary studies: Before selection, articles
were initially cross-checked for relevance against the research
questions that are related to this systematic mapping study. The
titles, abstracts and keywords were scanned to determine the
relevance of the articles and whether they should be included
or excluded for the purpose of this study, based on the criteria
listed in Table II. After applying the exclusion and inclusion
criteria, a total of 33 articles were collected in this study.
Table III lists all the selected publications.
4) Keywording and Classification: Once papers were se-
lected, a qualitative assessment was conducted to create an
outline model for the quality of work. This helps to abstract
various possible dimensions for characterization and cate-
gorization. As a result, the research classification approach
performed in [46] was found to be generally applicable for
this research and was used to classify the papers as: Evaluation
Research, Opinion Paper, Solution Proposal, Experience Paper,
Validation Research and Philosophical Paper.
A) Identified keywords for microservices challenges (RQ1):
Subsequent to the first round of review, the following
keywords were identified to be mapped and linked to the
challenges of creating microservices style systems. Keywords
associated with challenges were identified to answer the study
research question 1.
• Communication/Integration: Communication and integra-
tion have many facets to them in a microservices-style
architecture. Defining a correct communication strategy
is vital to the design. The strategy involves identifying
the right protocol, response time expectations, timeouts
and API design.
Keywords: API, REST, sockets, TCP, gateway, circuit
breakers, load balancer, proxy
• Service discovery: This is the ability of various services to
discover each other in a consistent manner. It is important
for a system to have a standard and consistent process
for which services can register and announce themselves.
This help the consuming services to discover the end
points and the locations of other services. It also involves
deciding the right consumer strategy and specifying how
API gateways are configured to report service availability
and discovery.
Keywords: discovery, registration, service registry
• Performance: It was commonly observed that introducing
microservices architecture to the software industry often
adds more ‘chatty’ communication between the different
services. For example, fulfilling one single business func-
tional requirement would result in orchestrating multiple
service calls together, which in return introduces addi-
tional lag to the end-user experience. Due to bounded
contexts, often data that is frequently used by a single
microservice is owned by another. This requires creating
data sharing and synchronization primitives to avoid the
communication overhead caused by data copying which
happens during the service invocations. The following
keywords are normally associated with performance chal-
lenges.
Keywords: QoS, performance, SLA, speed, simulation.
• Fault-tolerance: This is the ability of a system to recover
from a partial failure. It is up to microservice developers
to take that into consideration and provide proper mecha-
nisms to gracefully recover or stop any failure to cascade
or migrate to other parts of the system. This is normally
expected in cloud environments where Infrastructure as a
Service (IaaS) causes inevitable failures.
Keywords: fault, failure, recovery, tolerance.
• Security: Security is a major challenge that must be care-
fully thought of in microservices architecture. Services
communicate with each other in various ways creating a
trust relationship. For some systems, it is vital that a user
is identified in all the chains of a service communication
happening between microservices. OAuth and OAuth2
are well-known solutions that are employed by designers
to handle security challenges.
Keywords: secure, authentication, authorization, OAuth,
OAuth2, encryption, vulnerability, attack
• Tracing and Logging: In microservices-based systems,
the services tracing and central logging are vital for
developers to understand the system behavior as a whole.
Breaking monolithic systems into microservices uses
techniques that are traditionally employed for debugging
and profiling systems. Various techniques and solutions
are emerging to solve this problem. Distributed tracing is
the ability of a system to track a chain of service calls
Table I
THE RESEARCH QUESTIONS AND THEIR MOTIVATIONS
Number Research Question Motivation
1
What are the architectural challenges that microservices systems face?
The aim is to explore all the published studies that were relevant
to microservices to highlight the gaps in them and look for future
solution foundations
2
What architectural diagrams/views are used to represent microservices
architectures?
The aim is to identify and investigate what are the possible methods
and models to best describe different aspects and levels of microser-
vices architecture.
3
What quality attributes related to microservices are presented in the
literature?
The aim is to recognize and disclose the gaps in current research
and hence set the direction for future research.
Table II
THE SELECTION CRITERIA
Criteria
Inclusion
• Studies presenting the definition of microservices ar-
chitecture.
• Studies that focus on microservices architecture and
implementation.
• Studies that focus on a platform to run systems
following a microservices-style architecture.
• Studies that focus on a specific challenge within
microservices (e.g. fault tolerance, acceptance testing
etc).
• Studies that implement microservices-style architec-
ture for a specific business or technical domain.
• Studies that do comparisons between monolithic and
microservices architectures.
Exclusion
• Papers using the microservice term but not to refer to
the architectural style.
• Papers which do not have real data to back the
proposed design/methodology/architecture.
• Studies that do not have microservices as their pri-
mary research topic or analysis.
• Studies that focus on platforms that are not primarily
designed to run microservices but may allow it.
to identify a single transaction or a single user request.
Logging is another critical component of any system.
Logs are important for auditing and debugging purposes.
Special attention must be paid to carefully design a
central logging and aggregation system for developers to
continue debugging systems in an appropriate manner.
Keywords: tracing, logging, debugging, profiling
• Application Performance Monitoring: APM is an infras-
tructural centric characteristic. It involves measuring in-
dividual microservices’ performance to assess the health
and existing SLAs for a system.
Keywords: monitoring, APM, health monitoring
• Deployment operations: Deployment operations and scal-
ing are fundamental infrastructure concerns. However,
selecting the right platform influences significantly the
architecture of a microservices system. Container orches-
tration tools and structured PaaS solutions provide vari-
ous features that makes deployment and operations very
trivial activities. However, selecting the right solution is
critical as all of these platforms come with their own set
of assumptions and opinions, which the designer has to
follow to be able to utilize the selected platform to its
potential. Scaling microservices can become a challenge
if the right architecture is not followed. There are several
guidelines such as 12 factor application and cloud native
designs
1
, which need to be followed to make service scal-
ing easier. Most of these guidelines demand statelessness
and portability by decoupling service runtime from OS
and platform resources.
Keywords: operations, orchestration deployment, scaling,
auto-scale, rolling upgrades, images, container
5) Data extraction strategy and Quality Assessment : Data
for this study was extracted using a machine learning-based
PDF Extraction Library called grobid [10], which extracts
the PDF data into structured TEI-encoded documents, with a
particular focus on technical and scientific publications. [16]
was used to do the visual analysis and generate various charts.
First, the selected keywords for the ‘challenges’ part were an-
alyzed using Kibana [16] visualization, in order to understand
the distribution over the underlying population. This gave a
quantitative indication of the possible classifications.
Furthermore, the studies have been subjected to a ques-
tionnaire to roughly classify the selected papers based on the
actual content review. The research questions were the driving
element of the questionnaire.
III. RESULTS
Significant Keywords:
At a high level, the following are the top significant key-
words from the previously mentioned keywords lists. Figure 1
lists the top terms found in the literature. It can be observed
that “deployment”, “cloud” and “performance” are the words
that dominate the papers, “deployment” is the most discussed
topic appearing in 31 out of 33 papers, followed by “cloud”
and “performance” in 23 papers.
Challenges of microservices system architecture (RQ1):
We identified papers which are actively addressing one or
more of the challenges mentioned in “Identified Keywords for
microservices challenges” (above). The classified papers either
present a solution, addressing a challenge as the primary or
secondary topics or discuss a challenge to a certain depth.
Furthermore, we quantitatively searched for earlier presented
keywords associated with the challenges in the papers and
presented the count of papers mentioned in one or more of
1
http://12factor.net/
Table III
PUBLICATIONS SELECTED
ID Paper Name Format
1
Sustaining runtime performance while incrementally modernizing transactional monolithic software towards microser-
vices [19]
Conference
2 The hidden dividends of microservices [17] Journal
3 An architecture for self-managing microservices [41] Workshop
4 Synapse: a microservices architecture for heterogeneous-database web applications [44] Conference
5 A reference architecture for real-time microservice API consumption [11] Workshop
6
Exploring the impact of situational context: a case study of a software development process for a microservices
architecture [30]
Workshop
7 Evaluating the monolithic and the microservice architecture pattern to deploy web applications in the cloud [45] Conference
8 Microservice-based architecture for the NRDC [21] Conference
9 Container and microservice driven design for cloud infrastructure DevOps [15] Conference
10 Scalable microservice based architecture for enabling DMTF profiles [25] Conference
11 Experience on a microservice-based reference architecture for measurement systems[43] Conference
12 Microservice based tool support for business process modelling [1] Workshop
13 Designing a smart city Internet of Things platform with microservice architecture [20] Conference
14 Microservices [40] Journal
15 A reusable automated acceptance testing architecture for microservices in behavior-driven development [34] Conference
16 Microservices architecture based cloudware deployment platform for service computing [12] Conference
17 Security-as-a-Service for microservices-based cloud applications[39] Conference
18 CYCLOPS: A micro service based approach for dynamic rating, charging and billing for cloud [32] Conference
19 Microservices validation: Mjolnirr platform case study [36] Conference
20 Data-Driven workflows for microservices: genericity in Jolie[35] Conference
21 Distributed systems of microservices Using Docker and Serfnode [38] Workshop
22 Location and context-based microservices for mobile and Internet of Things workloads[4] Conference
23 Performance evaluation of microservices architectures using containers [2] Conference
24 CIDE: an integrated development environment for microservices[24] Conference
25 Microservices and their design trade-offs: a self-adaptive roadmap [13] Conference
26 SeCoS: Web of Things platform based on a microservices architecture and support of time-awareness[47] Journal
27 Apache airavata as a laboratory:aArchitecture and case study for component-based gateway middleware [26] Workshop
28 Microservices validation: methodology and implementation[37] Workshop
29 Learning-based testing of distributed microservice architectures: Correctness and fault injection [27] Conference
30 Automated deployment of a microservice-based monitoring infrastructure [7] Journal
31 A microservice approach for near real-time collaborative 3D objects annotation on the web [29] Conference
32 Multi cloud deployment with containers [14] Journal
33 Migrating healthcare applications to the cloud through containerization and service brokering [3] Conference
Figure 1. The top 10 keywords in the literature
such keywords. Table IV and Figure 2 show the results of the
above classification.
Research paper approaches:
We classified papers using approaches presented in
Wieringa [46]. Since the microservices architectural style is
an emerging field, a lot of research is focused on presenting
Figure 2. The distribution of microservices challenges in the literature
evaluation research or solution proposals, followed by val-
idation research. A lack of experience reports and opinion
papers is also a clear indication of the emerging nature of
the research. Figure 3 presents the approaches plotted against
the number of papers with different challenges which gives a
combined view of the selected studies and their distribution
over these two dimensions. The size of the bubble represents
the number of papers. It can be observed from the figure,
that “communication” and “deployment” are well ahead of
Table IV
THE KEYWORDS ASSOCIATED WITH THE CHALLENGES IN THE LITERATURE
Challenges Keywords Mentions
Communication/Integration API, REST, sockets, TCP, gateway, circuit breakers, load balancer, proxy, routing, router 29
Service Discovery discovery, registration, service registry 11
Performance QoS, performance, SLA 28
Fault Tolerance fault, failure, recovery, tolerance, healing 23
Security secure, authentication, authorization, OAuth, OAuth2, encryption, vulnerability, attack 13
Tracing and Logging tracing, logging, debugging, profiling 8
Application Performance Monitoring monitoring, application performance monitoring 24
Deployment Operations
operations, orchestration deployment, configuration, scaling, auto-scale, rolling upgrades, im-
ages, container
34
Figure 3. Research approaches against the number of papers with different
challenges
the other challenges. It can also be noticed, that the “commu-
nication” and “deployment” challenges have more validation
and evaluation papers.
The microservices architectural views/diagrams (RQ2):
Solution proposal and validation research types of papers
were the main source to answer this question as they paid
more attention to architectural modeling than other papers. In
particular, the design and implementation sections of those pa-
pers provided figures of views/diagrams used along with their
detailed explanations. However, although component/context
diagrams were dominant in the literature, a wide variety of
other graphical modeling views were also presented, although
with no clear justification provided for the choice of a par-
ticular diagram. This lack of consistency in diagrammatic
presentations may indicate a need to propose a comprehensive
modeling view/language that best covers and describes a
microservices-based architecture.
The graphical architectural views found in the literature
were various and can be categorized into informal drawings
with free boxes and lines, sets of UML diagrams each covering
different aspects of the architecture, graphs with vertices
and arrows and finally diagrams for SQL/NoSQL relational
databases. Table V shows the diagrams used in the literature,
their annotations and sets of papers that included each type
of diagram. Interestingly, it has been noticed that there was
no distinction between component diagrams and container
diagrams in the literature. This implies that the trend of mi-
croservice architecture is to suggest placing one microservice,
i.e. component, in one running environment, i.e. container, in
order to achieve the ultimate independence and isolation of the
microservices. In addition to the description diagrams covered
earlier, description languages are also included in the literature
to provide a more elaborated view of architecture details. Cate-
gories of different formats of description languages mentioned
in the study included the following:
• Standard modeling languages, e.g. RAML and YAML.
• Specifically-designed modeling languages, e.g. CAMLE.
• Standard specification languages, e.g. Javascript
(Node.js), JSON and Ruby.
• Specifically-designed specification languages, e.g. Jolie.
• Pseudocode for algorithms.
Quality attributes related to microservices in literature (RQ3):
To approach this question, a generalization of attribute
names were necessary at first, since many alternative terms
found in the papers indicated the same meaning of one
attribute. Table VI shows each attribute and its alternative
terms. It was noticed in the literature that well-known quality
attributes of microservices architecture such as modularity,
scalability, independence and maintainability were presented
in almost all of the papers reviewed. However, some attributes
scored fewer occurrences which implied lack of consideration.
These attributes were basically security ID [15,18,23,32,33],
load balancing ID [1,20] and organizational alignment ID
[13,15]. In addition to the results of research questions 2
and 3 above, we decided to investigate a possible relation-
ship between quality attributes in the literature and model
views presented. For each quality attribute, we checked the
modeling diagrams included in the same papers mentioning
that attribute. This intersection method attempted to answer
what type of modeling view is more suitable to demonstrate
and/or test particular quality attributes in the architecture.
More elaboration on our findings and insights derived from
the results is provided in the next section.
IV. DISCUSSION
It can be observed from the results that microservices
architectural style research is still in its infancy. Since the
style is born out of industry, it has been noted that there are
wide gaps between the current industry level and academia.
