Information Technology Reference
In-Depth Information
hosted in clouds, the entire service lifecycle and
the behavioral aspects of the service during such
lifecycle, using a declarative language in the form
of a service definition manifest.
to meet demand, though the load balancer
would continue to serve as a single point
of entry.
3. Relevant KPI Description: Providing sup-
port for elasticity requires the state of the
application to be exposed to the infrastructure
in the form of monitorizable performance
indicators. These KPIs (Key Performance
Indicators) may be infrastructure level indi-
cators such as current disk use, but applica-
tion level performance indicators may prove
necessary to maximize the optimization and
response. We can consider in our example
the number of simultaneous sessions that
our web application will handle as a basis
for scaling the application.
4. Constraint policies: The use of virtualiza-
tion technologies introduces a degree of
location transparency - users may not
know where their services are running and
loosely coupled services may be deployed
across multiple physical and administra-
tive domains. However, there may exist
cases where users are in fact concerned with
controlling the spread of their applications
for administrative or technical reasons: le-
galities may mean that some data may not
leave a particular country for example, or
a provider may simply wish to minimize
latency between components by ensuring
that certain service components remain co-
located. It must hence be possible to provide
clear constraint policies on the distribution
of services across sites. Constraints may also
exist regarding the portability of the appli-
cations deployed on the cloud. The overall
service may be tied to specific hardware
or hypervisor technologies for example,
and heterogeneous hosting environments
must cater for such limitations. In addition
we must also consider potential constraints
when migrating services, and provide means
of specifying the optimum conditions that
have to be met to minimize disruption.
2.2.1 Requirements for a Cloud Based
Service Description Language
The requirements for a service definition language
for cloud computing can be broadly broken down
in a number of subsets described as follows. In
order to illustrate some of the requirements, we
will use a typical three tier web architecture to be
deployed on an IaaS or PaaS clouds via Amazon
EC2 or Azure. The application will consist of a
single database, web server and a load balancer.
1. Service Architecture: We are concerned here
with the overall structure of service deployed
on a cloud and any capacity or capability re-
quirements in terms of hardware or software
dependencies. This may include for example
the overall network topology and intercon-
nections among services, specific hardware
requirements of individual components
(e.g. CPU, memory, etc.), which may vary
according to the nature of the service.
2. Service Elasticity: When dealing with rapid
changes in service context and load (e.g.,
due to sudden pike in the number of service
users), timely adjustments may be necessary
to meet service level obligations that cannot
be met by human administrators. In such a
case, it may be necessary to automate the
process of requesting additional resources
or releasing existing resources to minimize
costs. In order to automate the scaling of
applications to meet variations in workload
the service provider must be able to describe
the conditions within which this scaling takes
place and the actions to follow should these
conditions hold true. Referring to the web
application example, it may be necessary to
increase the number of web servers available
Search WWH ::
Custom Search