Scalable Data Management Workshop, IEEE BigData Conference, Santa Clara, US, 6-9 October 2013

1. SLA data management criteria
Katerina Stamou, Verena Kantere, Jean-Henry Morin
Institute of Services Science, University of Geneva,
Switzerland
10/6/20131Scalable Cloud Data Management workshop, IEEE BigData Conference, Santa Clara, US

2. In a nutshell…
10/6/2013Scalable Cloud Data Management workshop, IEEE BigData Conference, Santa Clara, US
2
The systematic management of SLA data isrequired,as it
increases SLA and service manipulation opportunities in
the cloud computing setting. Thus, it contributes to
additional business value in a service-oriented economy.
The term SLA data managementencloses data operations
that may take place before, during or after SLA/service
execution.
We propose that the systematic management of SLAs can
be efficiently achieved using a digraph data model that
perceives SLA elements and their data relations as an
operational pipeline.

3. Agenda
10/6/2013Scalable Cloud Data Management workshop, IEEE BigData Conference, Santa Clara, US
3
Systematic SLA data management
Current SLA role in virtual economies
SLA data complexity
SLA data analysis
SLA digraph data model
Ongoing work

4. Definitions and assumptions
10/6/2013Scalable Cloud Data Management workshop, IEEE BigData Conference, Santa Clara, US
4
Service Level Agreements (SLAs) express mutually agreed service
levels between providers and customers [1].
SLAs define quality of service (QoS) criteria, along with functional service
properties.
The definition and structure of SLAs for cloud computing services are not
yet standardized.
The term “systematic SLA data management” describes the process of
SLA formulation, storage and processing by a backend supporting data-store
or DBMS.
SLAs are automated and cloud providers use automated processing
systems for the management of their offered services.
SLA templates can be used aswhat-you-see-is-what-you-get (WYSIWYG)
artifacts that customers use to negotiate and finalize their service selection.

5. Systematic SLA data management
10/6/2013Scalable Cloud Data Management workshop, IEEE BigData Conference, Santa Clara, US
5
Automated formulation: using a modular and adaptive data structure that
addresses SLA data intricacies.
Storage: finding the optimal storage mode for, typically, short-term data.
Processing: SLA information contains inner-dependencies and internal
functions that take place during service execution.
SLA information is not BigData; it is about managing and
processingcomplex information that may result to or involve operations on
massive data-sets.
SLAs represent semi-structured or even unstructured data, where no rigid
schema applies. Thus, an efficient data model is required to allow for
dynamic data processing.

6. SLA anatomy - Web Service Level
Agreement (WSLA), IBM [2]
10/6/2013Scalable Cloud Data Management workshop, IEEE BigData Conference, Santa Clara, US
6
Signatories, third parties: customer-
provider pair and their connections to
third party support for the service
execution.
Service description: decomposition
and hierarchical classification of
service objects, whose accumulation
or combination constitutes the service
definition.
Guarantees: obligations, typically from the provider part, to fulfill agreed and
promised levels or service provisioning. IBM distinguishes between measureable
targets (objectives) and predefined actions that occur during the service up-time.

7. Challenges for SLA manipulation in a
cloud service economy
10/6/2013Scalable Cloud Data Management workshop, IEEE BigData Conference, Santa Clara, US
7
The SLA definition provides an explicit view on how the service provisioning is
planned. It indicates precise bounds on service levels that a provider can afford.
1. SLAs as automated processes versus static documents that currently appear
in cloud marketplaces.
2. Diversified service offerings, various vocabularies of service descriptions =>
SLA semantic and structural heterogeneity.
3. SLA formulation depends from resource availability and is typically subject to
customer-provider variations. Given heterogeneity and unbounded length,
SLAs represent a fine example of semi-structured information that needs
concurrent processing over distributed computing settings.

8. SLA data complexity stems from:
10/6/2013Scalable Cloud Data Management workshop, IEEE BigData Conference, Santa Clara, US
8
Heterogeneity of data format and structure
Service dependencies between internal SLA components. Service
dependencies within an SLA lifecycle can be thought as actions that have to
occur, when a predefined condition is triggered.
Real time measurement/updates: internal SLA components may be used for the
definition and computation of other SLA components that typically reside within
the same SLA instance.
Data relationships may deal with monitoring and measurement of values that
are described by data end-point sources. Data connections may also deal with
updates of SLA component values that are dependent from the values of
neighbor SLA components.
A persisted SLA instance needs to be accessed by both external sourcesas well
as DBMS internal processes.

9. SLA data analysis I
10/6/2013Scalable Cloud Data Management workshop, IEEE BigData Conference, Santa Clara, US
9
The term SLA data management encloses all data operations that may take
place before, during or after SLA/service execution. Such operations can be
classified according to pre-instantiated, active and terminated SLAs. They
typically include fine-grained SLA elements that need dynamic processing.
Compared to other types of service contracts (e.g. terms-and-conditions, software
licences) the values of SLA terms need to be monitored and measured during
service execution to verify that SLOs are met and that no service violations have
occured.
The requirement for real-time data updates particularly applies in the cloud
computing setting, where services are exchanged on demand and business
relationships may enclose financial responsibilities.
Nested SLA information may include dependencies between diverse components
or component sets (e.g. a change in an SLA parameter value may affect
respective SLO values).

10. SLA data analysis II
10/6/2013Scalable Cloud Data Management workshop, IEEE BigData Conference, Santa Clara, US
10
Data criteria SLA
parameter
Metrics Measurable
objectives
Action
guarantees
complete
SLA doc
accessibility,
integrity
✔ ✔ ✔ ✔ ✔
velocity rate high high high low ~
replication,
staging
✔ ✔ ✔
dependencies ✔ ✔ ✔ ✔
cleanness ✔ ✔ ✔ ✔ ✔
accuracy ✔ ✔ ✔ ✔ ✔
ownership,
authenticity
✔ ✔ ✔ ✔ ✔
heterogeneity ✔ ✔ ✔ ✔ ✔

11. SLA digraph formalization
10/6/2013Scalable Cloud Data Management workshop, IEEE BigData Conference, Santa Clara, US
11

12. SLA into property graph
10/6/2013Scalable Cloud Data Management workshop, IEEE BigData Conference, Santa Clara, US
12
According to [5], a property graph G=(V, E, ) represents a directed, attributed,
edge-labeled graph that contains multi-relations, which are expressed as
key/value pairs on the graph elements.
The computing structure is the graph and the computing process consists of the
graph traversals.
The SLA digraph representation includes only uni-directed edges to denote the
flow of dependencies withinanySLA “pipeline”.
Three immediate advantages:
Modular: decomposable, flexible structure, extensible
Adaptive: with respect to diversified service environments,
inclusion/exclusion of additional elements
Dynamic: concurrent execution of operations and transactions within the
same or multiple graphs.

13. SLA dependencies
10/6/2013Scalable Cloud Data Management workshop, IEEE BigData Conference, Santa Clara, US
13
According to [3], service dependencies represent customer/provider relationships that
are reflected to the various cooperating components within a distributed service
management system.
A dependency denotes the directed relationshipbetween a dependent service or
application component that requires an operation performed by an antecedent
component in order for the former to execute its function.
SL A data elements are connected according to structural or operational dependencies,
where satisfactory dependency conditions are defined as edge-property triggers.
SLA dependency examples: <ActionGuarantee, SLO>uses, <CompositeMetric,
ResourceMetric>uses, <SupportParty, ActionGuarantee>obliged, where for every pair of
SLA nodes the following relationship holds:
<Dependent, Antecedent>rel, Dependentvalue -> function(Antecedentvalue)
,while a predefined set of conditions is valid and 'rel’ represents an outgoing edge from
the dependentto the antecedent component.

14. Query expressiveness, clear information
flow, SLA questions:
10/6/2013Scalable Cloud Data Management workshop, IEEE BigData Conference, Santa Clara, US
14
Provider aspect:
1. reach resourcex and get value of metricy;return value and update all relations,
where value is used.
2. update SLAxy; add new branch ServiceDefinition and in Obligations add SLO
branches and ActionGuarantees;updatethe dependencies/relations between the
newly added components.
3. update SLAqw23; delete SupportPartyoldwith name ’someCompany’ and update all
obligations of SupportPartyold to SupportPartynew
Customer aspect:
1. reach SupportPartynew; ask to return monitored values from a givenlist of metrics
2. how can I add a new SLA to my currently running one(s)?
3. which service is best for me? what are my service criteria?

15. Conclusions
10/6/2013Scalable Cloud Data Management workshop, IEEE BigData Conference, Santa Clara, US
15
The SLA digraph has been initially implemented using an in-memory graph
database, NetworkX [4].
Next, the data model has been re-implemented using the Titan distributed graph
database [6], where Gremlin [7] is used as the primary DSL.
Query comparison between Graph DSL, XQuery and MySQL.
Currently, we are testing the digraph efficiency using Cassandra as the
persistence backend behind Titan. We exercise the scenario, where massive http
requests reach the SLA information concurrently and request information retrieval
and filtered operations.
Actual SLA data represents a requirement…to avoid the use of fictitious
information. TPC benchmark to be used to further testing.

16. Thank you :)
Questions? -> http://www.cui.unige.ch/~stamou/
slides, full paper: http://www.slideshare.net/kat_slides/scdm
10/6/2013Scalable Cloud Data Management workshop, IEEE BigData Conference, Santa Clara, US
16

17. References
10/6/2013Scalable Cloud Data Management workshop, IEEE BigData Conference, Santa Clara, US
17
1. A. Dan, H. Ludwig, and G. Pacifici, “Web service differentiation with
service level agreements,” White Paper IBM Corporation, 2003.
2. H. Ludwig, A. Keller, A. Dan, R. King, and R. Franck, “Web Service Level
Agreement (WSLA) Language Specification,” IBM Corporation, 2003.
3. A. Keller, U. Blumenthal, and G. Kar, “Classification and Computation of
Dependencies for Distributed Management,” in Proc. of the Fifth IEEE
Symposium on Computers and Communications (ISCC 2000), ser.
ISCC ’00. IEEE Computer Society, 2000.
4. A. Hagberg, D. Schult, and P. Swart, “NetworkX,” http://networkx.
github.io/, accessed: March, 2013.
5. M. Rodriguez, “Property Graph Algorithms,” http://markorodriguez.
com/2011/02/08/property-graph-algorithms/, accessed: July, 2013.
6. ThinkAurelius, “Titan Distributed Graph Database,”
http://thinkaurelius.github.io/titan/, accessed: July, 2013.
7. ThinkAurelius team, “Gremlin graph query language,”
https://github.com/tinkerpop/gremlin/wiki, accessed: July, 2013.