- Email: [email protected]
Understanding cloud-native applications after 10 years of cloud computing - A systematic mapping study
Accepted Manuscript
Understanding Cloud-native Applications after 10 Years of Cloud Computing - A Systematic Mapping Study Nane Kratzke, Peter-Christian Quint PII: DOI: Reference:
S0164-1212(17)30001-8 10.1016/j.jss.2017.01.001 JSS 9905
To appear in:
The Journal of Systems & Software
Received date: Revised date: Accepted date:
23 September 2016 30 November 2016 4 January 2017
Please cite this article as: Nane Kratzke, Peter-Christian Quint, Understanding Cloud-native Applications after 10 Years of Cloud Computing - A Systematic Mapping Study, The Journal of Systems & Software (2017), doi: 10.1016/j.jss.2017.01.001
This is a PDF file of an unedited manuscript that has been accepted for publication. As a service to our customers we are providing this early version of the manuscript. The manuscript will undergo copyediting, typesetting, and review of the resulting proof before it is published in its final form. Please note that during the production process errors may be discovered which could affect the content, and all legal disclaimers that apply to the journal pertain.
ACCEPTED MANUSCRIPT
Highlights • The outcomes of a systematic mapping study on cloud-native applications
CR IP T
(CNA) are presented. • Identified principles, architectures, and methodologies for CNA are explained.
• Existing engineering trends for cloud-native applications are summarized. • Research implications of existing CNA studies are discussed.
AC
CE
PT
ED
M
AN US
• Promising future research directions for CNA engineering are proposed.
1
ACCEPTED MANUSCRIPT
Understanding Cloud-native Applications after 10 Years of Cloud Computing - A Systematic Mapping Study
CR IP T
Nane Kratzke1 , Peter-Christian Quint eMail:{nane.kratzke,peter-christian.quint}@fh-luebeck.de L¨ ubeck University of Applied Sciences Center of Excellence for Communcation, Systems and Applications M¨ onkhofer Weg 239 23562 L¨ ubeck, Germany
AN US
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
M
(2006) which seems somehow obvious nowadays. But the term disappeared almost completely. Suddenly and in the last years the term is used again more
ED
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.
PT
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 publi-
CE
cations and already existing and well-defined terminology into account. Keywords: Cloud-native application, CNA, systematic mapping study, elastic
AC
platform, microservice, self service, pattern, softwareization 2016 MSC: 00-01, 99-00
1 Corresponding
author.
Preprint submitted to Journal of Systems and Software
January 5, 2017
ACCEPTED MANUSCRIPT
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
5
CR IP T
20062 ) 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. Although terms like public/private/hybrid cloud com-
puting 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
AN US
10
often understood in differing ways. Gladfully, the mentioned terms are defined precisely by the NIST definition of cloud computing [1]. But there remains confusion with more specific topics in cloud computing like cloud-native applications (CNA). This contribution investigates a more precise understanding of the term ”cloud-native”.
M
15
According to Figure 1 and Google trends the term ”cloud-native” has an unusual diffusion rate over time. In birthday times of cloud computing – so about
ED
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
PT
20
Google. But since 2015, the term is more and more frequently used again and gained momentum (see Figure 1). We have to admit that Google trends is not
CE
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 Figure 1 and Figure 5a). Furthermore, our data indicates that the current understand-
AC
25
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 2 https://aws.amazon.com/releasenotes/122
3
(last access 5th July 2016)
CR IP T
ACCEPTED MANUSCRIPT
Figure 1: Google trends (01.01.2006 until 22.05.2016) of the term ”cloud-native”
suddenly popular in industry, but not before 2015 (according to Google trends, see Figure 1). We assume this sudden rise in industry has to do with the cur-
AN US
30
rent 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. However, the reader will see, that ”cloud-native” concepts are reflected for a while in research. So, although the 35
term seems to be new, it is not. It simply never has been wide spread. How-
M
ever, some contributions providing valuable insights what additional properties an application must fulfill to be called ”cloud-native” compared with classical
ED
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 40
more precise with regard to the term ”cloud-native”.
PT
Therefore this contribution is outlined as follows: In Section 2 we will explain our systematic mapping and adaptive reading steps. Furthermore, we
CE
introduce our research questions and present our data. We make a comparative analysis of the data (main outcome of our systematic mapping study) regarding
45
our research questions in Section 3. We discuss existing strengths and weak-
AC
nesses 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
50
able to propose a definition for the term ”cloud-native” in Section 5 taking all
4
CR IP T
ACCEPTED MANUSCRIPT
Figure 2: Research process (a combination of the process for performing systematic mapping studies and systematic literature reviews.
in Section 6.
2. Research Methodology
AN US
identified literature into consideration systematically. We conclude our findings
We aligned our research according to general guidelines for systematic map55
ping studies in software engineering [2, 3] and for systematic literature reviews
M
[4]. Additionally, we took updates and critical reflections [5] on these guidelines into consideration. Systematic mapping studies and systematic literature
ED
reviews are analyzing primary studies. A primary study is ”an empirical study investigating a specific research question” [4]. Reviews and mapping studies 60
are so called secondary studies. A secondary ”study [...] reviews all the pri-
PT
mary studies relating to a specific research question with the aim of integrating/synthesizing evidence related to a specific research question” [4]. A system-
CE
atic literature review ”uses a well-defined methodology to identify, analyze and interpret all available evidence related to a specific research question in a way
65
that is unbiased and (to a degree) repeatable” [4]. Other than that, a scoping or
AC
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” [4]. According to guidelines for systematic maps and reviews in software engi-
neering, we used both approaches complementary [3]. Due to the insight that
70
”systematic maps can summarize and help transfer results to practitioners” [3] better, we decided to keep the focus on the systematic mapping process and used 5
ACCEPTED MANUSCRIPT
Table 1: Results (Papers might be listed in two or more sources) Oldest
Youngest
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
CR IP T
Papers
AN US
Electronic Source
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 out75
comes are mainly discussed in Section 4. The same is true for selecting relevant
M
papers to derive a definition proposal for cloud-native applications (see Section 5). This process combination is visualized in Figure 2 and explained in the following paragraphs. The second author of the study performed detailed quality
80
ED
control checks on each of these presented steps and intermediate outcomes. 2.1. Research Scope and Research Questions
PT
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.
CE
But cloud environments are elastic. Elasticity is understood as the degree to which a system adapts to workload changes by provisioning and de-provisioning
85
resources automatically. Over the time system engineers understand the elastic-
AC
ity options of modern cloud environments better and they intentionally designed systems for such elastic cloud infrastructures. This intention is often expressed using the term ”cloud-native”. Therefore, our literature review has been guided by the following research questions defining our research scope:
90
• [RQ1] Where does the term ”cloud-native” come from? 6
ACCEPTED MANUSCRIPT
Table 2: Inclusion and exclusion criteria Inclusion
application design, engineering or operation in broadest sense.
Exclusion
CR IP T
(1) Keynotes, conference papers, journal papers, books and book chapters dealing with cloud-native
(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)
AN US
(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,
M
keynote) (5) Publication language was not English.
ED
• [RQ2] Is there a common understanding of the term ”cloud-native”? • [RQ3] What are existing trends in cloud-native application engineering?
PT
• [RQ4] What promising trends for future cloud-native research and engi-
CE
neering can be deduced?
95
2.2. Conduct Search for Primary Studies So far, the terms ”cloud-native” or ”native cloud” are not very intensively
AC
used in literature. However, they show increasing momentum and are emerging from an evolutionary process starting with the service-oriented architecture approach, system virtualization, cloud computing, operating system virtualization
100
(aka container) and ending in a recently most popular approach: microservices. We conducted our search for studies in the electronic sources listed in Table 1 (according to recommendations for performing literature reviews in software 7
ACCEPTED MANUSCRIPT
engineering [2, 5]). We searched for contributions published in or after 2006 having the term ”cloud-native” or ”cloud native” in their title, abstract or key105
words. However, we did not perform a full text search. We argue, that the
CR IP T
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 110
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
AN US
to include relevant publications like [6]. These kind of publications would have otherwise fallen through our search filters. This would have become problematic especially in case of [6], which turned out to be one of the most valuable sources 115
in understanding cloud-native applications.
2.3. Screening of Papers for Inclusion and Exclusion
M
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
ED
relevant to answer our research questions.
Experience
Opinion
Survey
Solution
Evaluation
Title (shortened)
Year
Type
Cloud Computing Patterns
2014
Book
x
x
CE
[6]
Validation
ID
PT
Table 3: Included and categorized papers (unsorted to avoid any bias)
[7]
Cloud Computing Design Patterns
2015
Book
x
x
[8]
Migrating to Cloud-Native Application
2015
Book
x
x
2016
Journal
2016
Journal
2012
Conf.
AC
Architectures
[9]
[10]
On Service Resilience in Cloud-Native 5G
x
x
Mobile Systems Microservices Architecture Enables DevOps:
x
Migration to a Cloud-native Architecture [11]
Designing for CAP
8
x
ACCEPTED MANUSCRIPT
2014
Conf.
and Deployment of Cloud Applications [13]
Migrating to Cloud-Native Architectures
2016
Chapter
[14]
Scalability and Robustness of Time-series
2014
Conf.
Databases for Cloud-native Monitoring of
[15]
CAP-Oriented Design for Cloud-Native Applications
2013
Chapter
[16]
Docker Cluster Management for the Cloud
2016
Journal
[17]
Touchless and always-on cloud analytics as
2016
Journal
a service
x
x
x
AN US
Industrial Processes.
Experience
Madcat: A Methodology for Architecture
Opinion
[12]
Survey
Type
Solution
Year
Evaluation
Title (shortened)
CR IP T
ID
Validation
Continuation of Table 3: Included and categorized papers
x
x
x
x
x
Forensic analysis of cloud-native artifacts
2016
Journal
[19]
Forensic Acquisition of Cloud Drives
2016
Journal
x
x
[20]
Towards a Cloud-Native Radio Access
2016
Chapter
x
x
2015
Chapter
x
x
Microservices Migration Pattern
2016
Journal
x
x
Migrating to Cloud-native Architectures
2015
Conf.
[21]
Building Go Web Applications on Google
[23]
PT
Cloud [22]
ED
M
[18]
Network
x
x
x
x
x
CE
Using Microservices: An Experience Report Service Fabric
2015
Chapter
[25]
Processing Radio Access Network Functions
2015
Conf.
2015
Book
AC
[24]
[26]
[27]
x x
x
in the Cloud: Critical Issues and Modeling Cloud Migration Patterns: A Multi-cloud Service Architecture Perspective
x
x
Chapter
Era of Cloud Computing: A New Insight to
2015
Hybrid Cloud
9
Journal
x
x
ACCEPTED MANUSCRIPT
2016
Journal
with auto-scaling resources for executing bioinformatics andbiomedical workflows [29]
Cloud Native Cost Optimization
2015
Keynote
[30]
Energy Cloud: Real-Time Cloud-Native
2014
Conf.
x
x
x
x
x
x
x
AN US
Energy Management System to Monitor and
Experience
Building an open source cloud environment
Opinion
[28]
Survey
Type
Solution
Year
Evaluation
Title (shortened)
CR IP T
ID
Validation
Continuation of Table 3: Included and categorized papers
Analyze Energy Consumption in Multiple Industrial Sites
Kubernetes and the Path to Cloud Native
2015
Keynote
x
[32]
Microservices for Scalability: Keynote Talk
2016
Keynote
x
[33]
Acceleration of Cloud Computing
2014
Conf.
[34]
Handling Performance Sensitive Native
2013
Conf.
x
2012
Conf.
x
2010
Conf.
QUELLE - A Framework for Elastic Systems
2014
Chapter
Toward an Anti-fragile e-Government
2016
Chapter
2013
Chapter
M
[31]
x
x
Cloud Applications with Distributed Cloud
[35]
ED
Computing and SLA Management
4CaaSt: Comprehensive Management of Cloud Services through a PaaS
[37] [38]
Cloud Database-as-a-Service (DaaS) - ROI
PT
[36]
x x x
CE
System
[39]
Cloud Services Composition Support by
x
x
AC
Using Semantic Annotation and Linked Data
[40]
The Hybrid Cloud
2016
Chapter
[41]
MobiCloUP!: a PaaS for cloud
2014
Journal
services-based mobile applications
10
x x
x
ACCEPTED MANUSCRIPT
2014
Chapter
A Case Study [43]
Opportunities to Innovate Today
2013
Chapter
[44]
Critical analysis of vendor lock-in and its
2016
Journal
impact on cloud computing migration: a
[45]
x
x
Cloud Detours: A Non-intrusive Approach
x
x
x
AN US
business perspective 2015
Conf.
x
x
2015
Conf.
x
x
2014
Journal
2015
Conf.
2014
Conf.
x
2016
Conf.
x
2016
Conf.
x
2016
Keynote
for Automatic Software Adaptation to the Cloud [46]
CPFirewall: A Novel Parallel Firewall
Environment [47]
Portability in Clouds: Approaches and
ED
Research Opportunities [48]
M
Scheme for FWaaS in the Cloud
Experimental Evaluation of the
x
x
Cloud-Native Application Design
Deployment Aggregates - A Generic
PT
[49]
Deployment Automation Approach for Applications Operated in the Cloud Cloud-native Event-based Programming for
CE
[50]
Mobile Appls
AC
[51]
[52]
QoE-aware elasticity support in cloud-native 5G systems Native Cloud Applications: Why Virtual Machines, Images and Containers Miss the Point!
11
Experience
A Hybrid Grid/Cloud Distributed Platform:
Opinion
[42]
Survey
Type
Solution
Year
Evaluation
Title (shortened)
CR IP T
ID
Validation
Continuation of Table 3: Included and categorized papers
x
x
ACCEPTED MANUSCRIPT
2016
Chapter
2016
Conf.
Cloud-native Application Provisioning for SMEs by Integrating Already Available Container Technologies [54]
ClouNS - A Cloud-native Application
120
x
x
AN US
Reference Model for Enterprise Architects
Experience
Project Cloud TRANSIT - Or to Simplify
Opinion
[53]
Survey
Type
Solution
Year
Evaluation
Title (shortened)
CR IP T
ID
Validation
Continuation of Table 3: Included and categorized papers
2.4. Categorization of Papers (Keywording of Abstracts)
According to [2] and if possible, existing classification schemes should be used for topic specific classification of papers. We checked IEEE, ISO/IEC as well as Swebok standards [55] but found no appropriate classification system.
125
M
So, like a majority of mapping studies [2] we were forced to derive our own toic specific classification scheme. We did this using the process shown in Figure
ED
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 [3]) and derived meaningful keywords on our own based on the title and the abstract.
130
PT
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
CE
adaptive reading and evaluated introduction and conclusion sections as well to derive meaningful keywords.
AC
In further steps we unified author provided keywords into a unified keyword
135
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 properties are 12
AN US
CR IP T
ACCEPTED MANUSCRIPT
Figure 3: Keywording of selected papers
achieved and how transferability of a CNA can be realized. According to selected
M
140
papers, CNAs should be operated on automation platforms. Softwarization of infrastructures should be strived for to support DevOps principles more conse-
ED
quently. 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
PT
145
architecture approaches (particular the microservice architecture approach) as well as accompanying service composition principles of self-contained deploy-
CE
ment units (containers). CNA methods include patterns and design methodologies to create effec-
tive CNA architectures and DevOps to automate the process of delivery and
AC
150
infrastructure changes. These methods are applied frequently in CNA context. CNA properties describe characteristics of CNA. Such characteristics deal-
ing with consistency models, availability, partition tolerance (all strongly related to Brewer’s CAP theorem [56]), elasticity, resilience and service levels (SLA).
155
This property combination seems to be very characteristic for CNA according
13
ACCEPTED MANUSCRIPT
Table 4: Topic specific categories 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 Cases
telecommunication, industrial processes, bioinformatics,videostreaming service
CR IP T
Research Topic
providers, energy management and experiences with public cloud services (likely
Other
AN US
incomplete)
forensics, cloud-native artifacts, costs,decision making (likely incomplete)
to selected papers.
Further keywords dealt with use cases. These use cases can be categorized into the following domains: telecommunication, industrial processes, bioinfor-
160
M
matics, 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
ED
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
165
PT
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
CE
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
AC
answer our research questions (see Section 2.1). First of all, each paper is
170
evaluated according to its publication year. This is documented in Table 3 and visualized in Figure 5a. Due to the fact, that we could only consider publications until September of 2016, we extrapolated (linearly) the estimated publications for the complete year 2016. We use this to search for the origin of
14
ACCEPTED MANUSCRIPT
Book 8%
Book Chapter (2 peer review rounds) 26%
Validation/ Evaluation 19%
Journal (1 peer review round) 24%
Experience Report 27%
Solution Proposal 35%
(a) Contribution types
AN US
Keynote 8%
Survey 10%
CR IP T
Conference (1 peer review round) 34%
Opinion 9%
(b) Research approaches
Figure 4: Distribution of selected papers
the term ”cloud-native”. This will be discussed in Section 3.1.
Each paper is assigned a contribution type (book, book chapter, journal
M
175
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 map-
ED
ping studies to cover keynotes. We decided to do so. Mainly, because some of the keynotes like [31] by E. Brewer are highly influential in the cloud-native domain. According to the best of our knowledge all keynotes we selected are
PT
180
published/listed in the proceedings of the respective conferences. This is documented in Table 3 and the distribution across contribution types is visualized
CE
in Figure 4a.
We decided to classify selected papers by their research type according to
an existing classification of research approaches (proposed by [57] and summa-
AC
185
rized 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 [5] that there arise a lot of discussions whether a study is a validation or evaluation study, we decided to group both re-
190
search types as equal. This is documented in Table 3 and the distribution across
15
Table 5: Research approaches
CR IP T
ACCEPTED MANUSCRIPT
Description
Evaluation/
Evaluation means that techniques are implemented in practice and an evaluation of the
Validation
technique is conducted. It is shown how the technique is implemented in practice (solution
Research
implementation) and what are the consequences of the implementation in terms of benefits
AN US
Category
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.
A solution for a problem is proposed, the solution can be either novel or a significant extension
Proposal
of an existing technique. The potential benefits and the applicability of the solution is shown
M
Solution
Survey Papers
ED
by a small example or a good line of argumentation. 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. These papers express the personal opinion of somebody whether a certain technique is good or
PT
Opinion Papers
bad, or how things should been done. They do not rely on related work and research methodologies. Experience papers explain on what and how something has been done in practice. It has to be
Reports
the personal experience of the author.
AC
CE
Experience
16
ACCEPTED MANUSCRIPT
contribution types is visualized in Figure 4b. 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
195
CR IP T
the methodology being described in Figure 3. The distribution of the main and detailed research topics in selected papers is visualized in Figure 5b and Figure
5c. 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
AN US
200
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 Figure 6 and will be used in Section 3.3 to discuss most investigated cloud-native topics. The scope of the research topics 205
are explained in Table 4.
M
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.
ED
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 210
more correlated than others. The resulting mapping of correlated detail research
PT
terms is presented in Figure 7. However, the reader should be aware that we did this detail research only for the identified main research topics and not for
CE
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).
215
Both mappings are used in Section 3.3 to discuss and reflect most investigated
AC
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 [2, 5]. Because 220
of selected electronic sources (see Table 1) and selection criteria (see Table 2) 17
ACCEPTED MANUSCRIPT
25
CNA Principles
20
CNA Architecture
15
CNA Properties
10
Use cases
5
CNA Methods 0 2007
2008
2009
2010
Published Papers
2011
2012
2013
2014
30% 25%
30%
40%
50%
60%
Other aspects
(b) Main research topics
M
20%
(c) Detailed research topics (without use cases) Figure 5: Distribution of research topics of selected papers
18
SLA for CNA
CAP Properties
DevOps
Design Methodology
Elasticity
Service Composition
Deployment Units
Resilience
Patterns
Scalability
Softwareization
Migration
PT Microservices
CNA Design
Automation Platform
CE
Interoperability
ED
15% 10% 5% 0%
2016
Extrapolation (for 2016)
(a) Publications over years
AC
2015
20%
AN US
2006
10%
70%
CR IP T
0%
30
AN US
CR IP T
ACCEPTED MANUSCRIPT
Figure 6: Mapping of research topics to research approaches
mainly academic and mostly peer-reviewed contributions should turn up. So, in
M
accordance to electronic sources and selection 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
ED
225
how much peer reviewing is accumulated along this process. A lot of research
PT
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
CE
230
are (only) written without formal peer reviewing involved, these books rely on
AC
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
235
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
19
ACCEPTED MANUSCRIPT
in a specific field of research. According to Figure 4a 78% of selected papers are from sources where it 240
is likely that there has been involved at least one peer review round. 54% of
CR IP T
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
contributions (keynotes and books) are contributions likely without a formal peer reviewing process. But these contributions rely on a lot of peer reviewed 245
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.
AN US
Section 5 will additionally include the outcomes of data extraction and synthesis steps of the systematic literature review shown in Figure 2 and discussed in Section 4. 250
2.7. Threats of Validity
According to [2] there are common validity threats for systematic mapping
M
studies. Therefore, we reflect on possible threats which might arise from this study.
255
ED
The theoretical validity might be incomplete due to not published new and controversial views on cloud-native applications. CNAs looking back on 10 years of cloud computing history. However, the term ”cloud-native” just re-
PT
cently 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 ”cloud-native”. Further-
CE 260
more, there are controversial discussions dealing with microservices and service
AC
oriented architectures (SOA) [52]. 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
265
to harden this fact. The descriptive validity might be insufficient for specific aspects. Ac-
cording to Figure 6 there are less evaluating or validating studies than solution 20
ACCEPTED MANUSCRIPT
proposals. That might indicate that our search filters omitted evaluating and validating studies. However, we think, this just describes the current state of 270
research. We had a broad view on CNA and searched not intentionally for spe-
CR IP T
cific 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 275
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. Never-
AN US
theless, 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 [54] relies 280
partly on action research. We are aware, that action research is seen by some researchers as a non-objective research method (or not a research method at all). Therefore, the reader should take especially [54] into additional considera-
M
tion 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 en-
ED
285
gineering [2], the second author responsible for quality assurance steps was not involved intentionally in [54] research to minimize such kind of researcher bias
PT
for this mapping study.
CE
3. Discussion of Research Questions We will discuss our research questions in this Section mainly on a quan-
290
titative and comparative basis. To avoid any bias we avoid any unnecessary
AC
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
295
reading steps.
21
ACCEPTED MANUSCRIPT
3.1. Origin of the term ”cloud-native” [RQ1] According to Figure 5a the first contributions using the term ”cloud-native” have been published in 2012 [11, 35]. Both conference papers proposed solu-
300
CR IP T
tions for cloud-native application engineering. [11] proposes a pattern-based solution for a cloud-native application design methodology based on systemat-
ically identifying consistency, availability and network partitionability requirements (according to the CAP theorem presented by Brewer et al. [58, 59, 60]).
The authors of this contribution are all from the research group headed by Frank Leymann (Institute of Architecture and Application Systems, University
of Stuttgart, Germany). The paper itself references several other papers dealing
AN US
305
with pattern-based approaches. But none of these papers use the term ”cloudnative” until [11]. Several further papers of this research group focus similar topics, often model- and pattern-based approaches. Our study selection contains at least three papers by this research group. E.g. the TOSCA standard is 310
heavily influenced by the work of this research group.
M
The second paper [35] is about 4CaaSt, a ”PaaS framework that enables flexible definition, marketing, deployment and management of Cloud-based ser-
ED
vices and applications. The major innovations proposed [...] are [...] lifecycle management, a one stop shop for Cloud services and a PaaS level resource 315
management featuring elasticity, [...] a portfolio of ready to use cloud-native
PT
services and Cloud-aware immigrant technologies”. The 4CaaST project was an EU funded project and the authors of the publication are from various aca-
CE
demic and industrial research institutions: Telefonica, Tilburg University, SAP Research Centre, University of St. Gallen, University of Madrid, Nokia Siemens
320
Networks, Orange Labs and Ericsson Research Center. However, the already
AC
mentioned Institute of Architecture and Application Systems was involved in additional publications covering the 4CaaSt project as well. The publications [11, 61] were – according to the acknowledgement – at least partly funded by the 4CaaSt project.
325
It is interesting to see, that both publications focus aspects like pattern based approaches [11] and automation platforms [35] which are intensively reflected in 22
ACCEPTED MANUSCRIPT
several other selected papers as well. Figure 7 shows the correlation on research topics. The reader sees that the research topic automation platform is intensively correlated to cloud-native architecture topics and cloud-native application properties like scalability, re-
CR IP T
330
silience and elasticity. The same is true for patterns which are intensively correlated to cloud-native application 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. [6] as one of the most helpful and complete 335
sources systematizing a lot of cloud-native application aspects. This contri-
AN US
bution is derived by and integrates several other publications (beginning with [11]) 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 340
major contributions to a better understanding of the term ”cloud-native”.
M
3.2. Meaning of the term ”cloud-native” [RQ2]
Although there exist no precise definition what a cloud-native application
ED
exactly is, we can conclude that there is a common but unconscious understanding across all analyzed papers. According to Section 2.4 and Figure 7, 345
cloud-native applications (CNA) should be build according to corresponding
PT
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 princi-
CE
ples enable to build CNA architectures (mainly service-based and often with
350
self-contained deployment units involved) with specific and wishful CNA prop-
AC
erties (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
355
these CNA topics (principles, architecture, methods and resulting properties) are influencing each other. However, some topics and their interdependencies 23
ED
M
AN US
CR IP T
ACCEPTED MANUSCRIPT
Figure 7: Correlation of research topics
PT
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).
CE
360
AC
3.3. Existing trends in cloud-native engineering [RQ3] According to Figure 5b, 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 plat-
365
forms are named elastic platforms by Fehling et al. [6]. In industry we see this trend as well. There is currently a lot of interest in platforms like Apache Mesos,
24
ACCEPTED MANUSCRIPT
Kubernetes, Docker Swarm and so on. Another important focus can be seen in appropriate architectures of cloudnative applications. An intensively focused detail topic is how to create an appropriate design of a cloud-native application. Most authors focus service-
CR IP T
370
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 [62, 23]. However, the question remains whether microservices are 375
something new or just a specific (maybe more pragmatic) approach of the service
AN US
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’ 380
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,
M
accompanying the term microservice there is an increasing focus on container technologies as well in industry. The interest is mainly due to the opportunity
ED
to create self-contained deployment units in a standardized form. The correlation of research topics is interesting as well (see Figure 7). CNA
385
design seems to be highly correlated with patterns. The same is true for mi-
PT
croservices and deployment units. Automation platforms are often mentioned beside architectural topics like microservices, service composition, and deploy-
CE
ment units. Furthermore, CNA properties like scalability, resiliency and elas390
ticity are mentioned very often in the same papers. So, automation platforms are seen by a lot of authors as an enabler to realize sustainable CNA archi-
AC
tectures. 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
395
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. 25
ACCEPTED MANUSCRIPT
3.4. Promising research directions [RQ4] Figure 6 shows, that there is a clear focus on solution proposals in research 400
dealing with cloud-native application engineering. The proposals cover mainly
CR IP T
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 405
would be reflected by a lot of survey studies which might end in new insights.
Looking at Figure 6, we see that this maturity seems not to be reached so
AN US
far in cloud-native application research. Insights in shortcomings of existing approaches are derived mainly from experience reports focusing CNA principles
and architectures. Methods and properties of CNA applications seem a bit un410
derrepresented 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
M
principles or architectures. 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
ED
415
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
PT
Figure 6). However, we will cover this aspect in Section 4 in more details.
CE
4. Engineering Trends and Possible Future Directions [RQ4] So far, we mainly have done a quantitative and comparative analysis on
420
AC
the identified paper population. In this Section we investigate identified cloudnative 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
425
open research topics (denoted as (TOPIC.NR) in text) which are listed in Table 6 and will be discussed in following sections.
26
CR IP T
ACCEPTED MANUSCRIPT
Table 6: Open research topics (without claim to be complete) Id
Valuable research directions
CNA Prin-
PRINC.1
Design of elastic intermediary platforms for multi-cloud sce-
PRINC.2
Transferability of CNA for hybrid or multi-cloud scenarios
METH.1
Long term implications of DevOps/microservice based engi-
METH.2
CNA specific engineering methodologies (intentionally cover-
METH.3
Compositional programming languages for CNA.
ARCH.1
Reference models for CNA.
ciples
narios.
AN US
Topic
(deeply related to ARCH-1/2). CNA Methods
neering methodologies.
Ar-
chitecture
ARCH.2
Standardization of elastic intermediary platforms.
ARCH.3
Integration of isolated trends (service, ).
PROP.1
Elasticity of stateful CNA components.
PROP.2
Synchronizing platform and application elasticity.
PROP.3
Security engineering for (multi-cloud) CNA.
PT
CNA Prop-
ED
CNA
M
ing elasticity).
AC
CE
erties
27
ACCEPTED MANUSCRIPT
4.1. Research Implications of CNA Principles We identified a trend to operate CNA not directly on IaaS infrastructures but on intermediary elastic platforms [6, 54]. This simplifies engineering, deploying and operating of CNAs and leverages softwareization of infrastructure
CR IP T
430
and networks. It even contributes to more economic operation of CNAs [29]. This has been done in past research often via specialized PaaS platforms [35, 41]
but these platforms have the tendency to create platform lock-ins [44]. So, in recent years there is a trend to encapsulate arbitrary software in standardized 435
and self-contained deployment units (containers) and to operate these units on
AN US
container clusters like Apache Mesos, Kubernetes, Docker Swarm [31, 16]. 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
440
fruitful research has been done for the question how existing legacy applications
M
can be migrated to cloud environments and how these applications must be transformed to be ”cloud-native” [23, 26, 10]. However, this obviously focus no
445
ED
systems intentionally designed for the cloud. Other interesting approaches focus how to design applications to be deployable to arbitrary environments often including but not limited to cloud-environments [45, 49]. But interoperability
PT
or portability in hybrid or multi-cloud scenarios (PRINC-2) seems to be only considered by single case or survey studies so far [42, 47]. But
CE
exactly this would be necessary to overcome vendor lock-in vulnerabilities of 450
CNAs [44].
AC
4.2. Research Implications of CNA Methodologies A lot of studies report about trends to use microservices [8, 23, 26, 48, 63, 32],
to use DevOps [24, 63] or to make use of softwareization [9, 25, 28, 33, 37, 46] to realize and operate CNAs pragmatically. These trends seem to be widely ac-
455
cepted and preferred. However, microservices, DevOps and softwarization shift more realizing autonomy to small development and operation teams. Especially 28
ACCEPTED MANUSCRIPT
the microservices approach motivates this intentionally [8]. But we found no study that dealt with the consequences. Microservice followers often cite Conways Law3 . However, according to this law the organizational (two pizza4 ) structures coming along with microservices and DevOps principles should lead
CR IP T
460
to more heterogeneous 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 components. But according to Conway [64] this 465
should result in increased heterogeneity (which most other approaches would like
AN US
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 470
the tendency to become hardly maintainable on the long term. Most existing microservice based systems are still very young systems nowadays. So, the long
M
term effects of these engineering methodologies might not be observed so far. A lot of CNA methodologies are pattern based [6, 7, 8, 10, 11]. Patterns are
475
ED
a well accepted and proven engineering methodology in software engineering. This insight has been transfered to CNA engineering as well. It is better not to reinvent the wheel but to rely on proven solutions that have been working in
PT
past. So, existing engineering methodologies are taken and combined with cloud specific patterns. This seems obvious. However, systems of the past were seldom
CE
elastic systems. So, there might be the need for some CNA specific engi480
neering methodologies (METH.2) covering CNA specific problems (namely
AC
elasticity).
3 ”Organizations
which design systems [...] are constrained to produce designs which are
copies of the communication structures of these organizations.” [64] 4 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.
29
ACCEPTED MANUSCRIPT
4.3. Research Implications of CNA Architectures Components of CNAs are often realized as containers [16].
These self-
contained deployment units are operated on elastic platforms. Popular elastic container platforms are Google’s Kubernetes, Apache Mesos, Docker Swarm,
CR IP T
485
to name a few. These platforms can be deployed across different cloud service
providers [54] and therefore reducing vendor lock-in effects (see [44]). However, a
CNA developed for Kubernetes is not deployable on Mesos or on Swarm without
further engineering efforts. There exist standardization initiatives for contain-
ers and there should be standardization initiatives for elastic container platforms (ARCH-2) as well.
AN US
490
Furthermore, CNA engineers use these elastic platforms to encapsulate deployment unit heterogeneity. To handle this heterogeneity of CNA components, we see some dominating major requirements. 495
1. The necessity to standardize packaging these components into standard-
M
ized self-contained deployment units is mentioned by a lot of studies [8, 12, 23, 16, 31, 48]. Technically this is solved using containers and operating system virtualization. Notably Docker has established here a de
500
ED
facto standard.
2. There is the necessity to interface these heterogeneous but standardized
PT
deployable services with scalable and simple communication means. This is often done via REST-based APIs transferring arbitrary but JSONserialized data. This seems to exploit existing internet infrastructures in a
CE
very pragmatic way to build distributed, large scale, massively (horizontal)
505
scalable and elastic cloud systems. In fact it seems that this is the main
AC
CNA component composition approach [8, 16, 10, 34, 39].
510
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 scalable but (mostly) eventual consistent storage solutions (which are often subsumed as NoSQL databases). These storage solutions are used to isolate states to simplify scalable sys30
ACCEPTED MANUSCRIPT
tem designs of (large parts of) these systems [6, 7, 15]. All trends (see Table 7) can be seen as isolated trends. However, 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
CR IP T
515
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).
AN US
520
4.4. Research Implications of CNA Properties
According to our survery, a CNA shall have wishful CNA property combination of horizontal scalability [29, 14], elasticity [37, 12], and resiliency [9, 14, 38, 42]. A lot of research about cloud-native applications is reported as solution proposals and experience reports. However, systematic evaluation and
M
525
validation of postulated effects seems to be rare. Elasticity is often aligned to microservice based approaches. And microser-
ED
vices are relying heavily on stateless services. But stateless services can be scaled up and down easily from a distributed systems conceptual point of view. 530
We found only little research dealing with the elasticity of stateful CNA
PT
components (PROP.1) which is the much harder problem. Although, we did not investigate elasticity research in details, we got the
CE
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
535
(e.g. on Kubernetes) can be elastic as well. But most of the times, elasticity
AC
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).
540
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
31
ACCEPTED MANUSCRIPT
CR IP T
Table 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 de-
velopers and IT operators. It aims to build, test, and release software
for software delivery. Softwareization
AN US
more rapidly, frequently, and more reliably using automated processes
Softwareization of infrastructure and network enables to automate the process of software delivery and infrastructure changes more rapidly.
Standardized
Deployment units wrap a piece of software in a complete filesystem
Deployment
that contains everything needed to run: code, runtime, system tools,
Units
system libraries. This guarantees that the software will always run
Elastic
Plat-
forms
M
the same, regardless of its environment.
Elastic platforms like Kubernetes, Mesos, Docker Swarm can be seen as a middleware for the execution of custom but standardized deploy-
ED
ment 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
PT
avoided, but stateful components should be reduced to a minimum and realized by intentional horizontal scalable storage systems (often eventual consistent NoSQL databases). REST-based APIs provide scalable and pragmatic communication
REST APIs
means relying mainly on already existing internet infrastructure and
CE
Versioned
AC
Loose coupling
well defined and widespread standards. 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).
32
ACCEPTED MANUSCRIPT
filters. However, we think this should be a relevant aspect for ongoing research as well (PROP-3).
CR IP T
5. Definition Proposal for CNA [RQ2] Previous Section 4 showed that there are open questions regarding CNA 545
engineering and research. Furthermore, our literature review did not turn up
a common definition that explains what a cloud-native application exactly is5 .
Nevertheless, our survery identified enough studies which can be used to derive a definition proposal for CNA because there is a common but unconscious
AN US
understanding across several relevant studies.
Fehling et al. propose that a cloud-native application should be IDEAL, so it
550
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 [6]. According to Stine [8] there
555
M
are common motivations for cloud-native application architectures like to deliver software-based solutions more quickly (speed), in a more fault isolating, fault tolerating, and automatic recovering way (safety), to enable horizontal (instead
ED
of vertical) application scaling (scale), and finally to handle a huge diversity of (mobile) platforms and legacy systems (client diversity). These common
560
PT
motivations are addressed by several application architecture and infrastructure approaches [22]:
CE
• Microservices represent the decomposition of monolithic (business) systems into independently deployable services that do ”one thing well”
AC
[65, 66].
565
• 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
5 Except
our own contribution [54] which relies partly on this mapping study. The reader
might want to consider [54] to get a complete picture.
33
ACCEPTED MANUSCRIPT
with JSON serialization, but other protocols and serialization formats can be used as well. • Single deployment units of the architecture are designed and intercon-
CR IP T
nected according to a collection of cloud-focused patterns like the
570
twelve-factor app collection [67], the circuit breaker pattern [68] or cloud computing patterns [6, 7].
• And finally, self-service agile infrastructure platforms are used to deploy and operate these microservices via self-contained deployment units
(containers). These platforms provide additional operational capabilities
AN US
575
on top of IaaS infrastructures like automated and on-demand scaling of application instances, application health management, dynamic routing, load balancing and aggregation of logs and metrics. These aspects lead us to the following definition:
M
A cloud-native application (CNA) is a distributed, elastic and horizontal scalable system composed of (micro)services which isolates state in a
ED
minimum of stateful components. The application and each self-contained deployment unit of that application is designed according to cloud-focused
580
PT
design patterns and operated on a self-service elastic platform.
Of course this definition can only be understood in a context of further terms
CE
already defined or characterized by other authors and standardizing initiatives: • Elasticity is ”the degree to which a system is able to adapt to workload
AC
changes by provisioning and de-provisioning resources in an autonomic
585
manner, such that at each point in time the available resources match the current demand as closely as possible” and has been already defined by [69]. • Scalability can be differentiated to ”structural scalability and load scalability. Structural scalability is the ability of a system to expand in a chosen 34
ACCEPTED MANUSCRIPT
dimension 6 without major modifications to its architecture. Load scalabil590
ity is the ability of a system to perform gracefully as the offered traffic increases” [70].
CR IP T
• Microservices are understood as an architectural style to develop ”a single application as a suite of small services, each running in its own
process and communicating with lightweight mechanisms, often an HTTP 595
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
storage technologies” [71]. 600
AN US
may be written in different programming languages and use different data
• Self-contained Deployment Unit is understood as ”a part of the application’s deployment topology for realizing a specific technical unit” [12]. More and more often a deployment unit is understood as ”a standard
M
container. The goal of a standard 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 depen-
ED
605
dencies, regardless of the underlying machine and the contents of the container”. This is the understanding of the Open Container Initiative (OCI)
PT
which is explained in the 5 principles of standard containers [72].
• Stateful components are used for ”multiple instances of a scaled-out application component [to] synchronize their internal state to provide a
CE
610
AC
unified behavior” [6].
• Elastic platform is understood as a ”middleware for the execution of custom applications, their communication, and data storage is offered via a self-service interface over a network” [6].
6 horizontally
in case of CNA
35
ACCEPTED MANUSCRIPT
615
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
CR IP T
used – maybe even dominated – by software and cloud industry nowadays. We
identified interesting but isolated trends in cloud systems engineering (see Table 620
7). If several of these trends are applied in parallel resulting software systems 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
AN US
with specific challenges.
Our critical discussion of identified research showed, that there is room and
625
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
630
M
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
ED
effects of these autonomous engineering approaches are hardly investigated so far. Even the existing systems are quite young and the long term effects might
PT
not be even observed.
However, our literature survey showed that there is a common but uncon-
635
scious understanding of cloud-native applications. A CNA should be build ac-
CE
cording to corresponding CNA principles (being 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 of-
AC 640
ten pattern-based (relying on comprehensive cloud computing pattern catalogs [6, 7]) 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.
36
ACCEPTED MANUSCRIPT
645
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
CR IP T
designed for the cloud.” Acknowledgements
This study was funded by German Federal Ministry of Education and Re-
650
search (Project Cloud TRANSIT, 03FH021PX4). We would like to thank our reviewers who contributed valuable and very constructive feedback. Further-
AN US
more, we thank Dr. Adersberger from QAWARE GmbH. He inspired us with
his MEKUNS approach (Mesos, Kubernetes Cloud-native Stack) and his consid655
erations about cloud-native applications from a practitioner point of view. And we thank Ren´e Peinl for his valuable contributions accompanying our research.
M
References
[1] P. Mell, T. Grance, The NIST Definition of Cloud Computing, National
ED
Institute of Standards and Technology (2011). doi:http://dx.doi.org/ 10.6028/NIST.SP.800-145.
660
[2] K. Petersen, S. Vakkalanka, L. Kuzniarz, Guidelines for conducting system-
PT
atic mapping studies in software engineering: An update, Information and Software Technology 64 (2015) 1–18. doi:http://dx.doi.org/10.1016/
CE
j.infsof.2015.03.007. 665
[3] K. Petersen, R. Feldt, S. Mujtaba, M. Mattsson, Systematic mapping stud-
AC
ies in software engineering, in: Proceedings of the 12th International Conference on Evaluation and Assessment in Software Engineering, EASE’08, British Computer Society, Swinton, UK, UK, 2008, pp. 68–77.
[4] B. Kitchenham, S. Charters, Guidelines for performing Systematic Litera-
670
ture Reviews in Software Engineering, Tech. Rep. EBSE 2007-001, Keele University and Durham University Joint Report (2007). 37
ACCEPTED MANUSCRIPT
[5] C. Wohlin, P. Runeson, P. A. da Mota Silveira Neto, E. Engstrm, I. do Carmo Machado, E. S. de Almeida, On the reliability of mapping studies in software engineering, Journal of Systems and Software 86 (10) (2013)
CR IP T
2594–2610. doi:http://dx.doi.org/10.1016/j.jss.2013.04.076.
675
[6] C. Fehling, F. Leymann, R. Retter, W. Schupeck, P. Arbitter, Cloud Computing Patterns, Springer, 2014.
[7] T. Erl, R. Cope, A. Naserpour, Cloud Computing Design Patterns, Springer, 2015.
[8] M. Stine, Migrating to Cloud-Native Application Architectures, O’Reilly,
AN US
680
2015.
[9] T. Taleb, A. Ksentini, B. Sericola, On Service Resilience in Cloud-Native 5G Mobile Systems, IEEE Journal on Selected Areas in Communications 34 (3) (2016) 483–496. doi:10.1109/JSAC.2016.2525342.
[10] A. Balalaie, A. Heydarnoori, P. Jamshidi, Advances in Service-Oriented and
M
685
Cloud Computing: Workshops of ESOCC 2015, Taormina, Italy, September
ED
15-17, 2015, Revised Selected Papers, Springer International Publishing, 2016, Ch. Migrating to Cloud-Native Architectures Using Microservices: An Experience Report, pp. 201–215. doi:10.1007/978-3-319-33313-7_ 15.
PT
690
[11] V. Andrikopoulos, C. Fehling, F. Leymann, DESIGNING FOR CAP -
CE
The Effect of Design Decisions on the CAP Properties of Cloud-native Applications, in: Proceedings of the 2nd International Conference on
AC
Cloud Computing and Services Science, 2012, pp. 365–374. doi:10.5220/
695
0003931503650374.
[12] C. Inzinger, S. Nastic, S. Sehic, M. V¨ ogler, F. Li, S. Dustdar, Madcat: A methodology for architecture and deployment of cloud application topologies, in: Service Oriented System Engineering (SOSE), 2014 IEEE 8th International Symposium on, 2014, pp. 13–22. doi:10.1109/SOSE.2014.9. 38
ACCEPTED MANUSCRIPT
700
[13] A. Balalaie, A. Heydarnoori, P. Jamshidi, Advances in Service-Oriented and Cloud Computing: Workshops of ESOCC 2015, Taormina, Italy, September 15-17, 2015, Revised Selected Papers, Springer International Publishing,
CR IP T
2016, Ch. Migrating to Cloud-Native Architectures Using Microservices: An Experience Report, pp. 201–215. doi:10.1007/978-3-319-33313-7_ 15.
705
[14] T. Goldschmidt, A. Jansen, H. Koziolek, J. Doppelhamer, H. P. Breivold,
Scalability and robustness of time-series databases for cloud-native monitoring of industrial processes, in: 2014 IEEE 7th International Conference
710
AN US
on Cloud Computing, 2014, pp. 602–609. doi:10.1109/CLOUD.2014.86.
[15] V. Andrikopoulos, S. Strauch, C. Fehling, F. Leymann, 2nd Int. Conf. on Cloud Computing and Services Science, CLOSER 2012, Springer International Publishing, 2013, Ch. CAP-Oriented Design for Cloud-Native
M
Applications, pp. 215–229. doi:10.1007/978-3-319-04519-1_14. [16] R. Peinl, F. Holzschuher, F. Pfitzer, Docker cluster management for the cloud - survey results and own solution, Journal of Grid Computing (2016)
715
ED
1–18doi:10.1007/s10723-016-9366-y. [17] S. Suneja, C. Isci, R. Koller, E. de Lara, Touchless and always-on cloud
PT
analytics as a service, IBM Journal of Research and Development 60 (2-3) (2016) 11:1–11:10. doi:10.1147/JRD.2016.2518438. [18] V. Roussev, S. McCulley, Forensic analysis of cloud-native artifacts, Dig-
CE
720
ital Investigation 16, Supplement (2016) 104–113, {DFRWS} 2016 Eu-
AC
ropeProceedings of the Third Annual {DFRWS} Europe.
doi:http:
//dx.doi.org/10.1016/j.diin.2016.01.013.
[19] V. Roussev, A. Barreto, I. Ahmed, Forensic acquisition of cloud drives,
725
CoRR (Computing Research Repository) abs/1603.06542. URL http://arxiv.org/abs/1603.06542
39
ACCEPTED MANUSCRIPT
[20] N. Nikaein, E. Schiller, R. Favraud, R. Knopp, I. Alyafawi, T. Braun, Studies in Big Data, Springer, 2016, 2016, Ch. Towards a Cloud-native Radio Access Network, pp. 171–202. [21] S. Varghese, Web Development with Go: Building Scalable Web Apps
CR IP T
730
and RESTful Services, Apress, Berkeley, CA, 2015, Ch. Building Go Web Applications on Google Cloud, pp. 251–283. 978-1-4842-1052-9_11.
doi:10.1007/
URL http://dx.doi.org/10.1007/978-1-4842-1052-9_11
[22] A. Balalaie, A. Heydarnoori, P. Jamshidi, Microservices architecture en-
AN US
735
ables devops: Migration to a cloud-native architecture, IEEE Software 33 (2016) 42–52.
[23] A. Balalaie, A. Heydarnoori, P. Jamshidi, Migrating to Cloud-native Architectures Using Microservices: An Experience Report, in: Europ. Conf. on Service-Oriented and Cloud Computing, Springer, 2015, pp. 201–215.
M
740
[24] B. Familiar, Microservices, IoT, and Azure: Leveraging DevOps and
ED
Microservice Architecture to Deliver SaaS Solutions, Apress, Berkeley, CA, 2015, Ch. Service Fabric, pp. 165–182.
doi:10.1007/
978-1-4842-1275-2_8.
URL http://dx.doi.org/10.1007/978-1-4842-1275-2_8
PT
745
[25] N. Nikaein, Processing radio access network functions in the cloud: Critical
CE
issues and modeling, in: Proceedings of the 6th International Workshop on Mobile Cloud Computing and Services, MCS ’15, ACM, New York, NY, USA, 2015, pp. 36–43. doi:10.1145/2802130.2802136.
AC
750
URL http://doi.acm.org/10.1145/2802130.2802136
[26] P. Jamshidi, C. Pahl, S. Chinenyeze, X. Liu, 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, 2015, Ch.
40
ACCEPTED MANUSCRIPT
Cloud Migration Patterns: A Multi-cloud Service Architecture Perspective,
755
pp. 6–19. doi:10.1007/978-3-319-22885-3_2. [27] A. Srinivasan, M. A. Quadir, V. Vijayakumar, Era of cloud computing: A
CR IP T
new insight to hybrid cloud, Procedia Computer Science 50 (2015) 42 – 51, big Data, Cloud and Computing Challenges. doi:http://dx.doi.org/ 10.1016/j.procs.2015.04.059.
760
[28] M. T. Krieger, O. Torreno, O. Trelles, D. Kranzlm¨ uller, Building an open
source cloud environment with auto-scaling resources for executing bioin-
AN US
formatics and biomedical workflows, Future Generation Computer Systemsdoi:http://dx.doi.org/10.1016/j.future.2016.02.008. 765
[29] A. Cockcroft, Cloud Native Cost Optimization, in: Proc. of the 6th ACM/SPEC Int. Conf. on Perf. Eng., ICPE ’15, ACM, New York, NY, USA, 2015, pp. 109–109. doi:10.1145/2668930.2693197.
M
[30] H. Sequeira, P. Carreira, T. Goldschmidt, P. Vorst, Energy Cloud: RealTime Cloud-Native Energy Management System to Monitor and Analyze Energy Consumption in Multiple Industrial Sites, in: Proceedings of the
ED
770
2014 IEEE/ACM 7th International Conference on Utility and Cloud Computing, UCC ’14, IEEE Computer Society, Washington, DC, USA, 2014,
PT
pp. 529–534. doi:10.1109/UCC.2014.79. [31] E. A. Brewer, Kubernetes and the path to cloud native, in: Proceedings of the Sixth ACM Symposium on Cloud Computing, SoCC ’15, ACM, New
CE
775
York, NY, USA, 2015, pp. 167–167. doi:10.1145/2806777.2809955.
AC
[32] W. Hasselbring, Microservices for scalability: Keynote talk abstract, in:
780
Proceedings of the 7th ACM/SPEC on International Conference on Performance Engineering, ICPE ’16, ACM, New York, NY, USA, 2016, pp. 133–134. doi:10.1145/2851553.2858659.
[33] A. S. Housfater, M. S. Aslam, D. Gupta, S. Meraji, R. Bennis, Acceleration of cloud computing, in: Proceedings of 24th Annual International Confer41
ACCEPTED MANUSCRIPT
ence on Computer Science and Software Engineering, CASCON ’14, IBM Corp., Riverton, NJ, USA, 2014, pp. 297–298. 785
[34] D. Mazmanov, C. Curescu, H. Olsson, A. Ton, J. Kempf, Handling per-
CR IP T
formance sensitive native cloud applications with distributed cloud com-
puting and sla management, in: Utility and Cloud Computing (UCC),
2013 IEEE/ACM 6th International Conference on, 2013, pp. 470–475. doi:10.1109/UCC.2013.92. 790
[35] S. Garca-Gmez, M. Escriche-Vicente, P. Arozarena-Llopis, F. Lelli,
AN US
Y. Taher, C. Momm, A. Spriestersbach, J. Vogel, A. Giessmann, F. Junker,
M. Jimnez-Ga’n, J. Biro, G. L. Jeune, M. Dao, S. P. Carrie, J. Niemoller, D. Mazmanov, 4caast:
Comprehensive management of cloud services
through a paas, in: 2012 IEEE 10th International Symposium on Parallel and Distributed Processing with Applications, 2012, pp. 494–499.
795
M
doi:10.1109/ISPA.2012.72.
[36] V. Mateljan, D. Cisic, D. Ogrizovic, Cloud database-as-a-service (daas) roi, in: MIPRO, 2010 Proceedings of the 33rd International Convention,
800
ED
2010, pp. 1185–1188.
[37] D. Moldovan, G. Copil, H.-L. Truong, S. Dustdar, Service-Oriented and
PT
Cloud Computing: Third European Conference, ESOCC 2014, Manchester, UK, September 2-4, 2014. Proceedings, Springer Berlin Heidelberg, Berlin, Heidelberg, 2014, Ch. QUELLE – A Framework for Accel-
CE
erating the Development of Elastic Systems, pp. 93–107. doi:10.1007/ 978-3-662-44879-3_7.
805
AC
[38] K. J. Hole, Anti-fragile ICT Systems, Springer International Publishing, 2016, Ch. Toward an Anti-fragile e-Government System, pp. 57–65. doi: 10.1007/978-3-319-30070-2_6.
´ Foghl´ [39] M. Serrano, L. Shi, M. O. u, W. Donnelly, Knowledge Discovery, 810
Knowledge Engineering and Knowledge Management: Third International
42
ACCEPTED MANUSCRIPT
Joint Conference, IC3K 2011, Paris, France, October 26-29, 2011. Revised Selected Papers, Springer Berlin Heidelberg, Berlin, Heidelberg, 2013, Ch. Cloud Services Composition Support by Using Semantic Annotation and
815
CR IP T
Linked Data, pp. 278–293. doi:10.1007/978-3-642-37186-8_18. [40] M. Missbach, T. Staerk, C. Gardiner, J. McCloud, R. Madl, M. Tempes, G. Anderson, SAP on the Cloud, Springer Berlin Heidelberg, Berlin,
Heidelberg, 2016, Ch. The Hybrid Cloud, pp. 153–164. doi:10.1007/ 978-3-662-47418-1_7.
AN US
[41] L. O. Colombo-Mendoza, G. Alor-Hern´ andez, A. Rodr´ıguez-gonz´ alez, R. Valencia-garc´ıa, Mobicloup!: a paas for cloud services-based mobile
820
applications, Automated Software Engineering 21 (3) (2014) 391–437. doi:10.1007/s10515-014-0143-5.
[42] M. Ben Belgacem, H. Hafsi, N. Abdennadher, Grid and Pervasive Comput-
M
ing: 8th International Conference, GPC 2013 and Colocated Workshops, Seoul, Korea, May 9-11, 2013. Proceedings, Springer Berlin Heidelberg,
825
Berlin, Heidelberg, 2013, Ch. A Hybrid Grid/Cloud Distributed Platform:
ED
A Case Study, pp. 162–169. doi:10.1007/978-3-642-38027-3_17. [43] A. Mann, G. Watt, P. Matthews, The Innovative CIO: How IT Leaders Can
PT
Drive Business Transformation, Apress, Berkeley, CA, 2013, Ch. Opportunities to Innovate Today, pp. 103–125. doi:10.1007/978-1-4302-4411-0_
830
CE
6.
[44] J. Opara-Martins, R. Sahandi, F. Tian, Critical analysis of vendor lock-
AC
in and its impact on cloud computing migration: a business perspec-
835
tive, Journal of Cloud Computing 5 (1) (2016) 1–18.
doi:10.1186/
s13677-016-0054-z.
[45] M. Vasconcelos, N. C. Mendon¸ca, P. H. M. Maia, Service Oriented and Cloud Computing: 4th European Conference, ESOCC 2015, Taormina,
43
ACCEPTED MANUSCRIPT
Italy, September 15-17, 2015, Proceedings, Springer International Publishing, Cham, 2015, Ch. Cloud Detours: A Non-intrusive Approach for Automatic Software Adaptation to the Cloud, pp. 181–195. doi:10.1007/
840
CR IP T
978-3-319-24072-5_13. [46] Z. Wang, Z. Lu, J. Wu, K. Fan, Advances in Services Computing: 9th Asia-Pacific Services Computing Conference, APSCC 2015, Bangkok, Thai-
land, December 7-9, 2015, Proceedings, Springer International Publishing, Cham, 2015, Ch. CPFirewall: A Novel Parallel Firewall Scheme
845
978-3-319-26979-5_9.
doi:10.1007/
AN US
for FWaaS in the Cloud Environment, pp. 121–136.
[47] D. Petcu, A. V. Vasilakos, Portability in clouds: approaches and research opportunities, Scalable Computing: Practice and Experience 15. 850
[48] S. Brunner, M. Bl¨ ochlinger, G. Toffetti, J. Spillner, T. M. Bohnert,
M
Experimental evaluation of the cloud-native application design, in: 8th IEEE/ACM International Conference on Utility and Cloud Computing, UCC 2015, Limassol, Cyprus, December 7-10, 2015, 2015, pp. 488–493.
855
ED
doi:10.1109/UCC.2015.87. [49] J. Wettinger, K. G¨ orlach, F. Leymann, Deployment aggregates - a generic
PT
deployment automation approach for applications operated in the cloud, in: Proceedings of the 18th International Enterprise Distributed Object Computing Conference Workshops and Demonstrations, IEEE Computer
CE
Society, 2014, pp. 173–180.
[50] I. Baldini, P. Castro, P. Cheng, S. Fink, V. Ishakian, N. Mitchell,
AC
860
865
V. Muthusamy, R. Rabbah, P. Suter, Cloud-native, Event-based Programming for Mobile Applications, in: Proceedings of the International Conf. on Mobile Software Engineering and Systems, MOBILESoft ’16, ACM, New York, NY, USA, 2016, pp. 287–288. doi:10.1145/2897073.2897713.
[51] S. Dutta, T. Taleb, A. Ksentini, QoE-aware elasticity support in cloud-
44
ACCEPTED MANUSCRIPT
native 5G systems, in: 2016 IEEE Int. Conf. on Communications (ICC), 2016, pp. 1–6. doi:10.1109/ICC.2016.7511377. [52] F. Leymann, C. Fehling, S. Wagner, J. Wettinger, Native Cloud Appli-
CR IP T
cations: Why Virtual Machines, Images and Containers Miss the Point!,
in: Proc. of the 6th Int. Conf. on Cloud Computing and Service Science
870
(CLOSER 2016), SciTePress, 2016, pp. 7– 15.
[53] N. Kratzke, P.-C. Quint, D. Palme, D. Reimers, Project Cloud TRANSIT - Or to Simplify Cloud-native Application Provisioning for SMEs by Inte-
AN US
grating Already Available Container Technologies, in: V. Kantere, B. Koch (Eds.), European Project Space on Smart Systems, Big Data, Future In-
875
ternet - Towards Serving the Grand Societal Challenges, SCITEPRESS, 2016, in print.
[54] N. Kratzke, R. Peinl, ClouNS - A Cloud-Native Application Reference
M
Model for Enterprise Architects, in: 2016 IEEE 20th International Enterprise Distributed Object Computing Workshop (EDOCW), 2016, pp.
880
ED
1–10. doi:10.1109/EDOCW.2016.7584353. [55] P. Bourque, R. E. Fairley (Eds.), SWEBOK: Guide to the Software Engineering Body of Knowledge, version 3.0 Edition, IEEE Computer Society,
PT
Los Alamitos, CA, 2014.
URL http://www.swebok.org/
885
CE
[56] E. Brewer, CAP twelve years later: How the ”rules” have changed, Computer 45 (2) (2012) 23–29. doi:10.1109/MC.2012.37.
AC
[57] R. Wieringa, N. Maiden, N. Mead, C. Rolland, Requirements engineering
890
paper classification and evaluation criteria: A proposal and a discussion, Requir. Eng. 11 (1) (2005) 102–107. doi:10.1007/s00766-005-0021-6.
[58] A. Fox, S. D. Gribble, Y. Chawathe, E. A. Brewer, P. Gauthier, Clusterbased Scalable Network Services, SIGOPS Oper. Syst. Rev. 31 (5) (1997) 78–91. doi:10.1145/269005.266662. 45
ACCEPTED MANUSCRIPT
[59] A. Fox, E. A. Brewer, Harvest, Yield, and Scalable Tolerant Systems, in: Proc. of the The 7th Workshop on Hot Topics in Operating Systems (HO-
895
TOS99), IEEE Computer Society, Washington, DC, USA, 1999, pp. 174–
CR IP T
179. [60] E. A. Brewer, Towards Robust Distributed Systems (Keynote), in: Proc. of the 19th Annual ACM Symp. on Princ. of Dist. Comp. (PODC ’00), ACM, New York, NY, USA, 2000, p. 7. doi:10.1145/343477.343502.
900
[61] S. Garcia-Gomez, M. Jimenez-Ganan, Y. Taher, C. Momm, F. Junker,
AN US
J. Biro, A. Menychtas, V. Andrikopoulos, S. Strauch, Challenges for the
Comprehensive Management of Cloud Services in a PaaS Framework, Scalable Computing: Practice and Experience (SCPE) 13 (3) (2012) 201–213. 905
[62] C. Pahl, P. Jamshidi, Microservices: A systematic mapping study, in: Proceedings of the 6th International Conference on Cloud Computing and Ser-
M
vices Science, 2016, pp. 137–146. doi:10.5220/0005785501370146. [63] A. Balalaie, A. Heydarnoori, P. Jamshidi, Microservices Architecture En-
ED
ables DevOps Migration to a Cloud-Native Architecture, IEEE SOFTWARE 33 (3) (2016) 42–52.
910
[64] Conway, Melvin E., How do Committees Invent?, Datamation 14 (5) (1968)
PT
28–31.
CE
[65] S. Newman, Building Microservices, O’Reilly Media, Incorporated, 2015. [66] D. Namiot, M. Sneps-Sneppe, On micro-services architecture, Int. Journal of Open Information Technologies 2 (9).
AC
915
[67] Adam Wiggins, The Twelve-Factor App, last access 2016-02-14 (2014). URL http://12factor.net/
[68] Martin Fowler, Circuit Breaker, last access 2016-05-27 (2014). URL http://martinfowler.com/bliki/CircuitBreaker.html
46
ACCEPTED MANUSCRIPT
920
[69] N. R. Herbst, S. Kounev, R. Reussner, Elasticity in cloud computing: What it is, and what it is not, in: Proceedings of the 10th International Conference on Autonomic Computing (ICAC 13), USENIX, San Jose, CA, 2013,
CR IP T
pp. 23–27. [70] A. B. Bondi, Characteristics of scalability and their impact on performance,
in: Proceedings of the 2nd International Workshop on Software and Per-
925
formance, WOSP ’00, ACM, New York, NY, USA, 2000, pp. 195–203. doi:10.1145/350391.350432.
last access 2016-05-27 (2014).
AN US
[71] Martin Fowler, Microservices - A Definition of this new Architectural Term,
URL http://martinfowler.com/articles/microservices.html
930
[72] Open Container Initiative, Open Container Runtime Specification, last access 2016-05-27 (2015).
M
URL https://github.com/opencontainers/runtime-spec
Appendix A. Unification of keywords
AC
CE
PT
935
ED
Appendices (Just for review, not intended for final publication)
47
applications,
engineering, Go,
Google Cloud platform,
Cloud-native
applications
development
bioinformatics,
biomedicine,
workflows, cloud
SaaS, Galaxy,
ED
computing, IaaS,PaaS,
PT
auto-scaling, GridFTP,
data transfer
[34]
Internet of Things,
x
x
x
CE
cloud SLA
management, cloud
AC
orchestration,
distributed cloud
computing, public
safety, service level
agreements, utility
demand response
48
x
x
Cloud costs (2)
Cloud artifacts (2)
Use Cases (15)
SLA for CNA (2)
x
Cloud Forensics (2)
CAP Properties (2)
Other
CNA Properties Elasticity (7)
Resilience (8)
DevOps (3)
Scalability (8)
x
M
[28]
Design Methodology (6)
AN US
application
Patterns (8)
CNA Methods
x
Deployment Unit (8)
Service Composition (7)
Microservices (11)
x
CNA Design (11)
x
Interoperability (8)
x
Softwarization (8)
x
Migration (8)
(*) Scalable
CR IP T
[21]
Keywords by Authors
Automation Platform (12)
Paper
CNA Principles
CNA Architecture
ACCEPTED MANUSCRIPT
Container
x
x
deployment, service
management,
x
x
x
x
x
x
x
x
construction, service
composition, cloud
[20]
(*) Microservice
x
PT
architecture,
ED
platform, container
application containers,
elastic scale, fault
CE
tolerance, automation
[24]
(*) Microservice
x
AC
architecture,
application containers,
elastic scale, fault
tolerance, automation
49
Cloud costs (2)
Other
x
x
M
application
x
Cloud artifacts (2)
Use Cases (15)
SLA for CNA (2)
Elasticity (7)
x
AN US
integration, Docker,
Cloud Forensics (2)
CAP Properties (2)
Resilience (8)
x
DevOps (3)
x
Patterns (8)
x
Microservices, System
(*) Kubernetes, service
Scalability (8)
x
CR IP T
x
Management tools,
[31]
CNA Properties
CNA Methods Deployment Unit (8)
x
Design Methodology (6)
Service Composition (7)
CNA Design (11)
Interoperability (8)
Softwarization (8)
x
Migration (8)
Cloud computing,
Microservices (11)
[16]
Keywords by Authors
Automation Platform (12)
Paper
CNA Principles
CNA Architecture
ACCEPTED MANUSCRIPT
native, microservices,
development,
resilience, elasticity,
scalability,
self-management
[35]
Cloud, Platform as a
x
Automation, Cloud
x
Cloud costs (2)
Cloud artifacts (2)
Use Cases (15)
Elasticity (7)
SLA for CNA (2)
Resilience (8)
DevOps (3)
Cloud Forensics (2)
Other
CNA Properties CAP Properties (2)
Design Methodology (6)
x
M
[17]
x
x
Service, Service
Composition
x
AN US
cloud computing, cloud
Scalability (8)
x
Patterns (8)
CNA Methods
x
Deployment Unit (8)
Service Composition (7)
Microservices (11)
CNA Design (11)
Interoperability (8)
Softwarization (8)
x
Migration (8)
Monitoring, cloud
CR IP T
[48]
Keywords by Authors
Automation Platform (12)
Paper
CNA Principles
CNA Architecture
ACCEPTED MANUSCRIPT
x
modeling, Data
PT
mining, Data
ED
computing, Context
structures, Runtime,
Virtual machine
CE
monitoring, Virtual
machine monitors
AC
[29]
autoscaling, aws, cloud
x
x
native, consolidated
billing, cost
optimization, netflix,
reservations
50
x
x
Internet Applications,
Web 2.0 services
x
x
x
Microservices,
Cloud-native
modernization
Cloud migration,
x
x
x
x
x
ED
Cloud architecture,
x
M
architectures, Software
[26]
Migration pattern,
[44]
PT
Multi-cloud
Cloud computing,
x
x
x
Vendor lock-in,
CE
Enterprise migration,
Cloud adoption, Cloud
API’s, Interoperability,
AC
Portability, Standards,
DevOps
51
Cloud costs (2)
Other Cloud artifacts (2)
Use Cases (15)
SLA for CNA (2)
Cloud Forensics (2)
CAP Properties (2)
Elasticity (7)
Resilience (8)
Scalability (8)
DevOps (3)
AN US
as a Service, Rich
Cloud migration,
CNA Properties
CNA Methods
x
Computing, Platform
[13]
Design Methodology (6)
Patterns (8)
Deployment Unit (8)
Service Composition (7)
Microservices (11)
CNA Design (11)
Interoperability (8)
Softwarization (8)
x
Migration (8)
Mobile Cloud
CR IP T
[41]
Keywords by Authors
Automation Platform (12)
Paper
CNA Principles
CNA Architecture
ACCEPTED MANUSCRIPT
AC service, software
development, software
engineering
[22]
ED
(*) Microservices, CNA
Cloud-native
architecture
DevOps, architectural
(*) Cloud-native
x
refactoring, cloud
computing,
microservices,
migration pattern,
mobile backend as a
x
Microservices (11) Service Composition (7) Deployment Unit (8) Patterns (8) Design Methodology (6)
Interoperability (8)
Softwarization (8)
Migration (8)
CNA Design (11)
x x x x x x x
Design, Recipes,
Migration,
x
x
architecture,
Microservices, Service
Decomposition,
Situational Method
Engineering (SME),
Migration, Pattern
52 x x
x
x
x
Cloud costs (2)
Cloud artifacts (2)
Cloud Forensics (2)
Use Cases (15)
SLA for CNA (2)
CAP Properties (2)
Elasticity (7)
Resilience (8)
Scalability (8)
DevOps (3)
CR IP T
AN US
[8] Automation Platform (12)
Paper Keywords by Authors
M
[10]
PT
CE
Other
CNA Properties
CNA Methods
CNA Architecture
CNA Principles
ACCEPTED MANUSCRIPT
AC PT
CE [49]
[33] (*) cloud native
programming
Deployment,
x
aggregate, topology,
provisioning, operation,
unification,
orchestration,
transformation,
meta-model, Cloud
x x
code transformation,
aspect-oriented
computing, DevOps
x
x
requirements, software
defined networking,
software defined
environments
53
Design Methodology (6)
Patterns (8)
Deployment Unit (8)
Service Composition (7)
Microservices (11)
CNA Design (11)
Interoperability (8)
Softwarization (8)
x
Cloud costs (2)
Cloud artifacts (2)
Cloud Forensics (2)
Use Cases (15)
SLA for CNA (2)
CAP Properties (2)
Elasticity (7)
Resilience (8)
Scalability (8)
DevOps (3)
CR IP T
AN US
(*) cloud migration, Migration (8)
Automation Platform (12)
Keywords by Authors
M
[45]
ED
Paper
Other
CNA Properties
CNA Methods
CNA Architecture
CNA Principles
ACCEPTED MANUSCRIPT
AC PT
CE 5G, Markov process,
virtualization (NFV),
network softwarization,
network virtualization,
resilience, social
network
[37]
[46] BBU, LTE, cloud
computing, cloud-ran,
open air interface,
RANnaaS,
Virtualization
cloud service,
Cloud computing,
x
x x
carrier, cloud, cloud
network function
x
software-defined,
elasticity capability,
elasticity quantification
x
FWaaS, Parallel
firewall, NFV
54
Design Methodology (6)
Patterns (8)
Deployment Unit (8)
Service Composition (7)
Microservices (11)
CNA Design (11)
Interoperability (8)
Softwarization (8)
Migration (8)
x
x
x
Cloud costs (2)
Cloud artifacts (2)
Cloud Forensics (2)
Use Cases (15)
SLA for CNA (2)
CAP Properties (2)
Elasticity (7)
Resilience (8)
Scalability (8)
DevOps (3)
CR IP T
AN US
[9] Automation Platform (12)
Keywords by Authors
M
[25]
ED
Paper
Other
CNA Properties
CNA Methods
CNA Architecture
CNA Principles
ACCEPTED MANUSCRIPT
AC [27]
Drive, models
[40]
[42]
[47] (*) hybrid cloud,
workload movement,
ED
Computing, Service
Composition,
Elasticity,
Multi-tenancy, Linked
Data, Knowledge
Management
SkyDrive, hybrid,
DropBox, Google
distributed
Cloud computing,
Information Modelling,
x x
Semantic Annotation,
Interoperability, Cloud
x
x
computation, grid
computing, cloud
computing, MetaPIGA
x
Portability,
Multi-Clouds
55
x
Design Methodology (6)
Patterns (8)
Deployment Unit (8)
Service Composition (7)
Microservices (11)
CNA Design (11)
Interoperability (8)
Softwarization (8)
Migration (8)
Automation Platform (12)
x
x
x x
x
x
SLA
x
Cloud costs (2)
Cloud artifacts (2)
Cloud Forensics (2)
Use Cases (15)
SLA for CNA (2)
CAP Properties (2)
Elasticity (7)
Resilience (8)
Scalability (8)
DevOps (3)
CR IP T
AN US
Paper Keywords by Authors
M
[39]
PT
CE
Other
CNA Properties
CNA Methods
CNA Architecture
CNA Principles
ACCEPTED MANUSCRIPT
design methodology,
cloud architectural
pattern, CAP
properties
(*) Patterns, CNA
ED
[7]
x
x
x
x
x
x
x
x
[11]
PT
architecture
CAP Theorem, Cloud
Patterns, Cloud-native
CE
Applications Design
[12]
cloud computing,
x
x
AC
cloud-native
applications, software
development,
methodology
56
x
Cloud costs (2)
Use Cases (15)
Cloud artifacts (2)
Other
x
SLA for CNA (2)
Elasticity (7)
Resilience (8)
Scalability (8)
DevOps (3)
Design, Cloud-native
Cloud Forensics (2)
CAP Properties (2)
x
M
(*) Patterns, CNA
architecture
x
AN US
(*) CAP theorem,
Design, Cloud-native
CR IP T
anti-fragility
[6]
CNA Properties
CNA Methods
x
microservices,
[15]
Design Methodology (6)
Patterns (8)
x
Deployment Unit (8)
Microservices (11)
x
Service Composition (7)
CNA Design (11)
Interoperability (8)
(*) weakly connected,
Softwarization (8)
[38]
Migration (8)
Keywords by Authors
Automation Platform (12)
Paper
CNA Principles
CNA Architecture
ACCEPTED MANUSCRIPT
web-scale, patterns,
microservices
x
(*) microservices,
monitoring, scalability
[14]
linear scalability,
resiliency, read/write
independence, support
[36]
(*) ROI, DBaaS,
x
x
x
x
outsourcing, decision
[30]
PT
making
x
Energy efficiency, big
data, cloud computing,
CE
energy management
systems
AC
[43]
[18]
Cloud costs (2)
Cloud artifacts (2)
Use Cases (15)
SLA for CNA (2)
Elasticity (7)
Resilience (8)
Scalability (8)
DevOps (3)
Cloud Forensics (2)
Other
CNA Properties CAP Properties (2)
Design Methodology (6)
Patterns (8)
Deployment Unit (8)
CNA Methods
x
x
ED
independence
x
M
for industrial
workloads, workload
x
AN US
[32]
Service Composition (7)
Microservices (11)
CNA Design (11)
Interoperability (8)
Softwarization (8)
Migration (8)
x
(*) anti-fragility,
CR IP T
[? ]
Keywords by Authors
Automation Platform (12)
Paper
CNA Principles
CNA Architecture
ACCEPTED MANUSCRIPT
x
Innovation, Business
x
Cloud forensics,
Cloud-native artifacts,
Google docs format,
Reverse engineering,
kumodd, kumodocs
57
x
AC Paper
PT
CE Research
ED
[28]
Validation
x
[20]
Validation
x
[41]
Validation
x
[45]
Validation
[25]
Validation
[19]
Validation x
x
x
x
x
58 x
x
x
x x
x
x
x
x
CNA Properties
x
x Cloud costs (2)
Cloud artifacts (2)
Approach Cloud Forensics (2)
Use Cases (14)
SLA for CNA (2)
CAP Properties (2)
CNA Methods
Elasticity (5)
Cloud artifacts (2)
x x
Appendix B. Mapping of keywords to research approaches
Other
Cloud costs (2)
Cloud Forensics (2)
Use Cases (15)
SLA for CNA (2)
CAP Properties (2)
Elasticity (7)
Resilience (8)
Scalability (8)
DevOps (3)
Design Methodology (6)
Patterns (8)
Deployment Unit (8)
Service Composition (7)
Microservices (11)
CNA Design (11)
Interoperability (8)
Softwarization (8)
Migration (8)
CR IP T
kumodd, API-based
Resilience (7)
storage forensics,
Scalability (8)
DevOps (3)
CNA Architecture
Design Methodology (6)
CNA Principles
Patterns (7)
Box
AN US
Dropbox, OneDrive,
Deployment Unit (4)
Google Drive,
Service Composition (7)
M
evidence acquisition,
Microservices (10)
CNA Design (12)
Interoperability (8)
Cloud forensics, cloud Automation Platform (12)
[19]
Softwarization (8)
Keywords by Authors
Migration (10)
Automation Platform (12)
Paper
Other
CNA Properties
CNA Methods
CNA Architecture
CNA Principles
ACCEPTED MANUSCRIPT
ACCEPTED MANUSCRIPT
[36]
Evaluation
[21]
Solution
x
x
[28]
Solution
x
x
[34]
Solution
x
[16]
Solution
x
[20]
Solution
x
[24]
Solution
x
[35]
Solution
[17]
Solution
[41]
Solution
AC
x
x
x
x
x
AN US
x
x
x
x
x
x
x
M
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
ED
x
x
x
x
x
x
x
Solution
x
Solution
x
CE
[45]
x
PT
[8]
x
x
x
x
x
x
x
[22]
Solution
x
[49]
Solution
x
[9]
Solution
x
[25]
Solution
x
[37]
Solution
x
[46]
Solution
x
[39]
Solution
x
[15]
Solution
x
x
x
x
x
x
x
x
x
Cloud costs (2)
Evaluation
Cloud artifacts (2)
[26]
Cloud Forensics (2)
Evaluation
x
Use Cases (14)
[14]
x
x
SLA for CNA (2)
Evaluation
x
CAP Properties (2)
[9]
x
Elasticity (5)
x
Resilience (7)
x
Other
CR IP T
Evaluation
Approach
CNA Properties
Scalability (8)
[48]
DevOps (3)
x
Design Methodology (6)
x
Patterns (7)
x
CNA Design (12)
x
Interoperability (8)
Evaluation
Research
Softwarization (8)
[16]
Paper
Migration (10)
Deployment Unit (4)
CNA Methods
Service Composition (7)
CNA Architecture
Microservices (10)
Automation Platform (12)
CNA Principles
x
x
x
x
59
x
x
x
x
ACCEPTED MANUSCRIPT
x
x
[11]
Solution
x
x
[12]
Solution
x
[30]
Solution
[18]
Solution
[19]
Solution
[16]
Survey
[26]
Survey
x
x
[44]
Survey
x
x
[33]
Survey
[27]
Survey
[47]
Survey
[43]
Survey
[31]
Opinion
[29]
Opinion
AC
x
x
x
x
Cloud costs (2)
Use Cases (14)
SLA for CNA (2)
CAP Properties (2)
Elasticity (5)
Resilience (7)
AN US
x
x
x
x
x
x
x
x
M
x
x
x
ED
x
x
x
x
x
x
Opinion
x
x
x
x
x
Opinion
CE
[32]
x
x
x
PT
[33]
x
Cloud artifacts (2)
Solution
Cloud Forensics (2)
[7]
Other
CR IP T
Approach
CNA Properties
Scalability (8)
DevOps (3)
Design Methodology (6)
Patterns (7)
CNA Methods
Deployment Unit (4)
Service Composition (7)
Microservices (10)
CNA Design (12)
CNA Architecture
Interoperability (8)
Softwarization (8)
Research
Migration (10)
Paper
Automation Platform (12)
CNA Principles
x
[43]
Opinion
[28]
Experience
x
[29]
Experience
x
[13]
Experience
x
[26]
Experience
x
[8]
Experience
x
x
x
[10]
Experience
x
x
x
[22]
Experience
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
60
x
x
x
x
x
x
x
x
AC PT
CE ED
[39] Experience x
[40] Experience x
[42] Experience x
[38] Experience x
[6] Experience x
[7] Experience x
[? ] Experience
[14] Experience
[43] Experience
[18] Experience x
61
x
x x
x
x
x
x
x
x
x
x
x
x
x
x
CNA Properties
x x
Cloud costs (2)
Cloud artifacts (2)
x
Cloud Forensics (2)
Use Cases (14)
SLA for CNA (2)
CAP Properties (2)
Elasticity (5)
CNA Methods
Resilience (7)
Scalability (8)
CR IP T
Approach DevOps (3)
Design Methodology (6)
CNA Architecture
Patterns (7)
Deployment Unit (4)
Service Composition (7)
Microservices (10)
CNA Design (12)
Interoperability (8)
Softwarization (8)
Migration (10)
CNA Principles
AN US
Research
M
Paper Automation Platform (12)
ACCEPTED MANUSCRIPT
Other
ACCEPTED MANUSCRIPT
Nane Kratzke is Professor for Computer Science and Business Informa940
tion Systems at Lbeck University of Applied Sciences (Germany) and head of the cloud computing research group at the Center of Excellence for Commu-
CR IP T
nication, 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 945
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 re-
AN US
search group at the Center of Excellence for Communication, Systems and Ap-
plications (CoSA, Lbeck University of Applied Sciences, Germany). His main 950
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
AC
CE
PT
ED
M
career he was a software and quality engineer for medical information systems.
62
Understanding Cloud-native Applications after 10 Years of Cloud Computing - A Systematic Mapping Study Nane Kratzke, Peter-Christian Quint PII: DOI: Reference:
S0164-1212(17)30001-8 10.1016/j.jss.2017.01.001 JSS 9905
To appear in:
The Journal of Systems & Software
Received date: Revised date: Accepted date:
23 September 2016 30 November 2016 4 January 2017
Please cite this article as: Nane Kratzke, Peter-Christian Quint, Understanding Cloud-native Applications after 10 Years of Cloud Computing - A Systematic Mapping Study, The Journal of Systems & Software (2017), doi: 10.1016/j.jss.2017.01.001
This is a PDF file of an unedited manuscript that has been accepted for publication. As a service to our customers we are providing this early version of the manuscript. The manuscript will undergo copyediting, typesetting, and review of the resulting proof before it is published in its final form. Please note that during the production process errors may be discovered which could affect the content, and all legal disclaimers that apply to the journal pertain.
ACCEPTED MANUSCRIPT
Highlights • The outcomes of a systematic mapping study on cloud-native applications
CR IP T
(CNA) are presented. • Identified principles, architectures, and methodologies for CNA are explained.
• Existing engineering trends for cloud-native applications are summarized. • Research implications of existing CNA studies are discussed.
AC
CE
PT
ED
M
AN US
• Promising future research directions for CNA engineering are proposed.
1
ACCEPTED MANUSCRIPT
Understanding Cloud-native Applications after 10 Years of Cloud Computing - A Systematic Mapping Study
CR IP T
Nane Kratzke1 , Peter-Christian Quint eMail:{nane.kratzke,peter-christian.quint}@fh-luebeck.de L¨ ubeck University of Applied Sciences Center of Excellence for Communcation, Systems and Applications M¨ onkhofer Weg 239 23562 L¨ ubeck, Germany
AN US
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
M
(2006) which seems somehow obvious nowadays. But the term disappeared almost completely. Suddenly and in the last years the term is used again more
ED
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.
PT
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 publi-
CE
cations and already existing and well-defined terminology into account. Keywords: Cloud-native application, CNA, systematic mapping study, elastic
AC
platform, microservice, self service, pattern, softwareization 2016 MSC: 00-01, 99-00
1 Corresponding
author.
Preprint submitted to Journal of Systems and Software
January 5, 2017
ACCEPTED MANUSCRIPT
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
5
CR IP T
20062 ) 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. Although terms like public/private/hybrid cloud com-
puting 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
AN US
10
often understood in differing ways. Gladfully, the mentioned terms are defined precisely by the NIST definition of cloud computing [1]. But there remains confusion with more specific topics in cloud computing like cloud-native applications (CNA). This contribution investigates a more precise understanding of the term ”cloud-native”.
M
15
According to Figure 1 and Google trends the term ”cloud-native” has an unusual diffusion rate over time. In birthday times of cloud computing – so about
ED
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
PT
20
Google. But since 2015, the term is more and more frequently used again and gained momentum (see Figure 1). We have to admit that Google trends is not
CE
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 Figure 1 and Figure 5a). Furthermore, our data indicates that the current understand-
AC
25
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 2 https://aws.amazon.com/releasenotes/122
3
(last access 5th July 2016)
CR IP T
ACCEPTED MANUSCRIPT
Figure 1: Google trends (01.01.2006 until 22.05.2016) of the term ”cloud-native”
suddenly popular in industry, but not before 2015 (according to Google trends, see Figure 1). We assume this sudden rise in industry has to do with the cur-
AN US
30
rent 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. However, the reader will see, that ”cloud-native” concepts are reflected for a while in research. So, although the 35
term seems to be new, it is not. It simply never has been wide spread. How-
M
ever, some contributions providing valuable insights what additional properties an application must fulfill to be called ”cloud-native” compared with classical
ED
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 40
more precise with regard to the term ”cloud-native”.
PT
Therefore this contribution is outlined as follows: In Section 2 we will explain our systematic mapping and adaptive reading steps. Furthermore, we
CE
introduce our research questions and present our data. We make a comparative analysis of the data (main outcome of our systematic mapping study) regarding
45
our research questions in Section 3. We discuss existing strengths and weak-
AC
nesses 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
50
able to propose a definition for the term ”cloud-native” in Section 5 taking all
4
CR IP T
ACCEPTED MANUSCRIPT
Figure 2: Research process (a combination of the process for performing systematic mapping studies and systematic literature reviews.
in Section 6.
2. Research Methodology
AN US
identified literature into consideration systematically. We conclude our findings
We aligned our research according to general guidelines for systematic map55
ping studies in software engineering [2, 3] and for systematic literature reviews
M
[4]. Additionally, we took updates and critical reflections [5] on these guidelines into consideration. Systematic mapping studies and systematic literature
ED
reviews are analyzing primary studies. A primary study is ”an empirical study investigating a specific research question” [4]. Reviews and mapping studies 60
are so called secondary studies. A secondary ”study [...] reviews all the pri-
PT
mary studies relating to a specific research question with the aim of integrating/synthesizing evidence related to a specific research question” [4]. A system-
CE
atic literature review ”uses a well-defined methodology to identify, analyze and interpret all available evidence related to a specific research question in a way
65
that is unbiased and (to a degree) repeatable” [4]. Other than that, a scoping or
AC
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” [4]. According to guidelines for systematic maps and reviews in software engi-
neering, we used both approaches complementary [3]. Due to the insight that
70
”systematic maps can summarize and help transfer results to practitioners” [3] better, we decided to keep the focus on the systematic mapping process and used 5
ACCEPTED MANUSCRIPT
Table 1: Results (Papers might be listed in two or more sources) Oldest
Youngest
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
CR IP T
Papers
AN US
Electronic Source
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 out75
comes are mainly discussed in Section 4. The same is true for selecting relevant
M
papers to derive a definition proposal for cloud-native applications (see Section 5). This process combination is visualized in Figure 2 and explained in the following paragraphs. The second author of the study performed detailed quality
80
ED
control checks on each of these presented steps and intermediate outcomes. 2.1. Research Scope and Research Questions
PT
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.
CE
But cloud environments are elastic. Elasticity is understood as the degree to which a system adapts to workload changes by provisioning and de-provisioning
85
resources automatically. Over the time system engineers understand the elastic-
AC
ity options of modern cloud environments better and they intentionally designed systems for such elastic cloud infrastructures. This intention is often expressed using the term ”cloud-native”. Therefore, our literature review has been guided by the following research questions defining our research scope:
90
• [RQ1] Where does the term ”cloud-native” come from? 6
ACCEPTED MANUSCRIPT
Table 2: Inclusion and exclusion criteria Inclusion
application design, engineering or operation in broadest sense.
Exclusion
CR IP T
(1) Keynotes, conference papers, journal papers, books and book chapters dealing with cloud-native
(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)
AN US
(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,
M
keynote) (5) Publication language was not English.
ED
• [RQ2] Is there a common understanding of the term ”cloud-native”? • [RQ3] What are existing trends in cloud-native application engineering?
PT
• [RQ4] What promising trends for future cloud-native research and engi-
CE
neering can be deduced?
95
2.2. Conduct Search for Primary Studies So far, the terms ”cloud-native” or ”native cloud” are not very intensively
AC
used in literature. However, they show increasing momentum and are emerging from an evolutionary process starting with the service-oriented architecture approach, system virtualization, cloud computing, operating system virtualization
100
(aka container) and ending in a recently most popular approach: microservices. We conducted our search for studies in the electronic sources listed in Table 1 (according to recommendations for performing literature reviews in software 7
ACCEPTED MANUSCRIPT
engineering [2, 5]). We searched for contributions published in or after 2006 having the term ”cloud-native” or ”cloud native” in their title, abstract or key105
words. However, we did not perform a full text search. We argue, that the
CR IP T
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 110
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
AN US
to include relevant publications like [6]. These kind of publications would have otherwise fallen through our search filters. This would have become problematic especially in case of [6], which turned out to be one of the most valuable sources 115
in understanding cloud-native applications.
2.3. Screening of Papers for Inclusion and Exclusion
M
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
ED
relevant to answer our research questions.
Experience
Opinion
Survey
Solution
Evaluation
Title (shortened)
Year
Type
Cloud Computing Patterns
2014
Book
x
x
CE
[6]
Validation
ID
PT
Table 3: Included and categorized papers (unsorted to avoid any bias)
[7]
Cloud Computing Design Patterns
2015
Book
x
x
[8]
Migrating to Cloud-Native Application
2015
Book
x
x
2016
Journal
2016
Journal
2012
Conf.
AC
Architectures
[9]
[10]
On Service Resilience in Cloud-Native 5G
x
x
Mobile Systems Microservices Architecture Enables DevOps:
x
Migration to a Cloud-native Architecture [11]
Designing for CAP
8
x
ACCEPTED MANUSCRIPT
2014
Conf.
and Deployment of Cloud Applications [13]
Migrating to Cloud-Native Architectures
2016
Chapter
[14]
Scalability and Robustness of Time-series
2014
Conf.
Databases for Cloud-native Monitoring of
[15]
CAP-Oriented Design for Cloud-Native Applications
2013
Chapter
[16]
Docker Cluster Management for the Cloud
2016
Journal
[17]
Touchless and always-on cloud analytics as
2016
Journal
a service
x
x
x
AN US
Industrial Processes.
Experience
Madcat: A Methodology for Architecture
Opinion
[12]
Survey
Type
Solution
Year
Evaluation
Title (shortened)
CR IP T
ID
Validation
Continuation of Table 3: Included and categorized papers
x
x
x
x
x
Forensic analysis of cloud-native artifacts
2016
Journal
[19]
Forensic Acquisition of Cloud Drives
2016
Journal
x
x
[20]
Towards a Cloud-Native Radio Access
2016
Chapter
x
x
2015
Chapter
x
x
Microservices Migration Pattern
2016
Journal
x
x
Migrating to Cloud-native Architectures
2015
Conf.
[21]
Building Go Web Applications on Google
[23]
PT
Cloud [22]
ED
M
[18]
Network
x
x
x
x
x
CE
Using Microservices: An Experience Report Service Fabric
2015
Chapter
[25]
Processing Radio Access Network Functions
2015
Conf.
2015
Book
AC
[24]
[26]
[27]
x x
x
in the Cloud: Critical Issues and Modeling Cloud Migration Patterns: A Multi-cloud Service Architecture Perspective
x
x
Chapter
Era of Cloud Computing: A New Insight to
2015
Hybrid Cloud
9
Journal
x
x
ACCEPTED MANUSCRIPT
2016
Journal
with auto-scaling resources for executing bioinformatics andbiomedical workflows [29]
Cloud Native Cost Optimization
2015
Keynote
[30]
Energy Cloud: Real-Time Cloud-Native
2014
Conf.
x
x
x
x
x
x
x
AN US
Energy Management System to Monitor and
Experience
Building an open source cloud environment
Opinion
[28]
Survey
Type
Solution
Year
Evaluation
Title (shortened)
CR IP T
ID
Validation
Continuation of Table 3: Included and categorized papers
Analyze Energy Consumption in Multiple Industrial Sites
Kubernetes and the Path to Cloud Native
2015
Keynote
x
[32]
Microservices for Scalability: Keynote Talk
2016
Keynote
x
[33]
Acceleration of Cloud Computing
2014
Conf.
[34]
Handling Performance Sensitive Native
2013
Conf.
x
2012
Conf.
x
2010
Conf.
QUELLE - A Framework for Elastic Systems
2014
Chapter
Toward an Anti-fragile e-Government
2016
Chapter
2013
Chapter
M
[31]
x
x
Cloud Applications with Distributed Cloud
[35]
ED
Computing and SLA Management
4CaaSt: Comprehensive Management of Cloud Services through a PaaS
[37] [38]
Cloud Database-as-a-Service (DaaS) - ROI
PT
[36]
x x x
CE
System
[39]
Cloud Services Composition Support by
x
x
AC
Using Semantic Annotation and Linked Data
[40]
The Hybrid Cloud
2016
Chapter
[41]
MobiCloUP!: a PaaS for cloud
2014
Journal
services-based mobile applications
10
x x
x
ACCEPTED MANUSCRIPT
2014
Chapter
A Case Study [43]
Opportunities to Innovate Today
2013
Chapter
[44]
Critical analysis of vendor lock-in and its
2016
Journal
impact on cloud computing migration: a
[45]
x
x
Cloud Detours: A Non-intrusive Approach
x
x
x
AN US
business perspective 2015
Conf.
x
x
2015
Conf.
x
x
2014
Journal
2015
Conf.
2014
Conf.
x
2016
Conf.
x
2016
Conf.
x
2016
Keynote
for Automatic Software Adaptation to the Cloud [46]
CPFirewall: A Novel Parallel Firewall
Environment [47]
Portability in Clouds: Approaches and
ED
Research Opportunities [48]
M
Scheme for FWaaS in the Cloud
Experimental Evaluation of the
x
x
Cloud-Native Application Design
Deployment Aggregates - A Generic
PT
[49]
Deployment Automation Approach for Applications Operated in the Cloud Cloud-native Event-based Programming for
CE
[50]
Mobile Appls
AC
[51]
[52]
QoE-aware elasticity support in cloud-native 5G systems Native Cloud Applications: Why Virtual Machines, Images and Containers Miss the Point!
11
Experience
A Hybrid Grid/Cloud Distributed Platform:
Opinion
[42]
Survey
Type
Solution
Year
Evaluation
Title (shortened)
CR IP T
ID
Validation
Continuation of Table 3: Included and categorized papers
x
x
ACCEPTED MANUSCRIPT
2016
Chapter
2016
Conf.
Cloud-native Application Provisioning for SMEs by Integrating Already Available Container Technologies [54]
ClouNS - A Cloud-native Application
120
x
x
AN US
Reference Model for Enterprise Architects
Experience
Project Cloud TRANSIT - Or to Simplify
Opinion
[53]
Survey
Type
Solution
Year
Evaluation
Title (shortened)
CR IP T
ID
Validation
Continuation of Table 3: Included and categorized papers
2.4. Categorization of Papers (Keywording of Abstracts)
According to [2] and if possible, existing classification schemes should be used for topic specific classification of papers. We checked IEEE, ISO/IEC as well as Swebok standards [55] but found no appropriate classification system.
125
M
So, like a majority of mapping studies [2] we were forced to derive our own toic specific classification scheme. We did this using the process shown in Figure
ED
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 [3]) and derived meaningful keywords on our own based on the title and the abstract.
130
PT
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
CE
adaptive reading and evaluated introduction and conclusion sections as well to derive meaningful keywords.
AC
In further steps we unified author provided keywords into a unified keyword
135
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 properties are 12
AN US
CR IP T
ACCEPTED MANUSCRIPT
Figure 3: Keywording of selected papers
achieved and how transferability of a CNA can be realized. According to selected
M
140
papers, CNAs should be operated on automation platforms. Softwarization of infrastructures should be strived for to support DevOps principles more conse-
ED
quently. 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
PT
145
architecture approaches (particular the microservice architecture approach) as well as accompanying service composition principles of self-contained deploy-
CE
ment units (containers). CNA methods include patterns and design methodologies to create effec-
tive CNA architectures and DevOps to automate the process of delivery and
AC
150
infrastructure changes. These methods are applied frequently in CNA context. CNA properties describe characteristics of CNA. Such characteristics deal-
ing with consistency models, availability, partition tolerance (all strongly related to Brewer’s CAP theorem [56]), elasticity, resilience and service levels (SLA).
155
This property combination seems to be very characteristic for CNA according
13
ACCEPTED MANUSCRIPT
Table 4: Topic specific categories 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 Cases
telecommunication, industrial processes, bioinformatics,videostreaming service
CR IP T
Research Topic
providers, energy management and experiences with public cloud services (likely
Other
AN US
incomplete)
forensics, cloud-native artifacts, costs,decision making (likely incomplete)
to selected papers.
Further keywords dealt with use cases. These use cases can be categorized into the following domains: telecommunication, industrial processes, bioinfor-
160
M
matics, 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
ED
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
165
PT
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
CE
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
AC
answer our research questions (see Section 2.1). First of all, each paper is
170
evaluated according to its publication year. This is documented in Table 3 and visualized in Figure 5a. Due to the fact, that we could only consider publications until September of 2016, we extrapolated (linearly) the estimated publications for the complete year 2016. We use this to search for the origin of
14
ACCEPTED MANUSCRIPT
Book 8%
Book Chapter (2 peer review rounds) 26%
Validation/ Evaluation 19%
Journal (1 peer review round) 24%
Experience Report 27%
Solution Proposal 35%
(a) Contribution types
AN US
Keynote 8%
Survey 10%
CR IP T
Conference (1 peer review round) 34%
Opinion 9%
(b) Research approaches
Figure 4: Distribution of selected papers
the term ”cloud-native”. This will be discussed in Section 3.1.
Each paper is assigned a contribution type (book, book chapter, journal
M
175
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 map-
ED
ping studies to cover keynotes. We decided to do so. Mainly, because some of the keynotes like [31] by E. Brewer are highly influential in the cloud-native domain. According to the best of our knowledge all keynotes we selected are
PT
180
published/listed in the proceedings of the respective conferences. This is documented in Table 3 and the distribution across contribution types is visualized
CE
in Figure 4a.
We decided to classify selected papers by their research type according to
an existing classification of research approaches (proposed by [57] and summa-
AC
185
rized 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 [5] that there arise a lot of discussions whether a study is a validation or evaluation study, we decided to group both re-
190
search types as equal. This is documented in Table 3 and the distribution across
15
Table 5: Research approaches
CR IP T
ACCEPTED MANUSCRIPT
Description
Evaluation/
Evaluation means that techniques are implemented in practice and an evaluation of the
Validation
technique is conducted. It is shown how the technique is implemented in practice (solution
Research
implementation) and what are the consequences of the implementation in terms of benefits
AN US
Category
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.
A solution for a problem is proposed, the solution can be either novel or a significant extension
Proposal
of an existing technique. The potential benefits and the applicability of the solution is shown
M
Solution
Survey Papers
ED
by a small example or a good line of argumentation. 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. These papers express the personal opinion of somebody whether a certain technique is good or
PT
Opinion Papers
bad, or how things should been done. They do not rely on related work and research methodologies. Experience papers explain on what and how something has been done in practice. It has to be
Reports
the personal experience of the author.
AC
CE
Experience
16
ACCEPTED MANUSCRIPT
contribution types is visualized in Figure 4b. 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
195
CR IP T
the methodology being described in Figure 3. The distribution of the main and detailed research topics in selected papers is visualized in Figure 5b and Figure
5c. 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
AN US
200
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 Figure 6 and will be used in Section 3.3 to discuss most investigated cloud-native topics. The scope of the research topics 205
are explained in Table 4.
M
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.
ED
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 210
more correlated than others. The resulting mapping of correlated detail research
PT
terms is presented in Figure 7. However, the reader should be aware that we did this detail research only for the identified main research topics and not for
CE
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).
215
Both mappings are used in Section 3.3 to discuss and reflect most investigated
AC
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 [2, 5]. Because 220
of selected electronic sources (see Table 1) and selection criteria (see Table 2) 17
ACCEPTED MANUSCRIPT
25
CNA Principles
20
CNA Architecture
15
CNA Properties
10
Use cases
5
CNA Methods 0 2007
2008
2009
2010
Published Papers
2011
2012
2013
2014
30% 25%
30%
40%
50%
60%
Other aspects
(b) Main research topics
M
20%
(c) Detailed research topics (without use cases) Figure 5: Distribution of research topics of selected papers
18
SLA for CNA
CAP Properties
DevOps
Design Methodology
Elasticity
Service Composition
Deployment Units
Resilience
Patterns
Scalability
Softwareization
Migration
PT Microservices
CNA Design
Automation Platform
CE
Interoperability
ED
15% 10% 5% 0%
2016
Extrapolation (for 2016)
(a) Publications over years
AC
2015
20%
AN US
2006
10%
70%
CR IP T
0%
30
AN US
CR IP T
ACCEPTED MANUSCRIPT
Figure 6: Mapping of research topics to research approaches
mainly academic and mostly peer-reviewed contributions should turn up. So, in
M
accordance to electronic sources and selection 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
ED
225
how much peer reviewing is accumulated along this process. A lot of research
PT
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
CE
230
are (only) written without formal peer reviewing involved, these books rely on
AC
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
235
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
19
ACCEPTED MANUSCRIPT
in a specific field of research. According to Figure 4a 78% of selected papers are from sources where it 240
is likely that there has been involved at least one peer review round. 54% of
CR IP T
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
contributions (keynotes and books) are contributions likely without a formal peer reviewing process. But these contributions rely on a lot of peer reviewed 245
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.
AN US
Section 5 will additionally include the outcomes of data extraction and synthesis steps of the systematic literature review shown in Figure 2 and discussed in Section 4. 250
2.7. Threats of Validity
According to [2] there are common validity threats for systematic mapping
M
studies. Therefore, we reflect on possible threats which might arise from this study.
255
ED
The theoretical validity might be incomplete due to not published new and controversial views on cloud-native applications. CNAs looking back on 10 years of cloud computing history. However, the term ”cloud-native” just re-
PT
cently 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 ”cloud-native”. Further-
CE 260
more, there are controversial discussions dealing with microservices and service
AC
oriented architectures (SOA) [52]. 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
265
to harden this fact. The descriptive validity might be insufficient for specific aspects. Ac-
cording to Figure 6 there are less evaluating or validating studies than solution 20
ACCEPTED MANUSCRIPT
proposals. That might indicate that our search filters omitted evaluating and validating studies. However, we think, this just describes the current state of 270
research. We had a broad view on CNA and searched not intentionally for spe-
CR IP T
cific 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 275
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. Never-
AN US
theless, 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 [54] relies 280
partly on action research. We are aware, that action research is seen by some researchers as a non-objective research method (or not a research method at all). Therefore, the reader should take especially [54] into additional considera-
M
tion 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 en-
ED
285
gineering [2], the second author responsible for quality assurance steps was not involved intentionally in [54] research to minimize such kind of researcher bias
PT
for this mapping study.
CE
3. Discussion of Research Questions We will discuss our research questions in this Section mainly on a quan-
290
titative and comparative basis. To avoid any bias we avoid any unnecessary
AC
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
295
reading steps.
21
ACCEPTED MANUSCRIPT
3.1. Origin of the term ”cloud-native” [RQ1] According to Figure 5a the first contributions using the term ”cloud-native” have been published in 2012 [11, 35]. Both conference papers proposed solu-
300
CR IP T
tions for cloud-native application engineering. [11] proposes a pattern-based solution for a cloud-native application design methodology based on systemat-
ically identifying consistency, availability and network partitionability requirements (according to the CAP theorem presented by Brewer et al. [58, 59, 60]).
The authors of this contribution are all from the research group headed by Frank Leymann (Institute of Architecture and Application Systems, University
of Stuttgart, Germany). The paper itself references several other papers dealing
AN US
305
with pattern-based approaches. But none of these papers use the term ”cloudnative” until [11]. Several further papers of this research group focus similar topics, often model- and pattern-based approaches. Our study selection contains at least three papers by this research group. E.g. the TOSCA standard is 310
heavily influenced by the work of this research group.
M
The second paper [35] is about 4CaaSt, a ”PaaS framework that enables flexible definition, marketing, deployment and management of Cloud-based ser-
ED
vices and applications. The major innovations proposed [...] are [...] lifecycle management, a one stop shop for Cloud services and a PaaS level resource 315
management featuring elasticity, [...] a portfolio of ready to use cloud-native
PT
services and Cloud-aware immigrant technologies”. The 4CaaST project was an EU funded project and the authors of the publication are from various aca-
CE
demic and industrial research institutions: Telefonica, Tilburg University, SAP Research Centre, University of St. Gallen, University of Madrid, Nokia Siemens
320
Networks, Orange Labs and Ericsson Research Center. However, the already
AC
mentioned Institute of Architecture and Application Systems was involved in additional publications covering the 4CaaSt project as well. The publications [11, 61] were – according to the acknowledgement – at least partly funded by the 4CaaSt project.
325
It is interesting to see, that both publications focus aspects like pattern based approaches [11] and automation platforms [35] which are intensively reflected in 22
ACCEPTED MANUSCRIPT
several other selected papers as well. Figure 7 shows the correlation on research topics. The reader sees that the research topic automation platform is intensively correlated to cloud-native architecture topics and cloud-native application properties like scalability, re-
CR IP T
330
silience and elasticity. The same is true for patterns which are intensively correlated to cloud-native application 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. [6] as one of the most helpful and complete 335
sources systematizing a lot of cloud-native application aspects. This contri-
AN US
bution is derived by and integrates several other publications (beginning with [11]) 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 340
major contributions to a better understanding of the term ”cloud-native”.
M
3.2. Meaning of the term ”cloud-native” [RQ2]
Although there exist no precise definition what a cloud-native application
ED
exactly is, we can conclude that there is a common but unconscious understanding across all analyzed papers. According to Section 2.4 and Figure 7, 345
cloud-native applications (CNA) should be build according to corresponding
PT
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 princi-
CE
ples enable to build CNA architectures (mainly service-based and often with
350
self-contained deployment units involved) with specific and wishful CNA prop-
AC
erties (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
355
these CNA topics (principles, architecture, methods and resulting properties) are influencing each other. However, some topics and their interdependencies 23
ED
M
AN US
CR IP T
ACCEPTED MANUSCRIPT
Figure 7: Correlation of research topics
PT
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).
CE
360
AC
3.3. Existing trends in cloud-native engineering [RQ3] According to Figure 5b, 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 plat-
365
forms are named elastic platforms by Fehling et al. [6]. In industry we see this trend as well. There is currently a lot of interest in platforms like Apache Mesos,
24
ACCEPTED MANUSCRIPT
Kubernetes, Docker Swarm and so on. Another important focus can be seen in appropriate architectures of cloudnative applications. An intensively focused detail topic is how to create an appropriate design of a cloud-native application. Most authors focus service-
CR IP T
370
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 [62, 23]. However, the question remains whether microservices are 375
something new or just a specific (maybe more pragmatic) approach of the service
AN US
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’ 380
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,
M
accompanying the term microservice there is an increasing focus on container technologies as well in industry. The interest is mainly due to the opportunity
ED
to create self-contained deployment units in a standardized form. The correlation of research topics is interesting as well (see Figure 7). CNA
385
design seems to be highly correlated with patterns. The same is true for mi-
PT
croservices and deployment units. Automation platforms are often mentioned beside architectural topics like microservices, service composition, and deploy-
CE
ment units. Furthermore, CNA properties like scalability, resiliency and elas390
ticity are mentioned very often in the same papers. So, automation platforms are seen by a lot of authors as an enabler to realize sustainable CNA archi-
AC
tectures. 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
395
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. 25
ACCEPTED MANUSCRIPT
3.4. Promising research directions [RQ4] Figure 6 shows, that there is a clear focus on solution proposals in research 400
dealing with cloud-native application engineering. The proposals cover mainly
CR IP T
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 405
would be reflected by a lot of survey studies which might end in new insights.
Looking at Figure 6, we see that this maturity seems not to be reached so
AN US
far in cloud-native application research. Insights in shortcomings of existing approaches are derived mainly from experience reports focusing CNA principles
and architectures. Methods and properties of CNA applications seem a bit un410
derrepresented 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
M
principles or architectures. 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
ED
415
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
PT
Figure 6). However, we will cover this aspect in Section 4 in more details.
CE
4. Engineering Trends and Possible Future Directions [RQ4] So far, we mainly have done a quantitative and comparative analysis on
420
AC
the identified paper population. In this Section we investigate identified cloudnative 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
425
open research topics (denoted as (TOPIC.NR) in text) which are listed in Table 6 and will be discussed in following sections.
26
CR IP T
ACCEPTED MANUSCRIPT
Table 6: Open research topics (without claim to be complete) Id
Valuable research directions
CNA Prin-
PRINC.1
Design of elastic intermediary platforms for multi-cloud sce-
PRINC.2
Transferability of CNA for hybrid or multi-cloud scenarios
METH.1
Long term implications of DevOps/microservice based engi-
METH.2
CNA specific engineering methodologies (intentionally cover-
METH.3
Compositional programming languages for CNA.
ARCH.1
Reference models for CNA.
ciples
narios.
AN US
Topic
(deeply related to ARCH-1/2). CNA Methods
neering methodologies.
Ar-
chitecture
ARCH.2
Standardization of elastic intermediary platforms.
ARCH.3
Integration of isolated trends (service, ).
PROP.1
Elasticity of stateful CNA components.
PROP.2
Synchronizing platform and application elasticity.
PROP.3
Security engineering for (multi-cloud) CNA.
PT
CNA Prop-
ED
CNA
M
ing elasticity).
AC
CE
erties
27
ACCEPTED MANUSCRIPT
4.1. Research Implications of CNA Principles We identified a trend to operate CNA not directly on IaaS infrastructures but on intermediary elastic platforms [6, 54]. This simplifies engineering, deploying and operating of CNAs and leverages softwareization of infrastructure
CR IP T
430
and networks. It even contributes to more economic operation of CNAs [29]. This has been done in past research often via specialized PaaS platforms [35, 41]
but these platforms have the tendency to create platform lock-ins [44]. So, in recent years there is a trend to encapsulate arbitrary software in standardized 435
and self-contained deployment units (containers) and to operate these units on
AN US
container clusters like Apache Mesos, Kubernetes, Docker Swarm [31, 16]. 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
440
fruitful research has been done for the question how existing legacy applications
M
can be migrated to cloud environments and how these applications must be transformed to be ”cloud-native” [23, 26, 10]. However, this obviously focus no
445
ED
systems intentionally designed for the cloud. Other interesting approaches focus how to design applications to be deployable to arbitrary environments often including but not limited to cloud-environments [45, 49]. But interoperability
PT
or portability in hybrid or multi-cloud scenarios (PRINC-2) seems to be only considered by single case or survey studies so far [42, 47]. But
CE
exactly this would be necessary to overcome vendor lock-in vulnerabilities of 450
CNAs [44].
AC
4.2. Research Implications of CNA Methodologies A lot of studies report about trends to use microservices [8, 23, 26, 48, 63, 32],
to use DevOps [24, 63] or to make use of softwareization [9, 25, 28, 33, 37, 46] to realize and operate CNAs pragmatically. These trends seem to be widely ac-
455
cepted and preferred. However, microservices, DevOps and softwarization shift more realizing autonomy to small development and operation teams. Especially 28
ACCEPTED MANUSCRIPT
the microservices approach motivates this intentionally [8]. But we found no study that dealt with the consequences. Microservice followers often cite Conways Law3 . However, according to this law the organizational (two pizza4 ) structures coming along with microservices and DevOps principles should lead
CR IP T
460
to more heterogeneous 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 components. But according to Conway [64] this 465
should result in increased heterogeneity (which most other approaches would like
AN US
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 470
the tendency to become hardly maintainable on the long term. Most existing microservice based systems are still very young systems nowadays. So, the long
M
term effects of these engineering methodologies might not be observed so far. A lot of CNA methodologies are pattern based [6, 7, 8, 10, 11]. Patterns are
475
ED
a well accepted and proven engineering methodology in software engineering. This insight has been transfered to CNA engineering as well. It is better not to reinvent the wheel but to rely on proven solutions that have been working in
PT
past. So, existing engineering methodologies are taken and combined with cloud specific patterns. This seems obvious. However, systems of the past were seldom
CE
elastic systems. So, there might be the need for some CNA specific engi480
neering methodologies (METH.2) covering CNA specific problems (namely
AC
elasticity).
3 ”Organizations
which design systems [...] are constrained to produce designs which are
copies of the communication structures of these organizations.” [64] 4 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.
29
ACCEPTED MANUSCRIPT
4.3. Research Implications of CNA Architectures Components of CNAs are often realized as containers [16].
These self-
contained deployment units are operated on elastic platforms. Popular elastic container platforms are Google’s Kubernetes, Apache Mesos, Docker Swarm,
CR IP T
485
to name a few. These platforms can be deployed across different cloud service
providers [54] and therefore reducing vendor lock-in effects (see [44]). However, a
CNA developed for Kubernetes is not deployable on Mesos or on Swarm without
further engineering efforts. There exist standardization initiatives for contain-
ers and there should be standardization initiatives for elastic container platforms (ARCH-2) as well.
AN US
490
Furthermore, CNA engineers use these elastic platforms to encapsulate deployment unit heterogeneity. To handle this heterogeneity of CNA components, we see some dominating major requirements. 495
1. The necessity to standardize packaging these components into standard-
M
ized self-contained deployment units is mentioned by a lot of studies [8, 12, 23, 16, 31, 48]. Technically this is solved using containers and operating system virtualization. Notably Docker has established here a de
500
ED
facto standard.
2. There is the necessity to interface these heterogeneous but standardized
PT
deployable services with scalable and simple communication means. This is often done via REST-based APIs transferring arbitrary but JSONserialized data. This seems to exploit existing internet infrastructures in a
CE
very pragmatic way to build distributed, large scale, massively (horizontal)
505
scalable and elastic cloud systems. In fact it seems that this is the main
AC
CNA component composition approach [8, 16, 10, 34, 39].
510
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 scalable but (mostly) eventual consistent storage solutions (which are often subsumed as NoSQL databases). These storage solutions are used to isolate states to simplify scalable sys30
ACCEPTED MANUSCRIPT
tem designs of (large parts of) these systems [6, 7, 15]. All trends (see Table 7) can be seen as isolated trends. However, 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
CR IP T
515
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).
AN US
520
4.4. Research Implications of CNA Properties
According to our survery, a CNA shall have wishful CNA property combination of horizontal scalability [29, 14], elasticity [37, 12], and resiliency [9, 14, 38, 42]. A lot of research about cloud-native applications is reported as solution proposals and experience reports. However, systematic evaluation and
M
525
validation of postulated effects seems to be rare. Elasticity is often aligned to microservice based approaches. And microser-
ED
vices are relying heavily on stateless services. But stateless services can be scaled up and down easily from a distributed systems conceptual point of view. 530
We found only little research dealing with the elasticity of stateful CNA
PT
components (PROP.1) which is the much harder problem. Although, we did not investigate elasticity research in details, we got the
CE
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
535
(e.g. on Kubernetes) can be elastic as well. But most of the times, elasticity
AC
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).
540
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
31
ACCEPTED MANUSCRIPT
CR IP T
Table 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 de-
velopers and IT operators. It aims to build, test, and release software
for software delivery. Softwareization
AN US
more rapidly, frequently, and more reliably using automated processes
Softwareization of infrastructure and network enables to automate the process of software delivery and infrastructure changes more rapidly.
Standardized
Deployment units wrap a piece of software in a complete filesystem
Deployment
that contains everything needed to run: code, runtime, system tools,
Units
system libraries. This guarantees that the software will always run
Elastic
Plat-
forms
M
the same, regardless of its environment.
Elastic platforms like Kubernetes, Mesos, Docker Swarm can be seen as a middleware for the execution of custom but standardized deploy-
ED
ment 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
PT
avoided, but stateful components should be reduced to a minimum and realized by intentional horizontal scalable storage systems (often eventual consistent NoSQL databases). REST-based APIs provide scalable and pragmatic communication
REST APIs
means relying mainly on already existing internet infrastructure and
CE
Versioned
AC
Loose coupling
well defined and widespread standards. 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).
32
ACCEPTED MANUSCRIPT
filters. However, we think this should be a relevant aspect for ongoing research as well (PROP-3).
CR IP T
5. Definition Proposal for CNA [RQ2] Previous Section 4 showed that there are open questions regarding CNA 545
engineering and research. Furthermore, our literature review did not turn up
a common definition that explains what a cloud-native application exactly is5 .
Nevertheless, our survery identified enough studies which can be used to derive a definition proposal for CNA because there is a common but unconscious
AN US
understanding across several relevant studies.
Fehling et al. propose that a cloud-native application should be IDEAL, so it
550
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 [6]. According to Stine [8] there
555
M
are common motivations for cloud-native application architectures like to deliver software-based solutions more quickly (speed), in a more fault isolating, fault tolerating, and automatic recovering way (safety), to enable horizontal (instead
ED
of vertical) application scaling (scale), and finally to handle a huge diversity of (mobile) platforms and legacy systems (client diversity). These common
560
PT
motivations are addressed by several application architecture and infrastructure approaches [22]:
CE
• Microservices represent the decomposition of monolithic (business) systems into independently deployable services that do ”one thing well”
AC
[65, 66].
565
• 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
5 Except
our own contribution [54] which relies partly on this mapping study. The reader
might want to consider [54] to get a complete picture.
33
ACCEPTED MANUSCRIPT
with JSON serialization, but other protocols and serialization formats can be used as well. • Single deployment units of the architecture are designed and intercon-
CR IP T
nected according to a collection of cloud-focused patterns like the
570
twelve-factor app collection [67], the circuit breaker pattern [68] or cloud computing patterns [6, 7].
• And finally, self-service agile infrastructure platforms are used to deploy and operate these microservices via self-contained deployment units
(containers). These platforms provide additional operational capabilities
AN US
575
on top of IaaS infrastructures like automated and on-demand scaling of application instances, application health management, dynamic routing, load balancing and aggregation of logs and metrics. These aspects lead us to the following definition:
M
A cloud-native application (CNA) is a distributed, elastic and horizontal scalable system composed of (micro)services which isolates state in a
ED
minimum of stateful components. The application and each self-contained deployment unit of that application is designed according to cloud-focused
580
PT
design patterns and operated on a self-service elastic platform.
Of course this definition can only be understood in a context of further terms
CE
already defined or characterized by other authors and standardizing initiatives: • Elasticity is ”the degree to which a system is able to adapt to workload
AC
changes by provisioning and de-provisioning resources in an autonomic
585
manner, such that at each point in time the available resources match the current demand as closely as possible” and has been already defined by [69]. • Scalability can be differentiated to ”structural scalability and load scalability. Structural scalability is the ability of a system to expand in a chosen 34
ACCEPTED MANUSCRIPT
dimension 6 without major modifications to its architecture. Load scalabil590
ity is the ability of a system to perform gracefully as the offered traffic increases” [70].
CR IP T
• Microservices are understood as an architectural style to develop ”a single application as a suite of small services, each running in its own
process and communicating with lightweight mechanisms, often an HTTP 595
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
storage technologies” [71]. 600
AN US
may be written in different programming languages and use different data
• Self-contained Deployment Unit is understood as ”a part of the application’s deployment topology for realizing a specific technical unit” [12]. More and more often a deployment unit is understood as ”a standard
M
container. The goal of a standard 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 depen-
ED
605
dencies, regardless of the underlying machine and the contents of the container”. This is the understanding of the Open Container Initiative (OCI)
PT
which is explained in the 5 principles of standard containers [72].
• Stateful components are used for ”multiple instances of a scaled-out application component [to] synchronize their internal state to provide a
CE
610
AC
unified behavior” [6].
• Elastic platform is understood as a ”middleware for the execution of custom applications, their communication, and data storage is offered via a self-service interface over a network” [6].
6 horizontally
in case of CNA
35
ACCEPTED MANUSCRIPT
615
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
CR IP T
used – maybe even dominated – by software and cloud industry nowadays. We
identified interesting but isolated trends in cloud systems engineering (see Table 620
7). If several of these trends are applied in parallel resulting software systems 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
AN US
with specific challenges.
Our critical discussion of identified research showed, that there is room and
625
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
630
M
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
ED
effects of these autonomous engineering approaches are hardly investigated so far. Even the existing systems are quite young and the long term effects might
PT
not be even observed.
However, our literature survey showed that there is a common but uncon-
635
scious understanding of cloud-native applications. A CNA should be build ac-
CE
cording to corresponding CNA principles (being 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 of-
AC 640
ten pattern-based (relying on comprehensive cloud computing pattern catalogs [6, 7]) 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.
36
ACCEPTED MANUSCRIPT
645
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
CR IP T
designed for the cloud.” Acknowledgements
This study was funded by German Federal Ministry of Education and Re-
650
search (Project Cloud TRANSIT, 03FH021PX4). We would like to thank our reviewers who contributed valuable and very constructive feedback. Further-
AN US
more, we thank Dr. Adersberger from QAWARE GmbH. He inspired us with
his MEKUNS approach (Mesos, Kubernetes Cloud-native Stack) and his consid655
erations about cloud-native applications from a practitioner point of view. And we thank Ren´e Peinl for his valuable contributions accompanying our research.
M
References
[1] P. Mell, T. Grance, The NIST Definition of Cloud Computing, National
ED
Institute of Standards and Technology (2011). doi:http://dx.doi.org/ 10.6028/NIST.SP.800-145.
660
[2] K. Petersen, S. Vakkalanka, L. Kuzniarz, Guidelines for conducting system-
PT
atic mapping studies in software engineering: An update, Information and Software Technology 64 (2015) 1–18. doi:http://dx.doi.org/10.1016/
CE
j.infsof.2015.03.007. 665
[3] K. Petersen, R. Feldt, S. Mujtaba, M. Mattsson, Systematic mapping stud-
AC
ies in software engineering, in: Proceedings of the 12th International Conference on Evaluation and Assessment in Software Engineering, EASE’08, British Computer Society, Swinton, UK, UK, 2008, pp. 68–77.
[4] B. Kitchenham, S. Charters, Guidelines for performing Systematic Litera-
670
ture Reviews in Software Engineering, Tech. Rep. EBSE 2007-001, Keele University and Durham University Joint Report (2007). 37
ACCEPTED MANUSCRIPT
[5] C. Wohlin, P. Runeson, P. A. da Mota Silveira Neto, E. Engstrm, I. do Carmo Machado, E. S. de Almeida, On the reliability of mapping studies in software engineering, Journal of Systems and Software 86 (10) (2013)
CR IP T
2594–2610. doi:http://dx.doi.org/10.1016/j.jss.2013.04.076.
675
[6] C. Fehling, F. Leymann, R. Retter, W. Schupeck, P. Arbitter, Cloud Computing Patterns, Springer, 2014.
[7] T. Erl, R. Cope, A. Naserpour, Cloud Computing Design Patterns, Springer, 2015.
[8] M. Stine, Migrating to Cloud-Native Application Architectures, O’Reilly,
AN US
680
2015.
[9] T. Taleb, A. Ksentini, B. Sericola, On Service Resilience in Cloud-Native 5G Mobile Systems, IEEE Journal on Selected Areas in Communications 34 (3) (2016) 483–496. doi:10.1109/JSAC.2016.2525342.
[10] A. Balalaie, A. Heydarnoori, P. Jamshidi, Advances in Service-Oriented and
M
685
Cloud Computing: Workshops of ESOCC 2015, Taormina, Italy, September
ED
15-17, 2015, Revised Selected Papers, Springer International Publishing, 2016, Ch. Migrating to Cloud-Native Architectures Using Microservices: An Experience Report, pp. 201–215. doi:10.1007/978-3-319-33313-7_ 15.
PT
690
[11] V. Andrikopoulos, C. Fehling, F. Leymann, DESIGNING FOR CAP -
CE
The Effect of Design Decisions on the CAP Properties of Cloud-native Applications, in: Proceedings of the 2nd International Conference on
AC
Cloud Computing and Services Science, 2012, pp. 365–374. doi:10.5220/
695
0003931503650374.
[12] C. Inzinger, S. Nastic, S. Sehic, M. V¨ ogler, F. Li, S. Dustdar, Madcat: A methodology for architecture and deployment of cloud application topologies, in: Service Oriented System Engineering (SOSE), 2014 IEEE 8th International Symposium on, 2014, pp. 13–22. doi:10.1109/SOSE.2014.9. 38
ACCEPTED MANUSCRIPT
700
[13] A. Balalaie, A. Heydarnoori, P. Jamshidi, Advances in Service-Oriented and Cloud Computing: Workshops of ESOCC 2015, Taormina, Italy, September 15-17, 2015, Revised Selected Papers, Springer International Publishing,
CR IP T
2016, Ch. Migrating to Cloud-Native Architectures Using Microservices: An Experience Report, pp. 201–215. doi:10.1007/978-3-319-33313-7_ 15.
705
[14] T. Goldschmidt, A. Jansen, H. Koziolek, J. Doppelhamer, H. P. Breivold,
Scalability and robustness of time-series databases for cloud-native monitoring of industrial processes, in: 2014 IEEE 7th International Conference
710
AN US
on Cloud Computing, 2014, pp. 602–609. doi:10.1109/CLOUD.2014.86.
[15] V. Andrikopoulos, S. Strauch, C. Fehling, F. Leymann, 2nd Int. Conf. on Cloud Computing and Services Science, CLOSER 2012, Springer International Publishing, 2013, Ch. CAP-Oriented Design for Cloud-Native
M
Applications, pp. 215–229. doi:10.1007/978-3-319-04519-1_14. [16] R. Peinl, F. Holzschuher, F. Pfitzer, Docker cluster management for the cloud - survey results and own solution, Journal of Grid Computing (2016)
715
ED
1–18doi:10.1007/s10723-016-9366-y. [17] S. Suneja, C. Isci, R. Koller, E. de Lara, Touchless and always-on cloud
PT
analytics as a service, IBM Journal of Research and Development 60 (2-3) (2016) 11:1–11:10. doi:10.1147/JRD.2016.2518438. [18] V. Roussev, S. McCulley, Forensic analysis of cloud-native artifacts, Dig-
CE
720
ital Investigation 16, Supplement (2016) 104–113, {DFRWS} 2016 Eu-
AC
ropeProceedings of the Third Annual {DFRWS} Europe.
doi:http:
//dx.doi.org/10.1016/j.diin.2016.01.013.
[19] V. Roussev, A. Barreto, I. Ahmed, Forensic acquisition of cloud drives,
725
CoRR (Computing Research Repository) abs/1603.06542. URL http://arxiv.org/abs/1603.06542
39
ACCEPTED MANUSCRIPT
[20] N. Nikaein, E. Schiller, R. Favraud, R. Knopp, I. Alyafawi, T. Braun, Studies in Big Data, Springer, 2016, 2016, Ch. Towards a Cloud-native Radio Access Network, pp. 171–202. [21] S. Varghese, Web Development with Go: Building Scalable Web Apps
CR IP T
730
and RESTful Services, Apress, Berkeley, CA, 2015, Ch. Building Go Web Applications on Google Cloud, pp. 251–283. 978-1-4842-1052-9_11.
doi:10.1007/
URL http://dx.doi.org/10.1007/978-1-4842-1052-9_11
[22] A. Balalaie, A. Heydarnoori, P. Jamshidi, Microservices architecture en-
AN US
735
ables devops: Migration to a cloud-native architecture, IEEE Software 33 (2016) 42–52.
[23] A. Balalaie, A. Heydarnoori, P. Jamshidi, Migrating to Cloud-native Architectures Using Microservices: An Experience Report, in: Europ. Conf. on Service-Oriented and Cloud Computing, Springer, 2015, pp. 201–215.
M
740
[24] B. Familiar, Microservices, IoT, and Azure: Leveraging DevOps and
ED
Microservice Architecture to Deliver SaaS Solutions, Apress, Berkeley, CA, 2015, Ch. Service Fabric, pp. 165–182.
doi:10.1007/
978-1-4842-1275-2_8.
URL http://dx.doi.org/10.1007/978-1-4842-1275-2_8
PT
745
[25] N. Nikaein, Processing radio access network functions in the cloud: Critical
CE
issues and modeling, in: Proceedings of the 6th International Workshop on Mobile Cloud Computing and Services, MCS ’15, ACM, New York, NY, USA, 2015, pp. 36–43. doi:10.1145/2802130.2802136.
AC
750
URL http://doi.acm.org/10.1145/2802130.2802136
[26] P. Jamshidi, C. Pahl, S. Chinenyeze, X. Liu, 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, 2015, Ch.
40
ACCEPTED MANUSCRIPT
Cloud Migration Patterns: A Multi-cloud Service Architecture Perspective,
755
pp. 6–19. doi:10.1007/978-3-319-22885-3_2. [27] A. Srinivasan, M. A. Quadir, V. Vijayakumar, Era of cloud computing: A
CR IP T
new insight to hybrid cloud, Procedia Computer Science 50 (2015) 42 – 51, big Data, Cloud and Computing Challenges. doi:http://dx.doi.org/ 10.1016/j.procs.2015.04.059.
760
[28] M. T. Krieger, O. Torreno, O. Trelles, D. Kranzlm¨ uller, Building an open
source cloud environment with auto-scaling resources for executing bioin-
AN US
formatics and biomedical workflows, Future Generation Computer Systemsdoi:http://dx.doi.org/10.1016/j.future.2016.02.008. 765
[29] A. Cockcroft, Cloud Native Cost Optimization, in: Proc. of the 6th ACM/SPEC Int. Conf. on Perf. Eng., ICPE ’15, ACM, New York, NY, USA, 2015, pp. 109–109. doi:10.1145/2668930.2693197.
M
[30] H. Sequeira, P. Carreira, T. Goldschmidt, P. Vorst, Energy Cloud: RealTime Cloud-Native Energy Management System to Monitor and Analyze Energy Consumption in Multiple Industrial Sites, in: Proceedings of the
ED
770
2014 IEEE/ACM 7th International Conference on Utility and Cloud Computing, UCC ’14, IEEE Computer Society, Washington, DC, USA, 2014,
PT
pp. 529–534. doi:10.1109/UCC.2014.79. [31] E. A. Brewer, Kubernetes and the path to cloud native, in: Proceedings of the Sixth ACM Symposium on Cloud Computing, SoCC ’15, ACM, New
CE
775
York, NY, USA, 2015, pp. 167–167. doi:10.1145/2806777.2809955.
AC
[32] W. Hasselbring, Microservices for scalability: Keynote talk abstract, in:
780
Proceedings of the 7th ACM/SPEC on International Conference on Performance Engineering, ICPE ’16, ACM, New York, NY, USA, 2016, pp. 133–134. doi:10.1145/2851553.2858659.
[33] A. S. Housfater, M. S. Aslam, D. Gupta, S. Meraji, R. Bennis, Acceleration of cloud computing, in: Proceedings of 24th Annual International Confer41
ACCEPTED MANUSCRIPT
ence on Computer Science and Software Engineering, CASCON ’14, IBM Corp., Riverton, NJ, USA, 2014, pp. 297–298. 785
[34] D. Mazmanov, C. Curescu, H. Olsson, A. Ton, J. Kempf, Handling per-
CR IP T
formance sensitive native cloud applications with distributed cloud com-
puting and sla management, in: Utility and Cloud Computing (UCC),
2013 IEEE/ACM 6th International Conference on, 2013, pp. 470–475. doi:10.1109/UCC.2013.92. 790
[35] S. Garca-Gmez, M. Escriche-Vicente, P. Arozarena-Llopis, F. Lelli,
AN US
Y. Taher, C. Momm, A. Spriestersbach, J. Vogel, A. Giessmann, F. Junker,
M. Jimnez-Ga’n, J. Biro, G. L. Jeune, M. Dao, S. P. Carrie, J. Niemoller, D. Mazmanov, 4caast:
Comprehensive management of cloud services
through a paas, in: 2012 IEEE 10th International Symposium on Parallel and Distributed Processing with Applications, 2012, pp. 494–499.
795
M
doi:10.1109/ISPA.2012.72.
[36] V. Mateljan, D. Cisic, D. Ogrizovic, Cloud database-as-a-service (daas) roi, in: MIPRO, 2010 Proceedings of the 33rd International Convention,
800
ED
2010, pp. 1185–1188.
[37] D. Moldovan, G. Copil, H.-L. Truong, S. Dustdar, Service-Oriented and
PT
Cloud Computing: Third European Conference, ESOCC 2014, Manchester, UK, September 2-4, 2014. Proceedings, Springer Berlin Heidelberg, Berlin, Heidelberg, 2014, Ch. QUELLE – A Framework for Accel-
CE
erating the Development of Elastic Systems, pp. 93–107. doi:10.1007/ 978-3-662-44879-3_7.
805
AC
[38] K. J. Hole, Anti-fragile ICT Systems, Springer International Publishing, 2016, Ch. Toward an Anti-fragile e-Government System, pp. 57–65. doi: 10.1007/978-3-319-30070-2_6.
´ Foghl´ [39] M. Serrano, L. Shi, M. O. u, W. Donnelly, Knowledge Discovery, 810
Knowledge Engineering and Knowledge Management: Third International
42
ACCEPTED MANUSCRIPT
Joint Conference, IC3K 2011, Paris, France, October 26-29, 2011. Revised Selected Papers, Springer Berlin Heidelberg, Berlin, Heidelberg, 2013, Ch. Cloud Services Composition Support by Using Semantic Annotation and
815
CR IP T
Linked Data, pp. 278–293. doi:10.1007/978-3-642-37186-8_18. [40] M. Missbach, T. Staerk, C. Gardiner, J. McCloud, R. Madl, M. Tempes, G. Anderson, SAP on the Cloud, Springer Berlin Heidelberg, Berlin,
Heidelberg, 2016, Ch. The Hybrid Cloud, pp. 153–164. doi:10.1007/ 978-3-662-47418-1_7.
AN US
[41] L. O. Colombo-Mendoza, G. Alor-Hern´ andez, A. Rodr´ıguez-gonz´ alez, R. Valencia-garc´ıa, Mobicloup!: a paas for cloud services-based mobile
820
applications, Automated Software Engineering 21 (3) (2014) 391–437. doi:10.1007/s10515-014-0143-5.
[42] M. Ben Belgacem, H. Hafsi, N. Abdennadher, Grid and Pervasive Comput-
M
ing: 8th International Conference, GPC 2013 and Colocated Workshops, Seoul, Korea, May 9-11, 2013. Proceedings, Springer Berlin Heidelberg,
825
Berlin, Heidelberg, 2013, Ch. A Hybrid Grid/Cloud Distributed Platform:
ED
A Case Study, pp. 162–169. doi:10.1007/978-3-642-38027-3_17. [43] A. Mann, G. Watt, P. Matthews, The Innovative CIO: How IT Leaders Can
PT
Drive Business Transformation, Apress, Berkeley, CA, 2013, Ch. Opportunities to Innovate Today, pp. 103–125. doi:10.1007/978-1-4302-4411-0_
830
CE
6.
[44] J. Opara-Martins, R. Sahandi, F. Tian, Critical analysis of vendor lock-
AC
in and its impact on cloud computing migration: a business perspec-
835
tive, Journal of Cloud Computing 5 (1) (2016) 1–18.
doi:10.1186/
s13677-016-0054-z.
[45] M. Vasconcelos, N. C. Mendon¸ca, P. H. M. Maia, Service Oriented and Cloud Computing: 4th European Conference, ESOCC 2015, Taormina,
43
ACCEPTED MANUSCRIPT
Italy, September 15-17, 2015, Proceedings, Springer International Publishing, Cham, 2015, Ch. Cloud Detours: A Non-intrusive Approach for Automatic Software Adaptation to the Cloud, pp. 181–195. doi:10.1007/
840
CR IP T
978-3-319-24072-5_13. [46] Z. Wang, Z. Lu, J. Wu, K. Fan, Advances in Services Computing: 9th Asia-Pacific Services Computing Conference, APSCC 2015, Bangkok, Thai-
land, December 7-9, 2015, Proceedings, Springer International Publishing, Cham, 2015, Ch. CPFirewall: A Novel Parallel Firewall Scheme
845
978-3-319-26979-5_9.
doi:10.1007/
AN US
for FWaaS in the Cloud Environment, pp. 121–136.
[47] D. Petcu, A. V. Vasilakos, Portability in clouds: approaches and research opportunities, Scalable Computing: Practice and Experience 15. 850
[48] S. Brunner, M. Bl¨ ochlinger, G. Toffetti, J. Spillner, T. M. Bohnert,
M
Experimental evaluation of the cloud-native application design, in: 8th IEEE/ACM International Conference on Utility and Cloud Computing, UCC 2015, Limassol, Cyprus, December 7-10, 2015, 2015, pp. 488–493.
855
ED
doi:10.1109/UCC.2015.87. [49] J. Wettinger, K. G¨ orlach, F. Leymann, Deployment aggregates - a generic
PT
deployment automation approach for applications operated in the cloud, in: Proceedings of the 18th International Enterprise Distributed Object Computing Conference Workshops and Demonstrations, IEEE Computer
CE
Society, 2014, pp. 173–180.
[50] I. Baldini, P. Castro, P. Cheng, S. Fink, V. Ishakian, N. Mitchell,
AC
860
865
V. Muthusamy, R. Rabbah, P. Suter, Cloud-native, Event-based Programming for Mobile Applications, in: Proceedings of the International Conf. on Mobile Software Engineering and Systems, MOBILESoft ’16, ACM, New York, NY, USA, 2016, pp. 287–288. doi:10.1145/2897073.2897713.
[51] S. Dutta, T. Taleb, A. Ksentini, QoE-aware elasticity support in cloud-
44
ACCEPTED MANUSCRIPT
native 5G systems, in: 2016 IEEE Int. Conf. on Communications (ICC), 2016, pp. 1–6. doi:10.1109/ICC.2016.7511377. [52] F. Leymann, C. Fehling, S. Wagner, J. Wettinger, Native Cloud Appli-
CR IP T
cations: Why Virtual Machines, Images and Containers Miss the Point!,
in: Proc. of the 6th Int. Conf. on Cloud Computing and Service Science
870
(CLOSER 2016), SciTePress, 2016, pp. 7– 15.
[53] N. Kratzke, P.-C. Quint, D. Palme, D. Reimers, Project Cloud TRANSIT - Or to Simplify Cloud-native Application Provisioning for SMEs by Inte-
AN US
grating Already Available Container Technologies, in: V. Kantere, B. Koch (Eds.), European Project Space on Smart Systems, Big Data, Future In-
875
ternet - Towards Serving the Grand Societal Challenges, SCITEPRESS, 2016, in print.
[54] N. Kratzke, R. Peinl, ClouNS - A Cloud-Native Application Reference
M
Model for Enterprise Architects, in: 2016 IEEE 20th International Enterprise Distributed Object Computing Workshop (EDOCW), 2016, pp.
880
ED
1–10. doi:10.1109/EDOCW.2016.7584353. [55] P. Bourque, R. E. Fairley (Eds.), SWEBOK: Guide to the Software Engineering Body of Knowledge, version 3.0 Edition, IEEE Computer Society,
PT
Los Alamitos, CA, 2014.
URL http://www.swebok.org/
885
CE
[56] E. Brewer, CAP twelve years later: How the ”rules” have changed, Computer 45 (2) (2012) 23–29. doi:10.1109/MC.2012.37.
AC
[57] R. Wieringa, N. Maiden, N. Mead, C. Rolland, Requirements engineering
890
paper classification and evaluation criteria: A proposal and a discussion, Requir. Eng. 11 (1) (2005) 102–107. doi:10.1007/s00766-005-0021-6.
[58] A. Fox, S. D. Gribble, Y. Chawathe, E. A. Brewer, P. Gauthier, Clusterbased Scalable Network Services, SIGOPS Oper. Syst. Rev. 31 (5) (1997) 78–91. doi:10.1145/269005.266662. 45
ACCEPTED MANUSCRIPT
[59] A. Fox, E. A. Brewer, Harvest, Yield, and Scalable Tolerant Systems, in: Proc. of the The 7th Workshop on Hot Topics in Operating Systems (HO-
895
TOS99), IEEE Computer Society, Washington, DC, USA, 1999, pp. 174–
CR IP T
179. [60] E. A. Brewer, Towards Robust Distributed Systems (Keynote), in: Proc. of the 19th Annual ACM Symp. on Princ. of Dist. Comp. (PODC ’00), ACM, New York, NY, USA, 2000, p. 7. doi:10.1145/343477.343502.
900
[61] S. Garcia-Gomez, M. Jimenez-Ganan, Y. Taher, C. Momm, F. Junker,
AN US
J. Biro, A. Menychtas, V. Andrikopoulos, S. Strauch, Challenges for the
Comprehensive Management of Cloud Services in a PaaS Framework, Scalable Computing: Practice and Experience (SCPE) 13 (3) (2012) 201–213. 905
[62] C. Pahl, P. Jamshidi, Microservices: A systematic mapping study, in: Proceedings of the 6th International Conference on Cloud Computing and Ser-
M
vices Science, 2016, pp. 137–146. doi:10.5220/0005785501370146. [63] A. Balalaie, A. Heydarnoori, P. Jamshidi, Microservices Architecture En-
ED
ables DevOps Migration to a Cloud-Native Architecture, IEEE SOFTWARE 33 (3) (2016) 42–52.
910
[64] Conway, Melvin E., How do Committees Invent?, Datamation 14 (5) (1968)
PT
28–31.
CE
[65] S. Newman, Building Microservices, O’Reilly Media, Incorporated, 2015. [66] D. Namiot, M. Sneps-Sneppe, On micro-services architecture, Int. Journal of Open Information Technologies 2 (9).
AC
915
[67] Adam Wiggins, The Twelve-Factor App, last access 2016-02-14 (2014). URL http://12factor.net/
[68] Martin Fowler, Circuit Breaker, last access 2016-05-27 (2014). URL http://martinfowler.com/bliki/CircuitBreaker.html
46
ACCEPTED MANUSCRIPT
920
[69] N. R. Herbst, S. Kounev, R. Reussner, Elasticity in cloud computing: What it is, and what it is not, in: Proceedings of the 10th International Conference on Autonomic Computing (ICAC 13), USENIX, San Jose, CA, 2013,
CR IP T
pp. 23–27. [70] A. B. Bondi, Characteristics of scalability and their impact on performance,
in: Proceedings of the 2nd International Workshop on Software and Per-
925
formance, WOSP ’00, ACM, New York, NY, USA, 2000, pp. 195–203. doi:10.1145/350391.350432.
last access 2016-05-27 (2014).
AN US
[71] Martin Fowler, Microservices - A Definition of this new Architectural Term,
URL http://martinfowler.com/articles/microservices.html
930
[72] Open Container Initiative, Open Container Runtime Specification, last access 2016-05-27 (2015).
M
URL https://github.com/opencontainers/runtime-spec
Appendix A. Unification of keywords
AC
CE
PT
935
ED
Appendices (Just for review, not intended for final publication)
47
applications,
engineering, Go,
Google Cloud platform,
Cloud-native
applications
development
bioinformatics,
biomedicine,
workflows, cloud
SaaS, Galaxy,
ED
computing, IaaS,PaaS,
PT
auto-scaling, GridFTP,
data transfer
[34]
Internet of Things,
x
x
x
CE
cloud SLA
management, cloud
AC
orchestration,
distributed cloud
computing, public
safety, service level
agreements, utility
demand response
48
x
x
Cloud costs (2)
Cloud artifacts (2)
Use Cases (15)
SLA for CNA (2)
x
Cloud Forensics (2)
CAP Properties (2)
Other
CNA Properties Elasticity (7)
Resilience (8)
DevOps (3)
Scalability (8)
x
M
[28]
Design Methodology (6)
AN US
application
Patterns (8)
CNA Methods
x
Deployment Unit (8)
Service Composition (7)
Microservices (11)
x
CNA Design (11)
x
Interoperability (8)
x
Softwarization (8)
x
Migration (8)
(*) Scalable
CR IP T
[21]
Keywords by Authors
Automation Platform (12)
Paper
CNA Principles
CNA Architecture
ACCEPTED MANUSCRIPT
Container
x
x
deployment, service
management,
x
x
x
x
x
x
x
x
construction, service
composition, cloud
[20]
(*) Microservice
x
PT
architecture,
ED
platform, container
application containers,
elastic scale, fault
CE
tolerance, automation
[24]
(*) Microservice
x
AC
architecture,
application containers,
elastic scale, fault
tolerance, automation
49
Cloud costs (2)
Other
x
x
M
application
x
Cloud artifacts (2)
Use Cases (15)
SLA for CNA (2)
Elasticity (7)
x
AN US
integration, Docker,
Cloud Forensics (2)
CAP Properties (2)
Resilience (8)
x
DevOps (3)
x
Patterns (8)
x
Microservices, System
(*) Kubernetes, service
Scalability (8)
x
CR IP T
x
Management tools,
[31]
CNA Properties
CNA Methods Deployment Unit (8)
x
Design Methodology (6)
Service Composition (7)
CNA Design (11)
Interoperability (8)
Softwarization (8)
x
Migration (8)
Cloud computing,
Microservices (11)
[16]
Keywords by Authors
Automation Platform (12)
Paper
CNA Principles
CNA Architecture
ACCEPTED MANUSCRIPT
native, microservices,
development,
resilience, elasticity,
scalability,
self-management
[35]
Cloud, Platform as a
x
Automation, Cloud
x
Cloud costs (2)
Cloud artifacts (2)
Use Cases (15)
Elasticity (7)
SLA for CNA (2)
Resilience (8)
DevOps (3)
Cloud Forensics (2)
Other
CNA Properties CAP Properties (2)
Design Methodology (6)
x
M
[17]
x
x
Service, Service
Composition
x
AN US
cloud computing, cloud
Scalability (8)
x
Patterns (8)
CNA Methods
x
Deployment Unit (8)
Service Composition (7)
Microservices (11)
CNA Design (11)
Interoperability (8)
Softwarization (8)
x
Migration (8)
Monitoring, cloud
CR IP T
[48]
Keywords by Authors
Automation Platform (12)
Paper
CNA Principles
CNA Architecture
ACCEPTED MANUSCRIPT
x
modeling, Data
PT
mining, Data
ED
computing, Context
structures, Runtime,
Virtual machine
CE
monitoring, Virtual
machine monitors
AC
[29]
autoscaling, aws, cloud
x
x
native, consolidated
billing, cost
optimization, netflix,
reservations
50
x
x
Internet Applications,
Web 2.0 services
x
x
x
Microservices,
Cloud-native
modernization
Cloud migration,
x
x
x
x
x
ED
Cloud architecture,
x
M
architectures, Software
[26]
Migration pattern,
[44]
PT
Multi-cloud
Cloud computing,
x
x
x
Vendor lock-in,
CE
Enterprise migration,
Cloud adoption, Cloud
API’s, Interoperability,
AC
Portability, Standards,
DevOps
51
Cloud costs (2)
Other Cloud artifacts (2)
Use Cases (15)
SLA for CNA (2)
Cloud Forensics (2)
CAP Properties (2)
Elasticity (7)
Resilience (8)
Scalability (8)
DevOps (3)
AN US
as a Service, Rich
Cloud migration,
CNA Properties
CNA Methods
x
Computing, Platform
[13]
Design Methodology (6)
Patterns (8)
Deployment Unit (8)
Service Composition (7)
Microservices (11)
CNA Design (11)
Interoperability (8)
Softwarization (8)
x
Migration (8)
Mobile Cloud
CR IP T
[41]
Keywords by Authors
Automation Platform (12)
Paper
CNA Principles
CNA Architecture
ACCEPTED MANUSCRIPT
AC service, software
development, software
engineering
[22]
ED
(*) Microservices, CNA
Cloud-native
architecture
DevOps, architectural
(*) Cloud-native
x
refactoring, cloud
computing,
microservices,
migration pattern,
mobile backend as a
x
Microservices (11) Service Composition (7) Deployment Unit (8) Patterns (8) Design Methodology (6)
Interoperability (8)
Softwarization (8)
Migration (8)
CNA Design (11)
x x x x x x x
Design, Recipes,
Migration,
x
x
architecture,
Microservices, Service
Decomposition,
Situational Method
Engineering (SME),
Migration, Pattern
52 x x
x
x
x
Cloud costs (2)
Cloud artifacts (2)
Cloud Forensics (2)
Use Cases (15)
SLA for CNA (2)
CAP Properties (2)
Elasticity (7)
Resilience (8)
Scalability (8)
DevOps (3)
CR IP T
AN US
[8] Automation Platform (12)
Paper Keywords by Authors
M
[10]
PT
CE
Other
CNA Properties
CNA Methods
CNA Architecture
CNA Principles
ACCEPTED MANUSCRIPT
AC PT
CE [49]
[33] (*) cloud native
programming
Deployment,
x
aggregate, topology,
provisioning, operation,
unification,
orchestration,
transformation,
meta-model, Cloud
x x
code transformation,
aspect-oriented
computing, DevOps
x
x
requirements, software
defined networking,
software defined
environments
53
Design Methodology (6)
Patterns (8)
Deployment Unit (8)
Service Composition (7)
Microservices (11)
CNA Design (11)
Interoperability (8)
Softwarization (8)
x
Cloud costs (2)
Cloud artifacts (2)
Cloud Forensics (2)
Use Cases (15)
SLA for CNA (2)
CAP Properties (2)
Elasticity (7)
Resilience (8)
Scalability (8)
DevOps (3)
CR IP T
AN US
(*) cloud migration, Migration (8)
Automation Platform (12)
Keywords by Authors
M
[45]
ED
Paper
Other
CNA Properties
CNA Methods
CNA Architecture
CNA Principles
ACCEPTED MANUSCRIPT
AC PT
CE 5G, Markov process,
virtualization (NFV),
network softwarization,
network virtualization,
resilience, social
network
[37]
[46] BBU, LTE, cloud
computing, cloud-ran,
open air interface,
RANnaaS,
Virtualization
cloud service,
Cloud computing,
x
x x
carrier, cloud, cloud
network function
x
software-defined,
elasticity capability,
elasticity quantification
x
FWaaS, Parallel
firewall, NFV
54
Design Methodology (6)
Patterns (8)
Deployment Unit (8)
Service Composition (7)
Microservices (11)
CNA Design (11)
Interoperability (8)
Softwarization (8)
Migration (8)
x
x
x
Cloud costs (2)
Cloud artifacts (2)
Cloud Forensics (2)
Use Cases (15)
SLA for CNA (2)
CAP Properties (2)
Elasticity (7)
Resilience (8)
Scalability (8)
DevOps (3)
CR IP T
AN US
[9] Automation Platform (12)
Keywords by Authors
M
[25]
ED
Paper
Other
CNA Properties
CNA Methods
CNA Architecture
CNA Principles
ACCEPTED MANUSCRIPT
AC [27]
Drive, models
[40]
[42]
[47] (*) hybrid cloud,
workload movement,
ED
Computing, Service
Composition,
Elasticity,
Multi-tenancy, Linked
Data, Knowledge
Management
SkyDrive, hybrid,
DropBox, Google
distributed
Cloud computing,
Information Modelling,
x x
Semantic Annotation,
Interoperability, Cloud
x
x
computation, grid
computing, cloud
computing, MetaPIGA
x
Portability,
Multi-Clouds
55
x
Design Methodology (6)
Patterns (8)
Deployment Unit (8)
Service Composition (7)
Microservices (11)
CNA Design (11)
Interoperability (8)
Softwarization (8)
Migration (8)
Automation Platform (12)
x
x
x x
x
x
SLA
x
Cloud costs (2)
Cloud artifacts (2)
Cloud Forensics (2)
Use Cases (15)
SLA for CNA (2)
CAP Properties (2)
Elasticity (7)
Resilience (8)
Scalability (8)
DevOps (3)
CR IP T
AN US
Paper Keywords by Authors
M
[39]
PT
CE
Other
CNA Properties
CNA Methods
CNA Architecture
CNA Principles
ACCEPTED MANUSCRIPT
design methodology,
cloud architectural
pattern, CAP
properties
(*) Patterns, CNA
ED
[7]
x
x
x
x
x
x
x
x
[11]
PT
architecture
CAP Theorem, Cloud
Patterns, Cloud-native
CE
Applications Design
[12]
cloud computing,
x
x
AC
cloud-native
applications, software
development,
methodology
56
x
Cloud costs (2)
Use Cases (15)
Cloud artifacts (2)
Other
x
SLA for CNA (2)
Elasticity (7)
Resilience (8)
Scalability (8)
DevOps (3)
Design, Cloud-native
Cloud Forensics (2)
CAP Properties (2)
x
M
(*) Patterns, CNA
architecture
x
AN US
(*) CAP theorem,
Design, Cloud-native
CR IP T
anti-fragility
[6]
CNA Properties
CNA Methods
x
microservices,
[15]
Design Methodology (6)
Patterns (8)
x
Deployment Unit (8)
Microservices (11)
x
Service Composition (7)
CNA Design (11)
Interoperability (8)
(*) weakly connected,
Softwarization (8)
[38]
Migration (8)
Keywords by Authors
Automation Platform (12)
Paper
CNA Principles
CNA Architecture
ACCEPTED MANUSCRIPT
web-scale, patterns,
microservices
x
(*) microservices,
monitoring, scalability
[14]
linear scalability,
resiliency, read/write
independence, support
[36]
(*) ROI, DBaaS,
x
x
x
x
outsourcing, decision
[30]
PT
making
x
Energy efficiency, big
data, cloud computing,
CE
energy management
systems
AC
[43]
[18]
Cloud costs (2)
Cloud artifacts (2)
Use Cases (15)
SLA for CNA (2)
Elasticity (7)
Resilience (8)
Scalability (8)
DevOps (3)
Cloud Forensics (2)
Other
CNA Properties CAP Properties (2)
Design Methodology (6)
Patterns (8)
Deployment Unit (8)
CNA Methods
x
x
ED
independence
x
M
for industrial
workloads, workload
x
AN US
[32]
Service Composition (7)
Microservices (11)
CNA Design (11)
Interoperability (8)
Softwarization (8)
Migration (8)
x
(*) anti-fragility,
CR IP T
[? ]
Keywords by Authors
Automation Platform (12)
Paper
CNA Principles
CNA Architecture
ACCEPTED MANUSCRIPT
x
Innovation, Business
x
Cloud forensics,
Cloud-native artifacts,
Google docs format,
Reverse engineering,
kumodd, kumodocs
57
x
AC Paper
PT
CE Research
ED
[28]
Validation
x
[20]
Validation
x
[41]
Validation
x
[45]
Validation
[25]
Validation
[19]
Validation x
x
x
x
x
58 x
x
x
x x
x
x
x
x
CNA Properties
x
x Cloud costs (2)
Cloud artifacts (2)
Approach Cloud Forensics (2)
Use Cases (14)
SLA for CNA (2)
CAP Properties (2)
CNA Methods
Elasticity (5)
Cloud artifacts (2)
x x
Appendix B. Mapping of keywords to research approaches
Other
Cloud costs (2)
Cloud Forensics (2)
Use Cases (15)
SLA for CNA (2)
CAP Properties (2)
Elasticity (7)
Resilience (8)
Scalability (8)
DevOps (3)
Design Methodology (6)
Patterns (8)
Deployment Unit (8)
Service Composition (7)
Microservices (11)
CNA Design (11)
Interoperability (8)
Softwarization (8)
Migration (8)
CR IP T
kumodd, API-based
Resilience (7)
storage forensics,
Scalability (8)
DevOps (3)
CNA Architecture
Design Methodology (6)
CNA Principles
Patterns (7)
Box
AN US
Dropbox, OneDrive,
Deployment Unit (4)
Google Drive,
Service Composition (7)
M
evidence acquisition,
Microservices (10)
CNA Design (12)
Interoperability (8)
Cloud forensics, cloud Automation Platform (12)
[19]
Softwarization (8)
Keywords by Authors
Migration (10)
Automation Platform (12)
Paper
Other
CNA Properties
CNA Methods
CNA Architecture
CNA Principles
ACCEPTED MANUSCRIPT
ACCEPTED MANUSCRIPT
[36]
Evaluation
[21]
Solution
x
x
[28]
Solution
x
x
[34]
Solution
x
[16]
Solution
x
[20]
Solution
x
[24]
Solution
x
[35]
Solution
[17]
Solution
[41]
Solution
AC
x
x
x
x
x
AN US
x
x
x
x
x
x
x
M
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
ED
x
x
x
x
x
x
x
Solution
x
Solution
x
CE
[45]
x
PT
[8]
x
x
x
x
x
x
x
[22]
Solution
x
[49]
Solution
x
[9]
Solution
x
[25]
Solution
x
[37]
Solution
x
[46]
Solution
x
[39]
Solution
x
[15]
Solution
x
x
x
x
x
x
x
x
x
Cloud costs (2)
Evaluation
Cloud artifacts (2)
[26]
Cloud Forensics (2)
Evaluation
x
Use Cases (14)
[14]
x
x
SLA for CNA (2)
Evaluation
x
CAP Properties (2)
[9]
x
Elasticity (5)
x
Resilience (7)
x
Other
CR IP T
Evaluation
Approach
CNA Properties
Scalability (8)
[48]
DevOps (3)
x
Design Methodology (6)
x
Patterns (7)
x
CNA Design (12)
x
Interoperability (8)
Evaluation
Research
Softwarization (8)
[16]
Paper
Migration (10)
Deployment Unit (4)
CNA Methods
Service Composition (7)
CNA Architecture
Microservices (10)
Automation Platform (12)
CNA Principles
x
x
x
x
59
x
x
x
x
ACCEPTED MANUSCRIPT
x
x
[11]
Solution
x
x
[12]
Solution
x
[30]
Solution
[18]
Solution
[19]
Solution
[16]
Survey
[26]
Survey
x
x
[44]
Survey
x
x
[33]
Survey
[27]
Survey
[47]
Survey
[43]
Survey
[31]
Opinion
[29]
Opinion
AC
x
x
x
x
Cloud costs (2)
Use Cases (14)
SLA for CNA (2)
CAP Properties (2)
Elasticity (5)
Resilience (7)
AN US
x
x
x
x
x
x
x
x
M
x
x
x
ED
x
x
x
x
x
x
Opinion
x
x
x
x
x
Opinion
CE
[32]
x
x
x
PT
[33]
x
Cloud artifacts (2)
Solution
Cloud Forensics (2)
[7]
Other
CR IP T
Approach
CNA Properties
Scalability (8)
DevOps (3)
Design Methodology (6)
Patterns (7)
CNA Methods
Deployment Unit (4)
Service Composition (7)
Microservices (10)
CNA Design (12)
CNA Architecture
Interoperability (8)
Softwarization (8)
Research
Migration (10)
Paper
Automation Platform (12)
CNA Principles
x
[43]
Opinion
[28]
Experience
x
[29]
Experience
x
[13]
Experience
x
[26]
Experience
x
[8]
Experience
x
x
x
[10]
Experience
x
x
x
[22]
Experience
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
60
x
x
x
x
x
x
x
x
AC PT
CE ED
[39] Experience x
[40] Experience x
[42] Experience x
[38] Experience x
[6] Experience x
[7] Experience x
[? ] Experience
[14] Experience
[43] Experience
[18] Experience x
61
x
x x
x
x
x
x
x
x
x
x
x
x
x
x
CNA Properties
x x
Cloud costs (2)
Cloud artifacts (2)
x
Cloud Forensics (2)
Use Cases (14)
SLA for CNA (2)
CAP Properties (2)
Elasticity (5)
CNA Methods
Resilience (7)
Scalability (8)
CR IP T
Approach DevOps (3)
Design Methodology (6)
CNA Architecture
Patterns (7)
Deployment Unit (4)
Service Composition (7)
Microservices (10)
CNA Design (12)
Interoperability (8)
Softwarization (8)
Migration (10)
CNA Principles
AN US
Research
M
Paper Automation Platform (12)
ACCEPTED MANUSCRIPT
Other
ACCEPTED MANUSCRIPT
Nane Kratzke is Professor for Computer Science and Business Informa940
tion Systems at Lbeck University of Applied Sciences (Germany) and head of the cloud computing research group at the Center of Excellence for Commu-
CR IP T
nication, 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 945
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 re-
AN US
search group at the Center of Excellence for Communication, Systems and Ap-
plications (CoSA, Lbeck University of Applied Sciences, Germany). His main 950
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
AC
CE
PT
ED
M
career he was a software and quality engineer for medical information systems.
62