Service Level Agreement Comparison in Cloud Computing

Volume-4, Issue-3, June-2014, ISSN No.: 2250-0758
International Journal of Engineering and Management Research
Available at: www.ijemr.net
Page Number: 126-131
Service Level Agreement Comparison in Cloud Computing
Ritu Juneja1, Dr. Deepti Sharma2
M.Tech Student, Computer Science Department, Advanced College of Technology & Management, Palwal, INDIA
2
Head of department, Computer Science Department, Advanced College of Technology & Management, Palwal, INDIA
1
ABSTRACT
Service level agreements (SLAs) are one of the major
considerations for every buyer of cloud computing services.
Finding the SLA truth, and whether a service provider will meet
your requirements, depends on the details of how they define
their SLA measures and penalties. Our study indicates that none
of the surveyed cloud providers offer any performance
guarantees for compute services and leave SLA violation
detection to the customer. We then provide guidance on how
SLAs should be defined for future cloud services. This paper
surveys the state of practice in service level agreement
specification and offers guidelines on how to assure that services
are provided with high availability, security, performance, and
other required qualities. In addition, this paper discusses the
quality properties that have been expressed in service level
agreements.
Keywords- Cloud computing, SLA, SOA.
I. INTRODUCTION
Cloud computing [1] is the new trend of computing where
readily available computing resources are exposed as a
service. These computing resources are generally offered as
pay-as-you-go plans and hence have become attractive to cost
conscious customers. Apart from the cost, cloud computing
also supports the growing concerns of carbon emissions and
environmental impact since the cloud advocates better
management of resources. We see a growing trend of loading
the previously in-house service systems to the cloud, based
primarily on the cost and the maintenance burden. Such a
move allows businesses to focus on their core competencies
and not burden themselves with back operations. Cloud is
defined as both the applications delivered as services over the
Internet and the hardware and systems software in the data
centers that provide those services [1]. According to this
definition delivery of application as services (SaaS - Software
as a Service) over the Internet and hardware services (IaaS Infrastructure as a Service) are both parts of cloud computing
phenomena. From hardware service(utility computing) point
of view, there are few new aspects in cloud [1], the most
prominent being the illusion of infinite computing resources
and the ability to pay for use of computing resources on a
short-term basis as needed.
As consumers move towards adopting such a ServiceOriented Architecture, the quality and reliability of the
services become important aspects. However the demands of
the service consumers vary significantly. It is not possible to
fulfill all consumer expectations from the service provider
perspective and hence a balance needs to be made via a
negotiation process. At the end of the negotiation process,
provider and consumer commit to an agreement. In SOA
terms, this agreement is referred to as a SLA. This SLA serves
as the foundation for the expected level of service between the
consumer and the provider. The QoS attributes that are
generally part of an SLA (such as response time and
throughput) however change constantly and to enforce the
agreement, these parameters need to be closely monitored [2].
Due to the complex nature of consumer demands, a simple
"measure and trigger" process may not work for SLA
enforcement. Four different types of monitoring demands
made by consumers are mentioned in [3]. One scenario is a
consumer demands the data exposed by a service provider
without further refinement such as transaction count, which is
a raw metric. Second scenario is consumer requests that
collected data should put into meaningful context. This
scenario creates the requirement for a process which collects
data from different sources and applies suitable algorithms for
calculating meaningful results. Such metrics include statistical
measures such as average or standard deviation that need to be
computed from a raw set of numbers. The third scenario is the
consumer requests certain customized data to be collected. In
the fourth scenario the consumer even specifies the way how
data should be collected. Both the latter mentioned scenarios
imply an advanced consumer who would have a knowledge of
the inner workings of a provider and somewhat rare in
practice. Other issues such as trust also need to be considered
during SLA enforcement. For example consumers may not
completely trust the certain measurements provided solely by
a service provider and regularly employ third party mediators.
These mediators are responsible for measuring the critical
126
service parameters and reporting violations of the agreement
from either party.
We believe the upcoming trend of cloud computing is an
extension of the SOA paradigm and the above mentioned issue
of striking a balance applies to the cloud as well. The process
of managing the provider-consumer agreements in computing
clouds closely resemble the generic provider-consumer
agreement process we mentioned above. Hence we propose an
architecture for managing cloud consumer and provider SLAs,
based on the WSLA specification [3].
We highlight two reasons to justify the importance of this
research.
1. The most prominent cloud provider, Amazon EC2, puts the
burden of proving SLA violations on the consumer. i.e. the
consumer should take steps to enforce the SLA [4]. Having a
formalized SLA enables the setup of the enforcement process
to be automated and hence relieves consumers from that
burden.
2. We believe the work that significantly intersects with ours
is [5] where WSLA has been used as a base for grid service
monitoring. However computing grids are very different from
computing clouds in terms of 1) business model, 2)
architecture, 3) resource management, 4) programming model,
5) application model and 6) security model [6]. Hence we
believe applying WSLA to the cloud context would be a
significantly different effort from the previous work.
To the best of our knowledge this is the first use of WSLA in
the context of cloud computing.
Quality attribute requirements play an important role
in service selection in service-oriented architecture (SOA)
environments.
SOA is an approach for designing, developing,
deploying, and managing systems that are characterized by
coarse-grained services that represent reusable business
functionality. These systems serve consumers that compose
applications or systems using the functionality provided by
these services through standard interfaces. A very common
technology for SOA implementation is web services, in which
service interfaces are described using the Web Services
Description Language (WSDL), and Extensible Markup
Language (XML) payload is transmitted using SOAP over
Hypertext Transfer Protocol (HTTP). A set of additional web
service specifications (e.g., WS-BPEL, WS-Security, and WSReliable Messaging) can be used in this context to support
operations such as service orchestration and management and
qualities such as security and availability.
Service-oriented systems have gone through a
gradual evolution. Their first generation was based on
monolithic components that could be reconfigured at compile
time. Currently, their second generation is based on vertically
integrated components that can be adapted and reconfigured at
installation time and, to some extent, at runtime. In the future,
we will see an emerging third generation of service oriented
systems that will be cross-vertically integrated, contextsensitive, and reconfigurable in an autonomic, ad hoc, and ondemand manner [IST 2006].
At design time during service selection, an architect
of a first- or second-generation service-oriented system will
search for services to fulfill some set of functionality. The
architect will make the selection based on desired functional
requirements as well as quality attribute requirements that are
important to system stakeholders. These qualities will
probably be described in a service level agreement (SLA). In
the case of third-generation, service-oriented systems, this
service selection will likely occur at runtime, and the SLA will
need to be in a machine-readable format that can be
interpreted at runtime.
An SLA is part of the contract between the service
consumer and service provider and formally defines the level
of service.
It is the Service Level Agreement (SLA) that defines
the availability, reliability and performance quality of
delivered telecommunication services and networks to ensure
the right information gets to the right person in the right
location at the right time, safely and securely. The rapid
evolution of the telecommunications market is leading to the
introduction of new services and new networking technologies
in ever-shorter time scales. SLAs are tools that help support
and encourage Customers to use these new technologies and
services as they provide a commitment from SPs (Service
Providers) for specified performance levels [TM Forum 2008].
Organizations seek to develop SLAs for various
reasons. From a simple perspective, an SLA is developed
between two parties to spell out who is responsible for what,
what each party will do, and sometimes more importantly
what each party will not do. From a business perspective, an
SLA is developed for these reasons:
• New commercial services entering a competitive market can
use SLAs to establish themselves as reliable providers and
hence attract customers.
• Service interactions across organizations increasingly
permeate business processes and become critical to fulfilling
business goals. SLAs establish a commitment to quality levels
required by service users and providers to interact effectively.
Moreover, SLA management helps customers validate and
supervise the quality of services through scheduled and onexception reports.
• In one vision of the future, standardized services will be
offered by multiple service providers. For example, realtors
provide many different levels of service to home sellers, and
all must provide a minimum level of service. That minimum
service might offer use of the Multiple Listing Service (MLS)
for the home at the cost of 1% of the home’s posted sale price.
As part of enhanced service, the realtor might actively market
and handle the sale for the owner at the cost of 6 or 7%
percent of the home’s final sale price.
In the context of web services, standardized services
may be offered for common well-defined tasks such as tax
return preparation, credit history requests, insurance claims,
and banking. A common SLA that applies to a standard
service is an important quality management artifact for service
users and the regulatory agency responsible for overseeing the
service.
• Many organizations provide services that depend on services
from other organizations. For example, an online travelbooking system may interact with (1) banks to authorize credit
cards,
(2) hotel chains to check availability and reserve rooms,
(3) airlines for checking and booking flights, and
(4) car rental companies. In addition, each organization
providing a service may, in its turn, use services from other
organizations (commonly called layered or composite
127
services). In some situations, the unavailability or poor
performance of one of the services may compromise the whole
customer experience. In a multi-party composite service
situation, SLAs can be used to identify the party that is
responsible in case of a problem.
The goal of this technical note is to provide an
overview of the state of the practice in the development and
management of SLAs in the context of SOA.
We survey this state regarding SLAs in SOA
environments—mainly web services—and offer guidelines to
organizations that plan to contract external services or move to
the third generation of service-oriented systems where SLAs
in machine readable format become enablers.
In this paper, we consider important questions such
as:
• Currently, what mechanisms can be used to ensure quality of
service (QoS) by contract?
• What quality attributes can be expressed in SLAs?
• What mechanisms are used by service providers to achieve
and monitor those quality attributes?
• What technology support—such as tools, specifications, and
standards—is available to express quality requirements, and
what support will be considered in the future?
II.
BACKGROUND OF SLAs
SLAs have been used in IT organizations and departments
for many years. The definition of SLAs in a SOA context is
more recent but is becoming extremely important as serviceoriented systems are starting to cross organizational
boundaries and third-party service providers are starting to
emerge.
The current state of the practice for SLAs in an SOA
context is heavily influenced by the IT management processes
and procedures guiding SLAs.
As background for the rest of the report, in this section we
look at SLAs in IT organizations and SOA environments and
at qualities that can be specified in the SLAs that are
associated to services in SOA environments.
 IT SLAs
SLAs have been used for many years in IT
organizations and departments to identify the support
requirements for internal and external customers of IT
services.
In this context, an SLA sets the expectations of both
the IT service consumer and provider. It is common for IT
service providers to deliver services at different levels of
quality based on the cost paid for a service. An SLA is
valuable for helping all parties understand the tradeoffs
inherent between cost, schedule, and quality because their
relationship is stated explicitly. As with any type of contract,
the existence of an SLA cannot guarantee that all promises
will be kept, but it does define what will happen if those
promises are not kept. “An SLA cannot guarantee that you
will get the service it describes, any more than a warranty can
guarantee that your car will never break down. In particular,
an SLA cannot make a good service out of a bad one. At the
same time, an SLA can mitigate the risk of choosing a bad
service” [Allen 2006]. A “good” service is one that meets the
needs of the service customer in terms of both quality and
suitability.
A properly specified SLA describes each service
offered and addresses
• how delivery of the service at the specified level of quality
will become realized
• which metrics will be collected
• who will collect the metrics and how
• actions to be taken when the service is not delivered at the
specified level of quality and who is responsible for doing
them
• penalties for failure to deliver the service at the specified
level of quality
• how and whether the SLA will evolve as technology changes
(e.g., multi-core processors improve the provider’s ability to
reduce end-to-end latency)
IT SLAs are enforced by service management
processes and procedures. An example framework for IT
service management (ITSM) is the Information Technology
Infrastructure Library (ITIL), which has been widely used
since the mid 1990s. The ITIL focuses on the activities
involved with the deployment, operation, support, and
optimization of applications. Its main purpose is to ensure that
deployed applications can meet their defined service levels
[Allen 2006]. The ITIL provides several key practice areas for
ITSM. Below, we briefly describe the relationships between a
subset of these areas that are relevant to SLAs:
• Service level management (SLM) is the main practice area
for managing and maintaining QoS.
This process area focuses on improving the QoS by
continuously reviewing the quality of the services provided by
an IT organization. SLM provides input to all service
management processes and receives input from service
support processes.
• The change management process area focuses on managing
change in an efficient and consistent manner. It provides input
to SLM on how infrastructure changes can affect QoS.
• The incident management process area’s main purpose is to
minimize the disruption that incidents cause to a business. It
provides input to SLM on violations to agreements, who
should be notified, historical data and trends, and any other
actions that may be needed.
• The configuration management process area’s main
purpose is to identify, verify, control, and maintain
configuration items. This area is also responsible for managing
the relationships between configuration items. It identifies the
services affected by problems with configuration items and
provides this information to SLM.
• The capacity management process area’s activities include
monitoring, analyzing, tuning, and reporting on service
performance to produce SLA recommendations.
SLAs for IT typically fall into three categories:
1. Basic – a single SLA with well-established metrics that are
measured and/or verified. The collection of these metrics is
typically done manually.
2. Medium – the introduction of multi-level quality based on
the cost of the service. The objective is to balance the levels of
quality and cost. Automatic data collection enables
comprehensive reporting to IT managers and stakeholders.
3. Advanced – dynamic allocation of resources to meet
demand as business needs evolve
128
 Qualities That Can Be Defined in an SLA
In theory, it is possible to specify any quality in an
SLA, provided that all parties understand how to measure or
verify its achievement. We’ve seen two categories of qualities
that can be specified in SLAs: measurable and unmeasurable.
Measurable qualities can be measured automatically using
metrics; for example, the percentage of time a system is
available. Unmeasurable qualities are those that cannot be
measured automatically from a given viewpoint; for example,
determining the cost of changing a service (modifiability) is
difficult to automate [Dobson 2005].
Measurable Qualities
• Accuracy is concerned with the error rate of the service. It is
possible to specify the average number of errors over a given
time period.
• Availability is concerned with the mean time to failure for
services, and the SLAs typically describe the consequences
associated with these failures. Availability is typically
measured by the probability that the system will be operational
when needed. It is possible to specify
− the system’s response when a failure occurs
− the time it takes to recognize a malfunction
− how long it takes to recover from a failure
− whether error handling is used to mask failures
− the downtime necessary to implement upgrades (may be
zero)
− the percentage of time the system is available outside of
planned maintenance time
• Capacity is the number of concurrent requests that can be
handled by the service in a given time period. It is possible to
specify the maximum number of concurrent requests that can
be handled by a service in a set block of time.
• Cost is concerned with the cost of each service request. It is
possible to specify
− the cost per request
− the cost based on the size of the data
− cost differences related to peak usage times
• Latency is concerned with the maximum amount of time
between the arrival of a request and the completion of that
request.
• Provisioning-related time (e.g., the time it takes for a new
client’s account to become operational)
• Reliable messaging is concerned with the guarantee of
message delivery. It is possible to specify
− how message delivery is guaranteed (e.g., exactly once, at
most once)
− whether the service supports delivering messages in the
proper order
• Scalability is concerned with the ability of the service to
increase the number of successful operations completed over a
given time period. It is possible to specify the maximum
number of such operations.
Unmeasurable Qualities
• Interoperability is concerned with the ability of a collection
of communicating entities to share specific information and
operate on it according to an agreed-upon operational
semantics [Brownsword 2004]. It is possible to specify the
standards supported by the service and to verify them at
runtime. Significant challenges still need to be overcome to
achieve semantic interoperability at runtime.
• Modifiability, in this context, is concerned with how often a
service is likely to change. It is possible to specify how often
the service’s
− interface changes
− Implementation changes
• Security is concerned with the system’s ability to resist
unauthorized usage, while providing legitimate users with
access to the service. Security is also characterized as a system
providing
non-repudiation,
confidentiality,
integrity,
assurance, and auditing. It is possible to specify the methods
for
− authenticating services or users
− authorizing services or users
− encrypting the data
III.
AREAS COVERED BY SLAS
Cloud hosting and SLAs may provide protection at
several different levels across infrastructure operating systems,
and applications. Below are several of the important coverage
levels that may be covered by a cloud SLA.
Facilities-level SLA –
In a traditional colocation contract structure, the
colocation provider will typically offer an SLA covering the
data centre facilities required to support the client-owned
hardware. These include items such as power, on-site
generators, cooling, etc. This type of coverage is generally
considered the bare minimum in the hosting market. A cloud
service provider (CSP) will typically choose a colocation
facility that maintains a facilities-level SLA.
Platform-level SLA –
The next level of protection in a public cloud hosting
agreement typically covers physical server, virtualization
platform and network hardware owned by the cloud service
provider and used by the cloud hosting client. Typically, the
physical server and virtualization software are covered by a
Platform SLA. The cloud network (network between Cloud
Servers) may be covered by a separate availability SLA.
Operating system SLA –
The operating system (OS) is the next potential area
of coverage for a cloud hosting SLA. Cloud Service Providers
offering an OS-level SLA typically provide some degree of
managed services to a client. This additional service allows
the vendor to guarantee that the operating system is properly
maintained so that it is consistently available, and typically
has some caveats
Application-level SLA –
This type of SLA provides protection against
application level failures up to and including the custom
application running on the provider’s hardware. This type of
SLA is extremely rare in the cloud hosting market. Under this
model, the cloud hosting provider is guaranteeing the
availability and performance of their client’s software, which
is a difficult commitment to meet.
IV.
PENALTIES FOR SLA VIOLATIONS
After a contractual threshold of downtime has been
reached, most cloud providers will commit to a percentage
129
refund of the fees paid for a given period of time (generally
monthly). Be certain to carefully compare the time durations
and associated percentage of fees the provider agrees to refund
in the event of an outage.
Providers’ definitions of an SLA violation vary
widely, and clients need to review them carefully to ensure
that penalties paid under various SLAs are comparable. To
compare accurately, be certain you understand the following:
• The amount of downtime allowed under the SLA and
associated credit amounts
• At what amount SLA refunds are capped (i.e. how much of
the fees paid for a given period is the provider obligated to
refund)
• What portion of the fee is eligible for refund, for example:
–– Will the provider only refund my compute related fees and
exclude network, storage, CDN fees, etc., or is the credit
against my entire invoice for the month?
–– I f a server (or servers) fails with the result that my entire
application fails, am I credited only for the server(s) that
failed, for my entire invoice, or for the compute portion of my
invoice?
The answers to the questions above can greatly
impact the usability and value of the SLA to your business, so
ensure that you understand the level of commitment the
provider is offering under its SLA.
V.
SLA COMPARISON
• Weak Uptime Guarantees for Compute
The considered cloud providers offer only weak uptime
guarantees for running VMs and do not explicitly specify
uptime guarantee on a per instance basis. Amazon EC2 and
Terremark vCloud Express only offer uptime guarantee on a
per data center basis instead of per instance basis. Arguably,
the chance of a data center being unavailable is much lower
than per instance. Rackspace Cloud Servers and Storm on
Demand implicitly provide SLA guarantee on per instance
basis. Azure Compute provides uptime guarantees as an
aggregate over all instances instead of per instance basis.
• No Performance Guarantees for Compute
None of the considered cloud providers offer any
performance guarantees for compute instances. As a
consequence, a customer can only hope for its instances to
receive the provisioned CPU, memory, network, and disk
resources. Lack of performance guarantees may be
unacceptable in enterprise clouds.
• Customer Should Detect SLA Violation
The considered cloud providers leave the burden of
detecting SLA violation on the customer which may be
unacceptable for enterprise. Verizon, an enterprise Internet
connectivity provider, detects SLA violations for its dedicated
Internet service [20].
• Service Credit
Service credits for SLA violation offered by Amazon
EC2, S3, and Terremark vCloud Express can only be applied
towards future payments of respective cloud services. Amazon
EC2 and S3, Azure Compute and Storage, and Terremark
vCloud Express only partially reimburse the total cost of
affected services, while Rackspace Cloud Servers and Storm
on Demand can provide up to 100% reimbursement. Storm on
Demand is unique, in that it offers to reimburse 1000% of the
cost of affected instances. However, it is relatively a new IaaS
provider.
• SLA Violation Reporting Time Period
Azure Compute and Storage and Storm on Demand
SLAs stipulate that a customer must report the SLA violation
incident within five days of the incident occurrence which is
more stringent than the 30 day violation reporting and claim
filing time period offered by other cloud providers. Azure
does allow a customer to file a claim 30 days after reporting
the incident.
• SLA Jargon
An SLA is a legal document and is the sole remedy for a
customer for any service violations. The lack of
standardization in SLAs and the use of SLAs as a potential
marketing vehicle makes it difficult to compare SLAs of
different cloud providers. As an example, Storm on Demand,
and Rackspace guarantee their data center network, HVAC,
and power to be 100% of the time, but they qualify it with
scheduled maintenance. Similarly, Azure Storage performance
guarantee does not include the time it takes to transfer the data
in and out of data center. For a designer of cloud application,
it is important to pay attention to these details.
• Storage SLAs: Performance vs. Request Completion
For the storage SLAs, only Azure provides a performance
guarantee per transaction, i.e., processing time for a request
(which excludes the data download or upload time). Amazon
S3 and Rackspace Cloud Files do not provide any
performance guarantees and instead only provide a request
completion guarantee.
• SLAs Offered By Business Internet Providers
We briefly describe the Internet Dedicated SLA offered
by Verizon [20] and how it compares with SLAs offered by
cloud providers. Verizon Internet SLA comprises of nine
service guarantees such as availability, latency, network
packet latency, ticket response time for denial of service, and
time to repair.
Unlike SLAs of cloud providers considered in this paper,
the onus for detecting SLA violation for certain metrics such
as availability is on Verizon. However, a customer must
explicitly request a service credit within 30 days of the
incident occurrence. Scheduled maintenance is excluded from
the service guarantee calculation. A customer account is then
automatically credited for any service violation which is not
the case with any of the considered cloud provider SLAs.
• What is missing from the SLAs?
The SLAs of the considered cloud providers only focus
on availability or request completion rate. An enterprise cloud
SLA encompasses much more than availability, request
completion rate, or performance. It defines guidelines for
disaster recovery, privacy, auditability, and security.
The details of which service guarantees to consider for
enterprise cloud SLAs can be found in cloud computing use
cases paper [9]. Further, unlike the public cloud providers
considered in this paper, the burden of detecting SLA
violation may lie on the provider.
130
VI.
FUTURE OF CLOUD SLAS
In this section, we consider how a cloud provider may
define SLAs for cloud services in the future.
• Service guarantee: The considered cloud providers only
provide uptime guarantees for IaaS services. The cloud
providers may also want to offer other guarantees such as
performance, security, and ticket resolution time. Providing a
performance guarantee becomes necessary if cloud providers
oversubscribe the resources of physical servers to decrease the
number of physical servers used and increase their utilization.
The over-subscription of the physical servers implies that
performance of virtual machines running on physical servers
may become a concern. Further, co-location of a virtual
machine with other workloads may also impact the CPU, disk,
network, and memory performance of a VM. Moreover,
enterprises purchasing cloud based services may demand a
minimal level of performance guarantee. Therefore, it may be
necessary for a cloud provider to offer performance based
SLAs for its IaaS compute services with a tiered pricing
model, and charge a premium for guaranteed performance.
• Service guarantee time period and granularity: The
service guarantee time period and granularity determine how
stringent is the underlying service guarantee. A service
guarantee is stringent if the metric is performance based for a
fine-grained resource over a small time period, e.g. 99.9% of
memory transactions in a five minute interval must complete
within one micro second. Such a stringent guarantee can be
loosened by aggregating the service guarantee over a group of
resources (e.g., aggregate uptime percentage of all instances
must be greater than 99.5%). Providers can use a combination
of service guarantee granularity and service guarantee time
period to price their services appropriately.
For enterprise and mission critical workloads, a cloud provider
may have no choice but to provide finer service guarantees.
• Service violation detection and credit: None of the
considered providers automatically detect SLA violation and
leave the burden of providing the violation proof on the
customer. This aspect may not be acceptable to customers
with mission critical or enterprise workloads. A cloud provider
can differentiate the pricing of its offering if it automatically
detects and credits the customer for SLA violation.
However, the tooling cost to automatically measure, record,
and audit SLA metrics can be a concern.
• Outcome based SLAs: The cloud providers considered in
this paper offer IaaS and PaaS services.
Using these services, a customer can deploy her own
applications in the cloud. However, in the future, cloud
providers may offer outcome based services on top of cloud,
where a provider delivers a complete solution for a customer
using cloud. For outcome based services, a cloud provider
needs to define SLAs for the promised outcomes and how
those SLAs map to the underlying IaaS and PaaS
infrastructure it provides.
• Standardization of SLAs: The lack of standardization in
cloud SLAs makes it difficult for a customer to effectively
compare them. As cloud services mature, and as the vision of
utility computing is realized, the standardization of SLA is
likely to take center stage. Structured representation of SLAs
(e.g., in XML) may be necessary for standardized SLAs.
VII.
CONCLUSION
As discussed in this paper, there is much more to a
provider’s cloud SLA than simply an uptime percentage
guarantee, and savvy buyers need to investigate their options
carefully to ensure that they are comfortable with the
guarantee offered by their provider. All cloud providers leave
the burden of providing evidence for SLA violation on the
customer. We then discussed how SLAs should be defined for
future cloud services. As more and more consumers delegate
their tasks to cloud providers, Service Level agreements
(SLA) between consumers and providers emerge as a key
aspect. This study will help in clarifying and defining SLAs of
existing and future cloud based services.
REFERENCES
[1] Armbrust, M., Fox, A., Gri_th, R., Joseph, A.D., Katz,
R.H., Konwinski, A., Lee, G., Patterson, D.A., Rabkin, A.,
Stoica, I., Zaharia, M.: Above the clouds: A berkeley view of
cloud computing. Technical Report UCB/EECS-2009-28,
EECS
[2] Department, University of California, Berkeley (Feb 2009)
[3] Keller, A., Ludwig, H.: The wsla framework: Specifying
and monitoring service level agreements for web services. J.
Netw. Syst. Manage. 11(1) (2003) 57{81}.
[4] Ludwig, H., Keller, A., Dan, A., King, R., Franck, R.: Web
service level agreement (WSLA) language speci_cation. IBM
Corporation (2003)
[5] Amazon: Service level agreement for ec2
http://aws.amazon.com/ec2-sla/] (2008)
[6] He, C., Gu, L., Du, B., Li, Z.: A WSLA-based monitoring
system for grid service-GSMon. In: 2004 IEEE International
Conference on Services Computing, 2004.(SCC 2004).
Proceedings. (2004) 596{599}
[7] http://aws.amazon.com/ec2-sla/, as of 12/11/2012
[8] http://www.microsoft.com/en-us/download/details.
aspx?id=24434, as of 12/11/12
[9] https://www.hpcloud.com/sla, as of 12/11/2012
[10]
https://community.vcloudexpress.terremark.com/enusproduct_
docs/w/wiki/service-level-agreement.aspx,
as of 12/11/2012.
[11] [Allen 2006] Allen, Paul. Service Level Agreements.
Hhttp://www.cbdiforum.com/report_summary.php3?page=/se
cure/interact/200612/service_level_agreements.php&area=silverH (2006).
[12] [Andrieux 2007]Andrieux, Alain, et al. Web Services
Agreement
Specification
(WSAgreement).Hhttp://www.ogf.org/documents/GFD.107.pdfH
(2007).
[13] www.dimensiondata.com/cloud/sla
Copyright © 2011-14. Vandana Publications. All Rights Reserved.
131