This is the author’s version of the work. It is posted for your personal use. Notfor redistribution. The definitive version was published in Proceedings of the 10thInternational Conference on Cloud Computing and Services Science (CLOSER), pp.171–180, 2020, doi: 10.5220/0009571001710180.

Cloud-native Deploy-ability: An Analysis of Required Features ofDeployment Technologies to Deploy Arbitrary Cloud-native Applications

Michael Wurster1, Uwe Breitenbücher1, Antonio Brogi2, Frank Leymann1 and Jacopo Soldani21 Institute of Architecture of Application Systems, University of Stuttgart, Germany

2 Department of Computer Science, University of Pisa, Pisa, Italy[lastname]@iaas.uni-stuttgart.de, [lastname]@di.unipi.it

Keywords: Cloud-native Application, Automation, Deployment Technology.

Abstract: The adoption of cloud computing combined with DevOps enables companies to react to new market require-ments more rapidly and fosters the use of automation technologies. This influences the way software solutionsare built, which is why the concept of cloud-native applications has emerged over the last few years to buildhighly scalable applications, and to automatically deploy and run them in modern cloud environments. How-ever, there is currently no reference work clearly stating the features that a deployment technology must offer tosupport the deployment of arbitrary cloud-native applications. In this paper, we derive three essential featuresfor deployment technologies based on the current cloud-native research and characteristics discussed therein.The presented features can be used to compare and categorize existing deployment technologies, and they areintended to constitute a first step towards a comprehensive framework to assess deployment technologies.

1 INTRODUCTION

The wide adoption of cloud computing resulted in achange in how software solutions are developed anddeployed. Market demands push software companiesto adopt new practices to increase the ability of releas-ing more often, even immediately if required (Humbleand Farley, 2010). To support this, DevOps emergedas a widespread concept to establish a high levelof automation for accomplishing and managing soft-ware releases in shorter cycles. For rapid deploy-ment cycles, the application components themselvesneed to feature certain characteristics, which resultedin the notion of cloud-native applications (Kratzkeand Quint, 2017). The latter was introduced as anarchitectural approach to allow developing, deploy-ing and running software solutions and their compo-nents. The motivation for this was to deliver softwaresolutions more consistently, in an automated manner,while at the same time enabling horizontal scaling andintegrating diverse technologies, different clouds, andlegacy systems (Stine, 2015).

Several publications, authored by researchersfrom both academy and industry, define what a cloud-native application is, also in terms of the charac-teristics that it must feature for being consideredsuch (Janssen, 2018; Fehling et al., 2014; Stine, 2015;Pahl et al., 2019; Vettor and Smith, 2019). At thesame time, for ensuring a highly-automated deploy-

ment and configuration management, it is also cru-cial that the deployment technology itself offers sup-port for processing cloud-native applications and theircomponents. However, there is currently no referencework listing the features that a deployment technol-ogy should offer to support the deployment of arbi-trary cloud-native applications, i. e., to feature whatwe shall call cloud-native deploy-ability.

In this paper, we make a first step in this direction.We indeed derive three essential features for deploy-ment technologies based on the current cloud-nativeresearch and on the cloud-native application-centricattributes discussed therein. To do so, we first dis-till the main characteristics of cloud-native applica-tions, as per their current perception in both white andgray reference literature. Due to the influence of mi-croservices and their implementation based on con-tainers, it matters that deployment technologies sup-port emerging and de facto standard packaging for-mats and cloud service offerings. This means to sup-port (natively, or via extensions) all possible cloudservice models (e. g., FaaS or SaaS) on top of tradi-tional IaaS offerings (Leymann et al., 2017) and toprovide the opportunity to target different cloud de-ployment models, such a public, private, or hybridclouds (Kratzke and Quint, 2017). Further, it emergesthat reusable deployment models are needed to estab-lish a repeatable end-to-end deployment automationand to specify the deployment of arbitrary applica-

tion components, their relations and desired config-uration in a declarative manner, which is perceivedas the most appropriate approach in practice (Wursteret al., 2019b; Herry et al., 2011).

It is finally also worth stressing that this paperaims at performing a first step towards classifying andassessing the support for deploying cloud-native ap-plications provided by existing deployment technolo-gies. Indeed, even if the presented features and char-acteristics in terms of supporting the deployment ofcloud-native applications can already be used to com-pare existing deployment technologies, they are in-tended to set the basis for further research. We planto expand and build on top of them, with the ultimategoal of providing a comprehensive framework to as-sess existing deployment technologies.

The rest of the paper is as follows. Sect. 2 distillscurrently recognized characteristics of cloud-nativeapps, which are taken in Sect. 3 to determine theirinfluence on deployment technologies. Sect. 4 andSect. 5 define and characterize cloud-native deploy-ability, while Sect. 6 shows a deployment modelingexample. Finally, Section 7 and Sect. 8 discuss re-lated work and draw some concluding remarks.

2 CLOUD-NATIVE APPS:CHARACTERISTICS

Cloud-nativeness gained momentum over the lastyears, with the rise of the Cloud Native Comput-ing Foundation (CNCF, 2019). The latter definescloud-native technologies as the enablers for build-ing and running scalable applications in modern, dy-namic environments, such as public, private or hybridclouds. Containers, (micro)service compositions, im-mutable deployment infrastructures and declarativeAPIs are concrete examples in this direction (Kratzkeand Quint, 2017). They indeed enable the creationand enactment of loosely coupled systems (Hohpeand Woolf, 2004) that are resilient, manageable, andobservable. If combined with robust automation, theyallow engineers to enact changes while at the sametime minimizing toil (CNCF, 2019).

Fehling et al. first isolated some of the charac-teristics of cloud-native applications by prescribingthem to be IDEAL (Fehling et al., 2014), i. e., in-dicating that they should be (i) with isolated state,(ii) distributed in their nature, (iii) elastic, (iv) op-erated via automated management systems, and (v)made of loosely coupled components. By system-atically integrating such characteristics with otheremerging in published white literature, Kratzke and

Quint (2017) managed to distill the properties charac-terizing a cloud-native application. They define it as a“distributed, elastic and horizontally scalable systemcomposed of (micro)services, which isolates statesin a minimum of stateful components” (Kratzke andQuint, 2017). Further, they define that the “applica-tion and each self-contained deployment unit of thatapplication is designed according to cloud-focuseddesign patterns and operated on a self-service plat-form” (Kratzke and Quint, 2017). The findings byKratzke and Quint (2017) were then confirmed bylater published gray literature, e. g., the blog posts andwhitepapers by Microsoft (Vettor and Smith, 2019),New Stack (Janakiram MSV, 2018), Pivotal (PivotalSoftware, Inc., 2019), Red Hat (Red Hat, Inc., 2019),and Stackify (Janssen, 2018). Even if the list of cloud-native characteristics could be elaborated further, allabove mentioned works agree with Kratzke and Quint(2017) in saying that the following are the main char-acteristics of cloud-native applications:C1: Service-based architectures. Cloud-native ap-

plications are designed as suites of loosely-coupled (micro)services. Each service exists inde-pendently from the other services forming an ap-plication, hence allowing their independent devel-opment and operation (Kratzke and Quint, 2017).At the same time, a service typically interacts withother services in an application, which are discov-ered by exploiting features provided by the ap-plication runtime (Pivotal Software, Inc., 2019).This allows to compose services and form cloud-native applications.

C2: API-based interactions. Service-to-servicecommunications in cloud-native application areAPI-based. The services forming an applicationindeed publish APIs to offer their functionalities,and they connect to and consume the APIs ofother services in the application (Vettor andSmith, 2019). APIs are typically based onwell-known standard protocols (e. g., REST overHTTP), and each component in a cloud-nativeapplication should be encapsulated by offering itsAPI (Janssen, 2018; Vettor and Smith, 2019).

C3: State isolation. Cloud-native applications aredesigned with a clear separation among statelessand stateful services. Stateless services exist inde-pendently from stateful services, even if interact-ing with them, making them easy to scale in/out.Stateful services instead follow a different patternfor assuring higher availability and resiliency ofpersisted data (Fehling et al., 2014). This is doneby typically exploiting natively scalable storagesystems in the form of eventual consistent NoSQLdatabases (Kratzke and Quint, 2017).

C4: Self-contained service deployment. The ser-vices forming a cloud-native application arepackaged in standardized, self-contained deploy-ment units (Red Hat, Inc., 2019). Deploymentunits wrap services in virtual runtime envi-ronments containing everything services needto run, i. e., their source code and necessaryruntime support (system tools, system libraries,etc.). This guarantees isolation among servicesrunning in different deployment units, and thatthey will always run the same, independentlyfrom the execution environment, whether it ison-premise or on third-party clouds, or whetherit is a development, testing, or production en-vironment (Janssen, 2018). Currently, besidePaaS and FaaS, containerization is a key enablerfor self-contained deployment of the services ina cloud-native application (Kratzke and Quint,2017; Pahl et al., 2019).

C5: Disposability. The actual instances of the ser-vices forming a cloud-native application are dis-posable (Vettor and Smith, 2019). This is a pre-requisite for favoring both fast startups and scala-bility of services and graceful shutdown for leav-ing applications in correct state, which are bothpeculiar properties of cloud-native applications.Currently existing container-based technologiesinherently satisfy this requirement (Pivotal Soft-ware, Inc., 2019; Pahl et al., 2019).

C6: Fault-resilience. Failures are first-class citizensin cloud application deployment and management(Brogi et al., 2018), hence requiring cloud-nativeapplications to treat failures as first-class citizensas well. Cloud-native applications indeed as-sume that service instances can fail at any timeand feature mechanisms ensuring fault-resilience(Kratzke and Quint, 2017; Soldani et al., 2018).The services forming an application are built fortolerating the failure of the other services they in-teract with, typically by exploiting cloud-nativedesign patterns, e. g., circuit breakers (Vettor andSmith, 2019). At the same time, the platforms ex-ploited for deploying and managing cloud-nativeapplications are suitably configured to automati-cally recover failed service instances.

C7: Infrastructure abstraction. Cloud-native ap-plication abstract from underlying infrastructureand operating system dependencies, by operatingat a higher abstraction level (Janssen, 2018;Pivotal Software, Inc., 2019). An enabler in thisdirection is the exploitation of above mentionedself-contained deployment units, which allowto distribute the services of an application overmultiple, heterogeneous clouds (Kratzke and

Quint, 2017). This is typically achieved byexploiting self-service deployment platforms,allowing to ship and scale deployment units onIaaS or PaaS clouds (Red Hat, Inc., 2019).

C8: Infrastructure as code. Cloud-native applica-tions are highly automated, from their deliveryand deployment to their management, scaling,and monitoring (Janssen, 2018; Vettor and Smith,2019). Such automation is typically achieved us-ing infrastructure as code (Pivotal Software, Inc.,2019), i. e., through machine-readable files allow-ing to specify the desired configuration for an ap-plication and its components (Morris, 2016).

C9: Policy-driven elasticity. Cloud-native applica-tions are horizontally scalable, meaning that eachof their services can be scaled in/out, by adaptingthe amount of replicas (Janssen, 2018). This isdone by relying on self-service deployment plat-forms, which are configured through scaling poli-cies, indicating how to dynamically (re-)allocatecomputing resources to services, to continuouslysatisfy the ongoing needs of an application (Piv-otal Software, Inc., 2019; Red Hat, Inc., 2019).

C10: CI/CD compliance. Cloud-native applicationsare developed by embracing continuous integra-tion and continuous deployment/delivery (CI/CD)DevOps paradigm (Kratzke and Quint, 2017).Each service of a cloud-native application is de-veloped in a separate code base and possiblyequipped with its own deployment pipeline (Vet-tor and Smith, 2019). This allows different ser-vices to be developed by different teams using dif-ferent technologies, and to release service updatesas soon as they are available, also throughout shortand continuous delivery cycles (Janssen, 2018).

Deployment technologies can hence be consid-ered to feature cloud-native deploy-ability if they na-tively support cloud-native applications in exhibitingthe above-listed characteristics. A discussion con-cerning the influence on deployment technologies ispresented in the following section.

3 ON DEPLOYINGCLOUD-NATIVEAPPLICATIONS

This section presents the first contribution of thiswork in the form of an analysis of required features ofdeployment technologies for automating the deploy-ment of arbitrary cloud-native applications. The def-inition by Kratzke and Quint (2017) as well as the

characteristics C4 (standardized, self-contained ser-vice deployment) and C7 (infrastructure abstraction)imply that cloud-native applications are intended torun in public, private, or hybrid cloud environmentsoffering self-service capabilities. Thus, deploymenttechnologies must support the deployment of cloud-native applications to different cloud providers, envi-ronments, and platforms.

Further, characteristics C3 (state isolation), C4(standardized, self-contained service deployment),and C5 (disposability) imply the fact that a deploy-ment technology needs to provide the ability to de-ploy application components on top of IaaS, i. e., tocontainerized environments, PaaS offerings, and FaaSplatforms. Even the use and instrumentation of exist-ing SaaS offerings to implement application compo-nents need to be supported. Thus, deployment tech-nologies must support the use of all cloud servicemodels (XaaS) to deploy cloud-native applications,i. e., to deploy on IaaS, PaaS, FaaS, and SaaS.

To foster automation and to conform to C10(CI/CD compliance), deployment technologies mustprovide interfaces that can be used in combinationwith existing technologies for enacting and automat-ing deployment processes, e. g., Jenkins or Travis.Thus, deployment technologies must provide oneor more options to integrate with external systems,e. g., by providing SDKs, command-line interfaces,or APIs, either local or remotely accessible (such asREST APIs over HTTP). For example, AWS Cloud-Formation provides several SDKs in different pro-gramming languages, an HTTP API, and a CLI to au-tomate the interaction with AWS.

On top of that, to support C8 (infrastructure ascode) and to establish a repeatable and consistentworkflow to automate the release cycle, deploymenttechnologies must provide the ability to express theapplication deployment in machine-readable formats,i. e., in so-called deployment models. They can be cat-egorized into two types: (i) imperative models and (ii)declarative models (Endres et al., 2017). The mainidea of imperative models is to describe a detailed,executable process specifying all necessary technicaltasks to be executed, their implementations, and theirorder. In contrast, declarative models only describethe components to be deployed, their configurations,and the relations between them, but hardly provideexecutional details. Declarative models, hence, needto be interpreted by a deployment technology deriv-ing the technical deployment instructions to reach thedesired state. Therefore, C1 (service-based architec-tures) implies that deployment technologies must pro-vide the ability to structure the application deploy-ment into physical, functional, or logical units by

defining the deployment specifics of application com-ponents inside a deployment model, while C9 (policy-driven elasticity) implies that the definition of suchapplication components should be done in a declara-tive manner, as this is the most appropriate approachfor application deployment and configuration man-agement (Herry et al., 2011; Wurster et al., 2019b).

Moreover, the characteristics C3 (state isola-tion), C4 (standardized, self-contained service de-ployment), and C7 (infrastructure abstraction) implythat deployment technologies must offer the ability toexpress different types of application components intheir deployment. For example, it must be possibleto express the deployment of a virtual machine, theinstallation of a web server component on top of it,as well as the deployment of containerized applica-tions and functions running on a FaaS platform. How-ever, a deployment technology must not support allkinds of cloud service models from all kinds of cloudproviders natively. The deployment technology it-self could be extensible in two ways: (i) at the de-ployment modeling language level, where ontologi-cal types are used for extensibility and provided asreusable entities across different application deploy-ments (Bergmayr et al., 2018), or (ii) at the deploy-ment system level, where a plugin mechanism pro-vides a clearly described interfaces to extend the set ofdeployable component types or host environments onwhich components can be deployed. A plugin, in thiscontext, is a software component that adds a specificfeature to an existing deployment technology withoutchanging the actual source code of it.

Lastly, characteristic C2 (API-based interaction)implies the ability to express the notion that a spe-cific application component connects to another one.For example, the deployment model of a deploymenttechnology must support the definition of a respectiverelation between a web application and an arbitrarybacking service expressing the fact that the web ap-plication connects to the service during runtime.

In summary, all characteristics (C1-C10) fromSect. 2 impact on what a deployment technologiesshould support, if looking at them from the perspec-tive of automating the deployment of cloud-native ap-plications. From this perspective, deployment tech-nologies must support the automated deployment byusing deployment models to deploy on different cloudproviders and platforms and on all cloud service mod-els. In the following section, we build on top of thisanalysis to derive and introduce three essential fea-tures for deployment technologies for automating thedeployment of cloud-native applications, i. e., to fea-ture cloud-native deploy-ability.

4 CLOUD-NATIVEDEPLOY-ABILITY

In Sect. 2 we presented application-centric charac-teristics, based on the current cloud-native research,that must be supported by applications to be consid-ered as cloud-native. In Sect. 3 we analyzed what ex-actly it means for a deployment technology to sup-port those characteristics. In this section, we build ontop of the result of our analysis and discuss an initialset of features that must be supported by deploymenttechnologies to deploy arbitrary cloud-native appli-cations, i. e., (i) support for multiple cloud providersand platforms, (ii) support for all cloud service mod-els (XaaS), (iii) usage of deployment models sup-porting arbitrary components. We hereafter presenta first definition of cloud-native deploy-ability recap-ping features (i-iii), which we then explain in detail inSects. 4.1, 4.2, and 4.3.

Cloud-native deploy-ability describesthe ability to deploy arbitrary applicationcomponents, concerning all cloud servicemodels, that can be vertically “hostedon” or horizontally “connected to” anyother component or service hosted on anycloud provider, cloud platform, or hy-brid environment. This includes support-ing the processing of declarative deploy-ment models given in machine-readableformats fostering automation.

4.1 Support for Multiple CloudProviders and Platforms

From the analysis in Sect. 3 we can derive that a de-ployment technology must support the deployment ofapplication components to multiple cloud providersand platforms to comply with C4 (standardized, self-contained service deployment) and C7 (infrastructureabstraction). This includes the deployment to pub-lic cloud offerings such as Amazon Web Services(AWS) or Microsoft Azure. Further, this also requiresthe capability to deploy applications to self-hostedplatforms such as OpenStack. Even more, deploy-ment technologies need to support hybrid cloud de-ployments, i. e., the distribution of application com-ponents to different cloud providers. For example, byexecuting an automated deployment, it must be possi-ble to deploy certain application components to a pub-lic cloud provider (e. g., AWS) and others to a self-hosted platform (e. g., OpenStack). This increasesflexibility and enables the possibility to target differ-

ent environments for different use cases in the appli-cation development lifecycle, e. g., to deploy differ-ently for development, testing, and production.

4.2 Support for all Cloud ServiceModels (XaaS)

The analysis in 3 showed that providing the abilityto deploy on IaaS offerings may not be enough todeal with cloud-native applications (Leymann et al.,2017). To support the disposability (C5), self-contained (C4), and state isolation (C3) aspects ofcloud-native apps, deployment technologies must beable to target containerized environments as well asPaaS offerings. Further, lately the serverless comput-ing paradigm has gained momentum (CNCF, 2018a).The term serverless is often linked with the arisenFunction as a Service (FaaS) cloud delivery model.The idea of FaaS is to develop and deploy customserver-side logic in the form of ephemeral and state-less functions employing an event-driven program-ming model (CNCF, 2018a). With the use of server-less and FaaS, developers increase infrastructure ab-straction as the management and scaling of requiredcomputing resources remain fully the responsibilityof cloud providers. This is why FaaS can be consid-ered as an enabler for cloud-native application com-ponents and, therefore, must be supported by de-ployment technologies (Gannon et al., 2017; Roberts,2016). Moreover, to exploit the full stack of cloud ser-vice models, deployment technologies have to enablethe use and instrumentation of existing SaaS offeringsto implement application components. Thus, deploy-ment technologies must support the use of all cloudservice models to deploy cloud-native applications.

4.3 Usage of Deployment ModelsSupporting Arbitrary Components

Automation plays a major role in developing and run-ning cloud-native applications. Further, the emer-gence of containers to implement microservices andnew cloud service models such as FaaS, requires thata deployment technology can be used to express thedeployment of such applications components usingtheir deployment model mechanics. This requires theusage of deployment models and the ability to de-fine the deployment of arbitrary applications compo-nents in a declarative manner, which in turn complieswith the presented characteristics C2 (API-based in-teraction), C3 (state isolation), C4 (standardized, self-contained service deployment), C7 (infrastructure ab-straction), and C8 (infrastructure as code).

This means for deployment technologies to pro-vide the ability to express the application deploymentin a declarative model by defining arbitrary compo-nents based on arbitrary component types and respec-tive relations among them. Notably, component typesare either natively provided, or the deployment tech-nology is extensible (cf. Sect. 3) such that customcomponent types can be introduced. As depicted inFig. 1, this means that it must be possible to expressconstellations of components and relations definingthat a component A is “hosted on” or “contained in”a component B, such that component A is the hostedcomponent and component B is the hosting compo-nent. For example, a Tomcat web server is hostedon a Ubuntu virtual machine. Further, deploymenttechnologies must be able to express constellationsof components and relations specifying that a com-ponent X “connects to” or “invokes” a component Y,such that component X is the connecting componentand component Y is the connected component. Forexample, a web application needs to establish a con-nection to a managed messaging service.

5 DEPLOYMENT MODELINGSUPPORT: FORMALIZATION

In the last section we identified that an important as-pect is to express arbitrary constellations of compo-nents and relations in deployment models. In termsof deployment model expressiveness, we can charac-terize cloud-native deploy-ability in terms of two sep-arate sub-characteristics, i. e., vertical and horizontaldeploy-ability. Therefore, as a second contribution ofthis work, we hereafter provide a formal definition ofsuch characteristics.

Wurster et al. (2019b) showed that the top-mostdeployment technologies employing declarative mod-els share similar modeling constructs. All of themprovide the notion of components to describe logi-cal units, relations to specify dependencies betweencomponents, and component types and relation typesto convey reusable semantics, which was publishedas the Essential Deployment Metamodel (EDMM). Ithas been derived by conducting a systematic reviewof the 13 top-most deployment automation technolo-gies and describes the essential modeling elementssupported by declarative deployment models used inpractice (Wurster et al., 2019b). Figure 2 shows asimplified version of EDMM describing components,used to form an application deployment model, aswell as the component types, allowing to distinguishthem and giving them semantics.

According to EDMM, a Component is a physi-

YXconnects to

B

A

hosted on

HostedComponent

HostingComponent

ConnectingComponent

ConnectedComponent

Figure 1: Deployment technologies must be able to deploycomponents hosted on other components (left) and to de-ploy components connecting to other components (right).

cal, functional, or logical unit of an application, whilea Component Type is a reusable entity that specifiesthe semantics of a component that has this type as-signed. For example, a component representing thedeployment of a Tomcat server may be of type Tom-cat while a component representing the provisioningof a virtual machine (VM) may be of type Compute.While a component represents the deployment for aspecific application, the component type can be usedin different deployment models. Components oftendepend on other components, which is specified byrelations between components. A Relation is a di-rected physical, functional, or logical dependency be-tween exactly two components, while a Relation Typeis a reusable entity that specifies the semantics of arelation that has this type assigned. For example, arelation between a Tomcat server and its hosting com-pute component may of type hosted on, while a rela-tion expressing that a component connects to anothercomponent may of type connects to.

Formally, an EDMM deployment model is a di-rected graph, which nodes represent application com-ponents, and which edges represent inter-componentrelations. Let M be the set of all valid EDMM de-ployment models (i. e., all deployment models hav-ing syntactically and semantically correct constella-tions of components and relations) then a deploymentmodel m ∈M is defined by the following tuple1:

m = 〈Cm,Rm,CTm,RTm, typem,supertypem〉

The elements of EDMM are defined as follows:

• Cm is the set of Components in m, whereby eachci ∈Cm represents a component of the applicationto be deployed.

• Rm ⊆ Cm × Cm is the set of Relations in m,whereby each ri = (cs,ct)∈ Rm models a relation-ship between two components, with cs being thesource of the relationship and ct being its target.

1The tuple defines a deployment model according to thesimplified EDMM considered in this paper. Full EDMMdefinitions have been provided by Wurster et al. (2019b).

Relation Type

Component Type

is source of

is target ofis of type

ModelElement

ModelElement Type

is of typeComponentRelation

Figure 2: Simplified Essential Deployment Metamodel (EDMM).

Table 1: Formal definitions of vertical and horizontal deployability based on the simplified EDMM. Therein, hostedOn isa generic relationship type denoting the hosting of a component in another, while connectsTo is a generic relationship typedenoting the connection of a component to another (cf. Fig. 1). Additionally, canDeploy(t,m) is a predicate used to denotethat a given (valid) deployment model m ∈M can be deployed by deployment technology t ∈ T .

arbitraryVerticalDeployAbility(t) ⇐⇒∀ct1,ct2 ∈CT .∃m ∈M :

(∃c1,c2 ∈Cm,r = 〈c1,c2〉 ∈ Rm .type(c1) = ct1∧ type(c2) = ct2∧hostedOn ∈ supertypes(r))∧canDeploy(t,m)

arbitraryHorizontalDeployAbility(t) ⇐⇒∀ct1,ct2 ∈CT .∃m ∈M :

(∃c1,c2 ∈Cm,r = 〈c1,c2〉 ∈Rm .type(c1)= ct1∧type(c2)= ct2∧connectsTo∈ supertypes(r))∧canDeploy(t,m)

• CTm is the set of Component Types in m, wherebyeach cti ∈ CTm describes the semantics for thecomponents that have this type assigned.

• RTm is the set of Relation Types in m, wherebyeach rti ∈ RTm describes the semantics for the Re-lations that have this Relation Type assigned.

• typem is a map that assigns all Model Elements inm to their respective Model Element Type. LettingMEm := Cm ∪ Rm be the union set of all ModelElements of m, and METm := CTm ∪RTm be theunioin set of all Model Element Types of m, typemis defined as follows:

typem : MEm→METm

• supertypem is a partial function mapping eachModel Element Type to its respective supertype.It associates a meti ∈METm with a met j ∈METmwhere i 6= j, i. e., that met j is the supertype of meti:

supertypem : METm→METm

For simplifying notation, we hereafter also use thepartial function supertypesm to map a Model Ele-ment Type meti ∈ METm to the set containing allsupertypes. The latter can be easily computed bycomputing the transitive closure of supertype, i. e.,supertypes = supertype+:

supertypesm : METm→ 2METm

Following this, we define two requirements for mod-eling arbitrary component-relation-constellations asa feature for deployment technologies to support de-ploying arbitrary cloud-native applications:

Arbitrary Vertical Deploy-Ability. The abilityto deploy arbitrary types of hosted compo-nents on arbitrary types of hosting compo-nents. This is depicted in Fig. 1 (left-handside) and formalized in Table 1 (by predicatearbitraryVerticalDeployAbility).

Arbitrary Horizontal Deploy-Ability. The abil-ity to deploy arbitrary types of componentsconnecting to other types of components.This is depicted in Fig. 1 (right-hand side)and formalized in Table 1 (by predicatearbitraryHorizontalDeployAbility).

However, deployment technologies may be restrictedin their ability to use arbitrary constellations of com-ponents and relations. AWS CloudFormation (Ama-zon Web Services, Inc., 2018), for example, has alimited set of component types as this deploymenttechnology is only intended to be used with the AWScloud services. Further, Kubernetes (CNCF, 2018b) isconsidered to be multi-cloud deployable (many cloudoffer managed clusters), but is limited in componenttypes as only containers can be used. If such technolo-gies comply with the derived feature requirements,but are restricted in component and relation types,we speak of single-environment cloud-native deploy-ability. Notably, we speak of multi-environmentcloud-native deploy-ability if a deployment technol-ogy complies with the definition above. For example,TOSCA (OASIS, 2019) and Terraform (HashiCorp,2018) are considered as such, since both support theusage of arbitrary component types, either natively orby providing respective extension mechanisms.

6 DEPLOYMENT MODELINGEXAMPLE

We hereafter introduce a simple yet effective exam-ple to show a deployment model that follows ourformalized description from Sect. 5 based on a con-crete cloud-native deployment scenario. Figure 3 de-picts the scenario and shows a Java application named“Pet Clinic”, implemented using the Java frameworkSpring Boot. In the depicted scenario, the web ap-plication is hosted on AWS Beanstalk, the platform asa service (PaaS) offering by Amazon Web Services(AWS). Further, the application connects to a MySQLdatabase to store its data. The database in this cloud-native scenario is hosted on Amazon Aurora, whichis a fully managed MySQL database as a service(DBaaS) offering by AWS. By using EDMM’s meta-model entities, we can express the structure of sucha cloud-native application in a technology-agnosticway. For example, the “Pet Clinic” application is acomponent, which also references a component type(Web App) to define further semantics. Further, the“Database” component defines several properties thatcan be used to configure the deployment. Moreover,the Java application and the database component havean artifact attached which is, for example, a packagedWAR file in case of the Java application and a SQLfile containing the actual database schema and initialdata of the database component.

Even this simple example shows concretely the re-quirement that deployment technologies must be ableto deploy arbitrary component types on top of otherones, e. g., that the Java web application is hosted onAWS Beanstalk. Further, it highlights that it is alsorequired to express that arbitrary components connectto other types of components, e. g., that the web ap-plication connects to a database at runtime. Hence,the deployment technology has to execute the deploy-ment of the components in a certain order, e. g., thedatabase stack on the right-hand side of Fig. 3 must bedeployed before the application stack on the left-handside. The order in EDMM terminology is defined bydefining typed relations (“HostedOn” or “Connect-sTo” relations in Fig. 3) between two components.Moreover, in the case of so-called connects to rela-tions, it implies that a deployment technology mustprovide the possibility to inject endpoint and creden-tial information of related components. In practice,cloud-native applications often use environment vari-ables to configure the application’s logic. For exam-ple, the information required to connect to the mod-eled database is made available at runtime by inject-ing the respective deployment model properties intothe application’s environment.

App Runtime(AWS Beanstalk)

Region: eu-west-1Arche Type: javaMax Instances: 5

Pet Clinic(Web App)

Java WAR

Database(MySQL DB)

Schema: petclinicUser: pcPassword: pc

DBMS(AWS Aurora)

Region: eu-west-1Instance Type: small

HostedOnConnectsTo

Figure 3: Simple cloud-native application expressed asEDMM-based deployment model2.

The concrete deployment model, which can be ex-ecuted using a certain deployment technology can becreated manually by an application developer or oper-ations engineer. Using Ansible, a Playbook can be de-veloped containing the definitions to deploy the appli-cation: first, the deployment of the database compo-nent hosted on AWS Aurora, then the Java applicationhosted on AWS Beanstalk. Additionally, the Play-book also defines that the database connection creden-tials are injected using environment variables to theAWS Beanstalk runtime such that the Java applica-tion can be started accordingly. Similarly, this can bealso realized by using AWS CloudFormation, the in-frastructure as code (IaC) tooling provided by AWS.In a declarative manner, a CloudFormation templateallows you to define and provision the needed AWSresources including their configuration and wiring.

However, EDMM as a normalized metamodelprovides the basis for technology-independent de-ployment modeling. Also, recent work showed thatit can be used to facilitate the automated transfor-mation in different concrete deployment technolo-gies Wurster et al. (2019a). Using EDMM tooling,a user can model the deployment of an applicationgraphically by specifying the components to be de-ployed, their configurations, implementations, and re-lations to other components. By applying transforma-tion rules to such a model, depending on the selectedtarget deployment technology, the abstract EDMMmodel can be transformed into a concrete deploymenttechnology. The output of the EDMM Transforma-tion Framework is an executable, technology-specificdeployment model, which can be executed using theselected technology. The tooling is open-source andrespective examples are available online on GitHub3.

2http://bit.ly/39OYPMx3https://github.com/UST-EDMM

7 RELATED WORK

Several existing research efforts provide statementsregarding cloud-nativeness of software solutions,with that by Kratzke and Quint (2017) perhaps be-ing one of the most prominent efforts in this direc-tion. By studying published research (i. e., Fehlinget al. 2014; Kratzke and Peinl 2016; Leymann et al.2017; Stine 2015; just to mention some) and existingtrends in engineering such applications, they definedthe term “cloud-native application” as a distributed,elastic, and horizontally scalable system composed ofservices and operated on self-service platforms, whilethe services itself are designed as self-contained de-ployment units according to cloud design patterns.

Other noteworthy studies defining cloud-nativeness of applications come from practitionersdaily working with them, e. g., blog posts andwhitepapers published by renowned IT players,practitioners and companies (Vettor and Smith, 2019;Red Hat, Inc., 2019; Pivotal Software, Inc., 2019;Janakiram MSV, 2018; Janssen, 2018). Also, theCloud Native Computing Foundation was founded in2015 to help aligning the industry and coordinate itsevolution, with the support of large companies (i. e.,Google, IBM). They shaped the notion of cloud-native applications over the last years (CNCF, 2019)and defined it as an enabler for building and runningscalable applications in modern environments.

The study by Kratzke and Quint (2017) and theindustrial effort mentioned above however focus ondefining what a cloud-native application is. In ourstudy, we instead plan to pursue a different charac-terization, i. e., knowing how cloud-native applicationare characterized, can we understand whether an ex-isting deployment technology can actually support thedeployment of arbitrary cloud-native applications?

On the deployment technology side, there are sev-eral publications available comparing and classify-ing tools and platforms regarding their set of fea-tures and their intended use (Masek et al., 2018; Wet-tinger et al., 2016; Weerasiri et al., 2017). Further,Wurster et al. (2019b) conducted a systematic re-view of the 13 top-most deployment automation tech-nologies and introduced the categorization general-purpose, provider-specific, and platform-specific ofsuch. The categorization was done to find common-alities between deployment technologies to derive ametamodel for creating technology-independent de-ployment models, while those being transformableinto concrete technologies (Wurster et al., 2019b,a).

However, the recent publications either consider-ing the engineering part of the application itself orclassifying deployment technologies regarding their

features or use cases. To the best of our knowledge,no published work provided means to analyze deploy-ment technologies regarding their ability to deployarbitrary cloud-native applications. That is the mainreason motivating our work, in which we aim at an-alyzing what does it mean to deploy arbitrary cloud-native applications and what kind of features a respec-tive deployment technology must provide.

8 CONCLUSIONS

Cloud-nativeness emerged as a paradigm and enablerfor building and running scalable applications in mod-ern cloud environments (Kratzke and Quint, 2017).Beyond that, it is equally important that such built ap-plications can be effectively deployed. In this work,we presented three features a deployment technologyrequires to deploy arbitrary cloud-native applications.We derived these attributes by analyzing the currentresearch around what cloud-native means. We thenexploited such characteristics to provide a first defini-tion of cloud-native deploy-ability.

It is worth highlighting that both the presentedfeatures and the definition of cloud-native deploy-ability aims at performing a first step towards classi-fying and assessing the support for deploying cloud-native applications provided by existing deploymenttechnologies. We plan to refine and extend themin future work, to use them in a comprehensive re-view and classification framework to assess existingdeployment technologies concerning their ability todeploy arbitrary cloud-naive applications. In gen-eral, other dimensions should be considered to fullyclassify deployment technologies, e. g., characteris-tics of the employed modeling language or the exten-sibility of the deployment technology itself. There-fore, as immediate future, we emerge our contributionto a complete review framework capable of evaluat-ing and classifying deployment technologies, to ulti-mately provide a decision support system for the se-lection of the right deployment technology.

Further, in future work we want to addressinfluencing factors such as service level agree-ments (SLAs) or scalability attributes of components.For example, based on EDMM we are able to anno-tate SLAs for certain components in a technology-agnostic way and provide additional tooling to checkthe conformance of those SLAs for different tech-nologies and cloud environments.

ACKNOWLEDGEMENTS. This work is partiallyfunded by the EU project RADON (825040) and theprojects AMaCA (POR-FSE) and DECLware (Uni-versity of Pisa, PRA_2018_66).

REFERENCES

Amazon Web Services, Inc. (2018). AWS CloudForma-tion Official Site. https://aws.amazon.com/de/cloudformation.

Bergmayr, A., Breitenbücher, U., Ferry, N., Rossini, A.,Solberg, A., Wimmer, M., and Kappel, G. (2018).A Systematic Review of Cloud Modeling Languages.ACM Computing Surveys (CSUR), 51(1):1–38.

Brogi, A., Canciani, A., and Soldani, J. (2018). Fault-awaremanagement protocols for multi-component applica-tions. Journal of Systems and Software, 139:189 –210.

CNCF (2018a). CNCF Serverless Whitepaper v1.0. https://github.com/cncf/wg-serverless/tree/master/whitepapers/serverless-overview.

CNCF (2018b). Kubernetes Official Site. https://kubernetes.io.

CNCF (2019). CNCF Cloud Native Definition v1.0.https://github.com/cncf/toc/blob/master/DEFINITION.md.

Endres, C., Breitenbücher, U., Falkenthal, M., Kopp, O.,Leymann, F., and Wettinger, J. (2017). Declarative vs.Imperative: Two Modeling Patterns for the AutomatedDeployment of Applications. In Proceedings of the 9th

International Conference on Pervasive Patterns andApplications (PATTERNS), pages 22–27. Xpert Pub-lishing Services.

Fehling, C., Leymann, F., Retter, R., Schupeck, W., andArbitter, P. (2014). Cloud Computing Patterns: Fun-damentals to Design, Build, and Manage Cloud Ap-plications. Springer Publishing Company, Inc.

Gannon, D., Barga, R., and Sundaresan, N. (2017).Cloud-Native Applications. IEEE Cloud Computing,4(5):16–21.

HashiCorp (2018). Terraform Official Site. https://www.terraform.io.

Herry, H., Anderson, P., and Wickler, G. (2011). AutomatedPlanning for Configuration Changes. In Proceedingsof the 25th International Conference on Large Instal-lation System Administration (LISA 2011), pages 57–68. USENIX.

Hohpe, G. and Woolf, B. (2004). Enterprise IntegrationPatterns: Designing, Building, and Deploying Mes-saging Solutions. Addison-Wesley.

Humble, J. and Farley, D. (2010). Continuous Delivery:Reliable Software Releases Through Build, Test, andDeployment Automation. Addison-Wesley.

Janakiram MSV (2018). 10 Key Attributes ofCloud-Native Applications. The New Stack,https://thenewstack.io/10-key-attributes-of-cloud-native-applications.

Janssen, T. (2018). The Path to Cloud-Native Applications.Stackify, https://stackify.com/cloud-native.

Kratzke, N. and Peinl, R. (2016). ClouNS - a Cloud-NativeApplication Reference Model for Enterprise Archi-tects. In 2016 IEEE 20th International EnterpriseDistributed Object Computing Workshop (EDOCW),pages 1–10.

Kratzke, N. and Quint, P.-C. (2017). Understanding Cloud-native Applications after 10 Years of Cloud Comput-ing - A Systematic Mapping Study. Journal of Sys-tems and Software, 126:1–16.

Leymann, F., Breitenbücher, U., Wagner, S., and Wettinger,J. (2017). Native Cloud Applications: Why Mono-lithic Virtualization Is Not Their Foundation. CloudComputing and Services Science, pages 16–40.

Masek, P., Stusek, M., Krejci, J., Zeman, K., Pokorny, J.,and Kudlacek, M. (2018). Unleashing Full Potentialof Ansible Framework: University Labs Administra-tion. In 2018 22nd Conference of Open InnovationsAssociation (FRUCT).

Morris, K. (2016). Infrastructure as Code: ManagingServers in the Cloud. O’Reilly Media, Inc., 1st edi-tion.

OASIS (2019). TOSCA Simple Profile in YAML Version1.2.

Pahl, C., Brogi, A., Soldani, J., and Jamshidi, P. (2019).Cloud Container Technologies: A State-of-the-ArtReview. IEEE Transactions on Cloud Computing,7(3):677–692.

Pivotal Software, Inc. (2019). What are Cloud-Native Ap-plications? https://pivotal.io/cloud-native.

Red Hat, Inc. (2019). The Path to Cloud-Native Applica-tions. https://www.redhat.com/en/resources/path-to-cloud-native-applications-ebook.

Roberts, M. (2016). Serverless Architectures. http://martinfowler.com/articles/serverless.html.

Soldani, J., Tamburri, D. A., and Van Den Heuvel, W.-J.(2018). The pains and gains of microservices: A Sys-tematic grey literature review. Journal of Systems andSoftware, 146:215 – 232.

Stine, M. (2015). Migrating to Cloud-Native ApplicationArchitectures. O’Reilly Media, Inc.

Vettor, R. and Smith, S. (2019). ArchitectingCloud-Native .NET Apps for Azure. Microsoft.https://docs.microsoft.com/en-us/dotnet/architecture/cloud-native.

Weerasiri, D., Barukh, M. C., Benatallah, B., Sheng, Q. Z.,and Ranjan, R. (2017). A Taxonomy and Surveyof Cloud Resource Orchestration Techniques. ACMComputer Surveys, 50(2).

Wettinger, J., Breitenbücher, U., Kopp, O., and Leymann,F. (2016). Streamlining DevOps Automation forCloud Applications using TOSCA as StandardizedMetamodel. Future Generation Computer Systems,56:317–332.

Wurster, M., Breitenbücher, U., Brogi, A., Falazi, G.,Harzenetter, L., Leymann, F., Soldani, J., and Yus-supov, V. (2019a). The EDMM Modeling and Trans-formation System. In Service-Oriented Computing –ICSOC 2019 Workshops. Springer.

Wurster, M., Breitenbücher, U., Falkenthal, M., Krieger, C.,Leymann, F., Saatkamp, K., and Soldani, J. (2019b).The Essential Deployment Metamodel: A System-atic Review of Deployment Automation Technolo-gies. SICS Software-Intensive Cyber-Physical Sys-tems.