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

Abstract

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.

Full text

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 insufficient 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 insufficient 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 CNAs pragmatically. These trends seem
to be widely accepted and preferred. However, microservices,
DevOps and softwarization shift more realizing autonomy to small
development and operation teams. Especially the microservices
approach motivates this intentionally ( Stine, 2015 ). But we found
no study that dealt with the consequences. Microservice fol-
lowers often cite Conways Law.
2 However, according to this law
the organizational (two pizza
3
) structures coming along with
microservices and DevOps principles should lead to more hetero-
geneous service realizations which only focus singular problems.
The microservice intent is to solve these singular problems well
and in a massively horizontal scalable and elastic way. Large scale
systems are composed of these independently replaceable com-
ponents. But according to Conway ( Conway, Melvin E., 1968 ) this
should result in increased heterogeneity (which most other ap-
proaches would like to restrict). One may even ask if microservices
and DevOps are “eating” top down engineering methodologies?
It would be interesting to investigate what the long term
implications of these autonomous engineering approaches
are (METH.1). It seems likely that resulting systems might have
the tendency to become hardly maintainable on the long term.
Most existing microservice based systems are still very young
systems nowadays. So, the long term effects of these engineering
methodologies might not be observed so far.
A lot of CNA methodologies are pattern based ( Fehling et al.,
2014; Erl et al., 2015; Stine, 2015; Balalaie et al., 2016a; An-
drikopoulos et al., 2012 ). Patterns are a well accepted and proven
engineering methodology in software engineering. This insight has
been transferred to CNA engineering as well. It is better not to
reinvent the wheel but to rely on proven solutions that have been
working in past. So, existing engineering methodologies are taken
and combined with cloud specific patterns. This seems obvious.
However, systems of the past were seldom elastic systems. So,
there might be the need for some CNA specific engineering
methodologies (METH.2) covering CNA specific problems (namely
elasticity).
4.3. Research implications of CNA architectures
Components of CNAs are often realized as containers
( Peinl et al., 2016 ). These self-contained deployment units are
operated on elastic platforms. Popular elastic container platforms
2 “Organizations which design systems [...] are constrained to produce de-
signs which are copies of the communication structures of these organizations.”
Conway, Melvin E. (1968)
3 According to rumors, Amazon has a rule that a software engineering team
should not be larger than its hunger can be satisfied by two pizzas. This “two pizza
rule” is often mentioned by practitioners.

12 N. Kratzke, P.- C. Quint / The Journal of Systems and Software 12 6 (2017) 1–16
are Google’s Kubernetes, Apache Mesos, Docker Swarm, to name a
few. These platforms can be deployed across different cloud service
providers ( Kratzke and Peinl, 2016 ) and therefore reducing vendor
lock-in effects (see Opara-Martins et al., 2016 ). However, a CNA
developed for Kubernetes is not deployable on Mesos or on Swarm
without further engineering effort s. There exist standardization
initiatives for containers and there should be standardization
initiatives for elastic container platforms (ARCH-2) as well.
Furthermore, CNA engineers use these elastic platforms to
encapsulate deployment unit heterogeneity. To handle this het-
erogeneity of CNA components, we see some dominating major
requirements.
1. The necessity to standardize packaging these components into
standardized self-contained deployment units is mentioned
by a lot of studies ( Stine, 2015; Inzinger et al., 2014; Balalaie
et al., 2015; Peinl et al., 2016; Brewer, 2015; Brunner et al.,
2015 ). Technically this is solved using containers and operating
system virtualization. Notably Docker has established here a de
facto standard.
2. There is the necessity to interface these heterogeneous but
standardized deployable services with scalable and simple
communication means . This is often done via REST-based APIs
transferring arbitrary but JSON-serialized data. This seems to
exploit existing internet infrastructures in a very pragmatic way
to build distributed, large scale, massively (horizontal) scalable
and elastic cloud systems. In fact it seems that this is the main
CNA component composition approach ( Stine, 2015; Peinl et al.,
2016; Balalaie et al., 2016a; Mazmanov et al., 2013; Serrano
et al., 2013 ).
3. These services shall be loosely coupled by events or by data .
Event coupling is often realized via messaging solutions (e.g.
AQMP standard). Data coupling is realized using various scal-
able but (mostly) eventual consistent storage solutions (which
are often subsumed as NoSQL databases). These storage solu-
tions are used to isolate states to simplify scalable system de-
signs of (large parts of) these systems ( Fehling et al., 2014; Erl
et al., 2015; Andrikopoulos et al., 2013 ).
All trends (see Table 7 ) can be seen as isolated trends . How-
ever, according to practitioners they fit very well together and
support in a “natural way” to build massively scalable and large
scale systems which are more and more often called “cloud-
native applications”. But we found almost no studies focusing the
integration aspects of these isolated trends (ARCH-3) .
Furthermore, although these trends are identifiable, they do not
seem to be accompanied by systematic evaluation or validation
research and they are hardly covered by integrated concepts or
reference models (ARCH-1) .
4.4. Research implications of CNA properties
According to our survey, a CNA shall have wishful CNA property
combination of horizontal scalability ( Cockcroft, 2015; Goldschmidt
et al., 2014 ), elasticity ( Moldovan et al., 2014; Inzinger et al., 2014 ),
and resiliency ( Taleb et al., 2016; Goldschmidt et al., 2014;
Hole, 2016; Ben Belgacem et al., 2013 ). A lot of research about
cloud-native applications is reported as solution proposals and
experience reports. However, systematic evaluation and validation
of postulated effects seems to be rare.
Elasticity is often aligned to microservice based approaches.
And microservices are relying heavily on stateless services. But
stateless services can be scaled up and down easily from a dis-
tributed systems conceptual point of view. We found only little
research dealing with the elasticity of stateful CNA components
(PROP-1) which is the much harder problem.
Tabl e 7
Identified isolated engineering trends for CNA.
Trend Rationale
Microservices Microservices can be seen as a
“pragmatic” interpretation of SOA. In
addition to SOA microservice
architectures intentionally focus and
compose small and independently
replaceable horizontal scalable services
that are “doing one thing well”.
DevOps DevOps is a practice that emphasizes the
collaboration of software developers
and IT operators. It aims to build, test,
and release software more rapidly,
frequently, and more reliably using
automated processes for software
delivery.
Softwareization Softwareization of infrastructure and
network enables to automate the
process of software delivery and
infrastructure changes more rapidly.
Standardized deployment units Deployment units wrap a piece of
software in a complete filesystem
that
contains everything needed to run:
code, runtime, system tools, system
libraries. This guarantees that the
software will always run the same,
regardless of its environment.
Elastic platforms Elastic platforms like Kubernetes, Mesos,
Docker Swarm can be seen as a
middleware for the execution of
custom but standardized deployment
units. Elastic platforms extend resource
sharing and increase the utilization of
underlying compute, network and
storage resources.
State isolation Stateless components are easier to scale
up/down horizontally than stateful
components. Of course, stateful
components can not be avoided, but
stateful components should be reduced
to a minimum and realized by
intentional horizontal
scalable storage
systems (often eventual consistent
NoSQL databases).
Versioned REST APIs REST-based APIs provide scalable and
pragmatic communication means
relying mainly on already existing
internet infrastructure and well defined
and widespread standards.
Loose coupling Service composition is done by events or
by data. Event coupling relies on
messaging solutions (e.g. AQMP
standard). Data coupling relies often on
scalable but (mostly) eventual
consistent storage solutions (which are
often subsumed as NoSQL databases).
Although, we did not investigate elasticity research in details,
we got the impression that elasticity should be investigated on
two layers . A platform (e.g. Kubernetes) can be elastic, and a CNA
being operated on a platform (e.g. on Kubernetes) can be elastic
as well. But most of the times, elasticity seems to be investigated
on an application level only. And to the best of our knowledge
we do not know any study dealing the synchronization of both
levels (PROP-2) .
Finally, we did not identify at least one study covering security
aspects of CNA as major object of investigation. This might have
to do with our search filters. However, we think this should be a
relevant aspect for ongoing research as well (PROP-3) .

N. Kratzke, P.-C . Quint / The Journal of Systems and Software 126 (2017) 1–16 13
5. Definition proposal for CNA [RQ2]
Previous Section 4 showed that there are open questions re-
garding CNA engineering and research. Furthermore, our literature
review did not turn up a common definition that explains what
a cloud-native application exactly is.
4 Nevertheless, our survey
identified enough studies which can be used to derive a definition
proposal for CNA because there is a common but unconscious
understanding across several relevant studies.
Fehling et al. propose that a cloud-native application should
be IDEAL, so it should have an [i]solated state , is [d]istributed
in its nature, is [e]lastic in a horizontal scaling way, operated via
an [a]utomated management system and its components should
be [l]oosely coupled ( Fehling et al., 2014 ). According to Stine
( Stine, 2015 ) there are common motivations for cloud-native appli-
cation architectures like to deliver software-based solutions more
quickly (speed) , in a more fault isolating, fault tolerating, and au-
tomatic recovering way (safety) , to enable horizontal (instead of
vertical) application scaling (scale) , and finally to handle a huge di-
versity of (mobile) platforms and legacy systems (client diversity) .
These common motivations are addressed by several application
architecture and infrastructure approaches ( Balalaie et al., 2016c ):
•Microservices represent the decomposition of monolithic (busi-
ness) systems into independently deployable services that do
“one thing well” ( Newman, 2015; Namiot and Sneps-Sneppe,
2014 ).
•The main mode of interaction between services in a cloud-
native application architecture is via published and versioned
APIs (API-based collaboration) . These APIs are often HTTP
based and follow a REST-style with JSON serialization, but other
protocols and serialization formats can be used as well.
•Single deployment units of the architecture are designed and
interconnected according to a collection of cloud-focused
patterns like the twelve-factor app collection ( Adam Wig-
gins, 2014 ), the circuit breaker pattern ( Martin Fowler, 2014a ) or
cloud computing patterns ( Fehling et al., 2014; Erl et al., 2015 ).
•And finally, self-service agile infrastructure platforms are
used to deploy and operate these microservices via self-
contained deployment units (containers). These platforms pro-
vide additional operational capabilities on top of IaaS infras-
tructures like automated and on-demand scaling of applica-
tion instances, application health management, dynamic rout-
ing, load balancing and aggregation of logs and metrics.
These aspects lead us to the following definition:
A cloud-native application (CNA) is a distributed, elastic
and horizontal scalable system composed of (micro)services
which isolates state in a minimum of stateful components.
The application and each self-contained deployment unit of
that application is designed according to cloud-focused de-
sign patterns and operated on a self-service elastic platform.
Of course this definition can only be understood in a context
of further terms already defined or characterized by other authors
and standardizing initiatives:
•Elasticity is “the degree to which a system is able to adapt to
workload changes by provisioning and de-provisioning resources in
4 Except our own contribution ( Kratzke and Peinl, 2016 ) which relies partly on
this mapping study. The reader might want to consider ( Kratzke and Peinl, 2016 ) to
get a complete picture.
an autonomic manner, such that at each point in time the avail-
able resources match the current demand as closely as possible”
and has been already defined by Herbst et al. (2013) .
•Scalability can be differentiated to “structural scalability and
load scalability. Structural scalability is the ability of a system to
expand in a chosen dimension
5 without major modifications to its
architecture. Load scalability is the ability of a system to perform
gracefully as the offered traffic increases” ( Bondi, 20 0 0 ).
•Microservices are understood as an architectural style to de-
velop “a single application as a suite of small services, each
running in its own process and communicating with lightweight
mechanisms, often an HTTP resource API. These services are built
around business capabilities and independently deployable by fully
automated deployment machinery. There is a bare minimum of
centralized management of these services, which may be written
in different programming languages and use different data storage
technologies” ( Martin Fowler, 2014b ).
•Self-contained deployment unit is understood as “a part of the
application’s deployment topology for realizing a specific technical
unit” ( Inzinger et al., 2014 ) . More and more often a deployment
unit is understood as “a standard container. The goal of a stan-
dard container is to encapsulate a software component and all its
dependencies in a format that is self-describing and portable, so
that any compliant runtime can run it without extra dependen-
cies, regardless of the underlying machine and the contents of the
container”. This is the understanding of the Open Container Ini-
tiative (OCI) which is explained in the 5 principles of standard
containers ( Open Container Initiative, 2015 ).
•Stateful components are used for “multiple instances of a
scaled-out application component [to] synchronize their internal
state to provide a unified behavior” ( Fehling et al., 2014 ).
•Elastic platform is understood as a “middleware for the ex-
ecution of custom applications, their communication, and data
storage is offered via a self-service interface over a network”
( Fehling et al., 2014 ).
6. Conclusion
Although the first considerations on cloud-native applications
originate from research, the term “cloud-native” seems to be more
and more accepted and used – maybe even dominated –by soft-
ware and cloud industry nowadays. We identified interesting but
isolated trends in cloud systems engineering (see Table 7 ). If sev-
eral of these trends are applied in parallel resulting software sys-
tems are rated more and more often as “cloud-native applications”.
Such cloud-native applications are not just distributed systems.
They are “very” distributed, horizontal scalable, resilient and load
adaptive (elastic) systems coming along with specific challenges.
Our critical discussion of identified research showed, that
there is room and need for ongoing research. We identified some
promising future research directions (see Table 6 ) as well as
open questions. Applied microservice and DevOps engineering
methodologies are mainly bottom-up approaches shifting software
design autonomy to plenty of small teams. All this result in more
heterogeneity of components. This is astonishing, because most
engineering methodologies are used to reduce heterogeneity for a
better manageability. The long term effects of these autonomous
engineering approaches are hardly investigated so far. Even the
existing systems are quite young and the long term effects might
not be even observed.
However, our literature survey showed that there is a common
but unconscious understanding of cloud-native applications. A CNA
should be build according to corresponding CNA principles (being
5 horizontally in case of CNA.

14 N. Kratzke, P.- C . Quint / The Journal of Systems and Software 126 (2017) 1–16
operated on automation platforms, enabling softwareization of
infrastructure and network, having migration and interoperability
aspects in mind). CNA architectures are more and more often
microservice based. Proposed CNA development methodologies are
often pattern-based (relying on comprehensive cloud computing
pattern catalogs ( Fehling et al., 2014; Erl et al., 2015 )) and take
DevOps principles into consideration. We could even derive a
definition proposal for the term “cloud-native application” and we
explained its relationship to well established terms in the context
of distributed systems. We think our proposal contributes to a
more precise understanding of the term “cloud-native”. Especially
if this definition proposal is compared with the often heard
but vacuous sentence: “Cloud-native applications are intentionally
designed for the cloud.”
Acknowledgments
This study was funded by German Federal Ministry of Edu-
cation and Research (Project Cloud TRANSIT, 03FH021PX4). We
would like to thank our reviewers who contributed valuable and
very constructive feedback. Furthermore, we thank Dr. Adersberger
from QAWARE GmbH. He inspired us with his MEKUNS approach
(Mesos, Kubernetes Cloud-native Stack) and his considerations
about cloud-native applications from a practitioner point of
view. And we thank René Peinl for his valuable contributions
accompanying our research.
References
Adam Wiggins, 2014. The twelve-factor App . Last access 2016-02-14. http://12factor.
net/
Andrikopoulos, V., Fehling, C., Leymann, F., 2012. Designing for CAP - the effect of
design decisions on the CAP properties of cloud-native applications. In: Pro-
ceedings of the 2nd International Conference on Cloud Computing and Services
Science, pp. 365–374. doi: 10. 52 20 /0 0 03931503650374 .
Andrikopoulos, V., Strauch, S., Fehling, C., Leymann, F., 2013. CAP-oriented design
for cloud-native applications. 2nd International Conference on Cloud Computing
and Services Science, CLOSER 2012. Springer International Publishing, pp. 215–
229 . doi: 10.100 7/ 978- 3- 319- 04519- 1 _ 14 .
Balalaie, A. , Heydarnoori, A. , Jamshidi, P. , 2015. Migrating to cloud-native architec-
tures using microservices: an experience report. In: European Conference on
Service-Oriented and Cloud Computing. Springer, pp. 201–215 .
Balalaie, A ., Heydarnoori, A ., Jamshidi, P., 2016. Migrating to cloud-native architec-
tures using microservices: an experience report. Advances in Service-Oriented
and
Cloud Computing: Workshops of ESOCC 2015, Taormina, Italy, September
15-17, 2015, Revised Selected Papers. Springer International Publishing, pp. 201–
215 . doi: 10. 1007/ 97 8- 3- 319- 33313-7 _ 15 .
Balalaie, A ., Heydarnoori, A ., Jamshidi, P., 2016. Migrating to cloud-native architec-
tures using microservices: an experience report. Advances in Service-Oriented
and Cloud Computing: Workshops of ESOCC 2015, Taormina, Italy, Septem-
ber 15–17, 2015, Revised Selected Papers. Springer International Publishing,
pp. 201–215 . doi: 10.100 7/ 978- 3- 319- 33313-7 _ 15 .
Balalaie, A. , Heydarnoori, A. , Jamshidi, P. , 2016. Microservices architecture enables
devops: migration to a cloud-native architecture. IEEE Softw. 33, 42–52 .
Balalaie, A. , Heydarnoori, A. , Jamshidi, P. , 2016. Microservices architecture enables
DevOps migration to a cloud-native architecture. IEEE Softw. 33 (3), 42–52 .
Baldini, I., Castro, P., Cheng, P. , Fink, S., Ishakian, V., Mitchell, N., Muthusamy, V.,
Rabbah, R., Suter, P., 2016. Cloud-native, event-based programming for mo-
bile applications. In: Proceedings of the International Conference on Mobile
Software Engineering and Systems. ACM, New Yor k, NY, USA, pp. 287–288.
doi: 10. 1145/2897073 .2897713 .
Ben Belgacem, M., Hafsi, H., Abdennadher, N., 2013. A hybrid grid/cloud distributed
platform: a case study. Grid and Pervasive Computing: 8th International Con-
ference, GPC 2013 and Colocated Workshops, Seoul, Korea, May 9–11, 2013.
Proceedings. Springer Berlin Heidelberg, Berlin, Heidelberg, pp. 162–169 . doi:
10.1007/978 - 3- 642- 38027- 3 _ 17 .
Bondi, A.B., 20 0 0. Characteristics of scalability and their impact on performance. In:
Proceedings of the 2nd International Workshop on Software and
Performance.
ACM, New York, NY, USA, pp. 195–203. doi: 10 .1145 /3 50 391. 350432 .
Bourque, P., Fairley, R.E. (Eds.), 2014. SWEBOK: Guide to the Software Engineering
Body of Knowledge. IEEE Computer Society, Los Alamitos, CA. version 3.0 edi-
tion.
Brewer, E., 2012. CAP twelve years later: how the ”rules” have changed. Computer
45 (2), 23–29. doi: 10.1109/MC.2012. 37 .
Brewer, E.A., 20 0 0. Towards robust distributed systems (keynote). In: Proceedings
of the 19th Annual ACM Symposium on Principles of Distributed Computing
(PODC ’00). ACM, New Yo rk , NY, USA, p. 7. doi: 10.1145/ 34 347 7.3435 02 .
Brewer, E.A., 2015. Kubernetes and the path to cloud native. In: Proceedings of the
Sixth ACM Symposium on Cloud Computing. ACM, New York, NY, USA . 167–167.
doi: 10 .1145/2806777.28099 55 .
Brunner, S., Blöchlinger, M., Toffett i, G., Spillner, J., Bohnert, T.M., 2015. Experimen-
tal evaluation of the cloud-native application design. In: 8th IEEE/ACM Interna-
tional Conference on Utility and Cloud Computing, UCC 2015, Limassol, Cyprus,
December 7-10, 2015, pp. 4 88–4 93. doi: 10.1109/UCC.2015. 87 .
Cockcroft, A., 2015. Cloud native cost optimization. In: Proceedings of the 6th
ACM/SPEC International Conference on Performance Engineering. ACM, New
York, NY, USA . 109–109. doi: 10.1145/266 89 30 .2693197
.
Colombo-Mendoza, L.O., Alor-Hernández, G., Rodríguez-gonzález, A., Valencia-
garcía, R., 2014. Mobicloup!: a paas for cloud services-based mobile applica-
tions. Autom. Softw. Eng. 21 (3), 391–437. doi: 10.1007/s10515- 014- 0143- 5 .
ConwayMelvin E. , 1968 . How do committees invent? Datamation 14 (5), 28–31 .
Dutta, S., Taleb, T., Ksentini, A., 2016. QoE-aware elasticity support in cloud-native
5G systems. In: 2016 IEEE International Conference on Communications (ICC),
pp. 1–6. doi: 10.1109/ IC C. 2016.7 511377 .
Erl, T. , Cope, R. , Naserpour, A. , 2015. Cloud Computing Design Patterns. Springer .
Familiar, B., 2015. Service fabric. Microservices, IoT, and Azure: Leveraging DevOps
and Microservice
Architecture to Deliver SaaS Solutions. Apress, Berkeley, CA,
pp. 165–182 . doi: 10.1007/978- 1- 4842- 127 5- 2 _ 8 .
Fehling, C. , Leymann, F. , Retter, R. , Schupeck, W. , Arbitter, P. ,2014. Cloud Computing
Patterns. Springer .
Fox, A. , Brewer, E.A. , 1999. Harvest, yield, and scalable tolerant systems. In: Proceed-
ings of the The 7th Workshop on Hot Top ic s in Operating Systems (HOTOS99).
IEEE Computer Society, Wash ington, DC, USA, pp. 174 –179 .
Fox, A., Gribble, S.D., Chawathe, Y., Brewer, E.A., Gauthier, P., 19 97. Cluster-based
scalable network services. SIGOPS Oper. Syst. Rev. 31 (5), 78–91. doi: 10 .1145 /
269005.266662 .
Garcia-Gomez, S. , Jimenez-Ganan, M. , Taher, Y. , Momm, C. , Junker, F. , Biro, J. , Meny-
chtas, A. , Andrikopoulos, V. , Strauch, S. , 2012. Challenges for the comprehensive
management of cloud services in a PaaS framework. Scalable Comput. Pract. Ex-
perience 13 (3),
201–213 .
Garca-Gmez, S., Escriche-Vicente, M., Arozarena-Llopis, P., Lelli, F., Taher, Y.,
Momm, C., Spriestersbach, A., Vogel, J., Giessmann, A., Junker, F., Jimnez-
Ga’n, M., Biro, J., Jeune, G.L., Dao, M., Carrie, S.P., Niemoller, J., Mazmanov, D.,
2012. 4caast: comprehensive management of cloud services through a paas. In:
2012 IEEE 10th International Symposium on Parallel and Distributed Processing
with Applications, pp. 4 94–4 99. doi: 10.1109/ISPA .2 012.72 .
Goldschmidt, T., Jansen, A., Koziolek, H., Doppelhamer, J., Breivold, H.P., 2014. Scal-
ability and robustness of time-series databases for cloud-native monitoring of
industrial processes. In: 2014 IEEE 7th International Conference on Cloud Com-
puting, pp. 602–609. doi: 10.1109/CLOUD.2014 .8 6 .
Hasselbring, W., 2016. Microservices for scalability: keynote talk abstract. In: Pro-
ceedings of the 7th ACM/SPEC on International Conference on Performance En-
gineering. ACM, New Yo rk , NY, USA, pp. 133–134. doi: 10.1145/2851553 .2 85 86 59 .
Herbst, N.R. , Kounev, S. , Reussner, R. , 2013. Elasticity in cloud computing: what it
is, and what it is not. In: Proceedings of the 10t h International Conference on
Autonomic Computing (ICAC 13). USENIX, San Jose, CA, pp. 23–27 .
Hole, K.J., 2016. Toward an anti-fragile e-government system. Anti-fragile
ICT Systems. Springer International Publishing, pp. 57–65 . doi: 10.1007/
978- 3- 319-
30070- 2 _ 6 .
Housfater, A.S. , Aslam, M.S. , Gupta, D. , Meraji, S. , Bennis, R. , 2014. Acceleration
of cloud computing. In: Proceedings of 24th Annual International Conference
on Computer Science and Software Engineering. IBM Corp., Riverton, NJ, USA,
pp. 297–298 .
Inzinger, C., Nastic, S., Sehic, S., Vögler, M., Li, F. , Dustdar, S., 2014. Madcat: A
methodology for architecture and deployment of cloud application topologies.
In: Service Oriented System Engineering (SOSE), 2014 IEEE 8th International
Symposium on, pp. 13–22. doi: 10.1109/SOSE.2014 .9 .
Jamshidi, P., Pahl, C., Chinenyeze, S., Liu, X., 2015. Cloud migration patterns: a
multi-cloud service architecture perspective. Service-Oriented Computing -
ICSOC 2014 Workshops: WESOA; SeMaPS, RMSOC, KASA, ISC, FOR-MOVES,
CCSA and Satellite Events, Paris, France, November 3-6, 2014, Revised Selected
Papers. Springer International Publishing, pp. 6–19 . doi: 10.10 07/
978- 3- 319- 22885- 3 _ 2 .
Kitchenham, B. , Charters, S. , 2007. Guidelines for Performing Systematic Literature
Reviews in Software Engineering. Technical Report EBSE 20 07-0 01. Keele Uni-
versity and Durham University Joint Report .
Kratzke, N., Peinl, R., 2016. ClouNS - a cloud-native application reference model
for enterprise architects. In: 2016 IEEE 20th International Enterprise Distributed
Object Computing Workshop (EDOCW), pp. 1–10. doi: 10.1109/EDOCW.2016 .
7584353 .
Kratzke, N. , Quint, P.- C. , Palme, D. , Reimers, D. , 2017. Project cloud TRANSIT - or
to simplify cloud-native application provisioning for SMEs by integrating al-
ready available container technologies. In: Kantere, V., Koch, B. (Eds.), European
Project Space on Smart Systems, Big Data, Future Internet - Towards Serving the
Grand Societal Challenges. SCITEPRESS . In print.
Krieger, M.T., Tor reno, O., Trelles, O., Kranzlmüller, D., 2016. Building an open source
cloud environment with auto-scaling resources for executing bioinformatics and
biomedical workflows. Future Gen. Comput. Syst. doi: 10. 1016/j.fu tu re .2 016. 02 .
008 .
Leymann, F. , Fehling, C.
, Wagner, S. , Wettinger, J. , 2016. Native cloud applications:
why virtual machines, images and containers miss the point!. In: Proceedings
of the 6th International Conference on Cloud Computing and Service Science
(CLOSER 2016). SciTePress, pp. 7–15 .

N. Kratzke, P.-C . Quint / The Journal of Systems and Software 126 (2017) 1–16 15
Mann, A., Watt, G., Matthews, P. , 2013. Opportunities to innovate today. The Innova-
tive CIO: How IT Leaders Can Drive Business Transformation. Apress, Berkeley,
CA, pp. 103–125 . doi: 10.10 07 /978- 1- 4302- 4411- 0 _ 6 .
Martin Fowler, 2014. Circuit breaker . Last access 2016-05-27. http://martinfowler.
com/bliki/CircuitBreaker.html
Martin Fowler, 2014. Microservices - a definition of this new architectural term . Last
access 2016-05-27. http://martinfowler.com/articles/microservices.html
Mateljan, V. , Cisic, D. , Ogrizovic, D. , 2010. Cloud database-as-a-service (daas)
- roi. In: MIPRO, 2010 Proceedings of the 33rd International Convention,
pp. 1185– 118 8 .
Mazmanov, D., Curescu, C., Olsson, H., Ton, A., Kempf, J., 2013. Handling performance
sensitive native cloud applications with distributed cloud computing and sla
management. In: Utility and Cloud Computing (UCC), 2013 IEEE/ACM 6th In-
ternational Conference on, pp. 470–475. doi: 10.1109/UCC.2013. 92 .
Mell, P. , Grance, T., 2011. The NIST Definition of Cloud Computing. National Institute
of Standards and Technology doi: 10.6028/NIST.SP.800-145 .
Missbach, M., Staerk, T., Gardiner, C., McCloud, J., Madl, R., Tempes, M., Anderson, G.,
2016. The hybrid cloud. SAP on the Cloud. Springer Berlin Heidelberg, Berlin,
Heidelberg, pp. 153– 164 . doi: 10.10 07/97 8- 3- 662- 47418- 1 _ 7 .
Moldovan, D., Copil, G., Truong, H.-L., Dustdar, S., 2014.
QUELLE –a framework for
accelerating the development of elastic systems. Service-Oriented and Cloud
Computing: Third European Conference, ESOCC 2014, Manchester, UK, Septem-
ber 2-4, 2014. Proceedings. Springer Berlin Heidelberg, Berlin, Heidelberg,
pp. 93–107 . doi: 10. 1007/97 8- 3- 662- 44879- 3 _ 7 .
Namiot, D. , Sneps-Sneppe, M. , 2014. On micro-services architecture. Int. J. Open Inf.
Technol. 2 (9), 24–27 .
Newman, S. , 2015. Building Microservices. O’Reilly Media, Incorporated .
Nikaein, N., 2015. Processing radio access network functions in the cloud: critical
issues and modeling. In: Proceedings of the 6th International Workshop on
Mobile Cloud Computing and Services. ACM, New Yo rk , NY, USA, pp. 36–43.
doi: 10. 1145/2802130.2802136 .
Nikaein, N. , Schiller, E. , Favraud, R. , Knopp, R. , Alyafawi, I. , Braun, T. ,2016. To-
wards a cloud-native radio access network. Studies in Big Data. Springer, 2016,
pp. 171–202 .
Opara-Martins, J., Sahandi, R., Tian, F., 2016. Critical analysis of vendor lock-in and
its impact on cloud computing migration: a business perspective. J. Cloud Com-
put. 5 (1), 1–18. doi: 10.1186/s1367 7- 016- 0054- z .
Open Container Initiative , 2015. Open container runtime specification . Last access
2016-05-27
Pahl, C., Jamshidi, P. , 2016. Microservices: a systematic mapping study. In: Proceed-
ings of the 6th International Conference on Cloud Computing and Services Sci-
ence, pp. 137–146. doi: 10.5220 /0 0 05785501370146 .
Peinl, R., Holzschuher, F., Pfitzer, F., 2016. Docker cluster management for the
cloud - survey results and own solution. J. Grid Comput. 1–18. doi: 10.10 07 /
s10723- 016- 9366- y .
Petcu, D. , Vasilakos, A.V. , 2014. Portability in clouds: approaches and research op-
portunities. Scalable Comput. Pract. Experience 15 .
Petersen, K. , Feldt, R. , Mujtaba, S. , Mattsson, M. ,2008. Systematic mapping studies
in software engineering. In: Proceedings of the 12th International Conference on
Evaluation and Assessment in Software Engineering. British Computer Society,
Swinton, UK, UK, pp. 68–77 .
Petersen, K., Vakkalanka, S., Kuzniarz, L., 2015. Guidelines for conducting systematic
mapping studies in software engineering: an update. Inf. Softw. Technol. 64, 1–
18. doi: 10.1016/j.infsof.2015.03.007 .
Roussev, V. , Barreto, A. , Ahmed, I. , 2016. Forensic acquisition of cloud drives. CoRR .
abs/1603.06542.
Roussev, V., McCulley, S., 2016. Forensic analysis of cloud-native artifacts. Digital In-
vestigation 16 (Supplement), 104–113 . DFRWS 2016 Europe—Proceedings of the
Third Annual DFRWS Europe. doi: 10.1016/ j. di in .2 016. 01.013 .
Sequeira, H., Carreira, P., Goldschmidt, T., Vorst, P., 2014. Energy cloud: real-time
cloud-native energy management system to monitor and analyze energy con-
sumption in multiple industrial sites. In: Proceedings of the 2014 IEEE/ACM 7th
International Conference on Utility and Cloud Computing. IEEE Computer Soci-
ety, Was hington, DC, USA, pp. 529–534. doi: 10.1109/UCC.2014. 79 .
Serrano, M., Shi, L., Foghlú, M.Ó., Donnelly, W., 2013. Cloud services composition
support by using semantic annotation and linked data. Knowledge Discov-
ery, Knowledge Engineering and Knowledge Management: Third International
Joint Conference, IC3K 2011, Paris, France, October 26-29, 2011. Revised Se-
lected Papers. Springer Berlin Heidelberg, Berlin, Heidelberg, pp. 278–293 . doi:
10.1007/978 - 3- 642- 37186- 8 _ 18 .
Srinivasan, A., Quadir, M.A., Vijayakumar, V., 2015. Era of cloud computing: a new
insight to hybrid cloud. Procedia Comput. Sci. 50, 42–51 . Big Data, Cloud and
Computing Challenges. doi: 10.1016 /j .procs.2015. 04 .0 59 .
Stine, M. , 2015. Migrating to Cloud-Native Application Architectures. O’Reilly
.
Suneja, S., Isci, C., Koller, R., de Lara, E., 2016. Touchless and always-on cloud ana-
lytics as a service. IBM J. Res. Dev. 60 (2–3), 11:1–11 : 10 . doi: 10.1147/J RD .2 016.
2518438 .
Taleb, T., Ksentini, A., Sericola, B., 2016. On service resilience in cloud-native 5G
mobile systems. IEEE J. Sel. Areas Commun. 34 (3), 4 83–4 96. doi: 10.1109/ JSAC.
2016.2525342 .
Varghese, S., 2015. Building go web applications on Google cloud. Web Development
with Go: Building Scalable Web Apps and RESTful Services. Apress, Berkeley, CA,
pp. 251–283 . doi: 10.10 07/97 8- 1- 4842- 1052- 9 _ 11 .
Vasconcelos, M., Mendonça, N.C., Maia,
P.H .M. , 2015. Cloud detours: a non-intrusive
approach for automatic software adaptation to the cloud. Service Oriented
and Cloud Computing: 4th European Conference, ESOCC 2015, Taormina, Italy,
September 15-17, 2015, Proceedings. Springer International Publishing, Cham,
pp. 181–195 . doi: 10.100 7/978- 3- 319- 24072- 5 _ 13 .
Wang, Z., Lu, Z., Wu, J., Fan, K., 2015. CPFirewall: a novel parallel firewall scheme
for FWaaS in the cloud environment. Advances in Services Computing: 9th Asia-
Pacific Services Computing Conference, APSCC 2015, Bangkok, Thailand, Decem-
ber 7-9, 2015, Proceedings. Springer International Publishing, Cham, pp. 121–
136 . doi: 10.1007/ 978- 3- 319- 26979- 5 _ 9
.
Wettinger, J. , Görlach, K. , Leymann, F. , 2014. Deployment aggregates - a generic
deployment automation approach for applications operated in the cloud. In:
Proceedings of the 18th International Enterprise Distributed Object Com-
puting Conference Workshops and Demonstrations. IEEE Computer Society,
pp. 17 3–18 0 .
Wieringa, R., Maiden, N., Mead, N., Rolland, C., 2005. Requirements engineering pa-
per classification and evaluation criteria: a proposal and a discussion. Requir.
Eng. 11 (1), 102–107. doi: 10 .10 07/s0 0766-0 05- 0 021-6 .
Wohlin, C., Runeson, P., da Mota Silveira Neto, P.A . , Engstrm, E., do Carmo
Machado, I., de Almeida, E.S., 2013. On the reliability of mapping studies in
software engineering. J. Syst. Softw. 86 (10), 2594–2610. doi: 10.1016 /j .j ss.2013.
04.076 .

16 N. Kratzke, P.- C . Quint / The Journal of Systems and Software 126 (2017) 1–16
Nane Kratzke is Professor for Computer Science and Business Information Systems at Lübeck University of Applied Sciences (Germany) and head of the cloud computing
research group at the Center of Excellence for Communication, Systems and Applications (CoSA). His main research is about cloud computing, cloud-native applications and
elastic container platforms. In his former industrial career he executed functions as enterprise architect for mission critical information systems and functions as project-
leader, software-architect and software engineer for military distributed real-time systems.
Peter-Christian Quint is research assistant for the cloud computing research group at the Center of Excellence for Communication, Systems and Applications (CoSA, Lübeck
University of Applied Sciences, Germany). His main research is about pragmatic cloud adaption focusing small and medium sized enterprises. He investigates tools and
techniques to optimize the integration of large scale distributed and cloud-deployed systems. In his former industrial career he was a software and quality engineer for
medical and health information systems.
View publication statsView publication stats