2017 IEEE International Conference on Software Architecture

Research on Architecting Microservices: Trends,

Focus, and Potential for Industrial Adoption
Paolo Di Francesco∗ , Patricia Lago† , Ivano Malavolta†
∗ Gran Sasso Science Institute, L’Aquila, Italy - [email protected]
† Vrije Universiteit Amsterdam, The Netherlands - {p.lago | i.malavolta}@vu.nl

Abstract—Microservices are a new trend rising fast from the for understanding what we know about scientific research on
enterprise world. Even though the design principles around architecting microservices.
microservices have been identified, it is difficult to have a clear For achieving this goal we applied the systematic mapping
view of existing research solutions for architecting microservices.
In this paper we apply the systematic mapping study method- study methodology, which is a research methodology intended
ology to identify, classify, and evaluate the current state of to provide an unbiased, objective and systematic instrument
the art on architecting microservices from the following three to answer a set of research questions by analysing all of the
perspectives: publication trends, focus of research, and potential relevant research contributions in a specific research area. In
for industrial adoption. More specifically, we systematically define our study we identified, classified, and evaluated the current
a classification framework for categorizing the research on
architecting microservices and we rigorously apply it to the 71 state of the art on architecting microservices from differ-
selected studies. We synthesize the obtained data and produce ent perspectives. We selected 71 primary studies from over
a clear overview of the state of the art. This gives a solid three hundred potentially relevant papers; then, we rigorously
basis to plan for future research and applications of architecting defined a classification framework for precisely categorizing
microservices. research results on architecting microservices, and we applied
Index Terms—Microservices, Software Architecture, System-
atic Mapping Study
it to the 71 primary studies. Finally, we synthesized the
obtained data to produce a clear overview of the state of the
art in architecting microservices. Also, we assessed how re-
I. I NTRODUCTION
search results on architecting microservices can be potentially
Netflix, Amazon, The Guardian and other companies have transferred and adopted in industrial projects. This assessment
evolved their applications towards a microservice architecture can play the role of reference framework for acting towards
(MSA). Lewis and Fowler define the microservice architectural a smoother transfer of research results to practice, which is
style as an approach for developing a single application as a one of the goals of an applied research field such as software
suite of small services, each running in its own process and engineering [5].
communicating with lightweight mechanisms, often an HTTP The main contributions of this study are: (i) a reusable
resource API [4]. framework for classifying, comparing, and evaluating architec-
MSA arises from the broader area of Service Oriented tural solutions, methods, and techniques (e.g., tactics, patterns,
Architecture (SOA) and focuses on specific aspects, such as styles, views, models, reference architectures, or architectural
componentization of small lightweight services, application languages) specific for microservices; (ii) an up-to-date map
of agile and DevOps practices for development, usage of of the state of the art in architecting microservices and its
infrastructure automation with continuous delivery features, implications for future research; (iii) an evaluation of the
decentralized data management and decentralized governance potential for industrial adoption of existing research results
among services. There are many differences between SOA and on architecting microservices;
MSA. For example, the design of services in MSA is driven by The audience of this study is composed of both (i) re-
a share-nothing philosophy in order to support agile methods searchers interested to further contribute to this research area,
and promote isolation and autonomy. Instead, SOA adopts a and (ii) practitioners interested to understand existing research
share-as-much-as-you-can philosophy to promote a high de- on architecting microservices and thereby to critically adopt
gree of reuse [17]. Another significant difference is that MSA those solutions that best fit with their business goals.
mainly focuses on service choreography, while SOA relies on The rest of the paper is organized as follows. In Section II
both service orchestration and service choreography [17]. we set the stage by giving the basic concepts around archi-
Even though the design principles around the microservice tecting microservices. The design of the study is presented in
architectural style have been identified, many aspects are Section III, whereas its results are elaborated in Sections IV,
still unclear or unexplored. This makes it difficult for both V, and VI, where they are also put in a broader perspective
researchers and practitioners to have a clear view of existing and their potential implications for both researchers and prac-
research solutions for architecting microservices, their charac- titioners are presented. Threats to validity and related work
teristics, and their potential for broad industrial adoption. The are described in Sections VII and VIII. With Section IX we
goal of this paper is to characterize the current state of the art close the paper and discuss future work.

978-1-5090-5729-0/17 $31.00 © 2017 IEEE 21

DOI 10.1109/ICSA.2017.24
 II. A RCHITECTING M ICROSERVICES
Common characteristics to the microservice architectural
style are: (i) organization around business capability, (ii)
automated deployment, (iii) intelligence in the endpoints, and
(iv) decentralized control of languages and data. This style
allows to design architectures that result flexible, modular
and easy to evolve over time. Microservice architectures
can provide significant benefits. Among the important ones,
there is the possibility to design, develop, test and release
services with great agility. Infrastructure automation allows to Fig. 1. Overview and numbers of the search and selection process
reduce the manual effort involved in building, deploying and
operating microservices, thus enabling continuous delivery.
Decentralized governance and data management allow services 1. Initial search. As suggested in [7, 16], we performed
to be independent, and avoid an application to standardize on a automatic on four of the largest and most complete scientific
single technology. Microservice architectures are particularly databases and indexing systems in software engineering -
suitable for cloud infrastructures, as they greatly benefit from ACM Digital Library, IEEE Xplore, Web of Science, and
the elasticity and rapid provisioning of resources. Architecting Scopus. The selection of these electronic databases and in-
microservices, however, is not an easy task as it requires to dexing systems is guided by: (i) the fact that they have been
manage a distributed architecture and its challenges (e.g., net- recognised as being an effective means to conduct systematic
work latency and unreliability, fault tolerance, data consistency literature reviews in software engineering [16], (ii) their high
and transaction management, communication layers, load bal- accessibility, and (iii) their ability to export search results to
ancing). Cloud infrastructures and new technologies play a well-defined, computation-amenable formats.
fundamental role for realizing microservice architectures and ( a r c h i t e c t ∗ OR d e s i g n ∗ OR s y s t e m OR s t r u c t u r ∗ )
managing the associated challenges and complexities. AND ( m i c r o s e r v i ∗ OR micro−s e r v i ∗ OR ” m i c r o s e r v i ”∗)
Listing 1. Search string used for automatic research studies
III. S TUDY D ESIGN
Our search string is shown Listing III-B, in order to cover as
In this research we follow the well-established guidelines much relevant studies as possible we kept it very generic and
for systematic mapping studies [7, 16], in the following we considered exclusively the object of our research (i.e., existing
present the key aspects of the design of our study. research on architecting microservices). For consistency, the
search string has been applied to title, abstract and keywords
A. Research Questions
of papers in all the data sources considered in this research.
We refined our research goal into three research questions: 2. Impurity removal. Due to the nature of the involved data
RQ1 – What are the publication trends of research studies sources, search results included also elements that were clearly
about architecting microservices? By answering this research not research papers, such as international standards, textbooks,
question we aim at characterizing the intensity of scientific etc. In this stage we manually removed these results in order
interest on architecting microservices, the relevant venues to have a coherent set of potentially relevant research studies.
where academics are publishing their results on the topic, and 3. Merging and duplicates removal. Here we combined all
their contribution types over the years. studies into a single dataset. Duplicated entries have been
RQ2 – What is the focus of research on architecting mi- matched by title, authors, year, and venue of publication.
croservices? By answering this research question we aim 4. Application of selection criteria. We considered all the
at providing (i) a solid foundation for classifying existing selected studies and filtered them according to a set of well-
(and future) research on architecting microservices and (ii) defined selection criteria. In this stage it was crucial to select
an understanding of current research gaps in the state of the studies objectively and in a cost-effective manner. To this
art on architecting microservices. purpose we used the adaptive reading depth [15], as the full-
RQ3 – What is the potential for industrial adoption of existing text reading of clearly excluded studies was not necessary. The
research on architecting microservices? By answering this inclusion and exclusion criteria of our study are:
research question we aim at assessing how and if the current I1 - Studies focussing on architectural solutions, methods or
state of the art on architecting microservices is ready to be techniques (e.g., tactics, styles, reference architectures, or
transferred and adopted in industry. architectural languages) specific for microservices.
I2 - Studies providing an evaluation of the architectural so-
B. Search and Selection Process
lution, method or technique (e.g., via formal analysis,
As shown in Figure 1, our search and selection process experiment, exploitation in industry, simple examples).
has been designed as a multi-stage process in order to have I3 - Studies subject to peer review.
full control on the number and characteristics of the studies I4 - Studies written in English.
considered during the various stages.

22
E1 - Studies that, while focusing on microservices, do not framework. Examples of emerging categories include: sup-
explicitly deal with their architecture (e.g., studies fo- ported architecting activities, scope in the software lifecycle,
cussing only on technological aspects, inner details of considered quality attributes (e.g., reliability), etc. Next steps
microservices). have been performed for each primary study.
E2 - Studies where microservices are only used as an example. 4. Extract data from current study. A researcher extracted in-
E3 - Secondary or tertiary studies (e.g., systematic literature formation about the current study to be analysed by collecting
reviews, surveys, etc.). (i) information according to the parameters of the classification
E4 - Studies in the form of tutorial papers, editorials, etc. framework and (ii) any additional relevant information that did
because they do not provide enough information. not fit within any parameter of the classification framework. If
E5 - Studies not available as full-text. the collected information fit completely within the classifica-
5. Combination. If there were multiple papers on the same tion framework, then we proceeded to analyze the next study,
study, we kept a record of all of them and pointed them to otherwise the classification framework was refined.
a single study. This was necessary for ensuring completeness 5. Refine comparison framework. Two researchers discussed
and traceability of our results [20]. together on the collected additional information. This discus-
6. Snowballing. We complemented the previously described sion could result either in the correction of the performed clas-
automatic search with a snowballing activity [16]. The main sification or in the refinement of the classification framework.
goal of this stage is to enlarge the set of potentially relevant The above described process ended when there were no pri-
studies by considering each study selected in the previous mary studies to analyze left. The specific parameters emerging
stages, and focusing on those papers either citing and cited from the keywording process are described in Section V.
by it. More technically, we performed a closed recursive Potential for industrial adoption (RQ3). This facet is com-
backward and forward snowballing activity [19]. posed of four different parameters: (i) readiness level for as-
sessing the maturity of the involved technologies, (ii) industry
C. Data Extraction involvement for understanding how academic and industrial
researchers collaborate on the topic, (iii) tool support for
In this activity we (i) create a classification framework and distinguishing between software-based or knowledge-based
(ii) collect data for each primary study. When going through contributions, and (iv) open-source test system for identi-
the primary studies in detail for extracting information we fying existing benchmarks for microservice architectures.
agreed that 8 studies were semantically out of the scope of
this research, so they have been excluded (see Figure 1). In D. Data Synthesis
order to have a rigorous data extraction process and to ease the The data synthesis activity involves collating and summaris-
management of the extracted data, we systematically designed ing the data extracted from the primary studies [8, § 6.5] with
a structured classification framework; it is composed of three the main goal of understanding, analysing, and classifying
facets, one for each research question of our study. current research on architecting microservices. Specifically, we
Publications trends (RQ1). The parameters we considered performed a combination of content analysis (for categorizing
to collect data about publication trends are: publication year, and coding the studies under broad thematic categories) and
publication venue (e.g., conference, journal, etc.), and re- narrative synthesis (for explaining in details and interpreting
search strategy (e.g., solution proposal, opinion paper, etc.). the findings coming from the content analysis).
Focus of research (RQ2). We followed a systematic process
E. Replicability of the Study
called keywording for defining the categories of this facet.
Goal of the keywording process is to effectively develop a Due to page limitations we do not include all the details
classification framework so that it fits the primary studies and of the design of our study. To allow easy replication and
takes their research focus into account [15]. The following verification of our study, a complete replication package1 is
details each step of the keywording process: publicly available to interested researchers. Our replication
1. Identify starting set of studies. Two researchers randomly package includes: the detailed research protocol, the detailed
extracted 5 studies from the set of all primary studies; they description of all the parameters of the classification frame-
have been used as pilot studies during the keywording process. work, the list of all selected studies, raw data for each phase
2. Identify keywords and concepts. Two researchers collected of the study, and the R scripts for summarizing extracted data.
keywords and concepts by reading the full-text of each starting IV. R ESULTS - P UBLICATION T RENDS (RQ1)
study. When all starting studies were analyzed, we combined
Publication years. Figure 2 presents the distribution of pub-
all keywords and concepts to clearly identify the emerging
lications on architecting microservices over the years. Here
context, nature, and contribution of the research on architecting
we have a clear confirmation of the scientific interest on
microservices.
architecting microservices in the last years. A small number of
3. Cluster keywords and form categories. Two researchers publications have been produced until 2014, which is actually
performed a clustering operation on collected keywords and the first year in which (i) microservices started to attract the
concepts in order to cluster them according to emerging
categories. The output of this stage is the initial classification 1 http://cs.gssi.infn.it/ICSA2017ReplicationPackage

23
interest of large organizations, and (ii) the term microservice TABLE I
A PPLIED RESEARCH STRATEGIES
as architectural style was consistently used [14]. As a confir-
mation, even if the four studies published before 2014 were Res. strategies #Studies Studies
about systems composed of small-scale lightweight services Solution proposal 48 P1, P2, P3, P4, P6, P7, P9, P10, P12,
P13, P14, P15, P17, P18, P20, P21,
(P10, P62, P63, P64), they were referring to slightly different P22, P23, P25, P26, P29, P30, P32,
perspectives on microservices as they are considered today. P33, P36, P39, P42, P43, P44, P45,
For example, P10 refers to low-level software components in P47, P49, P50, P51, P52, P54, P55,
P56, P58, P61, P62, P63, P64, P66,
the robotic domain as microservices, whereas P62 considers P68, P69, P70, P71
microservices as mobile services generated by end-users. We Validation 14 P3, P6, P9, P14, P21, P24, P38, P51,
observed alternative definitions of microservices also in other research P52, P59, P61, P62, P69, P71
Opinion paper 8 P11, P16, P19, P28, P41, P48, P60, P67
cases throughout the years, as described in Section V-A. Experience paper 8 P8, P31, P34, P37, P38, P40, P57, P65
Philosophical pa- 3 P5, P46, P53
per
Evaluation 3 P27, P35, P45
research

on architecting microservices, specially if we want to either

(i) solve real problems coming from industrial scenarios or (ii)
Fig. 2. Distribution of primary studies by type of publication over the years push the technology transfer of research results into industry.

Publication types. The most common publication type is

conference papers (48/71), followed by journal (13/71) and Main findings:
workshop papers (10/71). Such a high number of conference  Year 2015 signed a booming, monotonic increase
and journal papers may indicate that architecting microservices in publication numbers with particular interest in
is maturing as research topic despite its relative young age. conferences and journals (both increasing).
Publication venues. We can observe an extreme fragmentation  The field is rooted in practice: publication venues
in terms of publication venues, where research on architecting are scattered across specific topics or application
microservices is spread across 62 venues spanning different domains, and most publications propose specific
research areas like cloud infrastructures, software engineering, solutions and validations thereof.
software services, autonomic computing, etc. This can be an
indication that architecting microservices is considered as an
V. R ESULTS - R ESEARCH F OCUS (RQ2)
orthogonal research target with many cross-cutting concerns.
Research strategies. Since this parameter is general and As described in Section III-C, the part of classification
independent from the research area, we reuse the comparison framework related to RQ2 has been systematically defined. Af-
of research approaches proposed by Wieringa et al. in [18]. ter this process we obtained two main categories related to the
We chose this comparison because (i) it has been widely used research focus on architecting microservices, namely: scope
in various systematic mapping studies (e.g., in [3]) , and (ii) (Section V-A) and support for architecting (Section V-B).
its categories are quite cost-effective to be identified [15].
A. Scope
As shown in Table I, here the clear winner is solution
proposal (48/71). We can root this result to the fact that With this category we provide information to help re-
the microservice architectural style is still in its infancy (we searchers and practitioners in putting a research study on
recall here that the first well acknowledged definition has architecting microservices into context. For example, here we
been provided only in 2014) and not yet consolidated in have parameters about the targeted problem, the main research
any (not even de facto) standards. This results in a large contributions, the used definition of microservice, etc. In the
number of researchers trying to propose their own solutions following we discuss the results related to each parameter.
for either recurrent or specific problems (see Section V-A Target problems. As shown in Table II, the most recur-
for the details on this). Validation research (14/71) is the rent problems targeted by the primary studies are complexity
second most recurrent research strategy, highlighting the fact (19/71) and low flexibility (19/71), followed by resources
that researchers are actually providing some level of evidence management (16/71) and service composition (15/71). These
about their proposed solutions, either by simulations, in- results confirm that if on the one hand microservices can help
the-lab experiments, prototypes, etc. However, Table I also in achieving a good level of flexibility (e.g., by promoting low
shows that researchers performed evaluation research very services coupling, higher maintainability), on the other hand
rarely (3/71), meaning that industry- and practitioners-oriented adopting a microservice-based architecture may bring higher
studies (e.g., industrial case study, action research, practitioner complexity, mainly because they imply a high number of
targeted survey) are not yet in the focus of researchers today. distributed services to operate. Interestingly, the bottom area of
This represents a gap that should be filled by future research Table II shows problems that are related to system-level quality

24
 TABLE II TABLE III
TARGET PROBLEMS R ESEARCH CONTRIBUTION

Problems #Studies Studies Contribution #Studies Studies

Complexity 19 P3, P10, P12, P18, P21, P22, P23, P26, Application 21 P3, P8, P9, P10, P12, P15, P17, P20, P21,
P31, P33, P37, P39, P41, P46, P50, P62, P25, P29, P31, P36, P37, P40, P47, P53,
P64, P67, P68 P54, P59, P65, P66
Low flexibility 19 P8, P15, P17, P19, P23, P25, P29, P37, Method 18 P7, P22, P24, P26, P27, P35, P42, P43, P51,
P38, P47, P49, P50, P54, P61, P63, P66, P56, P57, P58, P61, P62, P64, P69, P70,
P67, P68, P70 P71
Resources man- 16 P11, P15, P19, P21, P24, P27, P28, P34, Reference 16 P1, P2, P3, P5, P13, P18, P21, P33, P34,
agement P35, P36, P48, P49, P53, P54, P65, P70 architecture P38, P46, P49, P55, P59, P60, P63
Service compo- 15 P2, P30, P32, P33, P37, P41, P47, P52, Problem 14 P11, P12, P16, P19, P28, P30, P32, P33,
sition P55, P60, P66, P67, P68, P69, P70 framing P39, P41, P46, P48, P57, P67
Data 13 P3, P4, P9, P19, P20, P29, P38, P54, P55, Middleware 12 P3, P4, P6, P14, P23, P32, P40, P44, P45,
management P61, P62, P63, P64 P61, P62, P68
Modernization 11 P7, P8, P11, P13, P36, P42, P43, P51, Design pat- 2 P30, P50
P56, P65, P71 tern
Low auditabil- 7 P6, P14, P21, P22, P37, P41, P59 Architectural 2 P52, P62
ity language
Runtime uncer- 7 P5, P10, P22, P26, P39, P40, P45
tainty
Low portability 5 P1, P12, P22, P46, P48
Low testability 5 P6, P22, P44, P57, P58
and that researchers are still investigating how to leverage
Realtime com- 4 P2, P25, P31, P37 its characteristics. Not surprisingly, a significant number of
munication studies are investigating migration techniques in order to
Security 4 P14, P16, P28, P48
Time to market 4 P13, P47, P54, P66
adopt and benefit of microservices starting from the so called
monolithic applications. It is also interesting to note that the
domains of application of microservices are rather fragmented.
like low portability and testability (5/71), security and time to Indeed, the microservice architecture have been applied to
market (4/71). These have been extensively investigated in the recent technologies as Internet of Things (6/71) and mobile
software architecture area, but are still new to microservice (6/71), but also to domain-specific (11/71) fields as robotics
architectures; this result may be an indicator of a potentially (P10) or data centers (P29).
relevant research gap needing attention in the future. TABLE IV
R ESEARCH PERSPECTIVE
Research contribution. The main research contributions
are application (21/71) and method (18/71), as reported in Perspective #Studies Studies
Table III. The high number of applications might indicate that Cloud 21 P1, P11, P12, P16, P17, P21, P24, P27, P28,
P32, P34, P35, P36, P41, P42, P46, P48, P53,
microservice architerectures can be suitable in many areas, and P58, P65, P70
it would confirm that the trend emerged from the industrial System 21 P6, P7, P14, P16, P20, P22, P23, P24, P27,
field. Researchers seem to deal with the complexities in quality P28, P34, P35, P39, P44, P45, P49, P50, P57,
P58, P64, P66
architecting microservices by proposing new methods (18/71), Migration 16 P7, P8, P11, P36, P37, P39, P42, P43, P48,
reference architectures (16/71) and middlewares (12/71). A P51, P53, P56, P63, P65, P67, P71
significant number of problem framing (14/71) studies in- Domain- 11 P3, P9, P10, P15, P18, P25, P26, P29, P31,
specific P37, P69
dicates that researchers are trying to better undestand and IoT 6 P13, P23, P30, P40, P47, P54
shape the challenges in this field. Interestingly, few papers Mobile 6 P54, P55, P61, P62, P64, P66
are investigating design patterns and architectural languages oriented
Other 10 P2, P4, P5, P19, P33, P38, P52, P59, P60, P68
for microservices, which might reveal gaps to be filled by the
research community. Proposing an architectural language for Vertical scope. It is the layer of abstraction at which the study
microservices could help architects in many activities as for considers microservice architectures. As shown in Table V,
example in reasoning on the system as a whole, performing more than half of the studies focus on the service layer
analysis on the system qualities, coping with the dynamic and only (39/71) without considering other layers. Differently,
changing aspects of the application at runtime. other studies not only focus on services, but also consider
Research perspective. The research perspective is the main the environment upon which the services run. Indeed, the
focus area of the primary study. As reported in Table IV, container (14/71) layer and the virtual machine (13/71) layer
the predominant research perspectives are: cloud (21/71), are discussed as relevant aspects of the architectures.
system quality (21/71) and migration (16/71). The attention
on cloud confirms the close relation between the microservice Software lifecycle scope. Results show that when architecting
architectural style with the DevOps culture, and also confirms microservices, the predominant software lifecycle phases are:
that containerization and virtualization are key enabling tech- design (65/71), implementation (24/71) and operation (22/71)
nologies. Moreover, the focus on the system quality (e.g., scal- – see Table VI. Surprisingly, there is a significant gap be-
ability, performance, security) suggests that the microservice tween the number of studies on the design phase and both
architectural style has direct impact on the design of a system implementation and operation. This gap might confirm the

25
 TABLE V B. Support for architecting
V ERTICAL SCOPE
Here we characterize research studies with respect to how
Vertical scope #Studies Studies
Service 39 P1, P3, P4, P5, P6, P7, P9, P10, P13, P15, they support architecture-specific concerns and activities.
P18, P21, P22, P23, P33, P37, P38, P39, Architecting activities. We have based our classification of
P40, P42, P44, P45, P50, P51, P52, P54, architecting activities according to the introvert/extrovert
P55, P56, P57, P60, P61, P62, P63, P64,
P66, P67, P69, P70, P71 nature of software architects [11]. The introvert nature is com-
Container 14 P2, P8, P11, P17, P19, P25, P29, P35, posed of the analysis and other design-oriented architectural
P36, P47, P48, P58, P59, P68 activities and it has been refined into the architecting activities
Virtual machine 13 P12, P14, P16, P20, P24, P26, P30, P31,
P32, P34, P43, P49, P53 defined by Li et al. in [10]. The extrovert nature regards the
Hardware 4 P27, P28, P41, P46 communication between architects and other stakeholders and
Operating sys- 1 P65 it has been further classified into the providing information
tem
and getting input parameters proposed by Kruchten in [9].
As shown in Table VII, the mainly discussed introvert archi-
tecting activities are analysis (56/71) implementation (29/71),
existence of challenges and complexities in the implementation
description (23/71) and evaluation (18/71). These indicators
and deployment of microservice architectures in practice. It
seem to show that researchers are not focusing on architecting
is worth noting that the phases of maintenance (12/71) and
activities regarding architectural reuse (6/71) or maintenance
testing (10/71) are not a primary target of research, probably
and evolution (15/71) of existing assets. Moreover, architec-
because microservice applications are relatively young. Possi-
ture impact analysis (2/71) and architecture recovery (5/71)
bly, the areas of microservices maintenance and testing might
are hardly discussed. These aspects may be significant research
become fields for further investigations. We observe also that
directions to explore. In the lower part of the Table we can
in only (1/71) study (P8) the requirements are discussed in
observe how little investigation is performed on extrovert
detail along with their impact on the evolution of the presented
architecting activities, i.e., providing information (4/71) and
microservice-based system.
getting input (0/71). These complementary activities to the
TABLE VI system design concern the interaction with other stakeholders.
S OFTWARE LIFECYCLE SCOPE From a research perspective the low interest in these comple-
Lifecycle scope #Studies Studies mentary activities might indicate that there could be areas of
Design 65 P1, P2, P3, P4, P5, P7, P8, P9, P10, P11, improvement in the engagement of customers and users, and
P12, P13, P14, P15, P16, P17, P18, P19, also in the project management and the communication with
P20, P21, P23, P24, P25, P26, P27, P28,
P29, P30, P31, P32, P33, P34, P35, P36, the teams. Toward these directions an architectural language
P37, P38, P39, P40, P41, P42, P43, P46, might be a powerful instrument in order to enable better
P47, P48, P49, P50, P51, P52, P53, P54, communication with both stakeholders and developers.
P55, P56, P59, P60, P61, P62, P63, P64,
P65, P66, P67, P68, P69, P70, P71 Quality attributes. It is the set of quality attributes ad-
Implementation 24 P8, P9, P10, P14, P15, P20, P21, P25,
P29, P30, P31, P34, P35, P37, P38, P52,
dressed or discussed by the study. Performance efficiency
P54, P56, P60, P61, P64, P66, P68, P70 (40/71), and maintainability (28/71) are the most investigated
Operation 22 P1, P8, P11, P12, P16, P17, P19, P24, quality attributes, while the remaining qualities are almost
P25, P26, P27, P30, P32, P35, P36, P41,
P43, P48, P53, P59, P62, P65
equally represented, as shown in Table VIII. One of the key
Maintenance 12 P7, P30, P31, P37, P43, P51, P54, P56, reasons why performance efficiency is extensively investigated
P63, P68, P70, P71 is because it includes scalability, which microservice architec-
Testing 10 P6, P17, P22, P25, P43, P44, P45, P56,
P57, P58
tures aim to support to a great extend. Similarly, the attention
Requirements 1 P8 to maintainability might be related to the characteristics of
small services and automatic deployment. We observe that,
Microservice architecture definition. In the primary studies the difference between the higher focus on the maintainability
microservice architectures have been defined in several ways quality attribute with respect to the activity of maintenance
and in some cases even more than one single definition was and evolution (discussed in the previous paragraph) is due to
reported. The most recurring definition was the one provided the fact that researchers address more often the quality of the
by J. Lewis and M. Fowler (32/71) [4], followed by the one system rather than performing the activity of maintenance as
given by S. Newman (13/71) [13]. In (16/71) studies the prove- defined by Li et al. [10] as the activity of correcting faults and
nance of the definitions was scattered among other scientific adapting to a changed or changing operational environment.
papers, while in (19/71) studies own-informal definitions were If we compare the number of primary studies addressing
adopted. This evident fragmentation of definitions results in security (17/71), reliability (14/71) and portability (12/71)
ambiguities and does not help to provide clarity to the bound- to the number of studies focusing on performance efficiency
aries of the microservice architectural style. Interestingly, the (40/71) we might observe that these quality attributes have not
definitions provided by J. Lewis and M. Fowler and S. Newman received the same research attention. Possible research gaps
(13/71) seem to start prevailing over the remaining definitions. might exist in the areas related to these quality attributes.

26
 TABLE VII TABLE VIII
A RCHITECTING ACTIVITIES Q UALITY ATTRIBUTES

Arch. activities #Studies Studies Quality attr. #Studies Studies

Introvert activities Performance 40 P1, P3, P4, P6, P7, P9, P11, P12, P14, P15,
Architectural 56 P1, P2, P3, P4, P5, P7, P8, P9, P10, P11, efficiency P17, P18, P19, P20, P23, P24, P25, P26,
Analysis P12, P13, P14, P15, P16, P17, P18, P19, P27, P29, P30, P31, P32, P33, P34, P35,
P20, P21, P23, P25, P26, P28, P29, P31, P36, P41, P49, P51, P52, P54, P57, P58,
P32, P33, P34, P35, P36, P37, P38, P39, P61, P65, P66, P67, P68, P69
P40, P42, P45, P47, P48, P49, P50, P51, Maintainability 28 P1, P3, P4, P6, P8, P11, P14, P17, P22, P23,
P54, P55, P56, P57, P60, P61, P63, P64, P30, P33, P36, P37, P38, P39, P40, P43,
P65, P66, P67, P68, P69, P71 P45, P47, P50, P51, P53, P56, P63, P65,
Architectural 29 P2, P3, P8, P10, P11, P14, P15, P18, P20, P68, P71
Implementation P21, P25, P26, P29, P32, P33, P34, P37, Security 17 P1, P11, P14, P16, P17, P18, P19, P20, P21,
P38, P47, P49, P52, P54, P56, P60, P61, P28, P32, P52, P54, P58, P60, P64, P66
P66, P68, P69, P70 Functional 14 P2, P6, P11, P12, P29, P30, P38, P42, P47,
Architecture 23 P1, P3, P7, P8, P18, P37, P38, P40, P41, suitability P50, P55, P56, P59, P62
Description P51, P52, P53, P55, P56, P59, P61, P62, Reliability 14 P1, P5, P6, P12, P30, P32, P36, P44, P45,
P65, P66, P68, P69, P70, P71 P49, P54, P57, P65, P68
Architectural 18 P8, P12, P14, P15, P24, P25, P26, P29, Compatibility 14 P4, P5, P10, P18, P19, P21, P23, P30, P40,
Evaluation P32, P35, P37, P49, P51, P55, P56, P61, P53, P56, P58, P60, P68
P64, P65 Usability 13 P8, P9, P20, P25, P29, P33, P34, P37, P51,
Architectural 15 P1, P4, P6, P7, P8, P31, P37, P41, P43, P52, P56, P61, P62
Maintenance P44, P45, P51, P53, P58, P70 Portability 12 P1, P11, P12, P13, P17, P30, P46, P48, P53,
and Evolution P56, P65, P70
Architecture 10 P1, P7, P8, P11, P12, P26, P31, P37, P45,
Understanding P50
Architecture 6 P8, P11, P30, P37, P67, P70 TABLE IX
Reuse A RCHITECTURE PROVENANCE
Architectural 6 P8, P12, P13, P37, P51, P62
Synthesis Arch. #Studies Studies
Architecture 5 P9, P15, P27, P43, P65 provenance
Recovery Designed 58 P1, P2, P4, P5, P7, P10, P11, P12, P13, P14,
Architecture 2 P7, P8 P16, P18, P19, P20, P21, P22, P23, P24,
Impact P25, P26, P28, P29, P30, P32, P33, P34,
Analysis P35, P36, P38, P39, P40, P41, P42, P43,
Extrovert activities P46, P47, P48, P49, P50, P51, P52, P53,
Providing 4 P22, P40, P46, P70 P55, P56, P57, P58, P59, P60, P61, P62,
Information P63, P64, P66, P67, P68, P69, P70, P71
Getting Input 0 Extracted 13 P3, P6, P8, P9, P15, P17, P27, P31, P37,
P44, P45, P54, P65

Architecture provenance. An architecture is designed if it Architecture description types. The results show that the
is created prior its implementation, extracted vice versa. The architectures proposed were mostly described in their struc-
type of provenance of the architectures results to be mainly tural (55/71) aspects, while the behavioral (24/71) aspects
designed (58/71) rather than extracted (13/71), as reported were treated in a minor number of cases. In the remaining
in Table IX. This result might suggest that it is not easy to studies (12/71) this classification was not applicable.
realize microservice architectures unless an actual analysis and Design patterns. Several design patterns have being dis-
design of the system has been performed. From a research cussed in the primary studies, but not many have been applied
point of view, this might confirm that there exist some uncer- frequently. The most recurring design patterns are: API gate-
tainty about the realization of microservices. This uncertainty way (11/71), publish/subscribe (8/71), circuit breaker (6/71),
might be related either to the microservice architectural style proxy (4/71) and load balancer (3/71). It is important to note
challenges, or the needed infrastructure and technologies. that a number of other design patterns have been proposed, and
Architectural language. From the analysis of the primary as the field of microservice architectures matures more design
studies has emerged that the majority of the proposed archi- patterns will likely emerge. Results are reported in Table X.
tectures were described using informal architectural languages Technology-specific. We classified as technology-specific the
(50/71) while in few cases UML (4/71) was used. Interest- studies which have proposed solutions, methods or techniques
ingly, six different architectural languages were either used that are dependent from one or more specific technologies. The
or proposed as suitable languages for designing microservice results have shown that (54/71) of the primary studies were not
architectures: UML (P43), BPMN (P33, P51), Medley (P52), technology-specific, while the remaining (17/71) resulted to
OCCIEx (P59), Ciudad (P62) and Diary (P70). From a re- be technology-specific. The predominance of not technology-
searcher’s point of view, the use of informal architectural lan- specific studies is a good indicator because approaches and
guages and the lack of a predominant architectural language solutions can be reused. Differently, technology-specific stud-
can indicate difficulties in the description and modeling of ies have the advantage of being more detailed, but their
microservice architectures. applicability and portability in the future might be limited.

27
 TABLE X
D ESIGN PATTERNS ments – food for thought.
Design patterns #Studies Studies  Architecture analysis emerges as the most popular
API Gateway 11 P2, P3, P8, P18, P33, P35, P38,P47, architecting activity. Results suggest software archi-
P50, P65, P67,P68, P71 tecture as a powerful instrument for stakeholder en-
Publish/subscribe 8 P2, P3, P4, P19, P40, P50, P67, P68
Circuit breaker 6 P1, P16, P30, P44, P46, P65 gagement. The clear focus on infrastructure services
Proxy 4 P6, P8, P12, P18 will help devising new patterns and styles building
Load balancer 3 P30, P47, P49 upon them and hence further leveraging cloud-based
Other 9 P1, P11, P19, P30, P38, P44,P46,P50,
P67 architecture models.

VI. R ESULTS - P OTENTIAL FOR I NDUSTRIAL A DOPTION

Infrastructure services. It is the set of infrastructure ser-
(RQ3)
vices supporting non-functional tasks, as defined by Richards
in [17]. As shown in Table XI, the most relevant infrastructure Readiness level. Defined by the systematic measurement sys-
services seem to be related to monitoring (26/71) and system tem for assessing the maturity of a particular technology [12],
level management (26/71). Microservice architectures, being the technology readiness level (TRL) is an integer n where
inherently distributed, show a clear need for monitoring ca- 1 ≤ n ≤ 9. This measure has been proposed by the Horizon
pabilities (e.g., logging, profiling) but also need instruments 2020 European Commission for the 2014/2015 work program.
for system level management (e.g., health management, au-
toscaling, load balancing) in order to leverage the underlying
infrastructure efficiently. Once more this confirms the tight
coupling between microservices and DevOps.
TABLE XI
I NFRASTRUCTURE SERVICES

Infr. services #Studies Studies

Monitoring 26 P1, P9, P10, P14, P15, P16, P18, P20, P26, Fig. 3. Frequencies of technology readiness levels
P27, P28, P29, P30, P31, P32, P34, P37,
P38, P39, P41, P50, P53, P59, P60, P61,
P65 Figure 3 presents the frequencies of the TRLs of our primary
System level 26 P1, P2, P11, P12, P15, P18, P20, P25, P26, studies. Firstly, the majority of the studies (54/71) have a
management P34, P35, P36, P37, P40, P41, P43, P45, low TRL (i.e., TRL ≤ 4), where a technology is either
P46, P47, P48, P49, P50, P55, P59, P62,
P68 formulated, validated or demonstrated at most in lab. Secondly,
Service 13 P1, P3, P6, P8, P12, P15, P20, P46, P48, 4 studies have a medium TRL (i.e., 5 ≤ TRL ≤ 6), where a
Orchestration P49, P66, P68, P69 technology is either validated or demonstrated in the relevant
Service 10 P1, P11, P12, P20, P29, P31, P32, P40,
brokering P50, P68 environment, and 13 studies have a high TRL (i.e., TRL ≥ 7),
Messaging 6 P9, P21, P40, P53, P54, P68 where the technology is either completed, demonstrated, or
Security 6 P14, P20, P21, P23, P28, P62 proven in operational environment. These results indicate that
Service Prox- 4 P6, P12, P44, P67
ies (i) research on architecting microservices is still in its initial
Data storage 1 P18 phases for what concerns the transferability of the developed
technologies into industry (many of them are simply not ready
Not surprisingly, a significant research interest is pointing yet), (ii) in many studies (22/71) only the basic principles on
to service orchestration (13/71) and service brokering (10/71), architecting microservices have been discussed (TRL=1) or the
confirming that service management capabilities are funda- technology concept has been simply formulated (TRL=2)and
mental to this area. Interestingly, some research is also focused (iii) there is a relatively large number of studies in which the
on providing security (6/71) at the infrastructural layer. actual system has been proven in its operational environment
(P4, P8, P20, P34, P37, P61, P68). Interestingly, the studies
with TRL=9 are evenly distributed between academic only,
Main findings: industrial only, and mixed involvement (see next parameter).
 Both research scope and support for architecting Industry involvement. Here we classify each primary study
mirror the current immaturity of the field. as: academic if all authors are affiliated with universities or
 In scope are problems that consolidate the need research centers, industrial if all authors are affiliated with
to master the tradeoffs between complexity and some companies, or a mix of the previous two categories. As
flexibility; focus on cloud and mobile paradigms shown in Figure 4, the majority of primary studies contribute
(and many domains that rely on them); and the focus with an academic-only perspective (41/71), followed by mixed
on legacy migration. Also, most studies cover the (18/71) and industry-only (12/71) contributions. This result is
design phase, and only one does address require- encouraging as in almost half of the primary studies there
is the involvement of at least one industrial researcher or

28
practitioner; this means that in those cases we are potentially validity are unavoidable. The following reports on the main
smoothing the knowledge exchange between academia and threats to validity to our study and how we mitigated them.
industry, where research is performed on industrially relevant External validity. The most severe external threat of our
problems and new methods, technologies and tools are trans- study consists in the fact that our primary studies are not
ferred from academia to industry [20]. representative of the state of the art on architecting microser-
vices. As a solution, we applied a search strategy consisting
of both automatic search and backward-forward snowballing
on the selected studies in combination. Also, we considered
only peer-reviewed papers and excluded the so-called grey
literature (e.g., white papers, editorials, etc.); nevertheless, this
potential bias did not impact our study significantly since
Fig. 4. Distribution of industry involvement considered papers have undergone a rigorous peer-reviewed
Tool support. In the context of this study a tool can be process, which is a well-established requirement for high qual-
considered as an instance that may represent a precise version ity publications. We also applied well-defined and previously
of an automated tool or a written procedure [6]. Based on validated inclusion and exclusion criteria, which we refined
the given definition, we categorize a tool either as software iteratively by considering the pilot studies of our review.
based or knowledge based. Our analysis shows that almost Internal validity. We rigorously defined the research protocol
half of the studies (35/71) provide a knowledge-based tool of our study and we iteratively defined our classification
(e.g., best practices, documented design patterns, guidelines), framework by rigorously applying the keywording process.
whereas only 20 studies provide a software-based tool (e.g., a The syntheses of the collected data have been performed
testing tool, a code generator, a monitoring infrastructure) and by applying well-assessed descriptive statistics. During the
16 studies provide a combination of knowledge- and software- horizontal analysis we made a sanity test of the extracted data
based tool (e.g., a method for implementing services that by cross-analyzing parameters of the classification framework.
communicate via an implemented middleware, a testing tool Construct validity. We mitigated this potential bias by au-
together with a testing method, etc.). tomatically searching the studies on multiple data sources,
Open-source test system. When screening the 71 primary independently of publishers’ policies or business concerns;
studies we checked if an open-source test system for bench- also we are reasonably confident about the construction of
marking microservices-based systems was used, discussed or the search string since the terms used are very general and
proposed. We identified only one such systems (in P27), it suited to our research questions; the automatic search has
is called Acme Air and it is publicly available as open- been complemented with snowballing. Also, we rigorously
source repository on GitHub2 . Acme Air is a web-based selected the potentially relevant studies according to well-
system available in two different architectures (i.e., monolithic documented inclusion and exclusion criteria. This selection
service and microservice) and in two different languages (i.e., stage was performed by one researcher and, as suggested by
Node.js and Java), thus providing to researchers a very useful [20], a random sample of potentially relevant studies was
benchmark for evaluating, measuring, and comparing their identified and the inter-researcher agreement was ensured.
own solutions over a common reference system. Conclusion validity. We rigorously defined and iteratively
refined our classification framework, so that we could reduce
Main findings: potential biases during the data extraction process. In so doing
 In spite of their focus on specific solutions, the low we also have the guarantee that the data extraction process
TRL scores of most studies suggest that industrial was aligned with our research questions. More in general, we
transferability is far away. mitigated potential threats to conclusion validity by applying
 The balanced involvement of industrial and aca- the best practices coming from three different guidelines on
demic authors is however promising for knowledge systematic studies [7, 16, 20]. We applied those best practices
co-creation and cross-fertilization. in each phase of our study and we documented each phase in
a publicly available research protocol, thus making our study
VII. T HREATS TO VALIDITY easy to be replicated by other researchers.
In 2015, Petersen et al. [16] created a checklist for objec-
VIII. R ELATED W ORK
tively assessing the quality of systematic mapping studies. In
this context a score can be computed as the ratio of the number A systematic mapping on microservices was performed by
of actions taken in a study in comparison to the total number Pahl et al. on a set of 21 primary studies from 2014 to
of actions in the checklist. In our case we achieve a score of 2015 [14]. It is a classification of the research directions in
65%, far higher than most systematic studies in the literature, the field and highlights the relevant perspectives considered
which have a distribution with a median of 33% and 48% as by researchers. Our study differs from [14] in the following
the absolute maximum value. As always, however, threats to terms: (i) we apply a more comprehensive search process by
considering studies published in any year up to 2016 (allegedly
2 https://github.com/acmeair/acmeair
the term microservices has been used for the first time in 2011

29
[http://en.wikipedia.org/wiki/Microservices]), extending their [5] M. Ivarsson and T. Gorschek. A method for evaluating
search string, and complementing the automated search with rigor and industrial relevance of technology evaluations.
snowballing; (ii) we apply a systematic process for defining a Empirical Software Engineering, 16(3):365–395, 2011.
classification framework; (iii) we investigate on the potential of [6] M. L. Jaccheri, G. P. Picco, and P. Lago. Eliciting
industrial adoption of research in architecting microservices. software process models with the e 3 language. ACM
In [1] Alshuqayran, Ali and Evans presented a sys- Transactions on Software Engineering and Methodology
tematic mapping study on microservice architecture. Their (TOSEM), 7(4):368–410, 1998.
study focusses on (i) the architectural challenges faced by [7] B. Kitchenham and P. Brereton. A systematic review of
microservice-based systems, (ii) the architectural diagrams systematic review process research in software engineer-
used for representing them, and (iii) the involved quality ing. Information and software technology, 55(12):2049–
requirements. The work by Alshuqayran et al. and our study 2075, 2013.
can be considered as complementary, each of them cutting the [8] B. A. Kitchenham and S. Charters. Guidelines for
topic of architecting microservices from different perspectives. performing systematic literature reviews in software en-
The main difference between those two studies is that ours gineering. Technical Report EBSE-2007-01, Keele Uni-
considers different research questions, thus leading to different versity and University of Durham, 2007.
results, findings, and overlook for future research. [9] P. Kruchten. What do software architects really do?
Dragoni et al. performed an informal survey on microser- Journal of Systems and Software, 81(12), 2008.
vices [2]. Our study differs from their study because (i) [10] Z. Li, P. Liang, and P. Avgeriou. Application of
we specifically focus on architectural principles, method, and knowledge-based approaches in software architecture: A
techniques, rather than on microservices in general; (ii) we systematic mapping study. Information and Software
apply a rigorous empirical method throughout the study (i.e., Technology, 55(5):777–794, 2013.
systematic mapping), thus providing evidence-based results [11] I. Malavolta, P. Lago, H. Muccini, P. Pelliccione, and
and easing replication of the performed research; (iii) the A. Tang. What industry needs from architectural lan-
objective of our study is to characterize existing research on guages: A survey. IEEE Transactions on Software
architecting microservices, rather than on providing a narrative Engineering, 39(6):869–891, 2013.
viewpoint on their historical, current, and future traits. [12] J. C. Mankins. Technology readiness levels. White Paper,
April, 6, 1995.
IX. C ONCLUSIONS AND F UTURE W ORK [13] S. Newman. Building Microservices. O’Reilly Media,
Inc., 2015.
The purpose of this study is to provide a broader survey
[14] C. Pahl and P. Jamshidi. Microservices: A Systematic
investigating relationships among research contributions on
Mapping Study. In Proceedings of the 6th International
microservices is demanded [2]. Specifically, we performed a
Conference on Cloud Computing and Services Science,
systematic mapping on 71 primary studies and produced a
Rome, Italy, pages 137–146, 2016.
clear overview of the state of the art on architecting microser-
[15] K. Petersen, R. Feldt, S. Mujtaba, and M. Mattsson.
vices. The results of this study will benefit both researchers
Systematic mapping studies in software engineering. In
willing to further contribute to the area and practitioners
Proceedings of the 12th International Conference on
willing to understand existing research. Future work includes
Evaluation and Assessment in Software Engineering,
(i) a qualitative study involving practitioners aiming at better
EASE’08, pages 68–77, Swinton, UK, UK, 2008.
understanding the state of the practice on microservices and
[16] K. Petersen, S. Vakkalanka, and L. Kuzniarz. Guidelines
(ii) attacking a selection of the identified research gaps.
for conducting systematic mapping studies in software
engineering: An update. Information and Software Tech-
R EFERENCES
nology, 64:1–18, 2015.
[1] N. Alshuqayran, N. Ali, and R. Evans. A Systematic [17] M. Richards. Microservices vs. Service-Oriented Archi-
Mapping Study in Microservice Architecture. In Proc. tecture. O’Reilly Media, 2015.
of the 9th International Conference on Service-Oriented [18] R. Wieringa, N. Maiden, N. Mead, and C. Rolland.
Computing and Applications. IEEE, IEEE, 2016. Requirements engineering paper classification and evalu-
[2] N. Dragoni, S. Giallorenzo, A. L. Lafuente, M. Mazzara, ation criteria: a proposal and a discussion. Requirements
F. Montesi, R. Mustafin, and L. Safina. Microser- Engineering, 11(1):102–107, 2006.
vices: yesterday, today, and tomorrow. arXiv preprint [19] C. Wohlin. Guidelines for snowballing in systematic
arXiv:1606.04036, 2016. literature studies and a replication in software engineer-
[3] E. Engström and P. Runeson. Software product line ing. In Proceedings of the 18th International Conference
testing - a systematic mapping study. Inf. Softw. Technol., on Evaluation and Assessment in Software Engineering,
53(1):2–13, Jan. 2011. pages 38:1–38:10, New York, NY, USA, 2014. ACM.
[4] M. Fowler and J. Lewis. Microservices a def- [20] C. Wohlin, P. Runeson, M. Höst, M. Ohlsson, B. Regnell,
inition of this new architectural term. URL: and A. Wesslén. Experimentation in Software Engineer-
http://martinfowler.com/articles/microservices.html. ing. Computer Science. Springer, 2012.

30