TOSCA Light: Bridging the Gap between the TOSCA Speciﬁcation and

Production-ready Deployment Technologies

Michael Wurster

, Uwe Breitenbücher

, Lukas Harzenetter

Frank Leymann

, Jacopo Soldani

and Vladimir Yussupov

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

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

Keywords:

Deployment Automation, Cloud Computing, TOSCA.

Abstract:

The automation of application deployment is critical because manually deploying applications is time-

consuming, tedious, and error-prone. Several deployment automation technologies have been developed in

recent years employing tool-speciﬁc deployment modeling languages. At the same time, the OASIS standard

Topology Orchestration Speciﬁcation for Cloud Applications (TOSCA) emerged as a means for describing

cloud applications, i. e., their components and relationships, in a vendor-agnostic fashion. Despite TOSCA is

widely used in research, it is not supported by the production-ready deployment automation technologies daily

used by practitioners working with cloud-native applications, hence resulting in a gap between the state-of-the-

art in research and state-of-practice in the industry. To help bridging this gap, we leverage the recently intro-

duced Essential Deployment Metamodel (EDMM) and identify TOSCA Light, an EDMM-compliant subset of

TOSCA, to enact the transformation from TOSCA to the vast majority of deployment automation technology-

speciﬁc models used by today’s software industry. Further, we present an end-to-end TOSCA Light modeling

and transformation workﬂow and show a prototypical implementation to validate our approach.

1 INTRODUCTION

Modern software engineering industry focuses heav-

ily on strengthening the synergy between develop-

ment and operation processes, commonly referred to

as DevOps (Humble and Molesky, 2011). One of

the most important approaches is Infrastructure as

Code (IaC), which allows application developers and

operation engineers to specify the infrastructure of to-

be-deployed applications “as code”, which can then

be processed by deployment automation technologies

such as Chef, Puppet, or Terraform.

Deployment automation technologies typically

rely on tool-speciﬁc declarative or imperative mod-

eling languages. Declarative languages allow to de-

scribe the “what”, i. e., the desired target state of the

components to be deployed, while imperative lan-

guages allow indicating the “how”, i. e., all technical

tasks to be executed for deploying and conﬁguring

an application (Endres et al., 2017). Even if declar-

ative languages are by far considered to be the most

appropriate in practice (Wurster et al., 2019b), they

are tightly coupled to the corresponding deployment

automation technology, hence not favoring the porta-

bility of speciﬁed application deployments from one

deployment automation technology to another.

In contrast, the Topology and Orchestration Spec-

iﬁcation for Cloud Applications (TOSCA) (OA-

SIS, 2019) is a standardized cloud modeling lan-

guage (CML) which allows to declaratively specify

application deployments in a portable way. While

TOSCA is heavily used in research (Bellendorf and

Mann, 2019), it is currently not supported by the

production-ready deployment automation technolo-

gies used by practitioners. As a result, a gap between

the state-of-the-art in research and industry is arising.

One possible way to bridge this gap is to lever-

age the recently introduced Essential Deployment

Metamodel (EDMM), which can be used to enable

standards-based CMLs (like TOSCA) to get sup-

ported by existing deployment automation tooling.

EDMM describes a set of core deployment modeling

entities that the vast majority of deployment automa-

tion technologies understand (Wurster et al., 2019b).

As a result, deployment models relying on the mod-

eling constructs speciﬁed in the EDMM are easily

convertible to multiple heterogeneous deployment au-

tomation formats, which is also shown by existing

216

Wurster, M., Breitenbücher, U., Harzenetter, L., Leymann, F., Soldani, J. and Yussupov, V.

TOSCA Light: Bridging the Gap between the TOSCA Speciﬁcation and Production-ready Deployment Technologies.

DOI: 10.5220/0009794302160226

In Proceedings of the 10th International Conference on Cloud Computing and Services Science (CLOSER 2020), pages 216-226

ISBN: 978-989-758-424-4

work (Wurster et al., 2019a). However, for mapping it

to EDMM, and for seamlessly exploiting the ease-of-

transformation of EDMM models, a CML has to com-

ply with the set of requirements imposed by EDMM.

In this work, we present TOSCA Light, as an

EDMM-compliant subset of TOSCA. TOSCA Light

can be used for devising technology-agnostic ap-

plication speciﬁcations that can be translated to

technology-speciﬁc deployment artifacts, hence ex-

ploiting TOSCA to avoid coupling application de-

ployments with particular technologies, while en-

abling their deployment on production-ready deploy-

ment technologies at the same time. Thus, TOSCA

Light enhances the portability of models, requiring to

model application deployments only once, and then

allowing them to be reused for deploying applications

with different, heterogeneous technologies. The main

contributions of this paper are the following:

• We deﬁne the TOSCA Light subset of TOSCA, by

identifying the set of EDMM compliance rules for

TOSCA-based models.

• We describe an end-to-end TOSCA Light model-

ing and transformation workﬂow.

• We illustrate a proof-of-concept implementation

of the TOSCA Light toolchain.

The paper is organized as follows. Section 2 provides

some necessary background. Section 3 presents the

TOSCA Light. Section 4 illustrates the end-to-end

TOSCA Light modeling and transformation work-

ﬂow, which prototypical implementation is shown in

Section 5. Finally, Section 6 discusses related work

and Section 7 draws concluding remarks.

2 BACKGROUND

This section presents the fundamentals and terminol-

ogy needed in the rest of the paper.

2.1 TOSCA

TOSCA is an OASIS standard that enables model-

ing, provisioning, and management of cloud appli-

cations (OASIS, 2019; Binz et al., 2012). TOSCA

allows to model so-called Service Templates that de-

scribe the topology, i. e., the components and their

relationships, of an application to be deployed to a

cloud infrastructure. The core modeling concepts

in TOSCA are nodes and relationships. So-called

Node Templates represent components of an appli-

cation, such as virtual machines, web servers, or ar-

bitrary software components, and so-called Relation-

ship Templates represent the relations between those

nodes, e. g., that a node is hosted on another node,

or that a node connects to another node. Node and

Relationship Templates are typed using Node Types

and Relationship Types deﬁning their semantics, and

structuring them by listing their properties, attributes,

requirements, capabilities, and interfaces.

Properties and attributes are used to conﬁgure the

deployment, e. g., a “Tomcat” web server type may

specify the property “port”, which is ﬁlled with con-

crete values in the node template upon deployment.

In the TOSCA metamodel, nodes get related to each

other when one node has a requirement against some

capability provided by another node. For example,

a virtual machine node may offer the capability that

a Tomcat web server node can be hosted on it. Fur-

ther, TOSCA standardizes the so-called Lifecycle In-

terface specifying that node types may have “create”,

“conﬁgure”, “start”, “stop”, and “delete” operations

to be used for installing, conﬁguring, starting, and

stopping them. Such operations are implemented by

so-called Implementation Artifacts, e. g., in the form

of executable Shell scripts. In contrast, Deployment

Artifacts implement a nodes’ business logic. For ex-

ample, the compressed binary ﬁles to run a Tomcat

web server are meant to be attached as a deployment

artifact to the respective type.

On top of that, TOSCA uses the notion of Policies

to express non-functional requirements affecting an

application topology at a certain stage of its lifecycle,

and which are attached to single or groups of nodes

in the application topology. For example, security

aspects that need to be enforced at certain stage can

be expressed via TOSCA policies (Yussupov et al.,

2019). Beside input and output parameters to param-

eterize a service template, TOSCA deﬁnes the CSAR

packaging format allowing to exchange applications.

2.2 Essential Deployment Metamodel

In recent years, many deployment technologies

evolved following a declarative approach to auto-

mate the delivery of software components. Even if

such technologies share the same purpose, they dif-

fer in features and supported mechanisms which is

why comparing and selecting deployment automation

technologies is difﬁcult.

Recently, the Essential Deployment Metamodel

(EDMM) was introduced as the result of a sys-

tematic review of deployment automation technolo-

gies (Wurster et al., 2019b). In this work, the authors

extracted the essential modeling entities that are sup-

ported by the vast majority of declarative deployment

automation technologies. The EDMM enables a com-

mon understanding of declarative deployment mod-

TOSCA Light: Bridging the Gap between the TOSCA Speciﬁcation and Production-ready Deployment Technologies

217

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)).

els and, thus, eases the comparison and selection of

appropriate technologies. Figure 1 depicts the essen-

tial modeling entities of the normalized metamodel.

EDMM deﬁnes Components as physical, functional,

or logical units of an application. Further, Relations

are deﬁned as directed physical, functional, or log-

ical dependencies between exactly two components.

Both can be typed using Component Types and Re-

lation Types to express reusable entities that specify

a certain semantic. Further, EDMM deﬁnes Proper-

ties as a way to describe the current state or prescribe

the desired target state or conﬁguration of a compo-

nent or relation. Moreover, Operations are used in

declarative deployment models to deﬁne executable

procedures performed to manage a component or re-

lation. Such operations provide hook points and are

executed by deployment technologies to implement

certain requirements during application deployment.

the EDMM also deﬁnes Artifacts such that an artifact

implements a component or operation and is therefore

required for the execution of the application deploy-

ment as well as the ﬁnal application system. Finally,

according to EDMM, a Deployment Model describes

the desired target state of an application including all

necessary components, relations, properties, opera-

tions, and artifacts in a declarative manner.

3 TOSCA LIGHT

Recent work showed that an EDMM deployment

model can be transformed into 13 concrete deploy-

ment automation technologies, such as Terraform and

AWS CloudFormation (Wurster et al., 2019a). Thus,

by reducing TOSCA to EDMM’s essential modeling

entities, which we call TOSCA Light hereafter, we

enable the transformation of TOSCA Light-compliant

models into the deployment technologies that are

currently supported by the EDMM Transformation

Framework. In the following, we present the TOSCA

Light modeling proﬁle which semantically maps to

the EDMM modeling constructs introduced in the

previous section. We show the supported TOSCA

Light modeling proﬁle based on TOSCA’s YAML

grammar for describing service templates, type def-

initions, topology templates, their nodes, relation-

ships, and properties (OASIS, 2019). Further, for the

sake of clarity, we show several TOSCA Light exam-

ples and code snippets.

3.1 Service Template

A Service Template in TOSCA is used to deﬁne the

topology of application components and cloud ser-

vices so that they can be deployed in accordance with

constraints and policies. In particular, service tem-

plates allow the deﬁnitions of a topology template,

types (e. g., node, relationship, capability, artifact

types), groupings, policies, and constraints along with

any input or output parameters (cf. Sect. 2). How-

ever, not all of these entities are compliant to EDMM

and, therefore, not part of TOSCA Light. In general,

the Service Template entity of TOSCA’s metamodel

corresponds to EDMM’s Deployment Model as it de-

scribes declaratively the desired target state of an ap-

plication including all necessary model entities. List-

ing 1 shows the service template deﬁnition accord-

ing to TOSCA Light. It can include arbitrary node

tosca_definitions_version: tosca_light_yaml_1_0

metadata:

# map of key/value pairs

description: <value>

node_types:

# map of TOSCA Light node type definitions

relationship_types:

# map of TOSCA Light relationship types

interface_types:

# map of TOSCA Light interface types

topology_template:

# TOSCA Light topology template definition

Listing 1: TOSCA Light service template.

CLOSER 2020 - 10th International Conference on Cloud Computing and Services Science

218

types, relationship types and interface types, provided

that such deﬁnition are TOSCA Light-compliant (cf.

Sect. 3.2), as well as TOSCA Light-compliant topol-

ogy template deﬁnition (cf. Sect. 3.3). Moreover, de-

scription and metadata information can be deﬁned to

convey additional information not required for the ac-

tual deployment automation.

Condition 1: A TOSCA Light-compliant service tem-

plate can only contain what follows:

Ô Description and additional metadata information,

with the latter given as a map of key/value pairs.

Ô Deﬁnitions of reusable TOSCA Light-compliant

node types.

Ô Deﬁnitions of reusable TOSCA Light-compliant

relationship types.

Ô Deﬁnitions of reusable TOSCA Light-compliant

Light interface types.

3.2 Type Deﬁnitions

TOSCA deﬁnes type entities, such as group types,

data types, capability types, and policy types. EDMM

generally does not deﬁne metamodel entities that map

to such TOSCA entities (cf. Fig. 1). Therefore, these

types cannot be semantically mapped to EDMM and

are not supported by TOSCA Light.

Further, TOSCA Light limits the use of interface

types. Wurster et al. (2019b) deﬁned that EDMM al-

lows to hook into or inﬂuence the deployment life-

cycle. This means that application developers must

be able to specify operations along the application’s

deployment lifecycle, e. g., to install, start, stop, or

terminate components. As TOSCA standardizes the

Lifecycle Interface and deﬁnes the essential opera-

tions that must be supported, such as starting, con-

ﬁguring, and stopping a component, the map of pos-

sible TOSCA Light interface types is restricted to this

single type. Hence, models deﬁning custom interface

types are not supported by TOSCA Light.

Weerasiri et al. (2017) deﬁned in their taxonomy

of cloud resource orchestration techniques that it must

be possible to express such that (i) a component gen-

erally depends on another component, (ii) a compo-

nent is “hosted on” or “contained in” another compo-

nent, and (iii) a component connects to another com-

ponent. Therefore, TOSCA Light limits the support

of relationship types to “DependsOn”, “HostedOn”,

and “ConnectsTo” as deﬁned accordingly in the nor-

mative type reference of the TOSCA Simple Proﬁle

speciﬁcation (OASIS, 2019). Hence, custom relation-

ship types must inherit from these types, otherwise,

the model is not compliant with TOSCA Light.

tosca_definitions_version: tosca_light_yaml_1_0

node_types:

<node_type_name>:

derived_from: <parent_node_type_name>

metadata:

# map of key/value pairs

description: <value>

attributes:

# map of TOSCA Light attribute definitions

properties:

# map of TOSCA Light property definitions

interfaces:

# map of TOSCA Light interface definition

artifacts:

# map of TOSCA Light artifact definitions

Listing 2: TOSCA Light node type.

Semantically, TOSCA node and relationship types

refer to EDMM’s Component Type and Relationship

Type metamodel entities. Such types specify the se-

mantics by means of properties and operations, and

are often meant to be reused in multiple deployment

models. The TOSCA Light modeling proﬁle allows

the deﬁnition of attributes and properties on

such types, as shown in Listing 2 on the example of

node types. These are deﬁned by a type (in accor-

dance to the YAML 1.2 spec), a description, an op-

tional default value, and a required ﬂag, and corre-

spond to the Property entity in EDMM.

Apart from a “description” and additional “meta-

data” information, the map of artifacts corresponds

to the Artifact entity in EDMM. The map deﬁnes a

named list of ﬁles that are associated with this type

and used by deployment automation technologies to

facilitate the deployment and implementation of inter-

face operations. To hook into or inﬂuence the deploy-

ment lifecycle, a TOSCA Light node type may de-

ﬁne several operations based on TOSCA’s standard-

ized lifecycle interface. Such operations correspond

to EDMM’s Operation entity and deﬁne possible ex-

ecutable procedures performed to deploy this type.

tosca_definitions_version: tosca_light_yaml_1_0

topology_template:

inputs:

# map of TOSCA Light property definitions

outputs:

# map of TOSCA Light property definitions

node_templates:

# map of TOSCA Light node templates

relationship_templates:

# map of TOSCA Light relationship templates

Listing 3: TOSCA Light topology template.

TOSCA Light: Bridging the Gap between the TOSCA Speciﬁcation and Production-ready Deployment Technologies

219

Condition 2: A speciﬁcation is TOSCA Light-

compliant if the following constraints on types hold:

Ô The only employed interface type is the TOSCA’s

standard lifecycle interface.

Ô Employed relationship types are restricted to

TOSCA’s normative types “DependsOn”, “Hoste-

dOn”, and “ConnectsTo”, and to custom types de-

ﬁned by extending such types.

Ô Node types and relationship types can deﬁne a

description and additional metadata information,

with the latter given as a map of key/value pairs.

Ô If node types and relationship types deﬁne “at-

tributes” and “properties”, these specify a type,

description, default value, and required ﬂag.

Ô If node types and relationship types deﬁne oper-

ations, these are based on TOSCA’s standardized

lifecycle interface.

Ô If node types and relationship types list “artifacts”,

these are used to implement nodes, relations, or

interface operations.

3.3 Topology Template

A Topology Template deﬁnes the overall structure of

an application deployment and is part of a service

template. It contains the set of Node Template and

Relationship Template deﬁnitions that together deﬁne

the topology of the application as a directed graph,

which in turn correspond to the Components and Re-

lations entities in EDMM. Further, TOSCA Light al-

lows to deﬁne input and output parameters to param-

eterize a topology model instead of using ﬁxed val-

ues only. Such parameters correspond to the Property

entity in EDMM and can be deﬁned by a type (in ac-

cordance to the YAML 1.2 spec), a description, an

optional default value or a computed value by a com-

position of node properties. The “policy” and “work-

ﬂow” construct deﬁned by TOSCA (OASIS, 2019) is

not supported by TOSCA Light as there is no corre-

sponding entity in EDMM.

Listing 4 shows a simple TOSCA Light exam-

ple to install a MySQL database system on top of an

Ubuntu virtual machine. The Ubuntu virtual machine

and the MySQL software component are expressed as

separate node templates and specify the occurrences

of components as part of the deployment model. The

example shows how input parameters are used to pa-

rameterize the deﬁnition of the used root password.

Further, a “conﬁgure” script is assigned as an opera-

tion to execute custom logic during deployment.

Even more, the example highlights that TOSCA in

general relies on capabilities and requirements. For

example, capabilities are used to deﬁne additional

properties for a node, e. g., the type of operating sys-

tem to be used. Further, TOSCA relies on matching

tosca_definitions_version: tosca_light_yaml_1_0

topology_template:

inputs:

password:

type: string

port:

type: string

default: 3306

node_templates:

mysql:

type: tosca.nodes.DBMS.MySQL

properties:

root_password: { get_input: password }

port: { get_input: port }

interfaces:

Standard:

operations:

configure: configure.sh

requirements:

- host:

node: db_server

relationship: hosted_on

db_server:

type: tosca.nodes.Compute

capabilities:

os:

properties:

architecture: x86_64

type: linux

distribution: ubuntu

version: 18.04 LTS

relationship_templates:

hosted_on:

type: tosca.relationships.HostedOn

Listing 4: TOSCA Light template to install MySQL.

capabilities and requirements to express certain rela-

tionships between nodes, e. g., the “hosted on” rela-

tionship between the nodes in Listing 4.

However, TOSCA Light is not able to use re-

quirements and capabilities as a ﬁrst-class model-

ing construct as there is no matching entity avail-

able in EDMM. Instead, TOSCA Light relies on the

deﬁned normative requirements and capabilities of

the TOSCA Simple Proﬁle (OASIS, 2019) and maps

them semantically to properties (cf. operating system

properties) or considers them as a relationship deﬁni-

tion (cf. hosted on relationship). Moreover, advanced

TOSCA features such as “substitution mappings” or

the node_filter setting are in general not supported

by TOSCA Light. Anyhow, a TOSCA modeling tool

that supports both, TOSCA and TOSCA Light, could

try to resolve open requirements, resolve substitutable

types, and resolve the node_filter setting based on

a given TOSCA type repository before further pro-

cessing it as a TOSCA Light model.

CLOSER 2020 - 10th International Conference on Cloud Computing and Services Science

220

Condition 3: A TOSCA Light-compliant topology

template can only contain what follows:

Ô Deﬁnition of “input” and “output” parameters,

each specifying a type, description, value, or com-

puted value by a composition of properties.

Ô Node templates declaratively specifying the com-

ponents to be deployed.

Ô Relationship templates indicating the functional

or logical dependency between two nodes.

Ô Concrete values assigned to deﬁned “properties”.

Ô Additional operation deﬁnitions, still based on

TOSCA’s normative lifecycle interface.

Ô Usage of TOSCA’s normative “capabilities”.

3.4 Deﬁning TOSCA Light

In summary, a TOSCA application has to satisfy con-

ditions 1, 2, and 3 respectively discussed in Sect. 3.1

to 3.3 to be compliant with TOSCA Light.

Condition 1 deﬁnes that a TOSCA Light service

template, among the description and additional de-

scriptive metadata information, deﬁnes reusable sets

of TOSCA Light compliant node types, relationship

types, and interface types.

Condition 2 restricts type deﬁnitions. TOSCA

Light only allows the usage of the standard lifecycle

interface and the normative relationship types deﬁned

by the TOSCA standard. Hence, custom relationship

types must inherit from the normative types. Further,

the deﬁnition of “operations” on node types and rela-

tionship types must be based on the standard lifecycle

interface. Along with description and metadata, node

types and relationship types may deﬁne “attributes”

and “properties” to describe the current state or de-

sired target state of conﬁguration. Finally, node types

and relationship types may deﬁne “artifacts” to imple-

ment nodes, relations, or interface operations.

Condition 3 deﬁnes additional restrictions on

topology templates. TOSCA Light compliant topol-

ogy templates may deﬁne “input” and “output” pa-

rameters. Further, a set of node templates and re-

lationship templates deﬁne the declarative speciﬁca-

tion of components to be deployed and the func-

tional or logical dependency between them. More-

over, node templates and relationship templates may

assign concrete values to deﬁned “properties” as well

as deﬁne additional “artifacts” and “operations” as

long as they are comply with TOSCA’s normative

lifecycle interface. TOSCA Light supports the use

of TOSCA’s normative “requirements” and “capabil-

ities” to establish relationships or deﬁne additional

properties. However, the deﬁnition of open require-

ments (e.g., node_filter) is not supported.

4 END-TO-END TOOLCHAIN

In this section, we elaborate on the end-to-end mod-

eling and transformation workﬂow using TOSCA

Light. The overall process comprises four steps as

shown in Fig. 2 and starts with the creation of an

EDMM-compliant TOSCA Light deployment model.

4.1 Create Deployment Model

An application component architecture is speciﬁed

using the TOSCA CML to produce deployment model.

Workﬂow. The overall modeling workﬂow, essen-

tially, does not differ from the common process.

A given application’s component architecture is de-

scribed declaratively using TOSCA constructs either

using a graphical modeling tool or a text editor.

The resulting set of modeling artifacts comprises the

TOSCA-based deﬁnitions describing types and com-

ponent instances as well as the ﬁle artifacts required

for deploying the application, e. g., container images.

Tooling. The deployment model can be speciﬁed us-

ing multiple possible tools, including graphical mod-

eling tools such as Eclipse Winery (Kopp et al., 2013)

or Alien4Cloud (ALIEN 4 Cloud, 2020). Another

possible option is to use text-based editors such as Vi-

sual Studio Code offered by Microsoft.

4.2 Validate TOSCA Light Compliance

The produced TOSCA-based deployment model is

analyzed to ensure its compliance to the TOSCA

Light modeling proﬁle and, hence, to EDMM.

Workﬂow. As a next step, the resulting TOSCA-

based deployment model is validated for EDMM

compliance. To achieve this, the given model is

checked against the set of modeling requirements dis-

cussed in-detail in Sect. 3. In case the model is

EDMM-compliant it is labeled as TOSCA Light and

can be used as an input for transforming the model

into the desired target deployment format such as Ter-

raform or Kubernetes. In situations when the model

is not compatible with the TOSCA Light modeling

proﬁle, the model can be reﬁned according to the pro-

vided modiﬁcation recommendations.

Tooling. Essentially, the validation of the model can

be performed either at design time using graphical

modeling tools or text editors, or at transformation

time using transformation tools. In case of the for-

mer, corresponding TOSCA Light compliance plug-

ins have to be introduced. Further, tools like Eclipse

TOSCA Light: Bridging the Gap between the TOSCA Speciﬁcation and Production-ready Deployment Technologies

221

Create

Deployment

Model

Validate

TOSCA Light

Compliance

Execute

Deployment

Transform

Deployment

Model

TOSCA TOSCA

DTSM

Figure 2: TOSCA Light end-to-end toolchain.

Winery could also provide a TOSCA Light compli-

ance check while importing existing TOSCA applica-

tions or by providing mechanisms to verify a given

TOSCA repository regarding compliance.

4.3 Transform Deployment Model

The successfully validated TOSCA Light model is

transformed into the target deployment technology.

Workﬂow. Afterwards, the successfully validated

TOSCA Light model is used as an input for the

transformation engine to produce a deployment

technology-speciﬁc model (DTSM). Consequently,

another input required for the transformation engine

is the name of the target deployment automation tool,

e. g., Ansible or Terraform. As discussed previously,

the possibility to transform the model is guaranteed

by design since the used modeling constructs conform

to the essential entities deﬁned by EDMM.

Tooling. The EDMM Transformation Framework is

used to generate the DTSM (Wurster et al., 2019a).

To achieve this, a given TOSCA Light model’s con-

structs are mapped to the corresponding entities in the

target tool’s constructs space. It is worth mentioning,

that the generated target model might be reﬁned with,

e. g., security credentials or other conﬁguration infor-

mation in the form variables that are relevant only for

the target deployment automation technology.

4.4 Execute Deployment

The transformed technology-speciﬁc deployment

model is executed using the standard mechanisms

provided by the target deployment automation tool.

Workﬂow. Finally, after the generated target deploy-

ment model is ready to be deployed, it can be used as

an input for the target deployment automation tech-

nology. Hence, the actual deployment happens using

the standard tool’s mechanisms, which also simpliﬁes

further management of the application.

Tooling. Since the deployment happens using the

standard tool-speciﬁc deployment mechanisms, the

actual tooling that needs to be used depends on the

concrete use case, i. e., which target deployment tech-

nology was used. This also inﬂuences the way the tool

has to be used, i. e., where it can be hosted or who op-

erates it. For example, the interaction will be different

for as-a-service solutions such as AWS CloudForma-

tion and self-hosted tools such as Ansible.

5 PROOF-OF-CONCEPT

IMPLEMENTATION

In this section, we illustrate a proof-of-concept (PoC)

implementation based on (i) Eclipse Winery (Kopp

et al., 2013) and (ii) the EDMM Transformation

Framework

(Wurster et al., 2019a) to validate the

feasibility of the proposed TOSCA Light end-to-end

toolchain. Next, we brieﬂy explain the extensions, the

usage of the tools, and how they map to the proposed

end-to-end toolchain in Sect. 4.

Eclipse Winery is a web-based environment to

graphically model TOSCA-based application topolo-

gies. It provides a Management Interface to manage

all TOSCA related entities, such as node types, their

property deﬁnitions, operations, and artifacts. Fur-

ther, Winery provides a Topology Modeler component

which enables the graphical composition of the de-

sired target state of application to be deployed. For

this PoC, Winery has been extended by the TOSCA

Light Mode and is used to deﬁne and develop the de-

ployment model graphically in accordance to step 1 in

Fig. 2. We created a fork of Eclipse Winery and pub-

lished our extension to GitHub

respectively. The cur-

rent implementation checks the TOSCA Light com-

https://bit.ly/2WzlicC

https://bit.ly/2xg4hK0

CLOSER 2020 - 10th International Conference on Cloud Computing and Services Science

222

pliance when a user opens a TOSCA service template,

which implements step 2 of the proposed TOSCA

Light toolchain (cf. Fig. 2). Each created or imported

TOSCA model may be ﬂagged as TOSCA Light com-

pliant by showing a TOSCA Light logo in Winery’s

header component. Further, Winery is able to provide

a list of violated conditions when a TOSCA service

template is not compliant with TOSCA Light.

In terms of transformation (cf. step 3 in Fig. 2), we

exploit the existing EDMM export functionality by

Eclipse Winery, as TOSCA Light is fully compliant

to EDMM. The exported EDMM model can then di-

rectly be processed by the the EDMM Transformation

Framework (Wurster et al., 2019a), either by using the

provided CLI or the REST interface over HTTP. To-

gether with the EDMM model, a user can select a cer-

tain target deployment technology and the framework

generates the respective ﬁles and templates. Finally,

and according to step 4 (cf. Fig. 2), the output can be

executed using the target technology’s tooling.

6 RELATED WORK

The OASIS standard TOSCA constitutes a refer-

ence metamodel for specifying the topology and

orchestration of multi-component cloud applica-

tions (Bergmayr et al., 2018). At the same time, most

existing cloud deployment automation technologies

are not offering a native support to TOSCA, which

makes it complex to deploy and manage TOSCA-

based application in production-ready environments.

Currently existing efforts for enacting the de-

ployment of TOSCA-based applications can be clus-

tered in three main categories (Bellendorf and Mann,

2019). We can indeed distinguish (i) solutions for

directly deploying TOSCA application speciﬁcations

in cloud infrastructure, (ii) approaches integrating

TOSCA with other standards for enhancing deploy-

ment automation, and (iii) solutions for enabling the

deployment of TOSCA-based applications on existing

deployment technologies.

The reference approach for directly deploying

TOSCA-based cloud application is the OpenTOSCA

engine proposed by Binz et al. (2013), recently ex-

tended to also support the deployment of applications

also in IoT environments (da Silva et al., 2016). The

OpenTOSCA engine enables the orchestration of the

deployment and management of TOSCA-based appli-

cations on a target infrastructure, by obviously requir-

ing to get installed in the manager of such infrastruc-

ture and of being provided with the TOSCA speciﬁca-

tions of to-be-orchestrated applications. It is however

intended to be itself the orchestrator of the applica-

tion, and it currently does not support streamlining

the deployment and management of an application to

other existing deployment technologies (e. g., Kuber-

netes or Terraform), which are currently more used in

production-ready environments (Pahl et al., 2019).

Similar considerations apply to other existing

approaches enabling the deployment and manage-

ment of TOSCA-based application on target in-

frastructures, e. g., the DevOps-based streamlining

proposed by Wettinger et al. (2014, 2015), the

TOSCA support provided by Cloudify (Cloudify Plat-

form Ltd., 2020), the open-source initiatives Ari-

aTOSCA (Apache Software Foundation, 2018) and

Alien4Cloud (ALIEN 4 Cloud, 2020), and the multi-

cloud orchestration enacted by SeaClouds (Brogi

et al., 2016). All such approaches rely on the avail-

ability of full-ﬂedged TOSCA-compliant orchestra-

tors, while our objective is to identify the subset of

TOSCA enabling the speciﬁcation multi-component

applications that can then be processed by most used

production-ready cloud deployment automation tech-

nologies. We enable this by identifying the subset of

TOSCA that is compliant with the EDMM proposed

by Wurster et al. (2019b), and by providing the tool-

ing needed to enact the translation of TOSCA Light

application speciﬁcations on all cloud deployment

automation technologies supported by the EDMM

Transformation Framework (Wurster et al., 2019a).

Other approaches worth relating to ours are those in-

tegrating TOSCA with other standards for enhancing

deployment automation. Noteworthy efforts in this

direction are those by Calcaterra et al. (2017, 2018a)

and by Kopp et al. (2012), both working on the inte-

gration of BPMN with TOSCA to imperatively pro-

gram and automate the deployment and management

of multi-cloud application. Calcaterra et al. (2017,

2018a) propose a solution to automatically generate

BPMN workﬂows for deploying and managing multi-

component applications, starting from their TOSCA

speciﬁcation. They also provide an extension of their

approach, which allows to deal with potential failures

while actually enacting the generated BPMN work-

ﬂows (Calcaterra et al., 2018b). Kopp et al. (2012)

instead proposes a BPMN proﬁle for enabling the im-

perative programming of the deployment and man-

agement of multi-component applications speciﬁed in

TOSCA. Hence, even if different in the spirit, both the

approaches by Calcaterra et al. (2017, 2018a) and by

Kopp et al. (2012) enable automating the deployment

and management of TOSCA applications by relying

on the availability of a BPMN engine.

Cardoso et al. (2013) and Glaser. et al. (2017)

are worth mentioning efforts integrating TOSCA with

other standards for enhancing deployment automa-

TOSCA Light: Bridging the Gap between the TOSCA Speciﬁcation and Production-ready Deployment Technologies

223

tion. Cardoso et al. (2013) propose to integrate

TOSCA with the service description language USDL,

by exploiting the latter to deﬁne the functionalities of

cloud services, and by providing a prototypical plat-

form integrating service selection with deployment.

Glaser. et al. (2017) instead provide analyze the

analogies and possible integration between TOSCA

and OCCI (Open Grid Forum, 2016). They then pro-

pose a fully-automated model-driven cloud applica-

tion orchestrator based on the two standards.

However, the approaches by Calcaterra et al.

(2017, 2018a), Kopp et al. (2012), Cardoso et al.

(2013), and Bergmayr et al. (2016) all aim at tack-

ling objectives quite different from ours. They suc-

ceed in enabling the deployment and management

of TOSCA-based applications based on the integra-

tion of TOSCA with existing standards, but they are

not supporting the possibility of enacting the deploy-

ment of TOSCA-based applications using production-

ready deployment automation technologies.

Last, but probably the most related to our approach,

are the solutions enabling the deployment of TOSCA-

based applications on existing cloud deployment au-

tomation technologies. Breiter et al. (2014) illus-

trate how to deploy multi-component applications

speciﬁed in TOSCA on the IBM cloud comput-

ing infrastructure. Brogi et al. (2018b,a) propose a

TOSCA proﬁle for specifying container-based multi-

component application, by also providing the TosKer

engine for actually enacting their deployment and

management of such application on Docker-enabled

infrastructures. Carrasco et al. (2016); Carrasco et al.

(2018) enable trans-cloud application deployment, by

allowing to run TOSCA application speciﬁcations on

top of Apache Brooklyn (Apache Software Founda-

tion, 2020). However, all such efforts target a pre-

cise infrastructure or a precise cloud deployment au-

tomation technology. We instead aim at enabling the

deployment of TOSCA applications with most used

production-ready deployment technologies.

Similar considerations apply to the noteworthy ef-

forts by Katsaros et al. (2014) and Tricomi et al.

(2017). Both proposing different approaches for en-

abling the deployment of multi-component applica-

tions speciﬁed in TOSCA on OpenStack cloud infras-

tructures. Gusev et al. (2014) and Ivanovska et al.

(2015) goes even a step further by proposing the P-

TOSCA environment, which enables multi-cloud de-

ployment and management of TOSCA-based applica-

tions on both Eucalyptus and OpenStack.

In summary, to the best of our knowledge, all existing

approaches for enabling the deployment of TOSCA

application focus on supporting the full expressive-

ness of TOSCA, either by requiring to process ap-

plication speciﬁcations with TOSCA-compliant en-

gines or by requiring to run them with some speciﬁc

third-party orchestrator. Our aim is instead to identify

the subset of TOSCA (i. e., the TOSCA Light pro-

ﬁle) that can be processed by any production-ready

cloud deployment automation technology, to give ap-

plication administrators the freedom of choosing the

technology most suited to their needs. We indeed

identify the subset of TOSCA that is compliant with

the EDMM metamodel, which is known to distill the

essentials of cloud deployment automation technolo-

gies (Wurster et al., 2019b). Further, we provide all

tooling needed to actually translate TOSCA Light ap-

plication speciﬁcations into deployment technology-

speciﬁc models (DTSM) allowing to enact their de-

ployment and management on production-ready de-

ployment automation technologies, i. e., those cur-

rently supported by the EDMM Modeling and Trans-

formation Framework (Wurster et al., 2019a).

7 CONCLUSIONS

TOSCA as a standardized cloud modeling language

is indeed widely used in research. However, in

industry, concrete deployment automation technolo-

gies are much more common as they often provide

comprehensive tooling and support for integration in

modern software development and operations pro-

cesses. To close this gap, we identiﬁed and intro-

duced the TOSCA Light modeling proﬁle, a set of

EDMM compatibility rules resulting in a reduced

set of TOSCA modeling constructs, and described

the TOSCA Light end-to-end toolchain. Further, we

presented a PoC implementation of the end-to-end

toolchain by extending Eclipse Winery to interac-

tively check TOSCA applications for TOSCA Light

compliance. By leveraging EDMM and its transfor-

mation capabilities, we enact to translate TOSCA-

based application deployment models into concrete

deployment technology-speciﬁc models used by pop-

ular deployment automation technologies.

For immediate future work, we plan to fully im-

plement and evaluate the proposed TOSCA Light

toolchain. The modeling complexity as well as the

engineered prototype will be evaluated using a real-

world industrial scenario. We plan to show a detailed

study on how TOSCA Light can simplify the manage-

ment of applications running on Kubernetes.

Beside of that, we plan to investigate the re-

lation of EDMM to other cloud modeling lan-

guages (Bergmayr et al., 2018), such as CAMEL

or CloudML, to enact the translation based on the

EDMM Transformation Framework.

CLOSER 2020 - 10th International Conference on Cloud Computing and Services Science

224

ACKNOWLEDGMENTS

This work is partially funded by the EU project

RADON (825040), the German Research Founda-

tion (DFG) project SustainLife (379522012), and the

projects AMaCA (POR-FSE) and DECLware (Uni-

versity of Pisa, PRA_2018_66).

REFERENCES

ALIEN 4 Cloud (2020). ALIEN 4 Cloud. Version 3, https:

//alien4cloud.github.io.

Apache Software Foundation (2018). AriaTOSCA. Incuba-

tor, https://ariatosca.incubator.apache.org.

Apache Software Foundation (2020). Apache Brooklyn.

Version 1, https://brooklyn.apache.org.

Bellendorf, J. and Mann, Z. A. (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 Comput. Surv., 51(1).

Bergmayr, A., Breitenbücher, U., Kopp, O., Wimmer, M.,

Kappel, G., and Leymann, F. (2016). From Archi-

tecture Modeling to Application Provisioning for the

Cloud by Combining UML and TOSCA. In Proceed-

ings of the 6th International Conference on Cloud

Computing and Services Science - Volume 1 and 2,

CLOSER 2016, page 97–108. SciTePress.

Binz, T., Breitenbücher, U., Haupt, F., Kopp, O., Ley-

mann, F., Nowak, A., and Wagner, S. (2013). Open-

TOSCA — A Runtime for TOSCA-Based Cloud Ap-

plications. In Proceedings of the 11th International

Conference on Service-Oriented Computing - Volume

8274, ICSOC 2013, page 692–695, Berlin, Heidel-

berg. Springer-Verlag.

Binz, T., Breiter, G., Leymann, F., and Spatzier, T. (2012).

Portable Cloud Services Using TOSCA. IEEE Inter-

net Computing, 16(03):80–85.

Breiter, G., Behrendt, M., Gupta, M., Moser, S. D., Schulze,

R., Sippli, I., and Spatzier, T. (2014). Software de-

ﬁned environments based on TOSCA in IBM cloud

implementations. IBM Journal of Research and De-

velopment, 58(2/3):9:1–9:10.

Brogi, A., Carrasco, J., Cubo, J., D’Andria, F., Di Nitto, E.,

Guerriero, M., Pérez, D., Pimentel, E., and Soldani,

J. (2016). SeaClouds: An Open Reference Architec-

ture for Multi-cloud Governance. In Tekinerdogan, B.,

Zdun, U., and Babar, A., editors, Software Architec-

ture, volume 9839 of LNCS, pages 334–338. Springer

International Publishing.

Brogi, A., Neri, D., Rinaldi, L., and Soldani, J.

(2018a). Orchestrating incomplete TOSCA applica-

tions with Docker. Science of Computer Program-

ming, 166:194–213.

Brogi, A., Rinaldi, L., and Soldani, J. (2018b). TosKer: A

Synergy Between TOSCA and Docker for Orchestrat-

ing Multicomponent Applications. Software: Practice

and Experience, 48(11):2061–2079.

Calcaterra, D., Cartelli, V., Di Modica, G., and Tomar-

chio, O. (2017). Combining TOSCA and BPMN to

Enable Automated Cloud Service Provisioning. In

Proceedings of the 7th International Conference on

Cloud Computing and Services Science, CLOSER

2017, page 187–196. SciTePress.

Calcaterra, D., Cartelli, V., Di Modica, G., and Tomarchio,

O. (2018a). A Framework for the Orchestration and

Provision of Cloud Services Based on TOSCA and

BPMN. In Ferguson, D., Muñoz, V. M., Cardoso, J.,

Helfert, M., and Pahl, C., editors, Cloud Computing

and Service Science, pages 262–285, Cham. Springer

International Publishing.

Calcaterra, D., Cartelli, V., Modica, G. D., and Tomarchio,

O. (2018b). Exploiting BPMN Features to Design a

Fault-aware TOSCA Orchestrator. In Proceedings of

the 8th International Conference on Cloud Computing

and Services Science - Volume 1: CLOSER,, pages

533–540. SciTePress.

Cardoso, J., Binz, T., Breitenbücher, U., Kopp, O., and Ley-

mann, F. (2013). Cloud Computing Automation: In-

tegrating USDL and TOSCA. In Salinesi, C., Nor-

rie, M. C., and Pastor, Ó., editors, Advanced Infor-

mation Systems Engineering, pages 1–16. Springer

Berlin Heidelberg.

Carrasco, J., Cubo, J., Durán, F., and Pimentel, E.

(2016). Bidimensional Cross-Cloud Management

with TOSCA and Brooklyn. In 2016 IEEE 9th Inter-

national Conference on Cloud Computing (CLOUD),

pages 951–955.

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

cloud: CAMP/TOSCA-based bidimensional cross-

cloud. Computer Standards & Interfaces, 58:167 –

179.

Cloudify Platform Ltd. (2020). TOSCA Orchestration &

Training. https://cloudify.co/tosca.

da Silva, A. C. F., Breitenbücher, U., Képes, K., Kopp, O.,

and Leymann, F. (2016). OpenTOSCA for IoT: Au-

tomating the Deployment of IoT Applications Based

on the Mosquitto Message Broker. In Proceedings

of the 6th International Conference on the Internet of

Things, page 181–182. ACM.

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

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

Imperative: Two Modeling Patterns for the Automated

Deployment of Applications. In Proceedings of the 9

International Conference on Pervasive Patterns and

Applications (PATTERNS), pages 22–27. Xpert Pub-

lishing Services.

Glaser., F., Erbel., J., and Grabowski., J. (2017). Model

Driven Cloud Orchestration by Combining TOSCA

and OCCI. In Proceedings of the 7th International

Conference on Cloud Computing and Services Science

- Volume 1: CLOSER,, pages 672–678. SciTePress.

Gusev, M., Kostoska, M., and Ristov, S. (2014). Cloud P-

TOSCA porting of N-tier applications. In 2014 22nd

TOSCA Light: Bridging the Gap between the TOSCA Speciﬁcation and Production-ready Deployment Technologies

225

Telecommunications Forum Telfor (TELFOR), pages

935–938.

Humble, J. and Molesky, J. (2011). Why enterprises must

adopt devops to enable continuous delivery. Cutter IT

Journal, 24(8):6.

Ivanovska, B., Ristov, S., Kostoska, M., and Gusev, M.

(2015). Using the P-TOSCA model for energy efﬁ-

cient cloud. In 2015 38th International Convention

on Information and Communication Technology, Elec-

tronics and Microelectronics (MIPRO), pages 245–

249.

Katsaros, G., Menzel, M., Lenk, A., Revelant, J. R., Skipp,

R., and Eberhardt, J. (2014). Cloud Application Porta-

bility with TOSCA, Chef and Openstack. In 2014

IEEE International Conference on Cloud Engineer-

ing, pages 295–302.

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

(2012). BPMN4TOSCA: A Domain-Speciﬁc Lan-

guage to Model Management Plans for Composite

Applications. In Mendling, J. and Weidlich, M., ed-

itors, Business Process Model and Notation, volume

125 of Lecture Notes in Business Information Process-

ing, pages 38–52. Springer Berlin Heidelberg.

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 (2019). TOSCA Simple Proﬁle in YAML Version

1.3.

Open Grid Forum (2016). Open Cloud Computing Interface

(OCCI). https://occi-wg.org.

Pahl, C., Brogi, A., Soldani, J., and Jamshidi, P. (2019).

Cloud Container Technologies: A State-of-the-Art

Review. IEEE Transactions on Cloud Computing,

7(3):677–692.

Tricomi, G., Panarello, A., Merlino, G., Longo, F., Bru-

neo, D., and Puliaﬁto, A. (2017). Orchestrated Multi-

Cloud Application Deployment in OpenStack with

TOSCA. In 2017 IEEE International Conference on

Smart Computing (SMARTCOMP), pages 1–6.

Weerasiri, D., Barukh, M. C., Benatallah, B., Sheng, Q. Z.,

and Ranjan, R. (2017). A Taxonomy and Survey

of Cloud Resource Orchestration Techniques. ACM

Computer Surveys, 50(2).

Wettinger, J., Binz, T., Breitenbücher, U., Kopp, O., and

Leymann, F. (2015). Streamlining Cloud Manage-

ment Automation by Unifying the Invocation of Scripts

and Services Based on TOSCA, pages 2240–2261. IGI

Global.

Wettinger, J., Binz, T., Breitenbücher, U., Kopp, O., Ley-

mann, F., and Zimmermann, M. (2014). Uniﬁed Invo-

cation of Scripts and Services for Provisioning, De-

ployment, and Management of Cloud Applications

Based on TOSCA. In Proceedings of the 4th Interna-

tional Conference on Cloud Computing and Service

Science, CLOSER 2014, 3-5 April 2014, Barcelona,

Spain, pages 559–568. SciTePress.

Wurster, M., Breitenbücher, U., Brogi, A., Falazi, G.,

Harzenetter, L., Leymann, F., Soldani, J., and Yus-

supov, V. (2019a). The EDMM Modeling and Trans-

formation System. In Service-Oriented Computing –

ICSOC 2019 Workshops. Springer.

Wurster, M., Breitenbücher, U., Falkenthal, M., Krieger, C.,

Leymann, F., Saatkamp, K., and Soldani, J. (2019b).

The Essential Deployment Metamodel: A System-

atic Review of Deployment Automation Technolo-

gies. SICS Software-Intensive Cyber-Physical Sys-

tems.

Yussupov, V., Falazi, G., Falkenthal, M., and Leymann, F.

(2019). Protecting Deployment Models in Collabo-

rative Cloud Application Development. International

Journal On Advances in Security, pages 79–94.

CLOSER 2020 - 10th International Conference on Cloud Computing and Services Science

226