ArticlePDF Available

Understanding Cloud-native Applications after 10 Years of Cloud Computing - A Systematic Mapping Study

Authors:

Abstract and Figures

It is common sense that cloud-native applications (CNA) are intentionally designed for the cloud. Although this understanding can be broadly used it does not guide and explain what a cloud-native application exactly is. The term "cloud-native" was used quite frequently in birthday times of cloud computing (2006) which seems somehow obvious nowadays. But the term disappeared almost completely. Suddenly and in the last years the term is used again more and more frequently and shows increasing momentum. This paper summarizes the outcomes of a systematic mapping study analyzing research papers covering "cloud-native" topics, research questions and engineering methodologies. We summarize research focuses and trends dealing with cloud-native application engineering approaches. Furthermore, we provide a definition for the term "cloud-native application" which takes all findings, insights of analyzed publications and already existing and well-defined terminology into account.
Content may be subject to copyright.
The Journal of Systems and Software 126 (2017) 1–16
Contents lists available at ScienceDirect
The Journal of Systems and Software
journal homepage: www.elsevier.com/locate/jss
Understanding cloud-native applications after 10 years of cloud
computing - A systematic mapping study
Nane Kratzke
, Peter-Christian Quint
Lübeck University of Applied Sciences, Center of Excellence for Communication, Systems and Applications, Mönkhofer Weg 239, 23562 Lübeck, Germany
a r t i c l e i n f o
Article history:
Received 23 September 2016
Revised 30 November 2016
Accepted 4 January 2017
Available online 5 January 2017
MSC:
00-01
99-00
Keywo rds:
Cloud-native application
CNA
Systematic mapping study
Elastic platform
Microservice
Self service
Pattern
Softwareization
a b s t r a c t
It is common sense that cloud-native applications (CNA) are intentionally designed for the cloud. Al-
though this understanding can be broadly used it does not guide and explain what a cloud-native appli-
cation exactly is. The term “cloud-native” was used quite frequently in birthday times of cloud computing
(2006) which seems somehow obvious nowadays. But the term disappeared almost completely. Suddenly
and in the last years the term is used again more and more frequently and shows increasing momentum.
This paper summarizes the outcomes of a systematic mapping study analyzing research papers covering
“cloud-native” topics, research questions and engineering methodologies. We summarize research focuses
and trends dealing with cloud-native application engineering approaches. Furthermore, we provide a def-
inition for the term “cloud-native application” which takes all findings, insights of analyzed publications
and already existing and well-defined terminology into account.
©2017 Elsevier Inc. All rights reserved.
1. Introduction
The birthday of the cloud can be dated into the year 2006
the first launch of a general purpose public cloud service (Simple
Storage Service, S3 at 13th March 2006
1
) by the currently most
prominent public cloud service provider Amazon Web Services
(AWS). Therefore, this study has not considered any papers dated
before 2006. Meanwhile other providers and further services
followed. All these cloud providers and their services forming
nowadays our understanding of the term cloud computing. Al-
though terms like public/private/hybrid cloud computing and
acronyms like IaaS (Infrastructure as a Service), PaaS (Platform
as a Service) or SaaS (Software as a Service) are frequently used,
these terms are often understood in differing ways. Gladfully,
the mentioned terms are defined precisely by the NIST definition
of cloud computing ( Mell and Grance, 2011 ). But there remains
confusion with more specific topics in cloud computing like cloud-
Corresponding author.
E-mail addresses: nane.kratzke@fh-luebeck.de (N. Kratzke), peter-christian.
quint@fh-luebeck.de (P.-C. Quint).
1 https://aws.amazon.com/releasenotes/122 (last access 5th July 2016).
native applications (CNA). This contribution investigates a more
precise understanding of the term “cloud-native”.
According to Fig. 1 and Google trends the term “cloud-native”
has an unusual diffusion rate over time. In birthday times of cloud
computing – so about 10 years ago –it was used quite frequently.
To label something as cloud-native at the starting days of cloud
computing seems somehow obvious today. However, the usage of
the term “cloud-native” decreased over following years according
to Google. But since 2015, the term is more and more frequently
used again and gained momentum (see Fig. 1 ). We have to admit
that Google trends is not a very reliable source for research –it is
known to be prone for “industrial buzzwords”. But, our literature
review will show a very similar usage of the term “cloud-native”
in research studies (the reader might want to compare Figs. 1 and
5 a). Furthermore, our data indicates that the current understand-
ing of the term “cloud-native” seems to have its origin in research
and not in industry. It was used and characterized since 2012
in research. And yes, it gets suddenly popular in industry, but
not before 2015 (according to Google trends, see Fig. 1 ). We
assume this sudden rise in industry has to do with the current
popularity of microservice and container-based approaches. Cloud-
native applications may be a logical continuation of microservice
and container-based approaches from an industry point of view.
http://dx.doi.org/10.1016/j.jss.2017.01.001
0164-1212/© 2017 Elsevier Inc. All rights reserved.
2 N. Kratzke, P.- C. Quint / The Journal of Systems and Software 126 (2017) 1–16
Fig. 1. Google trends (01.01.2006 until 22.05.2016) of the term “cloud-native”.
Fig. 2. Research process (a combination of the process for performing systematic mapping studies and systematic literature reviews.
However, the reader will see, that “cloud-native” concepts are
reflected for a while in research. So, although the term seems to
be new, it is not. It simply never has been wide spread. However,
some contributions providing valuable insights what additional
properties an application must fulfill to be called “cloud-native”
compared with classical legacy distributed applications. But there
are although “white areas” on the map. So we think –after 10
years of cloud computing –it is time to be a bit more precise with
regard to the term “cloud-native”.
Therefore this contribution is outlined as follows: In
Section 2 we will explain our systematic mapping and adaptive
reading steps. Furthermore, we introduce our research questions
and present our data. We make a comparative analysis of the
data (main outcome of our systematic mapping study) regarding
our research questions in Section 3 . We discuss existing strengths
and weaknesses of state of the art research and engineering in
Section 4 (main outcome of our adaptive reading steps) to deduce
some interesting research implications, existing engineering trends
and valuable future research directions. Because we identified
enough studies dealing with cloud-native application specifics,
we were able to propose a definition for the term “cloud-native”
in Section 5 taking all identified literature into consideration
systematically. We conclude our findings in Section 6 .
2. Research methodology
We aligned our research according to general guidelines for sys-
tematic mapping studies in software engineering ( Petersen et al.,
2015; 2008 ) and for systematic literature reviews ( Kitchenham and
Charters, 2007 ). Additionally, we took updates and critical reflec-
tions ( Wohlin et al., 2013 ) on these guidelines into consideration.
Systematic mapping studies and systematic literature reviews
are analyzing primary studies. A primary study is “an empirical
study investigating a specific research question” ( Kitchenham and
Charters, 2007 ). Reviews and mapping studies are so called sec-
ondary studies. A secondary “study [...] reviews all the primary
studies relating to a specific research question with the aim of inte-
grating/synthesizing evidence related to a specific research question”
( Kitchenham and Charters, 2007 ). A systematic literature review
“uses a well-defined methodology to identify, analyze and interpret
all available evidence related to a specific research question in a way
that is unbiased and (to a degree) repeatable” ( Kitchenham and
Charters, 2007 ). Other than that, a scoping or mapping study
performs “a broad review of primary studies in a specific topic
area that aims to identify what evidence is available on the topic”
( Kitchenham and Charters, 2007 ).
According to guidelines for systematic maps and reviews in
software engineering, we used both approaches complementary
( Petersen et al., 2008 ). Due to the insight that “systematic maps can
summarize and help transfer results to practitioners” ( Petersen et al.,
2008 ) better, we decided to keep the focus on the systematic
mapping process and used the mapping approach to scan “cloud-
native” literature in a broad way. These mapping outcomes are
mainly presented in Section 3 . However, in adapting reading
depth steps we followed principles of systematic reviews. These
outcomes are mainly discussed in Section 4 . The same is true
for selecting relevant papers to derive a definition proposal for
cloud-native applications (see Section 5 ). This process combination
is visualized in Fig. 2 and explained in the following paragraphs.
The second author of the study performed detailed quality con-
trol checks on each of these presented steps and intermediate
outcomes.
2.1. Research scope and research questions
Cloud computing emerged 10 years ago. It is obvious that
in a first adoption phase existing IT systems simply had been
transferred to cloud environments. But cloud environments are
elastic. Elasticity is understood as the degree to which a system
adapts to workload changes by provisioning and de-provisioning
resources automatically. Over the time system engineers under-
stand the elasticity options of modern cloud environments better
and they intentionally designed systems for such elastic cloud
infrastructures. This intention is often expressed using the term
N. Kratzke, P.- C. Quint / The Journal of Systems and Software 126 (2017) 1–16 3
Tabl e 1
Results (Papers might be listed in two or more sources).
Electronic source Papers Oldest Youn ge st Latest access
IEEExplore 11 2010 2016 15 .09.2016
ACM Digital Library 8 2014 2016 15 .09.2016
Google Scholar 23 2015 2016 15 .09.2016
Citeseer 10 2010 2014 15 .09.2016
ScienceDirect 8 2010 2016 15 .09.2016
SpringerLink 41 2006 2016 15 .09.2016
Semantic Scholar 63 2011 2016 15 .09.2016
“cloud-native”. Therefore, our literature review has been guided by
the following research questions defining our research scope:
[RQ1] Where does the term “cloud-native” come from?
[RQ2] Is there a common understanding of the term “cloud-
native”?
[RQ3] What are existing trends in cloud-native application en-
gineering?
[RQ4] What promising trends for future cloud-native research
and engineering can be deduced?
2.2. Conduct search for primary studies
So far, the terms “cloud-native” or “native cloud” are not
very intensively used in literature. However, they show increas-
ing momentum and are emerging from an evolutionary process
starting with the service-oriented architecture approach, system
virtualization, cloud computing, operating system virtualization
(aka container) and ending in a recently most popular approach:
microservices. We conducted our search for studies in the elec-
tronic sources listed in Table 1 (according to recommendations for
performing literature reviews in software engineering ( Petersen
et al., 2015; Wohlin et al., 2013 )). We searched for contributions
published in or after 2006 having the term “cloud-native” or
“cloud native” in their title, abstract or keywords. However, we
did not perform a full text search. We argue, that the cloud-native
aspect should be intentionally taken so much into consideration
by authors that they should explicitly mention it in title, abstract
or as a keyword. However, in case of book chapters or books we
searched for the search terms in the content as well. For these
kind of publications sometimes abstracts and keywords are not
provided via electronic sources. In these cases we scanned for the
search terms in introduction and conclusion or summary sections
by hand to include relevant publications like Fehling et al. (2014) .
These kind of publications would have otherwise fallen through
our search filters. This would have become problematic especially
in case of Fehling et al. (2014) , which turned out to be one of the
most valuable sources in understanding cloud-native applications.
2.3. Screening of papers for inclusion and exclusion
Table 3 shows the selected studies. We selected these studies
by applying inclusion and exclusion criteria shown in Table 2
to exclude studies that are not relevant to answer our research
questions.
2.4. Categorization of papers (keywording of abstracts)
According to Petersen et al. (2015) and if possible, existing clas-
sification schemes should be used for topic specific classification
of papers. We checked IEEE, ISO/IEC as well as Swebok standards
( Bourque and Fairley, 2014 ) but found no appropriate classification
system. So, like a majority of mapping studies ( Petersen et al.,
2015 ) we were forced to derive our own topic specific classification
Tabl e 2
Inclusion and exclusion criteria.
Inclusion
(1) Keynotes, conference papers, journal papers, books and book chapters
dealing with cloud-native application design, engineering or operation in
broadest sense.
Exclusion
(1) The abstract made obvious that a contribution lies outside the cloud
computing domain (e.g. weather, climate papers often use ”cloud” terms,
the same is true for some astrophysical papers)
(2) The content of the paper showed that the term “cloud-native” has been
used only occasionally without focusing it explicitly (e.g. that a
methodology can be used for a cloud-native application as well beside a
lot of other use cases). We only checked this if the term “cloud-native” is
not explicitly
mentioned in title or abstract.
(3) The contribution was only available in the form of abstracts or
powerpoint presentations (this rule was not applied for keynotes).
(4) Type of publication could not be determined (technical report,
conference, journal, book chapter, book, keynote)
(5) Publication language was not English.
scheme. We did this using the process shown in
Fig. 3 . We took the
authors’ keywords as a starting point. If keywords of authors were
not provided we did some adaptive reading (as recommended by
Petersen et al. (2008) ) and derived meaningful keywords on our
own based on the title and the abstract. For some contribution
types like book Chapters or books and in rare cases for conference
papers and conference keynotes there were no abstracts provided
(or the abstracts were not helpful at all). In these cases we decided
to do even more adaptive reading and evaluated introduction and
conclusion sections as well to derive meaningful keywords.
In further steps we unified author provided keywords into a
unified keyword scheme by aggregating similar keywords into
a unified keyword category. All selected papers dealt with 21
detailed research topics of cloud-native applications. We decided
to group these detailed research topics into the following major
CNA research topics (see Table 4 ):
CNA principles describe recurring principles how CNA prop-
erties are achieved and how transferability of a CNA can
be realized. According to selected papers, CNAs should be
operated on automation platforms. Softwarization of infras-
tructures should be strived for to support DevOps principles
more consequently. Operation of CNAs in multi- and hybrid
clouds should by supported by applying migration and
interoperability principles.
CNA architecture include general CNA design aspects like
service-oriented architecture approaches (particular the
microservice architecture approach) as well as accompanying
service composition principles of self-contained deployment
units (containers).
CNA methods include patterns and design methodologies to
create effective CNA architectures and DevOps to automate
the process of delivery and infrastructure changes. These
methods are applied frequently in CNA context.
CNA properties describe characteristics of CNA. Such character-
istics dealing with consistency models, availability, partition
tolerance (all strongly related to Brewer’s CAP theorem
( Brewer, 2012 )), elasticity, resilience and service levels ( SLA ).
This property combination seems to be very characteristic
for CNA according to selected papers.
Further keywords dealt with use cases . These use cases can
be categorized into the following domains: telecommunication,
industrial processes, bioinformatics, videostreaming service providers,
energy management and experiences with public cloud services .
However, it is likely that there are a lot of other applicable use
cases which did not turn up in our literature screening due to
4 N. Kratzke, P.- C. Quint / The Journal of Systems and Software 126 (2017) 1–16
Tabl e 3
Included and categorized papers (unsorted to avoid any bias).
ID Title (shortened) Year Type Validation Evaluation Solution Survey Opinion Experience
Fehling et al. (2014) Cloud Computing Patterns 2014 Book x x
Erl et al. (2015) Cloud Computing Design
Patterns
2015 Book x x
Stine (2015) Migrating to Cloud-Native
Application Architectures
2015 Book x x
Taleb et al. (2016) On Service Resilience in
Cloud-Native 5G Mobile
Systems
2016 Journal x x
Balalaie et al. (2016a ) Microservices Architecture
Enables DevOps: Migration
to a Cloud-native
Architecture
2016 Journal x
Andrikopoulos et al. (2012) Designing for CAP 2012 Conf. x
Inzinger et al. (2014) Madcat: A Methodology for
Architecture and
Deployment of Cloud
Applications
2014 Conf. x
Balalaie et al. (2016b ) Migrating to
Cloud-Native
Architectures
2016 Chapter x
Goldschmidt et al. (2014) Scalability and Robustness of
Time-series Databases for
Cloud-native Monitoring of
Industrial Processes.
2014 Conf. x x
Andrikopoulos et al. (2013) CAP-Oriented Design for
Cloud-Native Applications
2013 Chapter x
Peinl et al. (2016) Docker Cluster Management
for the Cloud
2016 Journal x x x
Suneja et al. (2016) Touchless and always-on
cloud analytics as a service
2016 Journal x
Roussev and McCulley (2016) Forensic analysis of
cloud-native artifacts
2016 Journal x x x
Roussev et al. (2016) Forensic Acquisition of Cloud
Drives
2016 Journal x x
Nikaein et al. (2016) Towards a Cloud-Native
Radio
Access Network
2016 Chapter x x
Varghese (2015) Building Go Web Applications
on Google Cloud
2015 Chapter x x
Balalaie et al. (2016c ) Microservices Migration
Pattern
2016 Journal x x
Balalaie et al. (2015) Migrating to Cloud-native
Architectures Using
Microservices: An
Experience Report
2015 Conf. x
Familiar (2015) Service Fabric 2015 Chapter x
Nikaein (2015) Processing Radio Access
Network Functions in the
Cloud: Critical Issues and
Modeling
2015 Conf. x x
Jamshidi et al. (2015) Cloud Migration Patterns: A
Multi-cloud Service
Architecture Perspective
2015 Book Chapter x x x
Srinivasan et al. (2015) Era of Cloud Computing: A
New
Insight to Hybrid
Cloud
2015 Journal x
Krieger et al. (2016) Building an open source
cloud environment with
auto-scaling resources for
executing bioinformatics
andbiomedical workflows
2016 Journal x x x
Cockcroft (2015) Cloud Native Cost
Optimization
2015 Keynote x x
Sequeira et al. (2014) Energy Cloud: Real-Time
Cloud-Native Energy
Management System to
Monitor and Analyze
Energy Consumption in
Multiple Industrial Sites
2014 Conf. x
Brewer (2015) Kubernetes and the Path to
Cloud Native
2015 Keynote x x
Hasselbring (2016) Microservices for Scalability:
Keynote Talk
2016 Keynote x
( continued on next page )
N. Kratzke, P.-C . Quint / The Journal of Systems and Software 126 (2017) 1–16 5
Tabl e 3 ( continued )
ID Title (shortened) Year Type Validation Evaluation Solution Survey Opinion Experience
Housfater et al. (2014) Acceleration of Cloud
Computing
2014 Conf. x x
Mazmanov et al. (2013) Handling Performance
Sensitive Native Cloud
Applications with
Distributed Cloud
Computing and SLA
Management
2013 Conf. x
Garca-Gmez et al. (2012) 4CaaSt: Comprehensive
Management of Cloud
Services through a PaaS
2012 Conf. x
Mateljan et al. (2010) Cloud Database-as-a-Service
(DaaS) - ROI
2010 Conf. x
Moldovan et al. (2014) QUELLE - A Framework for
Elastic Systems
2014 Chapter x
Hole (2016) Toward an Anti-fragile
e-Government System
2016 Chapter x
Serrano et al. (2013) Cloud Services Composition
Support by Using Semantic
Annotation and Linked Data
2013 Chapter x x
Missbach et al. (2016) The Hybrid Cloud 2016 Chapter x
Colombo-Mendoza et al. (2014) MobiCloUP!: a PaaS for cloud
services-based mobile
applications
2014 Journal x x
Ben Belgacem et al. (2013) A Hybrid Grid/Cloud
Distributed Platform: A
Case Study
2014 Chapter x x
Mann et al. (2013) Opportunities to Innovate
Today
2013 Chapter x x x
Opara-Martins et al. (2016) Critical analysis of vendor
lock-in and its impact on
cloud computing migration:
a business perspective
2016 Journal x
Vasconcelos et al. (2015) Cloud Detours: A
Non-intrusive Approach for
Automatic Software
Adaptation to the Cloud
2015 Conf. x x
Wang
et al. (2015) CPFirewall: A Novel Parallel
Firewall Scheme for FWaaS
in the Cloud Environment
2015 Conf. x x
Petcu and Vasilakos (2014) Portability in Clouds:
Approaches and Research
Opportunities
2014 Journal x
Brunner et al. (2015) Experimental Evaluation of
the Cloud-Native
Application Design
2015 Conf. x
Wettinger et al. (2014) Deployment Aggregates - A
Generic Deployment
Automation Approach for
Applications Operated in
the Cloud
2014 Conf. x
Baldini et al. (2016) Cloud-native Event-based
Programming for Mobile
Appls
2016 Conf. x
Dutta et al. (2016) QoE-aware elasticity support
in cloud-native 5G systems
2016 Conf. x
Leymann et al. (2016) Native Cloud
Applications:
Why Virtual Machines,
Images and Containers Miss
the Point!
2016 Keynote x
Kratzke et al. (2016) Project Cloud TRANSIT - Or to
Simplify Cloud-native
Application Provisioning for
SMEs by Integrating
Already Available Container
Technologies
2016 Chapter x
Kratzke and Peinl (2016) ClouNS - A Cloud-native
Application Reference
Model for Enterprise
Architects
2016 Conf. x
6 N. Kratzke, P.-C . Quint / The Journal of Systems and Software 126 (2017) 1–16
Fig. 3. Keywording of selected papers.
Tabl e 4
Topic specific categories.
Research topic Detailed research topic
CNA principles Automation platform, migration, softwareization,
interoperability
CNA architecture CNA design, microservices, service composition,
deployment unit
CNA methods Patterns, design methodology, DevOps
CNA properties Scalability, resilience, elasticity, CAP properties, SLA for
CNA
Use ases Telecommunication, industrial processes,
bioinformatics,videostreaming service providers, energy
management and experiences with public cloud services
(likely incomplete)
Other Forensics, cloud-native artifacts, costs,decision making
(likely incomplete)
our focus on cloud-native application literature (we did not search
for use cases relevant for cloud applications in general). Other
keywords dealt with special aspects like forensics of cloud-native
artifacts and cloud costs and accompanying decision making
models. However, it seems that there is no clear focus on these
aspects associated with the term “cloud-native” (so far).
2.5. Data extraction and mapping of studies
We extracted data from the papers for several aspects and to
systematically answer our research questions (see Section 2.1 ).
First of all, each paper is evaluated according to its publication
year . This is documented in Table 3 and visualized in Fig. 5 a. Due
to the fact, that we could only consider publications until Septem-
ber of 2016, we extrapolated (linearly) the estimated publications
for the complete year 2016. We use this to search for the origin of
the term “cloud-native”. This will be discussed in Section 3.1 .
Each paper is assigned a contribution type (book, book
chapter, journal paper, conference paper, keynote) which is
used to evaluate the overall quality assessment of found papers
(see Section 2.6 ). It is quite uncommon in mapping studies to
Tabl e 5
Research approaches.
Category Description
Evaluation/
validation
research
Evaluation means that techniques are implemented in
practice and an evaluation of the technique is conducted. It
is shown how the technique is implemented in practice
(solution implementation) and what are the consequences
of the implementation in terms of benefits and drawbacks
(implementation evaluation). A validation is done for
techniques that might be novel or have not yet been
implemented in practice. These techniques are validated
using experiments, i.e., work done in the lab.
Solution proposal A solution for a problem is proposed, the solution can be
either novel or a significant extension of an existing
technique. The
potential benefits and the applicability of
the solution is shown by a small example or a good line of
argumentation.
Survey papers A survey reviews other primary or secondary studies relating
to a specific research question with the aim of
integrating/synthesizing evidence related to a specific
research question.
Opinion papers These papers express the personal opinion of somebody
whether a certain technique is good or bad, or how things
should been done. They do not rely on related work and
research methodologies.
Experience reports Experience papers explain on what and how something has
been done in practice. It has to be the personal experience
of the author.
cover keynotes. We decided to do so. Mainly, because some
of the keynotes by Brewer (2015) are highly influential in the
cloud-native domain. According to the best of our knowledge all
keynotes we selected are published/listed in the proceedings of
the respective conferences. This is documented in Table 3 and the
distribution across contribution types is visualized in Fig. 4 a.
We decided to classify selected papers by their research
type according to an existing classification of research ap-
proaches (proposed by Wieringa et al. (2005) and summarized
in Table 5 ). However, we did not classify philosophical papers
(because they are quite rare in software engineering) and replaced
philosophical papers by survey papers. And due to insights by
N. Kratzke, P.-C . Quint / The Journal of Systems and Software 126 (2017) 1–16 7
Fig. 4. Distribution of selected papers.
Fig. 5. Distribution of research topics of selected papers.
8 N. Kratzke, P.-C . Quint / The Journal of Systems and Software 126 (2017) 1–16
Fig. 6. Mapping of research topics to research approaches.
Wohlin et al. (2013) that there arise a lot of discussions whether a
study is a validation or evaluation study, we decided to group both
research types as equal. This is documented in Table 3 and the
distribution across contribution types is visualized in Fig. 4 b. We
use this data supportively to discuss and reflect most investigated
research topics in Section 3.3 .
The research topics were derived from keywords of selected
papers using the methodology being described in Fig. 3 . The distri-
bution of the main and detailed research topics in selected papers
is visualized in Fig. 5 b and c. Additionally, we mapped research
main topics to research approaches to visualize and investigate
what research approaches are applied mainly for what research
topics. Therefore, we aggregated all publications by their research
approach, their research detail topics and their main topic. Then
we counted how many papers of a specific research approach
dealt with a specific research main topic. Papers were counted
more than once if they had been assigned to two or more research
approaches or dealt with two or more main research topics. The
resulting mapping is presented in Fig. 6 and will be used in
Section 3.3 to discuss most investigated cloud-native topics. The
scope of the research topics are explained in Table 4 .
Most selected papers could not assigned to only one detail
research topic. So, we were interested how detail research topics
are correlated to each other. Therefore, we counted how many
papers dealt with two research topics in the same paper. We did
this to investigate what detail research topics seem to be more
correlated than others. The resulting mapping of correlated detail
research terms is presented in Fig. 7 . However, the reader should
be aware that we did this detail research only for the identified
main research topics and not for mentioned use cases (not the
focus of our research and therefore likely insucient data) and
other topics like cloud forensics or cost aspects (not enough data).
Both mappings are used in Section 3.3 to discuss and reflect most
investigated cloud-native research topics.
2.6. Study quality assessment
The quality assessment of a study is a challenging and tricky
task. Due to the nature of things there exist little objective criteria
to apply ( Petersen et al., 2015; Wohlin et al., 2013 ). Because of
selected electronic sources (see Table 1 ) and selection criteria (see
Table 2 ) mainly academic and mostly peer-reviewed contributions
should turn up. So, in accordance to electronic sources and selec-
tion criteria, we decided to estimate quality of a selected research
paper by their degree of peer reviewing. Contributions are rated
as higher quality as more peer reviewing is incorporated in them.
Furthermore, we look at a typical research contribution evolution
process and how much peer reviewing is accumulated along this
process. A lot of research contributions start as a conference
paper. Outstanding conference papers are invited as extended
papers to journals or as selected papers as book chapters in books.
This involves very often a second peer review round. So, books
integrate a lot of multiple peer reviewed research contributions.
Even if books are (only) written without formal peer reviewing
involved, these books rely on a lot of previous peer reviewed
research most of the times. A special contribution type regarding
quality are keynotes. Most of the times, keynotes are not formally
peer reviewed. But, keynote speakers are selected and invited due
to their former (peer reviewed) research contributions or practical
relevance of their industrial work. So it is likely, that keynotes rely
on valuable research contributions or practical relevance and often
show interesting (research) opinions in a specific field of research.
According to Fig. 4 a 78% of selected papers are from sources
where it is likely that there has been involved at least one peer
review round. 54% of selected papers are from sources where it
is likely that there has been involved two or even more review
rounds (journals or book chapters). And 9% of selected contribu-
tions (keynotes and books) are contributions likely without a for-
mal peer reviewing process. But these contributions rely on a lot of
peer reviewed research worth to be considered. Taking all together,
we think that Table 3 provides a reliable selection to do a profound
definition proposal in Section 5 . Section 5 will additionally include
the outcomes of data extraction and synthesis steps of the system-
atic literature review shown in Fig. 2 and discussed in Section 4 .
2.7. Threats of validity
According to Petersen et al. (2015) there are common validity
threats for systematic mapping studies. Therefore, we reflect on
possible threats which might arise from this study.
The theoretical validity might be incomplete due to not pub-
lished new and controversial views on cloud-native applications.
CNAs looking back on 10 years of cloud computing history. How-
ever, the term “cloud-native” just recently gained momentum in
academics as well as in industry. So it is likely that this study
could not take all relevant contributions into account which might
rise up in the near future or we might not took considerations
into account which are not intentionally associated with the term
N. Kratzke, P.-C . Quint / The Journal of Systems and Software 126 (2017) 1–16 9
Fig. 7. Correlation of research topics.
“cloud-native”. Furthermore, there are controversial discussions
dealing with microservices and service oriented architectures
(SOA) ( Leymann et al., 2016 ). And we got the intention that some
papers dealing with microservices might be handled “with care”
by established SOA researchers. However, there is no objective
data to the best of our knowledge to harden this fact.
The descriptive validity might be insucient for specific
aspects. According to Fig. 6 there are less evaluating or validating
studies than solution proposals. That might indicate that our
search filters omitted evaluating and validating studies. However,
we think, this just describes the current state of research. We had
a broad view on CNA and searched not intentionally for specific
aspects like cloud forensics, security, business applicability and so
on. Our study should not be taken to draw any conclusions on
these specific aspects.
A potential researcher bias might be given for Section 4 .
However, one (personal) intent of this study was to objectify
authors’ point of view on CNA engineering state of the art to
overcome this possible bias. And we have done the best to handle
each contribution from an objective point of view. Nevertheless,
the reader should be aware that one of the authors is deeply
involved in application design for cloud computing contexts and
therefore might have constructed a very specific point of view.
One of the authors’ studies ( Kratzke and Peinl, 2016 ) relies partly
on action research. We are aware, that action research is seen by
some researchers as a non-objective research method (or not a re-
search method at all). Therefore, the reader should take especially
( Kratzke and Peinl, 2016 ) into additional consideration to get a full
view and draw its conclusions on Section 4 . We assure, that action
research has not been applied for this study. Furthermore and
according to recommendations for conducting systematic mapping
studies in software engineering ( Petersen et al., 2015 ), the second
author responsible for quality assurance steps was not involved
intentionally in Kratzke and Peinl (2016) research to minimize
such kind of researcher bias for this mapping study.
3. Discussion of research questions
We will discuss our research questions in this Section mainly
on a quantitative and comparative basis. To avoid any bias we
avoid any unnecessary interpretation or rating of identified studies
and rely mainly on quantitative mapping outcomes. Of course, a
qualitative discussion of identified papers is interesting and will be
done in Section 4 summarizing outcomes of our adaptive reading
steps.
3.1. Origin of the term “cloud-native” [RQ1]
According to Fig. 5 a the first contributions using the term
“cloud-native” have been published in 2012 ( Andrikopoulos
et al., 2012; Garca-Gmez et al., 2012 ). Both conference papers
proposed solutions for cloud-native application engineering.
Andrikopoulos et al. (2012) proposes a pattern-based solution
for a cloud-native application design methodology based on
systematically identifying consistency, availability and network
partitionability requirements (according to the CAP theorem
presented by Fox et al. (1997) , Fox and Brewer (1999) and
Brewer (20 0 0) ). The authors of this contribution are all from the
research group headed by Frank Leymann (Institute of Architec-
ture and Application Systems, University of Stuttgart, Germany).
The paper itself references several other papers dealing with
pattern-based approaches. But none of these papers use the term
“cloud-native” until ( Andrikopoulos et al., 2012 ). Several further
papers of this research group focus similar topics, often model-
10 N. Kratzke, P.- C . Quint / The Journal of Systems and Software 126 (2017) 1–16
and pattern-based approaches. Our study selection contains at
least three papers by this research group. E.g. the TOSCA standard
is heavily influenced by the work of this research group.
The second paper ( Garca-Gmez et al., 2012 ) is about 4CaaSt, a
“PaaS framework that enables flexible definition, marketing, deploy-
ment and management of Cloud-based services and applications. The
major innovations proposed [...] are [...] lifecycle management, a one
stop shop for Cloud services and a PaaS level resource management
featuring elasticity, [...] a portfolio of ready to use cloud-native ser-
vices and Cloud-aware immigrant technologies”. The 4CaaST project
was an EU funded project and the authors of the publication
are from various academic and industrial research institutions:
Telefon ica, Tilburg University, SAP Research Centre, University
of St. Gallen, University of Madrid, Nokia Siemens Networks,
Orange Labs and Ericsson Research Center. However, the already
mentioned Institute of Architecture and Application Systems was
involved in additional publications covering the 4CaaSt project as
well. The publications ( Andrikopoulos et al., 2012; Garcia-Gomez
et al., 2012 ) were –according to the acknowledgement –at least
partly funded by the 4CaaSt project.
It is interesting to see, that both publications focus aspects
like pattern based approaches ( Andrikopoulos et al., 2012 ) and au-
tomation platforms ( Garca-Gmez et al., 2012 ) which are intensively
reflected in several other selected papers as well.
Fig. 7 shows the correlation on research topics. The reader sees
that the research topic automation platform is intensively corre-
lated to cloud-native architecture topics and cloud-native application
properties like scalability, resilience and elasticity. The same is true
for patterns which are intensively correlated to cloud-native appli-
cation design topics. So, both papers can be seen as one of the first
research papers dealing with and introduced cloud-native topics.
In fact, we found Fehling et al. (2014) as one of the most helpful
and complete sources systematizing a lot of cloud-native applica-
tion aspects. This contribution is derived by and integrates several
other publications (beginning with Andrikopoulos et al. (2012) ) of
the Leymann research group. So, we are willing to say that the
research project 4CaaSt and the research group around Leymann
et al. might be the origin of the term “cloud-native” in research.
Even if not, the authors provided major contributions to a better
understanding of the term “cloud-native”.
3.2. Meaning of the term “cloud-native” [RQ2]
Although there exist no precise definition what a cloud-native
application exactly is, we can conclude that there is a common but
unconscious understanding across all analyzed papers. According
to Section 2.4 and Fig. 7 , cloud-native applications (CNA) should be
build according to corresponding CNA principles (being operated
on automation platforms; using softwarization of infrastructure and
network; having migration and interoperability across different
cloud infrastructures and platforms in mind). Following these
principles enable to build CNA architectures (mainly service-based
and often with self-contained deployment units involved) with spe-
cific and wishful CNA properties (horizontal scalability, elasticity,
resiliency , isolated strict consistent or eventual consistent state) of
resulting applications. To realize CNAs, there exist accompanying
CNA methods which are often pattern based. Furthermore, DevOps
principles are taken more and more into consideration as well.
Each of these CNA topics (principles, architecture, methods and
resulting properties) are influencing each other. However, some
topics and their interdependencies are reflected more intensively
than other topics. We will discuss this in following Section 3.3 .
Additionally, we will propose a definition which takes all identified
literature into consideration systematically and relate it to already
existing and well defined terms (see Section 5 ).
3.3. Existing trends in cloud-native engineering [RQ3]
According to Fig. 5 b, most research focus lays on principles
how to design cloud-native applications. The most focused detail
topic is to operate cloud-native applications on top of automation
platforms . These kind of platforms are named elastic platforms
by Fehling et al. (2014) . In industry we see this trend as well.
There is currently a lot of interest in platforms like Apache Mesos,
Kubernetes, Docker Swarm and so on.
Another important focus can be seen in appropriate architec-
tures of cloud-native applications. An intensively focused detail
topic is how to create an appropriate design of a cloud-native
application. Most authors focus service-based approaches in this
context. Especially microservice based approaches are mentioned
more and more often. There exist very interesting papers dealing
with the trend to use microservice based approaches in cloud-
native application engineering ( Pahl and Jamshidi, 2016; Balalaie
et al., 2015 ). However, the question remains whether microservices
are something new or just a specific (maybe more pragmatic)
approach of the service oriented architecture approach (SOA). This
contribution can only state that the term microservice is correlated
to the term “cloud-native”. SOA is almost not mentioned explicitly
in “cloud-native” papers. It is to mention that Leymann et al. use
the term SOA (and seem to avoid the term microservices). The
authors’ opinion is, that service-based approaches are vital for
cloud-native approaches. It might be of minor relevance whether
a service is “micro” or not. However, accompanying the term
microservice there is an increasing focus on container technologies
as well in industry. The interest is mainly due to the opportunity
to create self-contained deployment units in a standardized form.
The correlation of research topics is interesting as well (see
Fig. 7 ). CNA design seems to be highly correlated with patterns . The
same is true for microservices and deployment units. Automation
platforms are often mentioned beside architectural topics like mi-
croservices, service composition , and deployment units . Furthermore,
CNA properties like scalability, resiliency and elasticity are men-
tioned very often in the same papers. So, automation platforms are
seen by a lot of authors as an enabler to realize sustainable CNA
architectures . The design of sustainable CNA architectures seems
to be influenced deeply by pattern based approaches and relies
on microservices being build on self-contained deployment units
(containers). Furthermore, microservices and CNA properties like
scalability, resiliency and elasticity are mentioned very often in the
same papers. So, automation platforms, microservices and pattern
based approaches seem to be seen as key enablers for cloud-native
applications.
3.4. Promising research directions [RQ4]
Fig. 6 shows, that there is a clear focus on solution proposals
in research dealing with cloud-native application engineering. The
proposals cover mainly principles and architectures how to build
cloud-native applications. A mature research domain would be
based on a lot of systematic validations/evaluations and concrete
experiences leading to solution proposals. Solution proposals
would be reflected by a lot of validation/evaluation studies. The
complete research would be reflected by a lot of survey studies
which might end in new insights. Looking at Fig. 6 , we see that
this maturity seems not to be reached so far in cloud-native ap-
plication research. Insights in shortcomings of existing approaches
are derived mainly from experience reports focusing CNA princi-
ples and architectures. Methods and properties of CNA applications
seem a bit underrepresented by solution proposals. Systematic
evaluation and validation research seems to be underrepresented
so far and focused on CNA principles and use cases . Most papers
present solution proposals focusing CNA principles or architectures .
N. Kratzke, P.-C . Quint / The Journal of Systems and Software 126 (2017) 1–16 11
Tabl e 6
Open research topics (without claim to be complete).
Topic Id Valuable research directions
CNA principles PRINC.1 Design of elastic intermediary platforms for
multi-cloud scenarios.
PRINC.2 Transferability of CNA for hybrid or multi-cloud
scenarios (deeply related to ARCH-1/2).
CNA methods METH.1 Long term implications of DevOps/microservice
based engineering methodologies.
METH.2 CNA specific engineering methodologies
(intentionally covering elasticity).
METH.3 Compositional programming languages for
CNA.
CNA architecture ARCH.1 Reference models for CNA.
ARCH.2 Standardization of elastic intermediary
platforms.
ARCH.3 Integration of isolated trends (service,).
CNA properties PROP.1 Elasticity of stateful CNA components.
PROP.2 Synchronizing platform and application
elasticity.
PROP.3 Security engineering for (multi-cloud) CNA.
So, solution proposals are very often derived from concrete use
cases or experience reports but not from systematic evaluations
or validations. Architecture, methods and properties are almost not
covered by validation studies. The same is true for survey studies .
So, from authors’ point of view, there is room for research in these
underrepresented fields (see Fig. 6 ). However, we will cover this
aspect in Section 4 in more details.
4. Engineering trends and possible future directions [RQ4]
So far, we mainly have done a quantitative and comparative
analysis on the identified paper population. In this Section we
investigate identified cloud-native research on a qualitative (so
with regards to content) basis. We do this by discussing research
implications of identified CNA principles, CNA architectures, CNA
methods, and CNA properties. That enables us to identify some
open research topics (denoted as (TOPIC.NR) in text) which are
listed in Table 6 and will be discussed in following sections.
4.1. Research implications of CNA principles
We identified a trend to operate CNA not directly on IaaS
infrastructures but on intermediary elastic platforms ( Fehling
et al., 2014; Kratzke and Peinl, 2016 ). This simplifies engineering,
deploying and operating of CNAs and leverages softwareization of
infrastructure and networks. It even contributes to more economic
operation of CNAs ( Cockcroft, 2015 ). This has been done in past
research often via specialized PaaS platforms ( Garca-Gmez et al.,
2012; Colombo-Mendoza et al., 2014 ) but these platforms have
the tendency to create platform lock-ins ( Opara-Martins et al.,
2016 ). So, in recent years there is a trend to encapsulate arbitrary
software in standardized and self-contained deployment units
(containers) and to operate these units on container clusters like
Apache Mesos, Kubernetes, Docker Swarm ( Brewer, 2015; Peinl
et al., 2016 ). However, we found little studies focusing how to
design and build such kind of intermediary elastic platforms
(PRINC-1) . We will cover this aspect in Section 4.3 in more details.
Another often mentioned principle is the migrateability of
CNAs. A lot of fruitful research has been done for the question
how existing legacy applications can be migrated to cloud en-
vironments and how these applications must be transformed
to be “cloud-native” ( Balalaie et al., 2015; Jamshidi et al., 2015;
Balalaie et al., 2016a ). However, this obviously focus no systems
intentionally designed for the cloud. Other interesting approaches
focus how to design applications to be deployable to arbitrary en-
vironments often including but not limited to cloud-environments
( Vasconcelos et al., 2015; Wettinger et al., 2014 ). But interop-
erability or portability in hybrid or multi-cloud scenarios
(PRINC-2) seems to be only considered by single case or survey
studies so far ( Ben Belgacem et al., 2013; Petcu and Vasilakos,
2014 ). But exactly this would be necessary to overcome vendor
lock-in vulnerabilities of CNAs ( Opara-Martins et al., 2016 ).
4.2. Research implications of CNA methodologies
A lot of studies report about trends to use microservices ( Stine,
2015; Balalaie et al., 2015; Jamshidi et al., 2015; Brunner et al.,
2015; Balalaie et al., 2016; Hasselbring, 2016 ), to use DevOps
( Familiar, 2015; Balalaie et al., 2016 ) or to make use of soft-
wareization ( Taleb et al., 2016; Nikaein, 2015; Krieger et al., 2016;
Housfater et al., 2014; Moldovan et al., 2014; Wang et al., 2015 )
to realize and operate