Adaptable Service Level Objective Agreement (A-SLO-A) for Cloud

Services

Stefan Frey, Claudia L

uthje, Ralf Teckelmann and Christoph Reich

Furtwangen University, Faculty of Computer Science, Furtwangen, Germany

Keywords:

SLA, Cloud Computing, Adaptive SLAs, Adaptable SLA Language Format.

Abstract:

Reducing IT costs by using Cloud Computing is tempting for start up companies. To attract companies to

outsource their services to Clouds, Cloud provider need to offer Service Level Objectives speciﬁed in SLAs

individually for their customers. Cloud provider like Amazon can not afford to negotiate individual SLAs man-

ually. Therefore, it becomes important to develop a format for machine-readable SLAs which can easily adapt

to the individual Service Level Objectives requested by the customer any time. Because of its adaptability at

run time by each individual customer on demand, this comply with the characteristics of Cloud Computing

and to satisﬁes the customer’s requirements to be ﬂexible. This paper describes an adaptable Service Level

Objective Agreement (A-SLO-A) format being machine-processed to offer the possibility to integrate the SLA

management into the highly automated processes of resource provisioning. Use cases show its applicability.

1 INTRODUCTION

Cloud providers do offer guarantees for QoS charac-

teristics like, bandwidth, data backup, etc on a best-

effort principal. But business requires QoS, moni-

toring and control of the Cloud services at any time,

as stated in the ”Architecture of Managing Clouds”

(Distributed Management Task Force, 2010) and oth-

ers e.g. Study Group Report of Cloud Computing

(ISO/IEC SC 38 Study Group, 2011).

Service Level Agreements (SLAs) are required

by the business customer to ensure risks and service

qualities are prevented respectively provided in the

way the customer wants. The the most a provider

offers is a global SLA for all customers. This is

insufﬁcient because the individual customer require-

ments are not considered. The classical, manual ne-

gotiation process for SLAs is simply not feasible,

either, considering the quick and easy way of re-

sources allocation on demand. Cloud Computing

needs more ﬂexibility and adaptability, which can be

accomplished by machine readable dynamic change-

able SLAs. Thereby an integration of the SLA man-

agement into the automated process of resource allo-

cation is required. Furthermore a transformation of

the negotiations, agreement of guarantees, implemen-

tations, monitoring and reactions of violations of the

SLAs must be achieved by technical measures.

Figure 1 depicts, how easy it could be for a cus-

tomer to change requirements (Service Level Objec-

tive (SLO)) for the Cloud service needed.

Figure 1: GUI for specifying customer SLOs.

After discussing related work in Section 2, the

new approach for SLA representation is described in

Section 3 and justiﬁed by a reference implementation

shown in Section 4. Section 5 illustrates applications

by presenting some major use cases and a conclusion

is drawn in Section 6.

2 RELATED WORK

As more and more companies are starting to use

Cloud services the need for SLAs is growing stronger.

NIST (Liu et al., 2011) has pointed out the necessity

of SLAs, SLA management, deﬁnition of contracts,

orientation of monitoring on Service Level Objects

457

Frey S., Lüthje C., Teckelmann R. and Reich C..

Adaptable Service Level Objective Agreement (A-SLO-A) for Cloud Services.

DOI: 10.5220/0004356604570462

In Proceedings of the 3rd International Conference on Cloud Computing and Services Science (CLOSER-2013), pages 457-462

ISBN: 978-989-8565-52-5

 2013 SCITEPRESS (Science and Technology Publications, Lda.)

(SLOs) and how to enforce them. However a clear

deﬁnition of a reference of a speciﬁc format is miss-

ing. This is also the case with the Internet Engineer-

ing Task Force (IETF) (Khasnabish et al., 2010). Be-

sides these approaches of the companies and organi-

zations there are further efforts to develop and to real-

ize Cloud management architectures and systems. A

basic discussion can be found in Service Level Agree-

ments for Cloud Computing (Happe et al., 2011), but

is mainly concerned about SLA deﬁnitions and nego-

tiations.

In 2003 IBM developed the Web Service Agree-

ment Language (WSAL) (Ludwig et al., 2003) with

the focus on performance and availability metrics, but

lacks expressiveness and therefore is simply not pow-

erful enough. Also the required ﬂexibility is missing,

which is needed for dynamical changes at run time.

WSAL has been mainly developed for Web services,

the usage in other ﬁelds is questionable. It shows sig-

niﬁcant shortcomings regarding content as it was fo-

cused mainly on technical properties. The structural

requirements, however, are met as discussed in Spill-

ner (Spillner et al., 2009).

WS-Agreement (WS-A) was developed by the

Open Grid Forum in 2007. The newest update, which

is based on the work of the European SLA@SOI

project, was done in 2011. The advantages are the ex-

pandability and the adaptability which is, on the other

hand, also one of its greatest disadvantages, because

it has not been speciﬁed in details by Kearney (Kear-

ney et al., 2011). Based only on technical transforma-

tions, structural transformations have not been taken

into account.

Although it has been enhanced within the

SLA@SOI project (SLA@SOI, ) the development is

unclear, because the SLA@SOI project developed its

own format SLA(T), which is supported by the Euro-

pean IT industry. A comprehensive project result has

been published on their web page but so far no inde-

pendent analysis of the advantages or disadvantages

of the SLA(T) format is available. SLA(T) provides

all structural requirements of SLAs and it has the

greatest intersection with regard to content. Therefore

we choose SLA(T) as the basis of the proposed ap-

proach in this paper. Further it should be accentuated

that a meta model SLA* is deﬁned which simpliﬁes

the extension and adaptability for SLA(T).

The Foundation of Self Governing ICT Infrastruc-

tures (FOSll)-Project (FOSII Team, 2012) is another

research project which aims at the usage of autonomic

principals for information and communication sys-

tems. Self determining infrastructures should be re-

alized and made available through Cloud based ser-

vices. Within the LoM2HiS autonomic SLA manage-

ment is realized by translation of system parameters

to abstract KPIs and SLOs (Brandic et al., 2009). The

SLA speciﬁcation is based on WSAL. Also the exist-

ing monitoring tools are only designed for monitoring

of the system, but not for SLAs.

3 ADAPTABLE SERVICE LEVEL

OBJECTIVE AGREEMENT

(A-SLO-A) FORMAT

The reference implementation of the A-SLO-A for-

mat is based on the abstract SLA* model, developed

within the SLA@SOI project. The SLA* model is

an abstraction layer and follows the description of

the Meta Object Facility (MOF), speciﬁed by the Ob-

ject Management Group (OMG). The MOF describes

a special meta data architecture and itself uses the

highest abstraction layer M3. The SLA* model is

on layer M2, this corresponds to the Platform Spe-

ciﬁc Model (PIM). The A-SLO-A Format is one ab-

straction layer below (M2). This describes the Plat-

form Speciﬁc Model (PSM). So the A-SLO-A For-

mat is on the same level like SLA(T) description of

the SLA@SOI project, as shown in Figure 2. In the

reference model A-SLO-A, the primitive data types of

the SLA* model have not been used, instead the EMF

data types of the Eclipse Module Ecore are used. This

was necessary to get a functional prototype.

Figure 2: Model based development of A-SLO-A.

The main goal of the format is to develop

adaptable, adequate machine readable agreements

which are legally binding. To get customer-oriented,

runtime-adaptable SLAs the structure is divided into a

static and a dynamic part. The static part contains the

contract partner IDs, addresses, etc. while the more

interesting dynamic part focuses on SLOs like scal-

ing limits, backup periods, etc. This dynamic SLA

part must be monitor-able and is controlled by the

customer.

Within the A-SLO-A format its possible to deﬁne

CLOSER2013-3rdInternationalConferenceonCloudComputingandServicesScience

458

Figure 3: Overview of A-SLO-A format.

Top-Level SLAs and A-SLO-Agreements (A-SLO-

As) which are single and dedicated for each SLO.

Top-Level-SLA to a SLO All Top-Level SLAs and

A-SLO-Agreements are based on an appropriated

template (see Figure 3). Also a Top-Level SLA al-

ways is displayed by a service which can have one

or more interfaces, which are the base of the agree-

ment. In contrast A-SLO-As are not based directly on

a service. Here technically or contractually responsi-

bilities can be modeled. Resulting characteristics of

the model are:

• Technical services are characterized by a one to

one assignment from a Top-Level-SLA to an SLO

template, called service oriented SLO template.

Also A-SLO-A templates can be referenced to an-

other A-SLO-A template and build a hierarchy.

• A-SLO-As can be grouped by a higher A-SLO-A

or a Top-Level SLA, building a hierarchical tree

where each entity is referenced to the next higher

A-SOL-A with an UUID and a naming conven-

tion.An entity directly references the low A-SLO-

A and monitoring can be done over all.

Top-Level SLAs and Top-Level SLA Templates.

Basically Top-Level SLA comprehend all the static

contractual information and only a few dynamic in-

formation. Also references can be made to link out-

sourced documents like general terms and conditions.

A Top-Level SLA necessary must contain informa-

tion about accounting of services, IT continuity plans,

service development plans, terminology, escalation

plans, guidelines for priorities, responsibilities of both

customer and company, data of both parties, service

times, accomplishment penalties, signing, an ID, how

reports have to been done and how they are displayed

and in which frequency, the interfaces with IDs and

descriptions, references of A-SLO-As with UUID and

naming conventions, and the termination reason.

For a legally binding A-SLO-A it has to con-

tain an A-SLO-A identiﬁer, contact data and service

times. Also the SLO itself with an ID, a value and

data type which has exactly one interface, the prior-

ity and boundary and marginal values has to be in-

cluded. The A-SLO-A also should contain the A-

SLO-A reference, the accounting, accomplishment

penalties, monitoring, how and with with interface it

is done, how the reporting is done and the termination

clause.

Workﬂow for a Top-Level SLA or A-SLO-A. To

generate a Top-Level SLA or a A-SLO-A , the cus-

tomer ﬁrst has to ﬁll in the customer basic informa-

tion, service times, how it will be payed for and how

the reporting should be done with which interfaces. In

case of a A-SLO-A there also has to be ﬁlled in how

it should be monitored. After that a decision is made

whether if its an standard template or a customer ori-

ented template. For a standard template all informa-

tion will be checked and if necessary it is asked for

correction. Otherwise if its an customer oriented tem-

plate, it is asked for a special template. If the value

veriﬁcation is accepted at the Top-Level SLA, all A-

SLO-A are ﬁlled in and the inferior references are

build. At the A-SLO-A template the reference to the

higher entity is build directly. After that the templates

gets signed and the contract is ready.

The incident an change management is mapped as

a inferior grouped A-SLO-A, so they can be used as

KPI. An extension of conditions and modality can in-

volve more actions, which always have a condition,

guidelines and postcondition, which describe how the

action will be triggered.

4 REFERENCE

IMPLEMENTATION

The SLA Format implementation was done at HFU in

the cloud research center (Cloud Research Center, ).

There have been made many extensions to the SLA

Templates proposed by the SLA@SOI project. One

important part of a SLA Template is the extension

of the attribute Type. It differs from the Type of the

SLA Template by the possibility to have 3 values: top-

level, service and customer. This causes an ’IF’ clause

to load a concrete structure into the SLA template or

SLA. This means, when Type is either service or cus-

tomer it is an A-SLO-A Template or A-SLO-A. For

the unique identiﬁcation the UUID attribute is used.

Also the model version can be found in the attribute

modelVersion. The following subsections discuss the

main features of the A-SLO-A Model in more detail.

SLAs and SLA Templates. There are two seg-

ments, that contains the documentation part of the

AdaptableServiceLevelObjectiveAgreement(A-SLO-A)forCloudServices

459

SLA/A-SLO-A Templates. The ﬁrst segment descrip-

tions keeps the general terms of the agreement. The

second segment fuDocs (short for further Documents)

contains the interface description. Both structures

will be described later. Normally it is possible to use

SLA and SLA Templates without an agreement term

segment, but for compatibility reasons to SLA* re-

spectively SLA(T) this segment is included.

Description of Agreements. The class Agreement

Description as the segment description of SLA tem-

plates and SLA has its own structure, which differs

from the SLA* model. In the A-SLO-A Format the

segment descriptions contains exactly one element of

the class Property with the segment entries. These en-

tries use the class Entry, which has two attributes key

and value. The attribute key contains the type of the

following document in the attribute value. The type

can be either a CoverageDescr, a AgrementDescr or

a Disclaimer. The information itself is stored in the

attribute value.

Signatures in SLAs and SLA Templates. New at-

tributes are in the class SLATemplate the segment

ProviderSignature and in the class SLATemplate the

segment customerSignature. These containe the sig-

nature of the corresponding party, for signing a

SLA online. If the SLA is accepted by the cus-

tomer/provider, the signature will be added to the SLA

(segment customerSig) and/or SLATemplate (segment

providerSig).

Interface Declaration. The interface declaration is

part of the service description and is used to connect

the interfaces of a service and the SLOs. Also this is

needed for the reference of further documents. There

are two ways to implement that useing the abstract

class interface. First the class ResVersion is used to

keep further external documentation in the segment

endpoints. The class Endpoints contains the three

attributes location, id and protocol, to describe how

to access the document. The location represents the

location of the ﬁle, for example an URL, the proto-

col states the required protocol to access the ﬁle, for

an URL this could be HTTP or HTTPS. The id con-

tains an unique identiﬁer for the document. The at-

tribute refProvider describes, who deposit the docu-

ment. Also the segment interface is represented by

the class with the same name, which contains through

the class ResourceType the type of the document. This

is in uppercase the type of the document. For exam-

ple for an PDF document the shortcut ’PDF’ is used.

Second the class SpecVersion, that can be deﬁned by

Figure 4: Overview of Agreement Terms.

WSDL (Web Service Description Language). This is

also part of the SAL* interface speciﬁcation.

Aggreement Terms. The AgreementTerm segment

is the core part of the SLA* Agreement because it

contains the states GuaranteedStates and the result-

ing actions GuaranteedAction and is a segment of

SLATemplate. A state describes the relation between

a SLO and a measure point based on an interface and

in general contain an attribute priority. Both (stats

and actions) have conditions. Thereby actions must

have a precondition and a postcondition, while a state

can have many preconditions. The representation of

conditions happens by the ground expressions of the

SLA* model. The actions have an attribute actorRef.

This ﬁeld contains the unit, which is responsible to

work on it. The class AgreementTerm is contained in

the segment term of the top level SLAs or A-SLO-As.

This is a difference between the SLA* model and the

A-SLO-A Format. Important is the fact, that the class

AgreementTerm can have only the segment Guaran-

teedStates, when the type is not top-level. Therefore

three state rules exist: (1) Top-Level SLA (Template)

hold no states, (2) A-SLO-A (Template) hold one or

more states, and (3) A-SLO-A (Template) without

a state is a group KPI. For ActionRules it is essen-

tial that a Top-Level SLA (Template) or a A-SLO-A

(Template) can hold any number of actions.

Dependencies. The Dependencies of the docu-

ments itself are solved simply with the classes De-

pendency and Property. Also there are no existing

solutions in the SLA* model or SLA(T). The idea be-

hind this is, to set the documents itself in relation. All

Agreement Terms can have many superordinate (seg-

ments depending) and subordinate (segments ante-

ceding) Terms over the class Dependency as segment

dependency. To store the information below the class

Dependency the class Property is used. The attribute

key contains the name and the attribute value refer-

ences the document either as URI or as UUID. Also

CLOSER2013-3rdInternationalConferenceonCloudComputingandServicesScience

460

rules can be applied. Important is the CustomerSLO-

ARule, which allows for non customer A-SLO-A (see

attribute type) only exactly one entry for anteceding.

This structure is quite simpler than the mechanism in

the SLA* model.

Service Level Objectives (SLOs). SLOs contain

two components: The ﬁrst component is the declara-

tion of objectives and its values and the thresholds. A

threshold will be deﬁned by the variable declaration.

This is a mechanism to deﬁne a name, a value and a

data type. Also the threshold values will be added,

so that all required information are available. The

state deﬁnition creates a connection between the val-

ues deﬁned in the SLO and at the runtime estimated

value (measure point). The second component of the

SLAs is the state deﬁnition. This is done by the class

GuaranteedState, which has a Priority, and is an op-

tional set. This class connects the values deﬁned in

the SLO and the measured real time values. These in-

formation are called measure point. Important is that

the name of a deﬁned interface and a UUID of a top

level template are required. This relation is known by

the SAL* model but was extended. An association to

an interface of a A-SLO-A is possible by storing an

UUID of the top level SLA.

Action Deﬁnitions. The next part are the actions

of the A-SLO-As. In general there are two different

types: Business Level Guaranteed Actions and Pric-

ing Business Terms. The ﬁrst one is from the point of

view of system functionality and is used for the ser-

vice provision. In that terms and templates are stored

as well as information that describes the execution of

the system functionality. When an event happens, this

information describes all further steps, which must be

executed. For example this could be an agreement

between provider and customer about the start time

of the monitoring or describe the automatic sending

of messages after an incident.

Business Level Guaranteed Actions. The Busi-

ness Level Guaranteed Actions has currently moni-

toring and reporting actions implemented. The mon-

itoring classes are extended for the A-SLO-As. Also

the attribute ParameterSource was added, which al-

lows to recognize properties through their names, data

types and its source (UUID). Also frequencies for the

deﬁnition of report, aggregation and acquisition inter-

vals have been added for triggering actions. For ex-

ample: onEvent: an event trigger, onTime: a constant

time stamp, perJob: runtime of a job, or perVolume:

volume of a resource (e.g. 30GB disk space is full).

A major change is the relation to the class Param-

eter. This was changed to composition with the 1:n

relation, where n must be at least 1. This allows the

declaration of multiple parameters and together with

the source of the parameter (SourceParameter) it is

possible to assign values of the depended A-SLO-As.

5 USE CASES

To illustrate possible applications this section presents

use cases and gives the corresponding sample imple-

mentations. Cloud Computing hugely beneﬁts of the

underlying self-serve principle. Therefore it is par-

ticular important to give customers the possibility to

ﬁll in the SLO templates with only a few steps and in

an self-explanatory way. The following use cases will

show the modeling possibilities of A-SLA-A:

Availability Use Case. For the ﬁrst use case we as-

sume that a customer runs a Cloud application on an

speciﬁc regular basis. Therefore he wants to ensure

that the resources are available for this speciﬁc times

and can be used. We assume that the customer al-

ready has completed the initial process of creating a

valid SLA with an provider for the service. The con-

tract thereby covers the speciﬁc service times, in this

case every friday from 14:00 to 18:00. For repeating

ServiceTimes the customer additionally speciﬁes an

interval and the associated day or calendar date. The

resulting XML ﬁle can be seen in Figure 5.

Lets assume due to the changing business environ-

ment the customer would like to change the created

SLA, because he needs the same service to be avail-

able on every wednesday from 09:00 to 14:00. There-

fore the customer loads the existing SLA and adapts

the ServiceTime so that his new requirements are met.

This however requires that the newly chosen param-

eters are inside the limitations given by the provider

and are valid. The validation is done automatic within

the adjustment tool. Did the validation succeed, the

SLA gets signed online by both parties and is then

legally binding. In the case of mismatching customer

demands and provider offerings the SLA can not be

signed and a manual negotiation process has to be per-

formed.

Additional KPI Use Case. As exemplary second

use case a customer cloud want to extend an exist-

ing SLA in order to match the advanced or varied re-

quirements of his services, so the service quality can

be better monitored and ensured. In such a case the

customer would want to add an additional KPI to the

existing SLA. That means another it AgreementTerm

AdaptableServiceLevelObjectiveAgreement(A-SLO-A)forCloudServices

461

Figure 5: ServiceTime XML ﬁle.

has to be added to the SLA. Inside this it Agreement-

Term the it GuaranteedState, itGuaranteedAction, etc.

have to be speciﬁed, and a it ServiceLevelObjective

has to be created. For example if a customer wants

to add a guarantee for the minimum bandwidth his

service can use, the KPI and the corresponding it in-

terfaceDeclr can be easiliy added by using the graph-

ical interface like shown in Figure 1. Therefore the

customer chooses a representing KPI from an list of

available KPIs, ﬁlls in the appropriate values and so

adds the new contract clause to the existing SLA.

Again it has to be checked if newly added KPI val-

ues are within the providers range of offerings or not,

and based on that be signed online.

In terms of a pricing model providers could give

certain offers in regard of predeﬁned KPI ranges. In

this way a provider would be able to achieve a bet-

ter resource allocation and usage prediction, while

customers could easily choose upon these predeﬁned

sets.

6 CONCLUSIONS

In this paper we demonstrated how adaptable SLA

management is essential for companies that want

to use Cloud services and complies with the Cloud

Computing self-service, on-demand characteristics to

change SLAs during runtime. High utilization of the

infrastructure for the provider and an ideal pay per

use basis for the companies can therefore be achieved.

With A-SLO-A it is possible to get customer speciﬁc

SLAs automated in acceptable conditions for both

parties. But to get an economical efﬁcient adapta-

tion, more automation is essential. It has been shown,

that the new adaptable SLA Agreement (A-SLA-A)

language can model static SLA information and dy-

namic SLA objectives to be the basis of an adaptable

SLA management. Use cases have been presented to

visualize the power of the A-SLA-A.

REFERENCES

Brandic, I., Music, D., Leitner, P., and Dustdar, S. (2009).

Vieslaf framework: Enabling adaptive and versatile

sla-management. In Proceedings of the 6th Inter-

national Workshop on Grid Economics and Business

Models, GECON ’09, pages 60–73, Berlin, Heidel-

berg. Springer-Verlag.

Cloud Research Center. University of Applied Science Furt-

wangen. http://www.wolke.hs-furtwangen.de.

Distributed Management Task Force (2010). Architecture

for managing clouds. http://dmtf.org.

FOSII Team (2012). Foundations of self-governing ict

infrastructures website. http://www.infosys.tuwien.

ac.at/linksites/FOSII.

Happe, J., Theilmann, W., Edmonds, A., and Kearney, K.

(2011). Service Level Agreements for Cloud Comput-

ing, chapter A Reference Architecture for Multi-Level

SLA Management, pages 13–26. Springer-Verlag.

ISO/IEC SC 38 Study Group (2011). Jtc 1/sc 38 study

group report on cloud computing. Technical re-

port, International Organization for Standardization.

http://isotc.iso.org.

Kearney, K. T., Torelli, F., and Kotsokalis, C. (2011). Sla*:

An abstract syntax for service level agreements. 11th

IEEE/ACM International Conference on Grid Com-

puting, pages 217–224.

Khasnabish, B., Chu, J., Ma, S., Meng, Y., So, N., and Un-

behagen, P. (2010). Cloud reference framework. Tech-

nical report, Internet Engineering Task Force. http://

tools.ietf.org/ html/ draft-khasnabish-cloud-reference-

framework-00.

Liu, F., Tong, J., Mao, J., Bohn, R. B., Messina, J. V., Bad-

ger, M. L., and Leaf, D. M. (2011). Nist cloud comput-

ing reference architecture. Technical report, National

Institute of Standards and Technology.

Ludwig, H., Keller, A., Dan, A., King, R. P., and Franck,

R. (2003). Web Service Level Agreement (WSLA)

Language Speciﬁcation, v1.0.

SLA@SOI. SLA@SOI projekt website. http://

sla-at-soi.eu/.

Spillner, J., Winkler, M., Reichert, S., Cardoso, J., and

Schill, A. (2009). Distributed contracting and mon-

itoring in the internet of services. In Proceedings

of the 9th IFIP WG 6.1 International Conference

on Distributed Applications and Interoperable Sys-

tems, DAIS ’09, pages 129–142, Berlin, Heidelberg.

Springer-Verlag.

CLOSER2013-3rdInternationalConferenceonCloudComputingandServicesScience

462