Automating the Deployment of Distributed Applications by Combining
Multiple Deployment Technologies
Michael Wurster
1
, Uwe Breitenbücher
1
, Antonio Brogi
2
, Felix Diez
1
,
Frank Leymann
1
, Jacopo Soldani
2
and Karoline Wild
1
1
University of Stuttgart, Institute of Architecture of Application Systems, Stuttgart, Germany
2
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 specific 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-
specific 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 Specification 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-Specific
Language (DSL) for specifying the desired state for
an application by means of a structural description of
the application components, their relations, and con-
figuration. Deployment automation is then achieved
by processing application specifications 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 specific 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 configuration 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 fits 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
Copyright
c
2021 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
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-specific 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 fits 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 configura-
tion management tools such as Chef or Ansible to in-
stall and configure 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 refinement
of provider-independent models to provider-specific
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
is of type
implements
ComponentRelation
Property Operation
has
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
1
.
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 define 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 configuration for a component. Operations
instead define executable procedures for managing a
component during application deployment. For ex-
ample, a “Tomcat Web Server” component type may
define a “Port” property as a means for configuration
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 define a spe-
cific 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 finally worth noting that components repre-
sent a certain functionality for a specific application
and relations are modeled between exactly two of its
components. Component types and relation types can
instead be reused in different models.
1
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 fits 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 configuration management technologies such
as Chef are to configure applications on running in-
frastructure. However, defining, 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 defined to be deployed using
different deployment automation technologies.
CLOSER 2021 - 11th International Conference on Cloud Computing and Services Science
180
DTSM
DTSM
DTSM
2
Transform
EDMM Fragments
into DTSMs
4
Create
EDMM Model
1
Annotate
Technology-
Specific Regions
in EDMM Model
2
Execute
Automated
Deployment
6
Determine
Deployment
Order
5
EDMM
Divide
EDMM Model
into Deployable
Fragments
3
EDMM
EDMM
3
EDMM
1
EDMM
2
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 simplified motivating scenario which nev-
ertheless reflects 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 configuration management tool “Chef” is used to
install and configure arbitrary software components,
e. g., the depicted MySQL database management sys-
tem and its configuration, on top of running infras-
tructure. Thus, the first 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-defined
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-specific 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 define several properties according to
the component type’s specification to configure 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 difficult 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 specific 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 -
Specific Regions
In this step, the holistically created EDMM model
will be annotated to create technology-specific
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 define
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 defined 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) specifies 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 first de-
ploy the components in the Terraform group as we
first need to run Chef to deploy the components in its
group, but a similar argument prevents first 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 refined so that no cycles occur among them.
We automatically enact such a refinement by exploit-
ing the division approach introduced in previous work
as a baseline (Saatkamp et al., 2019). As sketched in
Fig. 4, first 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., files 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 configuration 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 configuration 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 definition 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 defined order is the following: First
execute the Terraform model for the OpenStack in-
frastructure, then the Chef model to install and config-
ure the MySQL database, and finally the second Ter-
raform model to configure 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 defined 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-specific
regions are annotated by the user after exporting the
EDMM model from the Modeling Tool, i. e., covering
the first 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-specific directory structures, files, 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-
fied, but yet effective, case study to validate our ap-
proach
2
. 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
2
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 define respective relations between
them by connecting the components. Further, users
define configuration 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 define 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 specification, the technology-specific regions
can directly be define along the deployment model.
The technology_regions block defines the deploy-
ment technology and a list of components that should
be deployed with exactly this technology
2
.
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
defined 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 files 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 “ConfigMap”.
For runtime information, e. g., IP addresses, plugins
that are able to handle “Compute” components, e. g.,
Terraform, define technology-specific 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 first 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 configuration
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 workflow technology and an underlying work-
flow language such as BPMN or BPEL. However, it
could be combined with existing approaches employ-
ing the advantages of workflow technologies, either
by orchestration workflows or by using a choreogra-
phy for a decentralized deployment executed by in-
dividual independent participants (Wild et al., 2020).
This has no influence on the functionality itself, but by
using standardized workflow languages we can take
advantage of the capabilities of workflow 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
specifications, 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 specification 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 specifications. Further, Breitenbücher et al.
(2013) enable the integration of script-centric and
service-centric provisioning and configuration tech-
nologies based on Management Planlets, while Wet-
tinger et al. (2013) integrate the usage of configura-
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 specification of an application and
of its desired configuration. 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 specification 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-specific 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 specification 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 first 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 fitting 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-
flow technologies and to achieve a decentralized de-
ployment by employing choreographies. This fur-
ther increase the flexibility 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). Specification 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
th
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
th
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 Configuration Changes. In Proceedings
of the 25
th
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 Profile 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
th
Confer-
ence on USENIX Symposium on Internet Technologies
and Systems (USITS 2003). USENIX.
Panarello, A., Breitenbücher, U., Leymann, F., Puliafito,
A., and Zimmermann, M. (2017). Automating the
Deployment of Multi-Cloud Applications in Feder-
ated Cloud Environments. In Proceedings of the 10
th
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 configuration 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
th
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-
fication and Production-ready Deployment Technolo-
gies. In Proceedings of the 10
th
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