Automating the Deployment of Distributed Applications by Combining

Multiple Deployment Technologies

Michael Wurster

, Uwe Breitenbücher

, Antonio Brogi

, Felix Diez

Frank Leymann

, Jacopo Soldani

and Karoline Wild

University of Stuttgart, Institute of Architecture of Application Systems, Stuttgart, Germany

University of Pisa, Department of Computer Science, Pisa, Italy

Keywords:

Distributed Application Deployment, Automation, EDMM, EDMM Framework, Cloud Computing.

Abstract:

Various deployment technologies have been released to support automating the deployment of distributed

applications. Although many of these technologies provide general-purpose functionalities to deploy applica-

tions as well as infrastructure components, different technologies provide speciﬁc capabilities making them

suited for different environments and application types. As a result, the deployment of complex distributed

applications often requires to combine several deployment technologies expressed by different deployment

models. Thus, multiple deployment models are processed by different technologies and must be either orches-

trated manually or the automated orchestration must be developed individually. To address these challenges,

we present an approach (i) to annotate parts of a holistic deployment model that should be deployed with

different deployment technologies, (ii) to automatically transform an annotated model to multiple technology-

speciﬁc models for different technologies, and (iii) to automatically coordinate the deployment execution with

different technologies by employing a centralized orchestrator component. To prove the practical feasibility

of the approach, we describe a case study based on a third-party application.

1 INTRODUCTION

Automating the deployment of complex distributed

applications is crucial nowadays, as it enables fully

exploiting the potentials of cloud computing. At the

same time, manually executing the deployment of

complex systems is error-prone, time-consuming, and

costly (Oppenheimer et al., 2003; Brogi et al., 2018).

Various technologies, e. g., Terraform, CloudFor-

mation, or Ansible, and standards, e. g., the Topology

and Orchestration Speciﬁcation for Cloud Applica-

tions (TOSCA) (OASIS, 2015), have been released

to accomplish the need for deployment automation.

Most of them follow a declarative approach, which is

considered the de-facto standard for application de-

ployment in industry and research (Wurster et al.,

2019b). They indeed all feature a Domain-Speciﬁc

Language (DSL) for specifying the desired state for

an application by means of a structural description of

the application components, their relations, and con-

ﬁguration. Deployment automation is then achieved

by processing application speciﬁcations to automati-

cally derive the operations to be executed in the exact

order to reach the desired state (Endres et al., 2017).

However, the deployment of complex distributed

applications often requires to combine different de-

ployment automation technologies (Di Nitto et al.,

2017; Guerriero et al., 2019). Many deployment au-

tomation technologies offer multi-purpose function-

alities for deploying different types of applications

on different infrastructure components or cloud ser-

vices. Each technology however provides speciﬁc ca-

pabilities, e. g., Terraform focuses primarily on cloud

infrastructure and cloud service provisioning for dif-

ferent cloud platforms, while CloudFormation is tai-

lored for managing only AWS resources. Moreover,

technologies such as Chef or Ansible are instead spe-

cialized in the conﬁguration management of soft-

ware components on running virtual machines (VMs).

Thus, the combination of different deployment au-

tomation technologies enables to concretely enact ap-

plication deployments, e. g., Terraform to provision a

VM on a cloud platform, plus Ansible to manage ar-

bitrary software components on top of it. This is be-

cause there is no “one ﬁts all” deployment automation

technology, i. e., no existing technology supports de-

ploying arbitrary application components on arbitrary

computing environments or platforms.

178

Wurster, M., Breitenbücher, U., Brogi, A., Diez, F., Leymann, F., Soldani, J. and Wild, K.

Automating the Deployment of Distributed Applications by Combining Multiple Deployment Technologies.

DOI: 10.5220/0010404301780189

In Proceedings of the 11th International Conference on Cloud Computing and Services Science (CLOSER 2021), pages 178-189

ISBN: 978-989-758-510-4

As a result, application developers are required to

write multiple deployment models to deploy their ap-

plications, with each model describing a part of the

overall application deployment with a different DSL.

This requires the appropriate expertise in different

technologies and changes of the overall application

structure may require the adaptation of multiple de-

ployment models. In addition, the processing of di-

verse deployment models requires to orchestrate the

respective deployment technologies in the right order,

i. e., to invoke respective APIs, which have to be co-

ordinated manually. Currently, no existing approach

supports a single deployment model whose parts can

be processed by different deployment technologies

in an automated manner. Thus, the overall research

question is “How to seamlessly model and automate

the deployment of a complex application distributed

across heterogeneous environments that requires dif-

ferent deployment technologies?”

The contributions of this paper are twofold. First,

it presents an approach based on a holistic deployment

model that expresses the deployment of the over-

all application and enables (i) to annotate parts that

must be deployed by different technologies, (ii) to

automatically translate these parts into deployment

technology-speciﬁc models (DTSMs) that can be pro-

cessed by the respective technologies, and (iii) to au-

tomatically coordinate the overall deployment with all

target technologies. For this purpose we have built

on existing work and use the Essential Deployment

Metamodel (EDMM) (Wurster et al., 2019b), which

describes the essential modeling entities supported by

the majority of deployment technologies, and shows

how such a model can be partitioned and the execu-

tion orchestrated. So far only the use of one technol-

ogy has been possible. The second contribution is an

extended system architecture of the EDMM Frame-

work (Wurster et al., 2019a, 2020a) (i) to transform

an EDMM model in multiple DTSMs considering the

inter-dependencies between them and (ii) to automate

application deployments by orchestrating multiple de-

ployment technologies. Hereby, the deployment is en-

acted by only relying on APIs of a deployment tech-

nology, while ensuring that the deployment informa-

tion are exchanged adequately between them. A pro-

totypical implementation of the system architecture

and a case study using Kubernetes, Terraform, and

Ansible demonstrate the overall practical feasibility.

In the following, Sect. 2 presents fundamentals and

Sect. 3 motivates our work. Sect. 4 introduces our ap-

proach and Sect. 5 proposes the system architecture.

Sect. 6 describes the prototype and Sect. 7 discusses

the contributions while Sect. 8 and Sect. 9 discuss re-

lated work and draw some concluding remarks.

2 FUNDAMENTALS

This section presents the fundamentals of deployment

automation and introduces EDMM.

2.1 Deployment Models & Deployment

Technologies

In practice, deployment technologies typically use

declarative deployment models to describe the de-

sired outcome of an automated deployment of an ap-

plication (Herry et al., 2011; Wurster et al., 2019b;

Bergmayr et al., 2018). Many deployment automa-

tion technologies have been developed and many of

them have originated from the industry, such as Chef,

Puppet, AWS CloudFormation, Terraform, or Kuber-

netes. Each deployment automation technology uses

its own DSL to declaratively model application de-

ployments, leading to a vendor lock-in with respect

to the used deployment model and technology. Fur-

ther, there is no “one ﬁts all” deployment technology

that can be used for arbitrary use cases and many of

them are tailored for certain use cases and only of-

fer capabilities to target certain infrastructure compo-

nents or cloud services. Even if such technologies

share the same purpose, they differ in features and

supported mechanisms. For example, someone would

use Terraform to provision cloud infrastructure and

cloud services such as VMs or managed database of-

ferings from multiple vendors while using conﬁgura-

tion management tools such as Chef or Ansible to in-

stall and conﬁgure arbitrary software components on

these VMs that utilize the provisioned cloud services.

Existing model-driven approaches that enable

the deployment of distributed applications in multi-

cloud environments or across organizational bound-

aries mainly focus on the automated reﬁnement

of provider-independent models to provider-speciﬁc

models for respective hosting environments (Di Nitto

et al., 2017) or the distributed deployment and man-

agement (Sebrechts et al., 2018; Saatkamp et al.,

2019; Wild et al., 2020). However, the combination of

different deployment automation technologies is not

covered yet and requires still manual modeling, trans-

formation, and coordination effort.

2.2 Essential Deployment Metamodel

The essential modeling entities supported by the ma-

jority of declarative deployment technologies have

been extracted by investigating the 13 most used de-

ployment technologies (Wurster et al., 2019b). The

Essential Deployment Metamodel (EDMM) enables

a common understanding of declarative deployment

Automating the Deployment of Distributed Applications by Combining Multiple Deployment Technologies

179

Relation

Type

Component

Type

is source of

is target of

is of type

implements

ComponentRelation

Property Operation

has

Model

Entity

Artifact

Deployment

Model

contains

has

Figure 1: Essential Deployment Metamodel (EDMM) [adapted from Wurster et al. (2019b)].

models and eases the comparison and selection of ap-

propriate technologies. Further, it facilitates the trans-

formation of a model employing the EDMM model-

ing entities into the DSL of one of the 13 most used

deployment technologies (Wurster et al., 2019a). We

now recap the EDMM entities and terminology re-

quired to understand this paper

Figure 1 depicts the essential modeling entities

of EDMM. Components enable modeling physical,

functional, or logical units of an application. For ex-

ample, a deployment model may contain several com-

ponents representing the deployment of a Java web

application, a Tomcat web server, or the provisioning

of an Ubuntu virtual machine (VM). Further, Compo-

nent Types deﬁne reusable entities that specify the se-

mantics of a component that have this type assigned.

What required to install or terminate a component are

provided by its type in the form of Properties and

Operations. Properties describe the desired target

state or conﬁguration for a component. Operations

instead deﬁne executable procedures for managing a

component during application deployment. For ex-

ample, a “Tomcat Web Server” component type may

deﬁne a “Port” property as a means for conﬁguration

as well as a “install” and “start” operation to encap-

sulate the logic how to install and start it. Relations

instead enable representing directed physical, func-

tional, or logical dependencies between components.

Relation Types are reusable entities that deﬁne a spe-

ciﬁc kind of dependency. In particular, relation Types

enable distinguishing relations modeling that a com-

ponent “connects to” to another, e. g., a web applica-

tion component connecting to a database component,

from those modeling that a component is “hosted on”

another, e. g., a Tomcat web server installed in a VM.

It is ﬁnally worth noting that components repre-

sent a certain functionality for a speciﬁc application

and relations are modeled between exactly two of its

components. Component types and relation types can

instead be reused in different models.

A more detailed, self-contained presentation of EDMM

has been published by Wurster et al. (2019b).

3 MOTIVATING SCENARIO &

RESEARCH QUESTIONS

The reasons for using different technologies are mani-

fold. Different deployment technologies only support

certain target environments. For example, for provi-

sioning and managing AWS resources CloudForma-

tion ﬁts best. Further, different technologies have dif-

ferent capabilities and purposes. While technologies

such as Terraform are focusing on infrastructure man-

agement for multiple cloud platforms, the main pur-

pose of conﬁguration management technologies such

as Chef are to conﬁgure applications on running in-

frastructure. However, deﬁning, managing, and or-

chestrating multiple independent deployment models

for different parts of an application is costly, requires

expertise in each technology, and is error-prone due

to manual tasks coordinating the execution.

InstanceType: XL

Database VM

(Ubuntu)

User: petclinic

Password: 5%87@

[…]

Database

(MySQL DB)

RootPass: !928Sa#

DBMS

(MySQL DBMS)

Region: EU

Container Runtime

(AWS ECS)

App

(Container)

Endpoint: ${Database.Host}

DB_User: ${Database.User}

[…]

Private Cloud

(OpenStack)

Public Cloud

(AWS)

HostedOn

ConnectsTo

Terraform Chef

Figure 2: Multi-component application deployment sce-

nario where different parts are deﬁned to be deployed using

different deployment automation technologies.

CLOSER 2021 - 11th International Conference on Cloud Computing and Services Science

180

DTSM

Transform

EDMM Fragments

into DTSMs

Create

EDMM Model

Annotate

Technology-

Specific Regions

in EDMM Model

Execute

Automated

Deployment

Determine

Deployment

Order

EDMM

Divide

EDMM Model

into Deployable

Fragments

EDMM

Figure 3: Automating the deployment of distributed applications by combining multiple deployment technologies.

Therefore, we strive to model the complete appli-

cation system in a holistic deployment model. Fig. 2

depicts a simpliﬁed motivating scenario which nev-

ertheless reﬂects practical relevance. The scenario

shows a containerized application that is hosted on

Amazon’s Elastic Container Service (ECS) on the

left. The container exposes a web application con-

necting to a “MySQL” database to store its data. Due

to privacy concerns, the database management system

is installed on an Ubuntu VM hosted inside an on-

premise OpenStack environment. In this scenario, the

decision is to use “Terraform” for cloud infrastruc-

ture and cloud service provisioning as it can be used

with multiple cloud providers and platforms. Further,

the conﬁguration management tool “Chef” is used to

install and conﬁgure arbitrary software components,

e. g., the depicted MySQL database management sys-

tem and its conﬁguration, on top of running infras-

tructure. Thus, the ﬁrst research question (RQ) is:

RQ 1. “How can a holistic deployment model be

annotated and divided so that different parts are

deployed by different deployment technologies?”

The motivation scenario depicts that the database

components are deployed using a different technol-

ogy than the container and infrastructure components.

This requires to divide and transform the user-deﬁned

deployment technology regions, i. e., annotated com-

ponents, into executable DTSMs. As a result, this re-

quires orchestrating the execution of different models

using different deployment technologies. Thus, the

second RQ tackled by this paper is:

RQ 2. “How can the deployment execution be

suitably coordinated using multiple deployment

technologies, if these rely on different DSLs and

provide different APIs?”

To tackle these research questions in the next section

our approach is presented. The remaining details of

Fig. 2 are explained in Sect. 4.1.

4 APPROACH

This section introduces an approach to automate the

deployment of distributed applications by combining

multiple deployment technologies. The overall appli-

cation is modeled using EDMM and the components

are annotated with the deployment technology to be

used for the actual deployment. Afterwards, the holis-

tic model is divided into valid EDMM model frag-

ments that are transformed into executable DTSMs.

Finally, the execution of all target technologies are

coordinated to suitably automate the deployment by

employing a plugin-based orchestrator.

Our approach is structured in six steps (Fig. 3):

(1) Create EDMM model for the whole applica-

tion, (2) annotate technology-speciﬁc regions in the

EDMM model, (3) divide the EDMM model into

multiple EDMM model fragments, (4) transform the

EDMM model fragments into DTSMs, (5) determine

the deployment order of the generated DTSMs, and

(6) execute the automated deployment. Steps 1 to 4

address RQ1, while steps 5 and 6 address RQ2.

4.1 Step 1: Technology-independent

Application Modeling using EDMM

The modeling of the application is done using EDMM

to provide a normalized and technology-independent

model. The application modeling can be graphically

edited by exploiting the EDMM Modeling Tool as pro-

posed by Wurster et al. (2019a). Application com-

ponents can be modeled by instantiating an exist-

ing component type that is provided by the modeling

environment. For example, the “Database” compo-

nent in our motivating scenario (Fig. 2) is modeled

by instantiating the “MySQL DB” component type.

Apart from the component name, “Database” in this

case, one can deﬁne several properties according to

the component type’s speciﬁcation to conﬁgure the

deployment. Similarly, relations can be modeled by

Automating the Deployment of Distributed Applications by Combining Multiple Deployment Technologies

181

connecting two components, either to specify that the

source component “connects to” the target component

or that it is “hosted on” the other.

Certain components may require information

from components they relate to get successfully de-

ployed. While this could be straightforward when

deploying components with the same technology, it

may be difﬁcult when components are deployed with

different technologies. This requires to suitably co-

ordinate such technologies, especially concerning the

information that is only available at runtime. Con-

sider, for example, “App” in Fig. 2, which requires

the endpoint and credentials to connect to the MySQL

“Database”. While the username and password can be

directly accessed in the model, the IP address is only

available after the VM of the database has been de-

ployed. Therefore, it must be possible to reference

certain runtime information of speciﬁc components,

like in the case of the backend endpoint for “App”,

which must reference the hostname or IP address of

the database VM. Such runtime property references

must be provided as inputs to the respective deploy-

ment technology prior to the deployment execution.

4.2 Step 2: Annotate Technology -

Speciﬁc Regions

In this step, the holistically created EDMM model

will be annotated to create technology-speciﬁc

regions indicating which deployment technology

should be used for the deployment. According to

model-driven architecture (MDA), the components in

the model are marked with the deployment technol-

ogy to be used for the actual deployment, i. e., the

marked components form a region. For this, the

EDMM model syntax has been extended by a new el-

ement, called technology_regions, which we intro-

duce in the course of this work. This allows to deﬁne

a map that assigns each component of a deployment

model to exactly one deployment technology.

Our motivating scenario in Fig. 2 already shows

the assignment of the application components with

different groups of components assigned to different

deployment technologies: “Database” and “DBMS”

are to be deployed using Chef, while the other com-

ponents are to be deployed using Terraform. Notably,

technology regions are not limited to components

which are directly connected, as shown by Fig. 2.

4.3 Step 3: Divide EDMM Model into

Deployable Fragments

Before DTSMs can be generated, the overall EDMM

model has to be divided into deployable EDMM

EDMM (A) EDMM (B)

EDMM (C)

MergeDivide

deployment groupTerraform ChefTechnology Regions:

Figure 4: Abstracted EDMM model with assigned technol-

ogy regions: (A) non-deployable deployment group assign-

ment and the algorithms procedure for (B) dividing and (C)

merging deployment groups.

model fragments. A deployable fragment is a group

of components in the EDMM model that can be de-

ployed by a certain technology as a “one-shot deploy-

ment”, i. e., deployed by a single run of the underlying

deployment technology. Thus, we call this group of

components deployment group. The deﬁned technol-

ogy regions from step 2 are the basis, since all com-

ponents assigned to a technology region have to be

deployed by the same technology.

At the same time, it may be that the components

in a technology region cannot be deployed all to-

gether. Consider, for instance, the situation in Fig. 4,

which shows the application in our motivating sce-

nario by abstracting from component details. EDMM

(A) speciﬁes two deployment groups, each containing

all components that have to be deployed with the same

technology. Two relations have to be realized between

components assigned to different groups. This re-

sults in a cycle of dependencies between deployment

groups, which makes it not possible to automatically

process the deployment groups: We cannot ﬁrst de-

ploy the components in the Terraform group as we

ﬁrst need to run Chef to deploy the components in its

group, but a similar argument prevents ﬁrst deploying

the components in the Chef group.

To enable deploying an application like that in

EDMM (A) as depicted in Fig. 4, deployment groups

have to be reﬁned so that no cycles occur among them.

We automatically enact such a reﬁnement by exploit-

ing the division approach introduced in previous work

as a baseline (Saatkamp et al., 2019). As sketched in

Fig. 4, ﬁrst all deployment groups are partitioned into

singleton deployment groups. The obtained groups

are then iteratively merged until no more groups can

be merged without resulting in cyclic dependencies.

The objective is to minimize the number of groups to

reduce the coordination effort for collecting and dis-

tributing information between the deployment tech-

nologies, since for each deployment group, i. e., the

resulting DTSM, the required information must be

provided as input before it can be executed.

CLOSER 2021 - 11th International Conference on Cloud Computing and Services Science

182

We extended the algorithm presented by

Saatkamp et al. (2019) to determine deployment

groups not only based on horizontal relations, e. g.,

“ConnectsTo” relations, but also vertical relations,

e. g., “HostedOn” relations, while considering the

technology regions. The rule for merging deployment

groups is as follows: Two components can be de-

ployed together if (i) they have the same technology

assigned and (ii) merging the components preserves

the acyclicity between deployment groups.

4.4 Step 4: Transform EDMM Model

Fragments into DTSMs

In this step, each model fragment determined by the

last step is transformed into its respective DTSM. We

extended the existing EDMM Transformation Frame-

work (Wurster et al., 2019a) to transform an EDMM

model fragment into a DTSM of a certain deployment

technology. Notably, we achieve this primarily be-

cause each determined EDMM model fragment is as-

signed to a single deployment technology.

The EDMM Transformation Framework enables

transforming a given EDMM model into required arti-

facts, i. e., ﬁles and models, to execute the deployment

using a selected deployment technology. It is plugin-

based and supports the transformation into DTSMs of

13 deployment automation technologies, such as Ku-

bernetes, Terraform, Chef, Ansible, and AWS Cloud-

Formation. Thus, the transformation can be executed

for each EDMM model fragment. However, the trans-

formation process needs to be aware of dependencies,

i. e., relations, between deployment groups. For ex-

ample, in a horizontal split as depicted on the right

hand side in Fig. 2 between Chef and Terraform, the

“IP address” of the provisioned Ubuntu VM must be

made available before Chef can be executed. Fur-

ther, considering the vertical split between Terraform

and Chef, the database credentials of the MySQL

database need to be made available to the container

application prior to deployment. Therefore, we dis-

tinguish between conﬁguration parameters, such as

port numbers or credentials, that are available through

the overall EDMM model, and runtime information

that is only available after the deployment of a com-

ponent, e. g., IP addresses. Depending on the com-

bination of deployment technologies, certain infor-

mation must be provided from components deployed

with one technology to components deployed with an-

other technology. Therefore, the $-notation is used

for accessing such information, as shown in Fig. 2.

We extended EDMM Transformation Framework to

(i) resolve conﬁguration parameters using the overall

EDMM model and (ii) to translate the usage of run-

time properties into respective inputs and outputs of

the underlying deployment technology.

4.5 Step 5: Determine Deployment

Order

The deployment order is the basis to execute the over-

all deployment of the generated DTSMs. Thereby, it

considers the deployment dependencies between de-

ployment groups since these determine the order how

the overall application must be deployed. Further, the

deployment order also provides the knowledge which

inputs and outputs for each DTSM execution need to

be provided during the automated deployment.

In general, the provisioning dependencies be-

tween components is determined by reversing rela-

tions, i. e., the target component of a relation must

be deployed before the source component (Breiten-

bücher et al., 2014), which represents the deploy-

ment order of the connected components. Further,

following the deﬁnition by Saatkamp et al. (2019),

the deployment order of the determined deployment

groups is calculated by reversing the relations be-

tween components in different deployment groups.

For the example in Fig. 2, the algorithm would deter-

mine three inter-connected deployment groups: two

separate groups for Terraform and a third one for

Chef, as indicated by (C) the resulting deployment

groups shown in Fig. 4. By reversing the relations

between groups, and by topologically sorting the re-

sulting graph, the deﬁned order is the following: First

execute the Terraform model for the OpenStack in-

frastructure, then the Chef model to install and conﬁg-

ure the MySQL database, and ﬁnally the second Ter-

raform model to conﬁgure the cloud services in AWS

and deploy the container application.

4.6 Step 6: Execute Automated

Deployment

Deployment technologies usually provide multiple

options to interact with, e. g., by providing soft-

ware development kits (SDKs), command-line inter-

faces (CLIs), or APIs such as REST APIs over HTTP.

Therefore, suitable Orchestration Plugins need to

generalize the execution of one of the deployment

technology’s interaction mechanism. Further, these

Orchestration Plugins must handle the required inputs

and outputs, i. e., collect information prior to the exe-

cution and distribute information after the execution.

For example, considering the motivating scenario, the

plugin for Chef requires information about the target

compute environment, i. e., the IP address and SSH

credentials, to actually execute the deployment of the

Automating the Deployment of Distributed Applications by Combining Multiple Deployment Technologies

183

MySQL database. Therefore, the Orchestration Plu-

gin for Terraform must populate these information

based on the outputs deﬁned by the DTSM.

5 SYSTEM ARCHITECTURE

This section introduces the system architecture to au-

tomate application deployments by orchestrating mul-

tiple deployment technologies. Fig. 5 shows a compo-

nent diagram to depict the modular structure of the

system, which is an extension of the system archi-

tecture of the existing EDMM Modeling and Trans-

formation System (Wurster et al., 2020a). Light

gray components represent new components while the

shaded component represents an existing one that has

been extended in the course of this work.

The Modeling Tool (Wurster et al., 2019a) is a

web-based modeling environment that uses a REST

API to retrieve and update its data. All data, e. g., cre-

ated models or the reusable EDMM component types,

is accessible through the REST API and stored in

the Repository. Users graphically compose the struc-

ture of the overall EDMM model using the reusable

EDMM component types. The technology-speciﬁc

regions are annotated by the user after exporting the

EDMM model from the Modeling Tool, i. e., covering

the ﬁrst two steps of our proposed approach.

The remaining steps are covered by a CLI that can

be used to divide and transform the overall EDMM

model into multiple DTSMs and to execute the au-

tomated deployment. Therefore, the Model Parser

and Model Divider components are the core compo-

nents. The Model Parser parses the overall EDMM

model and translates it into an internal graph-based

data structure on which the Model Divider performs

the extended division approach.

To transform the EDMM model fragments into

DTSMs, we employ the EDMM Transformation

Framework (Wurster et al., 2019a) as baseline for the

depicted Transformation component. It uses a plugin

architecture that supports the integration of various

deployment technologies in an extensible way. Each

plugin encompasses the knowledge whether a certain

EDMM component is supported for transformation or

not. Further, the plugins carry the logic and trans-

formation rules to transform an EDMM model into

a DTSM, which includes the creation of respective

technology-speciﬁc directory structures, ﬁles, and ar-

tifacts based on the respective DSL. The Transfor-

mation component was extended to handle EDMM

model fragments as well as inputs and outputs for the

determined deployment groups.

REST API

CLIModeling Tool

Model Parser

Model Divider

Transformation

Ansible Plugin

Terraform Plugin

Repository

Types

Models

Orchestration

Ansible Plugin

Terraform Plugin

Figure 5: System architecture as an extension of the

EDMM Modeling and Transformation System (Wurster

et al., 2020a) with new components in light gray and ex-

tended components shaded.

The Orchestration component is required to de-

termine the deployment order and to invoke the Or-

chestration Plugins. A plugin wraps the interaction

with a certain deployment technology, e. g., by utiliz-

ing SDKs or CLIs. Essentially, each plugin is a sub-

process that executes the DTSM using the given input

data and retrieves runtime information, such as IP ad-

dresses, after the successful execution. However, the

Orchestration component acts as intermediary and is

responsible to populate and store runtime information

after a plugin successfully ran. Moreover, it is respon-

sible to determine the input information, i. e., property

values and runtime information, required by plugins

to successfully execute it. This component is aware

of the overall EDMM model, the EDMM model frag-

ments, the deployment groups, and the runtime infor-

mation propagated back to the system after each de-

ployment task, i. e., Orchestration Plugin invocation.

6 PROTOTYPE & CASE STUDY

In this section, we present a prototypical implemen-

tation and demonstrate the usage based on a simpli-

ﬁed, but yet effective, case study to validate our ap-

proach

. The case study scenario is slightly adapted

from the one introduced in Fig. 2 because we vali-

date the approach based on more than two deploy-

ment technologies. The prototype is based on two

major software components: (i) the EDMM Modeling

Tool based on Eclipse Winery (Kopp et al., 2013) and

(ii) the EDMM Transformation Framework (Wurster

et al., 2019a, 2020a). In the course of this paper, we

A concrete example of the depicted case study includ-

ing the overall EDMM model and the translated DTSMs is

available online at https://bit.ly/37aZDv3.

CLOSER 2021 - 11th International Conference on Cloud Computing and Services Science

184

extended the EDMM Framework by the light gray and

shaded components as depicted in Fig. 5.

The holistic EDMM model is created using the

web-based EDMM Modeling Tool. Users compose

the structure by drag-and-drop desired components

to the canvas and deﬁne respective relations between

them by connecting the components. Further, users

deﬁne conﬁguration properties, such as port numbers,

for certain components by directly specifying con-

crete values or by referencing properties from other

components. For example, the “Petclinic” web ap-

plication needs to connect to the MySQL database

at runtime and requires information concerning the

endpoint and credentials. Users may deﬁne prop-

erties referencing properties from other components

that have concrete values assigned. For example, a

notation like ${<Component>.<Property>} allows

users to reference property values from related com-

ponents, as depicted by the “DB_User” property of

the “Petclinic” component in Fig. 6. Moreover, spe-

cial runtime properties can be referenced for informa-

tion that is only available after the deployment of cer-

tain components, e. g., IP addresses of VMs.

After exporting the model according to EDMM’s

YAML speciﬁcation, the technology-speciﬁc regions

can directly be deﬁne along the deployment model.

The technology_regions block deﬁnes the deploy-

ment technology and a list of components that should

be deployed with exactly this technology

The transformation into the desired DTSMs is

started using the EDMM CLI. The EDMM Transfor-

mation Framework parses the given model and the

holistic EDMM model is divided depending on the

deﬁned technology regions. The result is stored in-

memory to execute suitably the corresponding trans-

formation plugin. Each transformation plugin em-

ploys the logic to transform modeled components and

related artifacts to the ﬁles and templates required by

a deployment technology. However, we extended the

transformation engine and the existing transforma-

tion plugins for Ansible, Kubernetes, and Terraform

to handle cross-technology property references and

to resolve them during transformation. For example,

the Kubernetes plugin is able to resolve the database

properties and translates them into a “ConﬁgMap”.

For runtime information, e. g., IP addresses, plugins

that are able to handle “Compute” components, e. g.,

Terraform, deﬁne technology-speciﬁc modeling con-

structs in the DTSM so that such information can be

retrieved as outputs by the system.

The Orchestration component calculates the de-

ployment order by sorting the deployment groups

topologically and invokes the respective Orchestra-

tion Plugins. The required inputs and outputs, i. e.,

User: petclinic

Password: 5%87@

[…]

Database

(MySQL DB)

RootPass: !928Sa#

DBMS

(MySQL DBMS)

HostedOn

ConnectsTo

Petclinic

(Container)

Endpoint: ${Database.Host}

DB_User: ${Database.User}

[…]

InstanceType: XL

Database VM

(Ubuntu)

Private Cloud

(OpenStack)

Kubernetes

Ansible

Terraform

Container Runtime

(Kubernetes)

Figure 6: Case study to validate our prototype.

model properties or runtime information, are re-

trieved, stored, and distributed before and after ex-

ecuting a DTSM. To prove the feasibility, we imple-

mented three plugins, for Terraform, Ansible, and Ku-

bernetes, that are able to execute a deployment fully

automatically using our approach and EDMM.

7 DISCUSSION

In practice, different deployment technologies can be

integrate in different ways. For example, Terraform

already enables that Chef or Puppet agents are auto-

matically installed to pass the necessary information

to the management server for registration. However,

it relies heavily on the support of a certain deploy-

ment technology to support such an integration. Fur-

ther, this may still result in the need to (i) execute and

(ii) coordinate different technologies in a manually

determined order. Both is solved in this paper by a

technology-independent model-based approach using

EDMM and model transformation.

The presented approach is extensible also to fur-

ther deployment technologies as long as they are com-

pliant with the EDMM metamodel. In general, the

plugin-based framework enables the extension with

further Transformation and Orchestration Plugins (cf.

Fig. 5). At the time of writing, the framework sup-

ports the transformation of an EDMM model to 13

different deployment technologies, namely Ansible,

Azure Resource Manager, Chef, Docker Compose,

Heat Orchestration Template, Kubernetes, Terraform,

Puppet, Cloudify, AWS CloudFormation, Salt, Juju,

Automating the Deployment of Distributed Applications by Combining Multiple Deployment Technologies

185

and CFEngine. Further, the framework currently sup-

ports Terraform, Ansible, and Kubernetes concerning

orchestration. We implemented these three plugins

as a ﬁrst step to validate the overall approach. Even

though the presented motivating scenario is indeed

simple, it still highlights the challenges to combine

and coordinate these deployment technologies.

In contrast to orchestrators that process a sin-

gle deployment model, references to conﬁguration

or runtime properties provided by other components

must be explicitly modeled in EDMM because the

concrete operations and their implementations sup-

ported by the different deployment technologies are

not known in advance. Thus, we cannot rely on the

deployment processing capabilities for dependencies

between components that are deployed by different

technologies. By explicitly modeling the required in-

puts from other components, the deployment of the

whole application can be automated without manual

user inputs during the deployment.

Further, the presented approach is not only ap-

plicable to EDMM and its underlying YAML syn-

tax. TOSCA, for example, is heavily used in re-

search (Bellendorf and Mann, 2019) but barely sup-

ported by production-ready deployment technolo-

gies. However, previous work (Wurster et al., 2020b)

showed and validated that EDMM is a compliant sub-

set of TOSCA, which makes it possible to combine it

with our approach to target a wider audience and help

to bridge the gap between the academic state-of-the-

art and the industrial state-of-the-practice.

The presented system architecture, as most

production-ready deployment systems, is based on a

central orchestration component that coordinates the

deployment of the generated DTSMs. It is not based

on a workﬂow technology and an underlying work-

ﬂow language such as BPMN or BPEL. However, it

could be combined with existing approaches employ-

ing the advantages of workﬂow technologies, either

by orchestration workﬂows or by using a choreogra-

phy for a decentralized deployment executed by in-

dividual independent participants (Wild et al., 2020).

This has no inﬂuence on the functionality itself, but by

using standardized workﬂow languages we can take

advantage of the capabilities of workﬂow technolo-

gies such as scalability, reliability, robustness, and

transactional processing.

8 RELATED WORK

The problem of automating the deployment of multi-

component applications on cloud platform is well-

known (Wettinger et al., 2018), with the OASIS

standard TOSCA (OASIS, 2015) being one of the

most known approaches in this direction (Bergmayr

et al., 2018). TOSCA provides a standardized lan-

guage for specifying multi-component application in

a portable way, and to automate their deployment

on cloud infrastructures, provided that the latter sup-

port the declarative processing of TOSCA application

speciﬁcations, e. g., featured by OpenTOSCA (Bre-

itenbücher et al., 2016). Various other approaches

follow a similar approach,e. g., CAMEL (Achilleos

et al., 2019), MODAClouds (Di Nitto et al., 2017),

Panarello et al. (Panarello et al., 2017), Sea-

Clouds (Brogi et al., 2014) and trans-cloud (Carrasco

et al., 2018) (just to mention some), by starting from

a vendor-agnostic speciﬁcation of a multi-component

application, and enabling its deployment on hetero-

geneous clouds provided that the latter provide ad-

hoc components or middlewares for processing ap-

plication speciﬁcations. Further, Breitenbücher et al.

(2013) enable the integration of script-centric and

service-centric provisioning and conﬁguration tech-

nologies based on Management Planlets, while Wet-

tinger et al. (2013) integrate the usage of conﬁgura-

tion management tools with TOSCA. Our approach

differs from all those listed above, as we aim at auto-

matically generating the deployment artifacts needed

to deploy applications with already existing deploy-

ment technologies as they are, i. e., without requiring

any additional software component or middleware.

Closer approaches to ours are those by Di Cosmo

et al. (2014, 2015), Guillén et al. (2013), and Alipour

and Liu (2018). They all share our baseline idea

of generating concrete deployment artifacts from a

vendor-agnostic speciﬁcation of an application and

of its desired conﬁguration. Di Cosmo et al. (2014,

2015) indeed propose a solution for automatically

synthesizing a concrete deployment for a multi-

component application in a cloud environment, based

on a high-level speciﬁcation of the application and its

desired state. Guillén et al. (2013) and Alipour and

Liu (2018) instead transform an originally vendor-

independent application into a platform-speciﬁc so-

lution to enact its deployment. The above approaches

however differ from ours, as Di Cosmo et al. (2014,

2015) targets only OpenStack-based application de-

ployments, while Guillén et al. (2013) and Alipour

and Liu (2018) are intended to process applications

whose sources are available to their frameworks.

Other approaches worth mentioning are those by

Brabra et al. (2019) and Bogo et al. (2020), which en-

able deploying TOSCA models with different deploy-

ment technologies. Brabra et al. (2019) use model-

to-model and text-to-model transformation concepts

to transform to different technologies such as Juju,

CLOSER 2021 - 11th International Conference on Cloud Computing and Services Science

186

Kubernetes, or Terraform. Bogo et al. (2020) in-

stead propose TOSKOSE, a distributed solution for

enacting the deployment of multi-service application

on top of Docker Compose and Kubernetes, given

the speciﬁcation of their deployment in TOSCA. Our

approach differs from those by Brabra et al. (2019)

and Bogo et al. (2020) since we target 13 different

deployment technologies (therein included all those

supported by such approaches) and we enable to par-

tition the deployment of the application over different

deployment technologies at the same time.

To summarize, to the best of our knowledge, ours

is the ﬁrst approach enabling to split a single applica-

tion into different parts to be deployed with different

deployment technologies, while at the same time not

requiring any middleware to be installed. How an ap-

plication can be split into multiple parts and then de-

ployed independently has been discussed in different

works (Sebrechts et al., 2018; Saatkamp et al., 2019;

Wild et al., 2020). However, Saatkamp et al. (2019)

and Wild et al. (2020) enable an automated decentral-

ized deployment but support only TOSCA. Sebrechts

et al. (2018) enables the transformation from TOSCA

to Juju models but focuses on the reuse of the de-

ployment knowledge and the partitioning of manage-

ment tasks instead of supporting different technolo-

gies. Such decentralized deployment concepts could

be combined with our approach to split and transform

to different deployment automation technologies.

9 CONCLUSIONS

In this paper we presented an approach (i) to annotate

parts of a holistic deployment model to be deployed

with different deployment technologies, (ii) to auto-

matically transform an annotated model into multi-

ple DTSMs each deploying the annotated part of the

whole application, and (iii) to automatically coordi-

nate the deployment execution using different deploy-

ment technologies. Thus, for each part of an applica-

tion the best ﬁtting deployment technology can be se-

lected and combined, e. g., depending on the hosting

environment or the required capabilities. For the auto-

mated deployment, a central orchestration component

coordinates the deployment of the DTSMs in the cor-

rect order and handles the input and output between

the different deployment technologies. Thus, the de-

ployment processing can be completely automated.

The presented prototype supports currently the

transformation to 13 different deployment technolo-

gies and the deployment execution for three deploy-

ment technologies. It will be extended in future by

implementing additional transformation and orches-

tration plugins. Further, we plan to extend the ap-

proach also to enable the advantages of using work-

ﬂow technologies and to achieve a decentralized de-

ployment by employing choreographies. This fur-

ther increase the ﬂexibility of the deployment of com-

plex distributed applications, especially for applica-

tion scenarios involving multiple organizational enti-

ties, e. g., different departments or companies.

ACKNOWLEDGMENTS

This work is partially funded by the follow-

ing projects: RADON (EU, 825040), IC4F

(01MA17008G), and DECLware (PRA_2018_66).

REFERENCES

Achilleos, A. P., Kritikos, K., Rossini, A., Kapitsaki,

G. M., Domaschka, J., Orzechowski, M., Seybold,

D., Griesinger, F., Nikolov, N., Romero, D., and Pa-

padopoulos, G. A. (2019). The cloud application mod-

elling and execution language. Journal of Cloud Com-

puting, 8.

Alipour, H. and Liu, Y. (2018). Model Driven Deployment

of Auto-Scaling Services on Multiple Clouds. In 2018

IEEE International Conference on Software Architec-

ture Companion (ICSA-C), pages 93–96. IEEE.

Bellendorf, J. and Mann, Z. Á. (2019). Speciﬁcation of

cloud topologies and orchestration using TOSCA: a

survey. Computing.

Bergmayr, A., Breitenbücher, U., Ferry, N., Rossini, A.,

Solberg, A., Wimmer, M., Kappel, G., and Leymann,

F. (2018). A Systematic Review of Cloud Modeling

Languages. ACM Computing Surveys, 51(1).

Bogo, M., Soldani, J., Neri, D., and Brogi, A. (2020).

Component-aware orchestration of cloud-based enter-

prise applications, from tosca to docker and kuber-

netes. Software: Practice and Experience.

Brabra, H., Mtibaa, A., Gaaloul, W., Benatallah, B., and

Gargouri, F. (2019). Model-Driven Orchestration for

Cloud Resources. In 2019 IEEE 12th International

Conference on Cloud Computing (CLOUD), pages

422–429.

Breitenbücher, U., Binz, T., Képes, K., Kopp, O., Leymann,

F., and Wettinger, J. (2014). Combining Declarative

and Imperative Cloud Application Provisioning based

on TOSCA. In International Conference on Cloud En-

gineering (IC2E 2014), pages 87–96. IEEE.

Breitenbücher, U., Binz, T., Kopp, O., Leymann, F.,

and Wettinger, J. (2013). Integrated Cloud Appli-

cation Provisioning: Interconnecting Service-Centric

and Script-Centric Management Technologies. In

On the Move to Meaningful Internet Systems: OTM

2013 Conferences (CoopIS 2013), pages 130–148.

Springer.

Automating the Deployment of Distributed Applications by Combining Multiple Deployment Technologies

187

Breitenbücher, U., Endres, C., Képes, K., Kopp, O., Ley-

mann, F., Wagner, S., Wettinger, J., and Zimmer-

mann, M. (2016). The OpenTOSCA Ecosystem -

Concepts & Tools. European Space project on Smart

Systems, Big Data, Future Internet - Towards Serving

the Grand Societal Challenges, pages 112–130.

Brogi, A., Canciani, A., and Soldani, J. (2018). Fault-aware

management protocols for multi-component applica-

tions. Journal of Systems and Software, 139:189–210.

Brogi, A., Carrasco, J., Cubo, J., D’Andria, F., Ibrahim,

A., Pimentel, E., and Soldani, J. (2014). EU Project

SeaClouds - Adaptive Management of Service-based

Applications Across Multiple Clouds. In Proceedings

of the 4

International Conference on Cloud Comput-

ing and Services Science (CLOSER 2014), pages 758–

763. SciTePress.

Carrasco, J., Durán, F., and Pimentel, E. (2018). Trans-

cloud: CAMP/TOSCA-based bidimensional cross-

cloud. Computer Standards & Interfaces, 58:167–

179.

Di Cosmo, R., Eiche, A., Mauro, J., Zacchiroli, S., Za-

vattaro, G., and Zwolakowski, J. (2015). Automatic

Deployment of Services in the Cloud with Aeolus

Blender. In Service-Oriented Computing, pages 397–

411. Springer.

Di Cosmo, R., Lienhardt, M., Treinen, R., Zacchiroli, S.,

Zwolakowski, J., Eiche, A., and Agahi, A. (2014). Au-

tomated synthesis and deployment of cloud applica-

tions. In Proceedings of the 29

ACM/IEEE Interna-

tional Conference on Automated Software Engineer-

ing, pages 211––222. ACM.

Di Nitto, E., Matthews, P., Petcu, D., and Solberg, A.

(2017). Model-Driven Development and Operation

of Multi-Cloud Applications: The MODAClouds Ap-

proach. SpringerBriefs in Applied Sciences and Tech-

nology. Springer, Cham.

Endres, C., Breitenbücher, U., Falkenthal, M., Kopp, O.,

Leymann, F., and Wettinger, J. (2017). Declarative

vs. Imperative: Two Modeling Patterns for the Au-

tomated Deployment of Applications. In Proceed-

ings of the 9th International Conference on Pervasive

Patterns and Applications (PATTERNS), pages 22–27.

Xpert Publishing Services.

Guerriero, M., Garriga, M., Tamburri, D. A., and Palomba,

F. (2019). Adoption, support, and challenges of

infrastructure-as-code: Insights from industry. In

2019 IEEE International Conference on Software

Maintenance and Evolution (ICSME), pages 580–589.

Guillén, J., Miranda, J., Murillo, J. M., and Canal, C.

(2013). A service-oriented framework for developing

cross cloud migratable software. Journal of Systems

and Software, 86(9):2294–2308.

Herry, H., Anderson, P., and Wickler, G. (2011). Automated

Planning for Conﬁguration Changes. In Proceedings

of the 25

International Conference on Large Instal-

lation System Administration (LISA 2011), pages 57–

68. USENIX.

Kopp, O., Binz, T., Breitenbücher, U., and Leymann,

F. (2013). Winery – a modeling tool for tosca-

based cloud applications. In International Confer-

ence on Service-Oriented Computing, pages 700–704.

Springer.

OASIS (2015). TOSCA Simple Proﬁle in YAML Version

1.0. Organization for the Advancement of Structured

Information Standards (OASIS).

Oppenheimer, D., Ganapathi, A., and Patterson, D. A.

(2003). Why do internet services fail, and what can

be done about it? In Proceedings of the 4

Confer-

ence on USENIX Symposium on Internet Technologies

and Systems (USITS 2003). USENIX.

Panarello, A., Breitenbücher, U., Leymann, F., Puliaﬁto,

A., and Zimmermann, M. (2017). Automating the

Deployment of Multi-Cloud Applications in Feder-

ated Cloud Environments. In Proceedings of the 10

EAI International Conference on Performance Evalu-

ation Methodologies and Tools, pages 194—-201. In-

stitute for Computer Sciences, Social-Informatics and

Telecommunications Engineering (ICST).

Saatkamp, K., Breitenbücher, U., Kopp, O., and Leymann,

F. (2019). Method, formalization, and algorithms to

split topology models for distributed cloud application

deployments. Computing, pages 1–21.

Sebrechts, M., Van Seghbroeck, G., Wauters, T., Volckaert,

B., and De Turck, F. (2018). Orchestrator conversa-

tion: Distributed management of cloud applications.

International Journal of Network Management, 28(6).

Wettinger, J., Andrikopoulos, V., Leymann, F., and Strauch,

S. (2018). Middleware-Oriented Deployment Au-

tomation for Cloud Applications. IEEE Transactions

on Cloud Computing, 6(4):1054–1066.

Wettinger, J., Behrendt, M., Binz, T., Breitenbücher, U.,

Breiter, G., Leymann, F., Moser, S., Schwertle, I., and

Spatzier, T. (2013). Integrating conﬁguration man-

agement with model-driven cloud management based

on tosca. In Proceedings of the 3rd International

Conference on Cloud Computing and Service Science

(CLOSER 2013), pages 437–446. SciTePress.

Wild, K., Breitenbücher, U., Képes, K., Leymann,

F., and Weder, B. (2020). Decentralized Cross-

Organizational Application Deployment Automation:

An Approach for Generating Deployment Choreogra-

phies Based on Declarative Deployment Models. In

Proceedings of the 32nd Conference on Advanced In-

formation Systems Engineering (CAiSE 2020), vol-

ume 12127 of Lecture Notes in Computer Science,

pages 20–35. Springer International Publishing.

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., Brogi, A., Harzenetter, L.,

Leymann, F., and Soldani, J. (2020a). Technology-

Agnostic Declarative Deployment Automation of

Cloud Applications. In Proceedings of the 8

Eu-

ropean Conference on Service-Oriented and Cloud

Computing (ESOCC 2020), pages 97–112. 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-

CLOSER 2021 - 11th International Conference on Cloud Computing and Services Science

188

gies. SICS Software-Intensive Cyber-Physical Sys-

tems.

Wurster, M., Breitenbücher, U., Harzenetter, L., Leymann,

F., Soldani, J., and Yussupov, V. (2020b). TOSCA

Light: Bridging the Gap between the TOSCA Speci-

ﬁcation and Production-ready Deployment Technolo-

gies. In Proceedings of the 10

International Con-

ference on Cloud Computing and Services Science

(CLOSER 2020), pages 216–226. SciTePress.

Automating the Deployment of Distributed Applications by Combining Multiple Deployment Technologies

189