A Comparison of Multi-cloud Provisioning Platforms

Domenico Calcaterra, Vincenzo Cartelli, Giuseppe Di Modica and Orazio Tomarchio

Department of Electrical, Electronic and Computer Engineering, University of Catania, Catania, Italy

Keywords:

Cloud Service Provisioning, Multicloud, Cloud orchestration, TOSCA, BPMN

Abstract:

Although cloud computing has been around for over a decade now, many issues of the ﬁrst hour still persist.

Vendor lock-in, poor interoperability and portability hinder users from taking full advantage of main cloud

features. On the industry side, the big players often adopt proprietary solutions to guarantee a seamless man-

agement and orchestration of cloud applications; on the research side, the TOSCA speciﬁcation has emerged

as the most authoritative effort for the interoperable description of cloud services. In this paper, we discuss the

design and implementation of a TOSCA-based orchestration framework for the automated service provision-

ing. We also compare this approach to two open-source orchestration tools (Heat, Cloudify) with respect to the

deployment of a two-tier application on an OpenStack environment. Test results show our method performs

comparably to the aforementioned tools, while maintaining full compliance with TOSCA.

1 INTRODUCTION

The adoption of the cloud computing paradigm is

nowadays very common in many companies and or-

ganizations. A very recent technological trend within

the cloud computing scenario is the use of services

and resources from multiple clouds, the so-called

multi-cloud paradigm (Grozev and Buyya, 2014;

Ferry et al., 2013). However, in order to enable an

effective multi-cloud paradigm, it is essential to guar-

antee an easy portability of a cloud application from

a cloud provider to another one (Petcu and Vasilakos,

2014; Ferry and Rossini, 2018).

Cloud orchestration frameworks have emerged as

systems to address this need as well: their goal is to

manage cloud resources through the lifecycle phases,

respectively to select, describe, conﬁgure, deploy,

monitor and control them (Weerasiri et al., 2017; Ran-

jan et al., 2015; Baur et al., 2015).

Most of the cloud providers offer their own or-

chestration platform (Weerasiri et al., 2017; Bous-

selmi et al., 2014): however, none of these com-

mercial products are open, neither their solutions

are portable on different providers. Moreover, since

cloud applications may have varying resource re-

quirements during different phases of their lifecy-

cle, the need to partition or migrate parts of a cloud

application to different platforms arises. Therefore,

designing effective cloud orchestration techniques to

cope with large-scale multi-cloud environments re-

mains a deeply challenging problem.

Several efforts have been made in the last few

years to overcome these issues: as a notable exam-

ple, TOSCA (Topology and Orchestration Speciﬁca-

tion for Cloud Applications) has been proposed as

an open standard for representing and orchestrating

cloud resources (OASIS, 2013). It describes a com-

posite cloud service using a service template, which

captures the topology of component resources and

sets a plan for orchestrating them (Binz et al., 2014).

In a previous paper we proposed the design and

implementation of TORCH, a TOSCA-based orches-

tration framework for automated cloud service pro-

visioning (Calcaterra et al., 2018). In this paper

we compare this approach with two open-source or-

chestration tools such as Heat (OpenStack, 2016)

and Cloudify (GigaSpaces, 2016), showing that our

solution achieves the automated provisioning over

multi-cloud environments, while maintaining a full

TOSCA compliance. Other beneﬁts include substan-

tial model reusability and abstraction, allowing to

avoid provider-speciﬁc customisation.

The remainder of the paper is organised as fol-

lows. In Section 2 we present the related work. Sec-

tion 3 brieﬂy presents the fundamentals of our sys-

tem TORCH. Section 4 describes the reference sce-

nario used to compare TORCH with Heat and Cloud-

ify. Details on comparative tests and systems perfor-

mance are provided in Sections 5 and 6, respectively.

Finally, the work is concluded in Section 7.

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

A Comparison of Multi-cloud Provisioning Platforms.

DOI: 10.5220/0007765005070514

In Proceedings of the 9th International Conference on Cloud Computing and Services Science (CLOSER 2019), pages 507-514

ISBN: 978-989-758-365-0

507

2 RELATED WORK

Many IT organizations and DevOps adopters look at

the cloud orchestration as a way to speed up the de-

livery of services to end users and reduce costs. All

the big cloud industry players use their own orches-

tration platform to manage the provisioning of cloud

services (e.g. Amazon CloudFormation

, Rightscale

Cloud Management Platform

, RedHat CloudForms

IBM Cloud Orchestrator

). Such platforms, to vary-

ing degrees, promise to provide automation in three

fundamental steps: cloud conﬁguration, cloud provi-

sioning and cloud deployment. The most advanced

also offer services and tools for the management of

the cloud applications’ lifecycle. None of these com-

mercial products are open to the community, and the

solutions they offer are not portable across third-party

providers either.

TOSCA is a standard proposed by OASIS to en-

able the portability of cloud applications and the re-

lated IT services (OASIS, 2013). This speciﬁcation

permits to describe the structure of a cloud application

as a service template, that is in turn composed of a

topology template and the types needed to build such

a template. The TOSCA Simple Proﬁle is an isomor-

phic rendering of a subset of the TOSCA v1.0 XML

speciﬁcation in the YAML language. It provides a

more accessible syntax as well as a more concise and

incremental expressiveness of the TOSCA language

in order to speed up the adoption of TOSCA to de-

scribe portable cloud applications.

Cloudify (GigaSpaces, 2016) is an open-source

orchestration framework based on TOSCA. It pro-

vides services to model applications and automate

their entire lifecycle through a set of built-in work-

ﬂows. Alien4Cloud (Application LIfecycle ENabler

for Cloud) (Alien4Cloud, 2018) is a TOSCA-based

designer and cloud application lifecycle management

platform. It is natively integrated with Cloudify for

runtime orchestration. Ubicity (Corporation, 2018) is

yet another TOSCA-based solution, which proposes

a model-driven approach to simplify service manage-

ment by providing a path towards a uniﬁed view of ap-

plications and services, independent of the underlying

cloud platform. The OpenStack platform

includes

an orchestration service which provides a template-

based way to describe cloud applications.

https://aws.amazon.com/cloudformation/

https://www.rightscale.com/

https://www.redhat.com/en/technologies/management/

cloudforms/

https://www.ibm.com/us-en/marketplace/deployment-

automation/

https://www.openstack.org/

In the literature some minor research initiatives

propose open-source cloud provisioning platforms

which are not based on TOSCA. Roboconf (Pham

et al., 2015) is a hybrid cloud orchestrator for ap-

plication deployment. It proposes a Domain Speciﬁc

Language (DSL) for ﬁne-grain deﬁnition of applica-

tions and execution environments. In (Giannakopou-

los et al., 2017) authors formulates the application de-

ployment problem as a directed acyclic graph traver-

sal and re-execution. The proposed tool is intended

for deploying applications over providers that tend to

present transient failures.

3 TORCH: A TOSCA-BASED

PROVISIONING SYSTEM

This section brieﬂy describes TORCH, a Tosca-

inspired ORCHestration framework introduced in

(Calcaterra et al., 2018). The framework orchestrates

the provision of cloud services separating the orches-

tration of the provisioning tasks from the invocation

of the provisioning services themselves. Provisioning

services are supplied by third-party service providers,

while the provisioning tasks orchestrated by the work-

ﬂow engine draw on those services in a SOA (Service

Oriented Architecture) fashion. Figure 1 depicts the

framework’s architecture.

The core component is the Cloud Orchestrator

which takes a TOSCA service template (in the YAML

format) as input, translates it into a collection of

proper BPMN data objects, and feeds such a collec-

tion as BPMN data inputs of a new instance of the

top-level process (see Figure 2) running in the BPMN

Engine, which eventually orchestrates all the provi-

sioning tasks. Provisioning tasks, in turn, have their

data inputs populated with a collection of data objects

describing both the demanded resources and the state

of each component, and do nothing but send service

requests to the Service Broker and receive back the

new state of the invoked provisioning services.

Two categories of provisioning services are con-

templated: Cloud Services and Packet-based Ser-

vices. The former comprise the resources offered

through any of the Cloud delivery models (IaaS, PaaS,

SaaS), whereas the latter include all the download-

able software ”packets” requiring a pre-conﬁgured

runtime environment to run. An intermediate Service

Connectors Layer is populated with REST services

called Service Connectors (advertised in a Service

Registry), which provide a uniﬁed interface model for

the invocation of the provisioning services. When

it comes to Cloud Services, additional conﬁguration

is usually required for Service Connectors to ac-

CLOSER 2019 - 9th International Conference on Cloud Computing and Services Science

508

cess the cloud environment. Since TOSCA abstracts

application-speciﬁc data away from templates for

portability reasons, extra conﬁguration properties can

be fed into TORCH as a separate input (Application

Properties in Figure 1). The framework is respon-

sible to properly inject this information into service

requests. Service requests issued by the BPMN plans

are directed to the Service Broker, which browses the

Service Registry for the most appropriate Connectors

meeting the speciﬁed requirements.

Create Network

Service

Create VM

Service

Create Storage

Service

Deploy DB

Package Service

Service BUS

Service

Broker

Deploy App Container

Package Service

Deploy …

Cloud Orchestrator

BPMN

Engine

YAML

to BPMN

BPMN

Service Connectors Layer Orchestration LayerService Provisioning Layer

Service

Registry

Tosca

YAML

Application

properties

Figure 1: TORCH architecture.

begin

error

escalation

node

Instantiate Node

deploy

any error

create

any error

node

[cloud resource]

node

[package]

cloud resource

error

package

error

complete

any error

escalation

cloud resource

package

Figure 2: Cloud Orchestrator BPMN process model.

The YAML-TO-BPMN component (see Figure 1) is

responsible for the conversion of the TOSCA YAML

template into the BPMN data object collection used as

data inputs in the provisioning process. The orches-

tration of the provisioning tasks is realised by three

BPMN process models. More precisely, a new top-

level process (see Figure 2) is instantiated with the

output of YAML-TO-BPMN as its “node” data in-

put collection. Since nodes comprise both cloud re-

sources and software packages, the top-level process

feeds each node of the input collection to a new in-

stance of either the create cloud resource or the de-

ploy package sub-processes. The orchestration of the

provisioning tasks is carried out by many instances of

these last two processes, which delegate the execution

of the provisioning services to the Service Broker, and

globally collect the status data that it returns.

4 REFERENCE SCENARIO

The application model taken into consideration de-

ploys a WordPress web application on an Apache web

server, with a MySQL DBMS hosting the application

content on a separate server. Figure 3 shows the over-

all TOSCA-compliant architecture (wordpress, php

and apache node types are non-normative, though).

HostedOn

HostedOn HostedOn

HostedOn

ConnectsTo

wordpress

WebApplication

Properties

• context_root

Requirements

Endpoint.Database

Container

PHPModule

mysql_database

Database

Properties

• name

• user

• password

• port

Requirements

Container

Capabilities

Endpoint.Database

php

SoftwareComponent

Capabilities

PHPModule

Requirements

Container

apache

WebServer

Properties

• port

• document_root

Capabilities

Container

Requirements

Container

mysql_dbms

DBMS

Properties

• port

• root_password

Capabilities

Container

Requirements

Container

app_server

Compute

Capabilities

Container

Properties

• disk_size

• num_cpus

• mem_size

• cpu_frequency

OperatingSystem

Properties

• architecture

• type

• distribution

• version

mysql_server

Compute

Capabilities

Container

Properties

• disk_size

• num_cpus

• mem_size

• cpu_frequency

OperatingSystem

Properties

• architecture

• type

• distribution

• version

Figure 3: WordPress Deploy - TOSCA Template.

There are two separate servers: app server for the

web server hosting and mysql server for the DBMS

hosting. Both servers are conﬁgurable on hardware

capacity (e.g., disk size, number of cpus, memory

size and CPU frequency) and operating system en-

vironment (e.g., OS architecture, OS type, OS dis-

tribution and OS version). The apache node fea-

tures port and document root properties, and is de-

pendent upon the app server via a HostedOn relation-

ship as well. Likewise, the php node is dependent

upon the app server via a HostedOn relationship. The

mysql dbms node features port and root password

properties, and a HostedOn dependency relationship

upon the mysql server. The mysql database node fea-

tures name, username, password and port properties,

A Comparison of Multi-cloud Provisioning Platforms

509

and a HostedOn dependency relationship upon the

mysql dbms. The wordpress node features the con-

text root property, and depends on mysql database

and php via two ConnectsTo relationships and on

apache via a HostedOn relationship, respectively.

5 COMPARISON OF

PROVISIONING STRATEGIES

In this section the focus is put on the provision-

ing strategies of the aforementioned reference sce-

nario enforced by Heat, Cloudify and TORCH, re-

spectively, highlighting the main similarities and dif-

ferences among the three methods.

5.1 Heat

Heat orchestrates composite cloud applications us-

ing either a CloudFormation compatible template for-

mat (CFN) or the native OpenStack Heat Orchestra-

tion Template format (HOT). A Heat template de-

scribes the infrastructure of a cloud application in

a declarative fashion. The resources, once created,

are referred to as stacks. HOT templates are de-

ﬁned in YAML and require to include at least the

heat template version key and the resources section.

Bearing in mind the use case in Section 4, Listing 1

shows how the “mysql server” node was described.

Listing 1: MySQL Server for Heat.

m y s q l s e r v e r :

t y pe : OS::Nova:: S e r v e r

p r o p e r t i e s :

name: m y s q l s e r v e r

im age : { g e t p a r a m : im age }

f l a v o r : { g e t pa r a m : f l a v o r }

ke y nam e : { g e t p a r a m : k e y p a i r n a m e }

s e c u r i t y g r o u p s :

- { g e t pa r a m : s e c u r i t y g r o u p n a m e }

n e t w o r k s :

- net w o r k: { g e t p a r a m : n e t w ork n a m e }

s u b n e t : { g e t p a r a m : s u b n e t na m e }

u s e r d a t a f o r m a t : RAW

u s e r d a t a :

s t r r e p l a c e :

t e m p l a t e : { g e t f i l e : s c r i p t s / d b i n s t a l l . sh }

par a m s :

$ d b r o o t p a s s w o r d : { g e t p a r a m : d b r o o t p a s s w o r d }

$ d b p o r t : { g e t p a r a m : d b p o r t }

$db name: { g e t p a r a m : db name }

$ d b u s e r : { g e t p a r a m : d b u s e r }

$ d b p a s s w o r d : { g e t p a r a m : d b pa s s w o r d }

The OS::Nova::Server allows to create a Compute in-

stance. The ﬂavor property is the only mandatory one,

but a boot source needs to be deﬁned using one of

the image or block device mapping properties. The

key name property deﬁnes the key-pair to enable re-

mote access via SSH. The security groups property

associates a security group to an instance. The net-

works property indicates which networks an instance

should connect to. Each network contains one of

the following keys: port, network. The network key

refers to the name or ID of an existing network. The

subnet key speciﬁes the name or the ID of an existing

subnet for the provided network. The user data prop-

erty enables to conﬁgure the software running on the

server instance. A shell script (e.g. db install.sh) can

be executed by the server during boot.

Heat templates are consumed by the OpenStack-

Client, which provides a command-line interface to

OpenStack APIs. Before any Heat commands can be

run, credentials need to be supplied as options on the

command-line or as environment variables. As for the

latter, Listing 2 shows typical credential information.

Listing 2: Credential info for Heat.

e x p o r t OS USERNAME=

e x p o r t OS PASSWORD=

e x p o r t OS PROJECT NAME=

e x p o r t OS USER DOMAIN NAME=

e x p o r t OS PROJECT DOMAIN NAME=

e x p o r t OS AUTH URL=

e x p o r t OS IDENTITY API VERSION=

e x p o r t OS IMAGE API VERSION=<im age−api −v e r s i o n>

5.2 Cloudify

Cloudify, based on TOSCA, automates the entire life-

cycle of applications, including deployment on any

cloud environment. Templates are referred to as

blueprints, which are YAML documents written in

Cloudify’s DSL (Domain Speciﬁc Language). Cloud

services are supported through built-in plugins. In re-

lation to the use case in Section 4, Listing 3 shows

how the “mysql server” node was described.

The cloudify.openstack.nodes.Server type, deﬁned

in the OpenStack plugin, allows to create a Compute

instance featuring image and ﬂavor speciﬁed in the

server property. The openstack conﬁg property de-

clares OpenStack credentials. In contrast to Heat,

they are stored as secrets and accessed via an alias

referencing a named anchor in the dsl deﬁnitions sec-

tion. The agent conﬁg property deﬁnes how to con-

ﬁgure the “host agent”, which executes orchestration

operations locally and collects metrics. Conﬁguration

properties for host agents installed via SSH include:

user, key and port. The relationships property de-

ﬁnes how nodes relate to one another. Three “con-

nected to” relationships describe the key-pair, secu-

rity group and network which the server instance

should be connected to, and one “depends

on” rela-

tionship delineates the subnet which it should depend

on. Conversely to Heat, Cloudify allows to model

software components running on a server instance as

CLOSER 2019 - 9th International Conference on Cloud Computing and Services Science

510

separate nodes. Listing 4 displays the description for

the mysql dbms node.

Listing 3: MySQL Server for Cloudify.

d s l d e f i n i t i o n s :

o p e n s t a c k c o n f i g : &o p e n s t a c k c o n f i g

us e r n ame : { g e t s e c r e t : k e y s t o n e u s e r n a m e }

pass w o r d : { g e t s e c r e t : k e y s t o n e p a s s w o r d }

t e n a n t n a m e : { g e t s e c r e t : k e y s t o n e t e n a n t n a m e }

a u t h u r l : { g e t s e c r e t : k e y s t o n e u r l }

r e g i o n : { g e t s e c r e t : k e y s t o n e r e g i o n }

n o d e t e m p l a t e s :

m y s q l s e r v e r :

t y p e : c l o u d i f y . o p e n s t a c k . n o d e s . S e r v e r

p r o p e r t i e s :

o p e n s t a c k c o n f i g : ∗ o p e n s t a c k c o n f i g

a g e n t c o n f i g :

u s e r : { g e t i n p u t : a g e n t u s e r n a m e }

key: { g e t p r o p e r t y : [ k e y p a i r , p r i v a t e k e y p a t h ] }

i n s t a l l m e t h o d : r e m o te

p o r t : 22

s e r v e r :

name: m y s q l s e r v e r

im ag e: { g e t i n p u t : im ag e }

f l a v o r : { g e t i n p u t : f l a v o r }

r e l a t i o n s h i p s :

- t y p e : c l o u d i f y . o p e n s t a c k . s e r v e r c o n n e c t e d t o k e y p a i r

t a r g e t : k e y p a i r

- t y p e : c l o u d i f y . o p e n s t a c k . s e r v e r c o n n e c t e d t o s e c u r i t y g r o u p

t a r g e t : s e c u r i t y g r o u p

- t y p e : c l o u d i f y . r e l a t i o n s h i p s . c o n n e c t e d t o

t a r g e t : n e t w o r k

- t y p e : c l o u d i f y . r e l a t i o n s h i p s . d e p e n d s o n

t a r g e t : s u b n e t

Listing 4: MySQL DBMS for Cloudify.

my sq l dbm s:

t y p e : MySqlDBMS

p r o p e r t i e s :

p o r t : { g e t i n p u t : d b p o r t }

r o o t p a s s w o r d : { g e t i n p u t : d b r o o t p w d }

i n t e r f a c e s :

c l o u d i f y . i n t e r f a c e s . l i f e c y c l e :

c r e a t e :

i m p l e m e n t a t i o n : s c r i p t s / my sqldbms / c r e a t e . sh

e x e c u t o r : h o s t a g e n t

i n p u t s :

d b r o o t p a s s w o r d : { g e t p r o p e r t y : [ SELF , r o o t p a s s w o r d ] }

c o n f i g u r e :

i m p l e m e n t a t i o n : s c r i p t s / my sqldbms / c o n f i g u r e . s h

e x e c u t o r : h o s t a g e n t

i n p u t s :

d b i p a d d r e s s : { g e t a t t r i b u t e : [ m y s q l s e r v e r , i p ] }

d b p o r t : { g e t p r o p e r t y : [ SELF , p o r t ] }

r e l a t i o n s h i p s :

- t y p e : c l o u d i f y . r e l a t i o n s h i p s . c o n t a i n e d i n

t a r g e t : m y s q l s e r v e r

Two properties are deﬁned: port and root password.

A “contained in” relationship relates the node to

mysql server. Shell scripts are also speciﬁed for cre-

ate and conﬁgure lifecycle operations, whose execu-

tion (via the Script plugin) is the host agent’s respon-

sibility. Blueprints are normally consumed by the

Cloudify Command Line Interface (CLI), which in-

cludes all of the commands necessary to run any ac-

tions on Cloudify Manager.

5.3 TORCH

TORCH offers a standardised way to deploy and or-

chestrate the lifecycle of applications across multi-

ple cloud environments. Applications are modelled

in YAML - according to TOSCA language - as ser-

vice templates. Unlike Cloudify, the primary focus

is only on design time aspects (i.e., the description

of services). Runtime aspects (such as orchestration,

service mapping and invocation) are addressed by the

TOSCA-based provisioning framework (see Section

3). With reference to the use case in Section 4, List-

ing 5 shows how the “mysql server” node was de-

scribed.

Listing 5: MySQL Server for TORCH.

m y s q l s e r v e r :

t y p e : t o s c a . n o d es . Compute

p r o p e r t i e s :

k e y p a i r :

p r o t o c o l : s s h

t o k e n t y p e : i d e n t i f i e r

t o k e n : { g e t i n p u t : k e y p a i r i d }

c a p a b i l i t i e s :

h o s t :

p r o p e r t i e s :

d i s k s i z e : { g e t i n p u t : m s h o s t d i s k s i z e }

nu m cpu s: { g e t i n p u t : m s h o s t c p u s }

me m siz e : { g e t i n p u t : m s h o s t m e m si z e }

c p u f r e q u e n c y : { g e t i n p u t : m s h o s t c p u f r e q u e n c y }

os:

p r o p e r t i e s :

a r c h i t e c t u r e : { g e t i n p u t : m s o s a r c h i t e c t u r e }

t y p e : { g e t i n p u t : m s o s t y p e }

d i s t r i b u t i o n : { g e t i n p u t : m s o s d i s t r i b u t i o n }

v e r s i o n : { g e t i n p u t : m s o s v e r s i o n }

ne t w o rk :

t y p e : t o s c a . n o d es . n e tw o r k . N etwor k

p r o p e r t i e s :

network n a m e : { g e t i n p u t : n e t w o r k n a m e }

m y s q l p o r t :

t y p e : t o s c a . n o d es . n e tw o r k . P o r t

p r o p e r t i e s :

i p r a n g e s t a r t : { g e t i n p u t : s u b n e t s t a r t i n g i p }

i p r a n g e e n d : { g e t i n p u t : s u b n e t e n d i n g i p }

r e q u i r e m e n t s :

- b i n d i n g :

no de: m y s q l s e r v e r

- l i n k :

no de: n e t w or k

The tosca.nodes.Compute type allows to create a

Compute instance, which is conﬁgurable in terms

of both hosting and operating system capabili-

ties. The keypair property speciﬁes the key-

pair for remote access via SSH. The “network”

node represents an existing logical network, which

the server instance should be connected to by

means of the “mysql port” node. Unlike Heat

and Cloudify, no platform-dependent information

is provided. For instance, neither ﬂavor nor im-

age concepts are speciﬁed. Service Connectors

infer them from tosca.capabilities.Container and

tosca.capabilities.OperatingSystem capability prop-

erties. The same considerations apply to keypair, net-

work and subnet concepts.

Similar to Cloudify, TORCH enables to describe

software components running on a server instance

as separate nodes. Listing 6 exhibits the description

for the mysql

dbms node. Two properties are de-

ﬁned in this case as well: port and root password. A

“tosca.relationships.HostedOn” dependency relation-

ship relates the node to mysql server. Shell scripts

A Comparison of Multi-cloud Provisioning Platforms

511

are also associated to create and conﬁgure lifecycle

operations, whose execution is delegated to Service

Connectors via the Service Broker.

Listing 6: MySQL DBMS for TORCH.

my sq l dbm s:

t y p e : t o s c a . n o d e s . DBMS

p r o p e r t i e s :

p o r t : { g e t i n p u t : d b p o r t }

r o o t p a s s w o r d : { g e t i n p u t : d b r o o t p w d }

r e q u i r e m e n t s :

- h o s t : m y s q l s e r v e r

i n t e r f a c e s :

S t a n d a r d :

c r e a t e :

i m p l e m e n t a t i o n : s c r i p t s / my sqldbms / c r e a t e . sh

i n p u t s :

d b r o o t p a s s w o r d : { g e t p r o p e r t y : [ SELF , r o o t p a s s w o r d ] }

c o n f i g u r e :

i m p l e m e n t a t i o n : s c r i p t s / my sqldbms / c o n f i g u r e . s h

i n p u t s :

d b a d d r : { g e t a t t r i b u t e : [ m y s q l s e r v e r , p r i v a t e a d d r e s s ] }

d b p o r t : { g e t p r o p e r t y : [ SELF , p o r t ] }

Conversely to Heat and Cloudify, TORCH supple-

ments templates with application-speciﬁc information

when Service Connectors require additional conﬁgu-

ration (see Section 3). By way of example, Listing 7

shows a JSON excerpt with extra conﬁguration prop-

erties for accessing an OpenStack environment.

Listing 7: Conﬁguration info for TORCH.

{

” comp ute . u r l ” : ,

” i d e n t i t y . u r l ” : ,

” ima g e . u r l ” : ,

” ne t w o r k . u r l ” : ,

” do main . i d ” : <domain−id>,

” u s e r n a m e ” : <use r name>,

” pas s w o r d ” : <pa s s w ord>,

” s e c u r i t y . gro u p ” : <s e c u r i t y −gr o up>

}

5.4 Discussion

Table 1 generalises the achievements of the three or-

chestration tools. Cloud Features relate to the cloud

infrastructure, whereas Application Features refer to

the deployment and automation of applications. Re-

garding the Cloud Features, the following applies:

• Both Cloudify and TORCH support a dis-

tributed deployment over multi-Cloud environ-

ments, while Heat only supports a single-Cloud

deployment on an OpenStack environment.

• Both Cloudify and TORCH are infrastructure ag-

nostic; but the former does not provide an abstrac-

tion layer, which hides differences and avoids

provider-speciﬁc customisation.

As for the Application Features, the main points

are as follows:

• Heat does not natively support TOSCA; Cloudify

is aligned with TOSCA, but it does not reference

the standard types. On the contrary, TORCH is

fully in compliance with the speciﬁcation.

• Heat and Cloudify exclusively supports manual

binding for cloud resources (i.e. the user needs to

reference provider-speciﬁc node types). TORCH

supports automatic binding (i.e. the user deﬁnes

abstract requirements, e.g. number of cores).

• All three tools provide support for shell scripts to

deploy applications. While Cloudify and TORCH

rely on TOSCA lifecycle interfaces, Heat relies on

user-data boot scripts associated to resources.

• All three tools support a way to conﬁgure commu-

nication relationships between components, and

resolve dependencies via attribute passing.

• Heat and Cloudify support both manual and au-

tomatic workﬂows, while TORCH only supports

automatic workﬂows.

• Both Cloudify and TORCH use the same reusabil-

ity mechanisms as TOSCA (e.g., type inheri-

tance). Heat partially supports reusability via in-

put parameters, and template composition.

Table 1: Comparison of Heat, Cloudify, and TORCH.

Orchestration Tools

Cloud Features Heat Cloudify TORCH

Multi-Cloud support 7 3 3

Infrastructure agnostic 7 3 3

Abstraction Layer 7 7 3

Application Features

TOSCA compliance 7 0 3

Resource Selection

- Manual Binding 3 3 7

- Automatic Binding 7 7 3

Lifecycle Description

- Shell Script 3 3 3

Wiring & Workﬂow

- Attribute Passing 3 3 3

- Manual Workﬂow 3 3 7

- Automatic Workﬂow 3 3 3

Reusability 0 3 3

7= not fulﬁlled, 0 = partially fulﬁlled, 3= fully fulﬁlled

6 PERFORMANCE

COMPARISON

In order to evaluate the effectiveness of the proposed

approach, extensive tests for the reference scenario in

Section 4 were conducted, by using Heat, Cloudify

and TORCH. Deployment tests were performed on a

minimal OpenStack environment, which comprises at

least two hosts: Controller node and Compute node.

The Controller node runs the Identity service, Im-

age service, management portions of Compute, man-

agement portion of Networking, various Networking

agents, and the Dashboard. The Compute node runs

the hypervisor portion of Compute that operates in-

stances. It also runs a Networking service agent that

CLOSER 2019 - 9th International Conference on Cloud Computing and Services Science

512

connects instances to virtual networks. The ”provider

networks” option is assumed as virtual networking in-

frastructure, which deploys the OpenStack Network-

ing service with primarily layer-2. Both Controller

and Compute nodes require a minimum of two net-

work interfaces for the following: a) Management

network, and b) Provider network.

A local cluster consisting of two identical off-the-

shelf PCs was considered in order to create a minimal

OpenStack Queens set-up, i.e., Controller node and

Compute node. The former also runs portions of the

Heat orchestration services, whilst the latter also hosts

the Cloudify Manager and the TORCH as well. The

features of the physical hosts can be summarised as

follows: Intel Core i7-4770S Quad-Core CPU @ 3.10

GHz, 8 GB SO-DIMM DDR3 SDRAM @ 1.6 GHz, 1

TB Hard Disk, 2 NICs. Both nodes run Ubuntu Server

16.04.5 LTS x86 64 Linux distribution.

Two different kinds of deployment tests were car-

ried out for Heat, Cloudify and TORCH; namely,

WordPress Single-Deployment and WordPress Multi-

Deployment. The former concerns the basic use case,

the latter refers to the scalable instantiation of the for-

mer instead. Regardless of the orchestration deploy-

ment scenario, the following assumptions were made

about each VM instance: a) Ubuntu Server 14.04

cloud image, b) “m1.small” ﬂavor (vcpus = 1, ram

= 1 GB, disk = 5 GB), and c) IPv4 address on a

DHCP-enabled external network. The following pa-

rameters were calculated for performance evaluation:

Boot time, Conﬁguration time, and Workﬂow time.

The ﬁrst pertains to the time taken for a VM instance

to be booted and cloud-init modules to be executed on

it. The second refers to the time software installation

and conﬁguration on a VM instance takes. The third

concerns the time the workﬂow takes for the entire

deployment to be complete.

Figure 4 illustrates the results obtained for the

single-deployment scenario. Both app server (Figure

4a) and mysql server (Figure 4b) instances were con-

sidered. Boot and Conﬁguration times (on the Y-axis)

for each VM instance were computed depending on

Heat, TORCH and Cloudify approaches (on the X-

axis). Both charts show that TORCH performance

lies halfway between Heat and Cloudify ones.

Test results for the multi-deployment scenario are

displayed in Figure 5. Three different experiments

were conducted by triggering the multiple instanti-

ation of the single-deployment scenario for 2 VMs

(Figure 5a), 4 VMs (Figure 5b) and 6 VMs (Fig-

ure 5c), respectively. Boot, Conﬁguration and Work-

ﬂow times (on the Y-axis) for VM instances were

calculated according to Heat, TORCH and Cloudify

methods (on the X-axis). In contrast to the single-

(a) app server

(b) mysql server

Figure 4: WordPress Single-Deployment - Boot and Con-

ﬁguration.

deployment case, both Boot and Conﬁguration times

are meant as the maximum Boot and Conﬁguration

times. For the sake of clarity, Boot time is calculated

as the difference between the maximum Boot end-

time and the minimum Boot start-time among all the

VMs. The same applies to Conﬁguration time. Even

in this case, the charts show that TORCH performs

midway between Heat and Cloudify. In particular, re-

gardless of the number of VMs, the following remarks

can be made: a) both TORCH and Cloudify prove

to be more effective in lowering Boot times, and b)

Conﬁguration and Workﬂow times gradually increase

from Heat to Cloudify, passing through TORCH.

7 CONCLUSION

Automating service orchestration has become one

of the driving factors behind the growth of cloud

providers. Several initiatives and tools have emerged

to facilitate the portable, automated management of

cloud services throughout their lifecycle.

In this work, we presented TORCH, i.e. a

TOSCA-based orchestration framework that auto-

mates the cloud service provisioning. In addition, we

selected two open-source orchestration tools (Heat,

Cloudify) and compared them on both quality and

quantity aspects using the experience from deploying

a sample use case. Test ﬁndings lead to the insight

A Comparison of Multi-cloud Provisioning Platforms

513

(a) 2 VMs

(b) 4 VMs

Figure 5: WordPress Multi-Deployment: Boot, Conﬁgura-

tion and Workﬂow.

that our method compares to Heat and Cloudify, while

remaining TOSCA-compliant. Future work will in-

clude support for containerisation using Docker

REFERENCES

Alien4Cloud (2018). FastConnect.

https://alien4cloud.github.io/index.html. Last ac-

cessed on 24-01-2019.

Baur, D., Seybold, D., Griesinger, F., Tsitsipas, A., Hauser,

C. B., and Domaschka, J. (2015). Cloud Orchestra-

tion Features: Are Tools Fit for Purpose? In 2015

IEEE/ACM 8th International Conference on Utility

and Cloud Computing, UCC 2015, pages 95–101.

Binz, T., Breitenb

ucher, U., Kopp, O., and Leymann, F.

(2014). TOSCA: Portable Automated Deployment

and Management of Cloud Applications. Advanced

Web Services.

https://www.docker.com/

Bousselmi, K., Brahmi, Z., and Gammoudi, M. M. (2014).

Cloud services orchestration: A comparative study of

existing approaches. In IEEE 28th International Con-

ference on Advanced Information Networking and Ap-

plications Workshops, (WAINA 2014), pages 410–416.

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

O. (2018). Exploiting BPMN features to design a

fault-aware TOSCA orchestrator. In Proceedings of

the 8th International Conference on Cloud Comput-

ing and Services Science (CLOSER 2018), pages 533–

540, Funchal-Madeira (Portugal).

Corporation, U. (2018). Ubicity. https://ubicity.com/. Last

accessed on 24-01-2019.

Ferry, N. and Rossini, A. (2018). CloudMF: Model-Driven

Management of Multi-Cloud Applications. ACM

Trans. Internet Technol, 18(2):16–24.

Ferry, N., Rossini, A., Chauvel, F., Morin, B., and Solberg,

A. (2013). Towards Model-Driven Provisioning, De-

ployment, Monitoring, and Adaptation of Multi-cloud

Systems. In 2013 IEEE Sixth International Confer-

ence on Cloud Computing, pages 887–894. IEEE.

Giannakopoulos, I., Konstantinou, I., Tsoumakos, D., and

Koziris, N. (2017). Recovering from cloud applica-

tion deployment failures through re-execution. In Al-

gorithmic Aspects of Cloud Computing: Second In-

ternational Workshop, ALGOCLOUD 2016, Aarhus,

Denmark, pages 117–130.

GigaSpaces (2016). Cloudify. http://getcloudify.org/. Last

accessed on 24-01-2019.

Grozev, N. and Buyya, R. (2014). Inter-Cloud architectures

and application brokering: taxonomy and survey. Soft-

ware: Practice and Experience, 44(3):369–390.

OASIS (2013). Topology and Orchestration Speciﬁcation

for Cloud Applications Version 1.0. http://docs.oasis-

open.org/tosca/TOSCA/v1.0/os/TOSCA-v1.0-

os.html. Last accessed on 10-04-2018.

OpenStack (2016). OpenStack Heat.

https://wiki.openstack.org/wiki/Heat. Last accessed

on 15-02-2017.

Petcu, D. and Vasilakos, A. V. (2014). Portability in clouds:

approaches and research opportunities. Scalable Com-

puting: Practice and Experience, 15(3):251–270.

Pham, L. M., Tchana, A., Donsez, D., de Palma, N., Zur-

czak, V., and Gibello, P. Y. (2015). Roboconf: A

hybrid cloud orchestrator to deploy complex applica-

tions. In Proceeding of IEEE 8th International Con-

ference on Cloud Computing, pages 365–372.

Ranjan, R., Benatallah, B., Dustdar, S., and Papazoglou,

M. P. (2015). Cloud Resource Orchestration Program-

ming: Overview, Issues, and Directions. IEEE Inter-

net Computing, 19:46–56.

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

and Ranjan, R. (2017). A taxonomy and survey of

cloud resource orchestration techniques. ACM Com-

put. Surv., 50(2):26:1–26:41.

CLOSER 2019 - 9th International Conference on Cloud Computing and Services Science

514