Cloud SLA relationships in multi-cloud environment: models and practices

Abstract

In the past few years, cloud computing has been realized and has achieved advancement. Sincemany cloud systems and providers have been deployed in this world, various models and platforms have been developed to support multiple cloud (i.e., multi-cloud) environments (e.g., inter-cloud, federated cloud, distributed cloud, hybrid cloud, multi-cloud management platform, and cloud service brokerageplatform). Whereas those models provide a multi-cloud environment, they are different according to their objectives, service models, SLA (service level agreement) models, and so on. Even though SLA is considered as a very important issue in cloud computing, SLA relationships in multi-cloud models are not formally described yet. Therefore, in this paper, we introduce various multi-cloud models and analyze the multi-cloud models in term of SLA relationship based on the proposed SLA relationship description model. In addition, this paper introduces open source multi-cloud projects to understand practices in cloud SLA relationships.

Full text

Cloud SLA relationships in multi-cloud environment:
models and practices
Seokho Son
Cloud Computing Research Group
Electronics and Telecommunications
Research Institute
Daejeon, Republic of Korea
shsonkorea@etri.re.kr
Sun Wook Kim
Cloud Computing Research Group
Electronics and Telecommunications
Research Institute
Daejeon, Republic of Korea
swkim99@etri.re.kr
Hyun-Hwa Choi
Cloud Computing Research Group
Electronics and Telecommunications
Research Institute
Daejeon, Republic of Korea
hyunwha @etri.re.kr
Byeong Thaek Oh
Cloud Computing Research Group
Electronics and Telecommunications
Research Institute
Daejeon, Republic of Korea
btoh@etri.re.kr
Byoung Seob Kim
Cloud Computing Research Group
Electronics and Telecommunications
Research Institute
Daejeon, Republic of Korea
powerkim@etri.re.kr
ABSTRACT
In the past few years, cloud computing has been realized and has
achieved advancement. Sincemany cloud systems and providers
have been deployed in this world, various models and platforms
have been developed to support multiple cloud (i.e., multi-cloud)
environments (e.g., inter-cloud, federated cloud, distributed cloud,
hybrid cloud, multi-cloud management platform, and cloud
service brokerageplatform). Whereas those models provide a
multi-cloud environment, they are different according to their
objectives, service models, SLA (service level agreement) models,
and so on. Even though SLA is considered as a very important
issue in cloud computing, SLA relationships in multi-cloud
models are not formally described yet.Therefore, in this paper, we
introduce various multi-cloud models and analyze the multi-cloud
models in term of SLA relationship based on the proposed SLA
relationship description model. In addition, this paper introduces
open source multi-cloud projects to understand practices in cloud
SLA relationships.
CCS Concepts
• Computer systems organization➝Cloud computing.
Keywords
Service level agreement; multi-cloud; inter-cloud; federated
cloud; cloud management platform; cloud service brokerage; open
source project.
1. INTRODUCTION
Cloud computing has been realized, and it is emerging as a key
infrastructure of various industries. As the number of consumers
of cloud increase, a number of cloud computing systems and
cloud service providers also have been deployed in this world.
Types of clouds and services have become diverse and
heterogeneous. To mitigate the complicated environment which
includes multiple and heterogeneous clouds (i.e., multi-cloud),
various models and platforms have been developed (e.g., inter-
cloud, federated cloud, distributed cloud, hybrid cloud, multi-
cloud management platform, and cloud service brokerage
platform). Whereas those models provide a multi-cloud
environment, they are different according to their objectives,
service models, SLA (service level agreement) models, and so on.
In a cloud computing management platform, SLA establishment
and management are essential because the provisioning unit in a
cloud is a service. A CSP (cloud service provider) and a CSC
(cloud service customer) can make a contract using a SLA.Even
though SLA is considered as a very important issue in cloud
computing, SLA relationships in multi-cloud models are not
formally described yet. Whereas there are several researches to
survey inter-cloud architectures [1] or multi-cloud models[2],
there is no effort to understandSLA relationships in various multi-
cloud models. WS-Agreement specification [3], which is a
standard for a Web Services protocol, specifies terms and
protocols establishing a SLA between two parties. However, WS-
Agreement does not deal with SLA relationship in multi-cloud
models.
In this paper, we introduce various multi-cloud models and
analyze the multi-cloud models in term of SLA relationship based
on the proposed SLA relationship description model. In Section 2,
we introduce various multi-cloud models and provide a
comparison among multi-cloud models. Section 3 proposes a SLA
relationship description model and analyze SLA relationships in
federated cloud, distributed cloud, hybrid cloud, multi-cloud
management platform, and cloud service brokerageplatform.
Section 4 introduces several open source multi-cloud platforms
and discuss SLA relationship in the platforms to understand
practices in cloud SLA relationships. Finally, Section 5 concludes
and includes a discussion of future research.
2. MULTI-CLOUD MODELS
The term multi-cloud denotes the usage of multiple, independent
clouds by a client or a service [1]. Therefore, various cloud
models can be considered as multi-cloud models. In this section
we introduce inter-cloud, federated cloud, distributed cloud,
hybrid cloud, multi-cloud management platform, and cloud
service brokerageplatform.
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that
copies bear this notice and the full citation on the first page. Copyrights
for components of this work owned by others than ACM must be
honored. Abstracting with credit is permitted. To copy otherwise, or
republish, to post on servers or to redistribute to lists, requires prior
specific permission and/or a fee. Request permissions from
Permissions@acm.org.
ICCMS '17, January 20-23, 2017, Canberra, Australia.
© 2017 ACM. ISBN 978-1-4503-4816-4/17/01…$15.00.
DOI: http://dx.doi.org/10.1145/3036331.3050422
1

 Inter-cloud:is a concept to describe interactions among more
than two clouds. Since an inter-cloud consists of multiple
cloud, inter-cloud provides a multi-cloud environment.
 Federated cloud: is a cloud model that consists of voluntarily
involved multiple clouds or multiple CSPs.
 Distributed cloud: consists of geographically distributed
multiple clouds. In general, a distributed cloud is used to
share geographically distributed resources to support latency
sensitive cloud services.
 Hybrid cloud: consists of a private cloud and public clouds.
In a hybrid cloud, a private cloud leases resources from
public cloud, whenever the resource in the private cloud is
not enough. The leasing a resource from public cloud is
called as cloud bursting.
 Multi-cloud management platform: is a system or tool to
manage multiple clouds in a single interface. Multi-cloud
management platform focuses on managing resources and
configurations of multiple clouds.
 Cloud service brokerageplatform: is a business model for
arbitraging cloud services operated by multiple cloud service
providers. In a general configuration of a CSB business
environment, there are three actors: CSP, CSB, and CSC.
CSB is an intermediator between multiple CSPs and a CSC.
So, if there are multiple CSPs, a CSB platform needs to
support a multi-cloud environment.
3. SLA IN MULTI-CLOUD MODELS
Since there are many entities in a multi-cloud model, they can
have SLA relationships. To represent SLA relationships in a
multi-cloud model, this paper defines a SLA relationship
description model as follows. Let SLA(A, B) be an established
SLA between A and B. In SLA(A, B), A is responsible for
managing and guaranteeing the established SLA, and B is a
consumer of the cloud service. For instance, the SLA in Fig. 1(a)
is expressed as SLA(CSP, CSC). In Fig. 1(a), a CSP provides a
cloud service to a CSC, and they have an established SLA. The
CSP is responsible to guarantee the SLA(CSP, CSC). This SLA
relationship model can be applied to inter-cloud. Fig. 1(b)
expresses a SLA relationship between CSP A and CSP B. They
form a SLA(CSP A, CSP B).
(a)(b)
Figure 1. A SLA relationship description model
Each multi-cloud model consists of multiple clouds (or CSPs) and
CSCs. Therefore, SLA relationships are vary according to
objectives and configurations of multi-cloud models. Hence, the
following subsections define required SLA relationship.
3.1 SLA relationship in a Federated cloud
Afederated cloud can be classified into two structures (i.e., peer-
to-peer and centralized).Each type forms different SLA
relationship. Fig. 2 shows a SLA relationship in the peer-to-peer
cloud federation model. In the example in Fig. 2, cloud B has not
only a member role in a cloud federation but also an intermediary
role which a CSC contacts with. Since cloud A, cloud B, and
cloud C are in a federation, they need to have an agreement for in
or out sourcing.
Figure 2. SLA relationship in peer-to-peer cloud federation
When cloud B is an intermediator between the federated cloud
and the CSC, cloud B needs to provide a cloud service or
application to the CSC. The resources, required for providing a
service or application, are provided by cloud A, cloud B, or cloud
C. Therefore, to form a federation, every clouds (i.e., CSPs) needs
to establish SLA each other. In general, a federation which
consists of k CSPs requires to establish SLA(CSP1, CSP2, CSP3,
… , CSPk), SLA(CSP2, CSP1, CSP3, … , CSPk), …, SLA(CSPk,
CSP2, CSP3, … , CSPk-1). Also, an intermediator of a cloud
federation needs to provide SLA(intermediator, CSC). In Fig. 2,
since cloud B is the intermediator, SLA(cloud B, CSC) is
established.
On the other hand, a centralized cloud federation has a centralized
controller (i.e., representative), and this representative is
responsible to communicate with CSCs. A centralized cloud
federation forms SLA(CSP1, representative), SLA(CSP2,
representative), …, SLA(CSPk, representative). For the fairness
among participated CSPs in the federation, each service level in
SLA(CSP1, representative), SLA(CSP2, representative), …,
SLA(CSPk, representative) are equivalent and public to the
federation. Also, as a CSC shall utilize a service from federated
cloud, the federated cloud and consumer need to establish a
SLA(federated cloud, CSC).
Figure 3. SLA relationship in centralized cloud federation
Fig. 3 shows an example of a SLA relationship in the centralized
cloud federation model. In this example, SLA(cloud A,
representative), SLA(cloud B, representative), SLA(cloud C,
representative), and SLA(federated cloud, CSC) should be
established.
3.2 SLA relationship in a Distributed cloud
A distributed cloud can be classified into two structures according
to the ownership of multiple clouds. First, if a distributed cloud
consists of multiple CSPs (i.e., clouds operated by individual
CSPs), a SLA relationship among CSPs is similar to the SLA
relationship in the centralized cloud federation model. The
difference between the centralized cloud federation model and a
distributed cloud model consists of multiple CSPs is that a
distributed cloud model focuses on geographically distributed
resources. Fig. 4 shows an example of distributed cloud with
2

multiple CSPs. There are CSP A, which consists of cloud site A
and B, and CSP C operated by another provider. Since CSP C
provides a service (i.e., resource service) to CSP A, they need to
form SLA(CSP C, CSP A). Also, since CSP A (distributed cloud
service provider) provides a service to a CSC, SLA(CSP A, CSC)
should be established.
Figure 4. SLA relationship in distributed cloud consists of
multiple CSPs
Conversely, a CSP who operates whole distributed cloud sites
(i.e., owner of whole infrastructures) does not require to establish
a SLA among clouds. The CSP needs to establish SLA with CSCs
only.
Figure 5. SLA relationship in distributed cloud with hosted
multiple clouds
3.3 SLA relationship in a Hybrid cloud
In a hybrid cloud, there are a private cloud and a public cloud
which is a resource provider for the private cloud. In general,
owner of a private cloud and pubic cloud are different. So, when a
public CSP (i.e., a cloud resource service provider) needs to
provide an SLA to a private CSP (i.e., a CSP who operates a
private cloud). Therefore, SLA(public CSP, private CSP) and
SLA(private CSP, CSC) are established in a hybrid cloud.
However, in general, since consumers of a private cloud are
private users, a SLA(private CSP, CSC) can be implicitly formed.
Figure 6. SLA relationship in a hybrid cloud
3.4 SLA relationship in a Multi-cloud
management platform
Multi-cloud management platform (M-CMP) is a system or a tool
to operate multiple cloud resources, and those cloud resources can
be aggregated from providers of public clouds (i.e., public CSPs)
or a cloud hosted by the admin of the M-CMP. Since both a
hosted cloud and M-CMP are operated by a host (i.e., admin), a
SLA establishment is not required. If M-CMP manages a cloud
resource provisioned (or serviced) by a public CSP, the public
CSP needs to provide a SLA to the M-CMP. Fig. 7 represents
SLA relationships in a M-CMP. The M-CMP is connected with
two public CSPs and a hosted cloud. So, in the environment of
Fig. 7, SLA(public CSP A, admin/users) and SLA(public CSP B,
admin/users) are established.
In general, M-CMP itself does not care a service provisioning to
CSCs. Because an admin or users of M-CMP is not a CSP, there
are no CSCs directly connected to M-CMP. If an admin or user of
M-CMP becomes a CSP by adding a service provisioning stack on
multi-cloud resources, the CSP can provide services to CSCs. Fig.
7 also includes such scenario. Between the CSP and a CSC
SLA(CSP, CSC) needs to be established.
Figure 7. SLA relationship in multi-cloud management
platform
3.5 SLA relationship in a Cloud service
brokerage
Fig. 8 shows a general configuration of a CSB business
environment. CSB is an intermediator between multiple CSPs and
a CSC. Therefore, when a CSC requested a service, CSB as an
intermediator is in SLA relationships among both a CSP and a
CSC. For instance, if a service requested by a CSC is brokered to
CSP C (i.e., CSP C provides a service to CSC via CSB), CSP C
and CSB need to form a SLA(CSP C, CSB); CSB and the CSC
need to form a SLA(CSB, CSC).
3

Figure 8. SLA relationship in CSB
According to business models of a CSB, the agreement in
SLA(CSB, CSC) can be identical to SLA(CSP, CSB). If a CSB
business model is just forwarding a service from a CSP to a CSC,
the CSB usually forwards a SLA, which the CSP guarantees, to
the CSC so that the CSP and CSC form SLA(CSP, CSC).
Otherwise a CSB provides value-added services (e.g., customized
service, integrated service, and so on) to CSCs, CSB needs to
form and manage SLA(CSB, CSC).
4. SLA PRACTICES IN OPEN SOURCE
MULTI-CLOUD PROJECTS
There are various open source software projects to enable multi-
cloud environments. As practices, we introduce some
representative projects as an instance of analyzed multi-cloud
modelsand check SLA relationships in the practical multi-cloud
projects.
4.1 ManageIQ
ManageIQ is a multi-cloud management platform software.
ManageIQ is anopen sourcedversion of Red Hat CloudForms
technology, which enables admins to manage public clouds,
private clouds, and virtual infrastructures in a single interface.
Figure 9. Structure of ManageIQ[4]
MangeIQ provides following management features [4].Inventory
management via smart state analysis, Self-service provisioning
&service catalog, Capacity and utilization, Quotas and
showback/chargeback, Configuration and change management,
Policy engine and management, Automation and orchestration,
and Reporting. ManageIQ can create auto-scalable cloud
applications.
In the perspective of cloud SLA relationship, ManageIQ does not
provide a SLA management functionality since ManageIQ (M-
CMP) itself does not care a service provisioning to CSCs. The
users of ManageIQ are not CSCs. If a user of ManageIQ
determines to be a service provider, the user need to develop a
software stack for a service provisioning. Eventually, the user (a
service provider) needs to establish SLA(CSP, CSC).
4.2 Scalr
Scalr is a web-based open source cloud management platform,
and the goal of Scalr is to make the managing and administrating
multi-cloud infrastructure and resources in the cloud. Scalr
basically allows users to manage cloud resources provided by
cloud service providers such as AWS, Rackspace, and etc. It also
enables users to create a cloud environment where they can
operate easily and quickly within the scope of a defined policy.
Figure 10. Structure of Scalr [5]
Scalr’s key functionalities are as follows[5].The hybrid cloud
management makes users have a common set of access controls,
policies and management practices. The cross-cloud API controls
multi-cloud in a single interface. The orchestration engine
automates handling event-based, manual, or scheduled state
changes to the cloud infrastructure. The cloud scaling automates
scaling of cloud resources based on CPU utilization or other
manual demands.
Since Scalr is a M-CMP, similar to ManageIQ, a user of Scalr is
not a CSC. So, Scalr does not provide a SLA management
functionality. Similar to ManageIQ, if a user of Scalr determines
to be a service provider, the user need to develop a software stack
for a service provisioning, and the user (a service provider) needs
to establish SLA(CSP, CSC) where a CSC is an end-user of the
service.
4.3 Stratos
Stratos [6] is an apache open source that is a highly-extensible
platform-as-a-Service (PaaS) framework. Apache Stratos supports
to run Apache Tomcat, PHP, and MySQL applications on cloud
infrastructures.
Figure 11. Architecture of Stratos [6]
Fig. 11 shows Stratos architecture. Stratos has a multi-layered
architecture, infrastructure as a service (IaaS), core components,
cartridges, and applications. IaaS providing virtualized computing
resources is the bottom layer in Stratos. Using jclouds (a library
including a unified API for multi-cloud) [7], Stratos can be
deployed on IaaS, e.g. EC2, OpenStack, CloudStack, Google
cloud. In addition, Stratos provides Docker with Google
Kubernetes and Mock IaaS simulating IaaS. The core component
of Stratos consist of Stratos Manager, auto-scaler, complex event
processor (CEP), Load Balancer, Message Broker,
4

identity/monitoring/metering services, and CLI/Web UI. Stratos
Manager provides REST APIs to provision applications, and also
monitor and meter the PaaS. Autoscaler is responsible for the
elasticity of application and load balancer manages the traffic of
load in Stratos. Stratos introduces a new concept called the
cartridge that is a virtual machine with software components to
interact with the Stratos. Stratos provides the following types of
cartridges.Users in Stratos can execute various applications based
on the cartridges such as spring, Tomcat, MySQL, and PHP on
cloud environments.
Stratos can be categorized into a M-CMP with a PaaS software
stack. Therefore, a user of Stratos is a PaaS service provider who
needs to establish SLA(CSP, CSC). Whereas Stratos does not
specifies SLA management functionality, some functionalities
such as auto-scaler implicitly manage service levels.Also,
SLA(CSP, user of Stratos) needs to be established. However,
public cloud providers (e.g., Amazon EC2, MS Azure, and so on)
usually just post SLA as it is, and consumers who agreed to use
the service is assumed to accept the SLA a public cloud provider
posted.
4.4 Project Jellyfish
Project Jellyfish is an open source broker system offering policy-
driven solutions that assist organizations with the management of
multi-cloud IT environments[8]. Because it is not just a cloud
management tool, but also an advanced business analytics and
intelligence tool[9], it helps service providers to unify their cloud-
based resources, infrastructure, and services through a centralized
e-commerce platform and to satisfy organization’s IT needs for
cloud services using an easy to use self-service portal within
budget.
Project Jellyfish’s key functionalities include providing search-
and-compare wizard to evaluate various cloud services and cost
across the multiple cloud infrastructure, user-friendly dashboard
to monitor usage and cost data, allowing users to create projects
with the defined services offered based on policy and workflow,
monitoring and orchestration of resources, and automation of
entire lifecycle of a cloud service.
Since Project Jellyfish is a CSB platform, CSB needs to establish
SLA(CSP A, CSB), …, SLA(CSP K, CSB), and SLA(CSB,
CSC).However, since Project Jellyfish does not provide value-
added (reproduced) services, the agreement in SLA(CSB, CSC) is
implicitly and identically defined to SLA(CSP, CSB).
4.5 CompatibleOne
CompatibleOne is an open source cloud service
brokerageplatform that provides IaaS brokerage from
heterogeneous clouds.CompatibleOne is focused on adoption of
open standards to foster an open cloud computingecosystem. For
instance, CompatibleOne adopted OCCI (Open Cloud Computing
Interface) standard [20], which defines a meta-model for cloud
resources and a RESTful protocol among the cloud resources, so
that CompatibleOne can provide a strong interoperability and a
high degree of extensibility of the platform. Along with OCCI,
CompatibleOne platform consists of many micro services and
they can communicate each other by using an object-based
description model and a RESTful protocol to perform a service
brokerage or management.CompatibleOne provides an object-
based description model (CompatibleOne resource description
model, CORDS) of cloud resources. Based on the description
model, a user of CompatibleOne can make a manifest in XML to
request or control a cloud service. The parser of CompatibleOne is
responsible for parsing of the manifest and validating XML
syntax so that micro services in CompatibleOne platform
understandthe requests from the user.
Figure 12. Architecture of CompatibleOne [10]
Fig. 12 shows the architecture of CompatibleOne. There are
various micro services in the platform. For instance, SLAM
(Service Level Agreement Manager), Parser which is responsible
for parsing and validating XML manifests, COSS
(CompatibleOne Security Service) which providesa Transport
Layer Security (TLS) to secure all micro services and users.
COMONS (CompatibleOne MONitoring Service) to manage
monitoring of provisioned services, COPS(CompatibleOne
Placement Service) to determine the optimalservice placement (to
which cloud), and COOBAS manages ordering, billing and
accounting.
CompatibleOne is a CSB platform and the platform explicitly
defines SLA(CSP A, CSB), …, SLA(CSP K, CSB), and
SLA(CSB, CSC).In CompatibleOne a CSP can describe
SLA(CSP, CSB) by using a XML manifest. Also, a CSC can
specify SLA(CSC, CSB) in a XML manifest as requirements of
requesting cloud service. The SLAM in CompatibleOne
responsible to manage established SLA(CSC, CSB). SLAM
receives monitoring data from COMONS to check a violation of
described SLA. If there is a violation, SLAM performs penalty
actions described in the SLA.
5. CONCLUSION AND FUTURE WORK
This paperintroduces various multi-cloud models such as inter-
cloud, federated cloud, distributed cloud, hybrid cloud, multi-
cloud management platform, and cloud service
brokerageplatform.Also we proposed a SLA relationship
description model to analyze the multi-cloud models in term of
SLA relationship. In this work, we noticed that understanding
SLA relationship in multi-cloud models is also helpful to
understand compositions, functionalities and differences among
multi-cloud models. In addition, this paper introduces open source
multi-cloud projects to understand practices of cloud SLA
relationships.Whereas this paper discusses about SLA
relationships in some of open source multi-cloud platforms, we
have a plan to extensively investigatepractical SLAs in various
multi-cloud environments as a future work.
6. ACKNOWLEDGMENTS
This work was supported by 'The Cross-Ministry Giga KOREA
Project' grant from the Ministry of Science, ICT and Future
Planning, Korea.
5

7. REFERENCES
[1] N. Grozev and R. Buyya. Inter-cloud architectures and
application brokering: Taxonomy and survey. Software
Practice and Experience.http://dx.doi.org/10.1002/spe.2168.
2012.
[2] D. Petcu. 2013. Multi-Cloud: Expectations and current
approaches. In Proceedings of the International Workshop on
Multi-Cloud Applications and Federated Clouds (Multi-
Cloud’13). ACM, New York, NY.
[3] OGF, “WS-Agreement Negotiation Specification v1.0,”
OGF, 2011.
[4] D. Neary, J. Marc. ManageIQ Overview at Management and
Orchestration Developer (MODM) Meet-up.
http://www.slideshare.net/JeromeMarc2/manageiq-overview-
at-management-and-orchestration-developer-modm-meetup.
[5] SCARL.www.scalr.com. (accessed on Oct., 2016)
[6] apache stratos. http://stratos.apache.org. (accessed on Oct.,
2016)
[7] apache jclouds. https://jclouds.apache.org. (accessed on Oct.,
2016)
[8] Project Jellyfish.http://www.jellyfish.org. (accessed on Oct.,
2016)
[9] Booz Allen Hamilton.Project Jellyfish, an open source cloud
services broker solution to manage and improve your
business operations. June, 2015.
[10] CompatibleOne and OCCI. http://occi-wg.org/2012/07/15/
occi-compatibleone.
6