Database Reference
In-Depth Information
Fig. 7.1
SLA parties in cloud environments
end-users for processing their workloads, depending on the customers' business
model. In both cases, the cloud customers need to guarantee their users' SLA.
Otherwise, penalties are applied, in the form of lost revenue or reputation. For
example, Amazon found that every 100 ms of latency costs them 1 % in sales and
Google found that an extra 500 ms in search page generation time dropped traffic
by 20 %.
1
In addition, large scale Web applications, such as eBay and Facebook,
need to provide high assurances in terms of SLA metrics such as response times and
service availability to their end-users. Without such assurances, service providers of
these applications stand to lose their end-user base, and hence their revenues.
In practice, resource management and SLA guarantee falls into two layers: the
cloud service providers and the cloud customers. In particular, the cloud service
provider is responsible for the efficient utilization of the physical resources and
guarantee their availability for their customers. The cloud customers are responsible
for the efficient utilization of their allocated resources in order to satisfy the SLA of
their end-users and achieve their business goals. Therefore, there are two types of
service level agreements (SLAs):
Cloud infrastructure SLA (I-SLA)
: These SLA are offered by cloud providers to
cloud customers to assure the quality levels of their cloud computing resources,
including server performance, network speed, resources availability, and storage
capacity.
Cloud application SLA (A-SLA)
: These guarantees relate to the levels of quality
for the software applications which are deployed on a cloud infrastructure. In
particular, cloud customers often offer such guarantees to their application's
end users in order to assure the quality of services that are offered such as the
application's response time and data freshness.
Figure
7.1
illustrates the relationship between I-SLA and A-SLA in the software
stack of cloud-hosted applications. In practice, traditional cloud monitoring tech-
nologies, such as Amazon CloudWatch, focus on low-level computing resources.
However, translating the SLAs of applications' transactions to the thresholds of
utilization for low-level computing resources is a very challenging task and is
