An application–centric model for cloud management

Terence Harmer, Peter Wright, Christina Cunningham, John Hawkins and Ron Perrott
Belfast e-Science
Queen’s University of Belfast
Belfast, UK
{t.harmer, p.wright, c.cunningham, j.hawkins, r.perrott}@besc.ac.uk

Abstract—The cloud model is increasingly popular as a
means of creating dynamic, flexible and cost effective network-
centric application infrastructures. The model separates the
applications, or application cloud, from the resources, or
resource cloud, upon which the applications will be hosted.
There are an increasing number of utility resource providers
that aim to provide cloud infrastructure on demand to users
and libraries that aim to manage owned infrastructure as
a resource cloud. There is, unfortunately, no common API
for cloud resources and it is unlikely that one will emerge
soon given the immaturity of the area and the competing
commercial interests in the domain. In this paper, we outline
our commodity and application-centric approach to resource
management, and describe our integration framework for cloud
application management–illustrating its use in a field deployed
application and a particular dynamic component within that
application.
I. I NTRODUCTION
The cloud computing or cloud model is increasingly pop-
ular as a means of creating dynamic, flexible and cost effec-
tive network-centric application infrastructures. The model
distinguishes between the software application components,
the application cloud, and the hosting computing resource
components upon which the application will be executed and
managed, the resource cloud. This separation of concerns
is intended to bring flexibility, mobility, scalability and
greater robustness to the application, and the potential of
cost savings in the deployment and operation of network
centric infrastructures.
The application cloud is most often dynamic and de-
signed to scale to meet demand from users for application
services–the hosting cloud provides a reliable and scalable
physical infrastructure that hosts application services. From
the application perspective, the hosting cloud is a utility
that is provisioned to meet the needs of the application
cloud. The resource cloud will consist of one or more
resource providers each of which supplies hosting, network
and storage capabilities on-demand. The role of the resource
cloud provider is to supply a robust, secure and flexible
environment that is configured to meet the needs of the
This work is supported by the UK Technology Strategy Board under
grant TP/3/PIT/6/l/15656 and the UK EPSRC under Platform Award
EP/F066139/1
application and provide a framework to enable an application
to be monitored and managed.
The separation between application concerns and resource
concerns means that the application can conceivably be
moved between different hosting environments providing
potential resilience and robustness to the application deploy-
ment. The resource cloud may be thought of as a resource
marketplace with resources consumed by the application
from the best available resource provider to match appli-
cation demands. This offers researchers and businesses the
potential of significant cost-savings in that it is possible for
them to match the cost of their computing and storage to
their demand for such resources. Thus, a user needing 1000
compute resources for 1 day per week may acquire those
resources only for the day they are required.
An application could be hosted on an internal resource
cloud consisting of compute resources, storage and net-
work that are wholly owned by the organisation, or similar
resources rented from a commercial resource provider or
indeed a combination of both. For wholly-owned resource
clouds, the model enables organisation-wide aggregation
of resource requirements which should lead to improved
resource utilisation, reduced management costs and pro-
vide a better return on investment in resources. In today’s
market, it is possible for a business or researcher to be a
significant computation resource consumer without owning
any significant infrastructure, instead relying primarily on
resources purchased from commercial hosting providers
when they need a compute infrastructure. Again, this can
bring significant cost benefits and reduce the barriers faced
by businesses in becoming significant service providers
or researchers whilst undertaking computationally intense
research experiments.
The cloud model has much potential and the creation of
a resource marketplace will bring significant cost savings
and robustness to application users. However, there is no
common provider interface and little prospect of one being
adopted in the short term given the immaturity of the cloud
model–the biggest provider, Amazon, might be regarded
as a de facto standard leading to open source libraries
based on its model[1]. On-demand provision of resources to
users has been around for some time with grid computing
services, such as the UK National Grid Service[2] and the
US TeraGrid[3], but they have largely been job focused
rather than service-focused. In these infrastructures the goal
is to optimise the compute jobs that are being requested by
users—delivering the fastest compute for users and making
the best use of the fixed compute infrastructure.
In general, an application must be aware of the providers
it is using and their particular features–this can vary from
the charging models they use to the network configuration
options and virtualisation technology they can provide. In
this evolving area, capabilities are added rapidly and the
supporting APIs to use these capabilities change frequently.
This represents a barrier to using the cloud model and
increases the current cost of use by requiring software to
track the evolution of provider APIs.
We (BeSC) have developed a number large-scale commer-
cial and research cloud deployments that use a commodity
market approach to resources provided within a resource
cloud. In the commodity marketplace, resources are discov-
ered and selected to satisfy the high-level needs of the appli-
cation. To support this work we have created an application-
centric and provider neutral interface[4] that enables an
application to use a variety of providers in a generic way
and to express provisioning using commodity market centric
ideas. In this paper we develop these commodity market API
ideas and illustrate their use within a large-scale operation
that is currently is user field trial.
II. BACKGROUND : R ESOURCE - CENTRIC API S
Almost all of the current cloud APIs focus on resource
clouds, removing the requirement to host or own the physical
cloud resources to be used. It is still necessary, however,
to manage this dynamic collection of resources that will
host the application cloud. Effective management of the
resource layer in a provider-neutral way is difficult. There
are both significant and subtle differences in current APIs.
More importantly, there are significant differences in the
resource allocation models those APIs support and which are
exposed to the application. In addition, utility provider APIs
are evolving rapidly and are subject to significant changes;
for example, Amazon’s introduction of Spot Instances intro-
duced an entirely new EC2 resource life-cycle model.
There has been an explosion of provider APIs (such
as EC2[5], Rackspace[6], OpenNebula[7] OCA, OCCI[8],
Azure[9], NewServers[10], etc.) and user libraries (such
as libcloud.org[11], Dasein[12]) for the cloud model. The
APIs, in general, are focused on exposing the available
infrastructure-level capabilities, such block devices, virtual
machines, snapshots, power states. This low-level view
makes cross-provider operations (or porting a novel cloud
between providers) heavy work if there is no exact match
to the features being used.
By way of an example, suppose a user provisions a
database and some time later they wish to produce a
snapshot of its state; if the database files sit on an Amazon
EBS (a networked block device system) volume then they
can simply call the EBS snapshot method on that volume.
However, if the user had provisioned this same system with
Flexiscale or NewServers (where there is no block device
snapshot API) then the user can not make such a request. If
the user was using an application-level abstraction, however,
they would have provisioned ”a database” and would be
requesting a snapshot of the database. With such a higher
abstraction there is more room for the API to change how
the request is executed: in the case of EC2 it could use
the Amazon Relational Database Service whereas in the
Flexiscale or NewServers case it could provision a host,
configure it with MySQL, say, and ask the database for a
snapshot directly.
The next section demonstrates the basic API differences
between provisioning the cheapest resources in the clouds
of Amazon EC2 and Flexiscale
A. Provisioning: Flexiscale
Flexiscale’s[13] API requires users to define the specifi-
cation of the machines they wish to start: the number of
CPUs, amount of RAM and the size of the hard disk. The
valid combinations of these are not exposed through the API
but rather are shown on the Flexiscale website in an HTML
table - if this table changes then the users of the API would
need to modify their provisioning logic to take account of
it.
S t r i n g i d = ‘ MyNewServer ’ ;
/ / Get d e f a u l t h o s t i n g p a c k a g e , VLAN + OS
P a c k a g e pkg = f l e x i s c a l e . p a c k a g e s [ 0 ] ;
Vlan v l a n = f l e x i s c a l e . v l a n s [ 0 ] ;
OSImage o s = new OSImage ( 2 7 ) ;
S e r v e r s = new S e r v e r ( ) ;
s . setName ( i d ) ;
s . setDisk capacity (4);
s . setProcessors (1);
s . setMemory ( 5 1 2 ) ;
s . s e t P a c k a g e i d ( pkg . i d ) ;
s . s e t O p e r a t i n g S y s t e m ( os ) ;
s . s e t I n i t i a l P a s s w o r d ( ‘ changeme ’ ) ;
f l e x i s c a l e . createServer ( s , vlan ) ;
f l e x i s c a l e . s t a r t S e r v e r ( i n s t I d , ‘ no n o t e s ’ ) ;
String ip = f l e x i s c a l e . getServer ( id ) [ 0 ] . ip [ 0 ] ;
System . o u t . p r i n t f ( ‘% s ’ s I P : %s \n ’ , i d , i p ) ;
In the above code we pick our hosting package (a handle to
Flexiscale’s billing system), the network VLAN to which the
machine should be connected and a pointer to the Ubuntu
operating system (image number 27.) We then create a server
with 1 CPU, 512MB of RAM and 4GB of disk space.
Once created, we start the machine and then request its
details from the API to determine the IP address assigned to
this instance. Flexiscale must create a machine image when
requested and so turnaround time can be in the region of
10 minutes - as a result it is important to create a resource
in advance of when it will be required by an application
(which can complicate scaling to meet changes in application
demand).
B. Provisioning: Amazon EC2
R u n I n s t R e q u e s t r e q = new R u n I n s t R e q u e s t ( ) ;
r e q . s e t I m a g e I d ( ‘ ami−1c5db975 ’ ) ;
r e q . s e t P l a c e m e n t ( ‘ us−e a s t −1a ’ ) ;
/ / 1GHz xeon , 1 . 7GB RAM, 150GB d i s k
r e q . s e t I n s t T y p e ( ‘ m1 . s m a l l ’ ) ;
r e q . setKeyName ( ‘ someAuthKey ’ ) ;
R e s e r v a t i o n r e s = ec2 . r u n I n s t a n c e s ( req ) ;
String id = res . getInstance ( ) . getInstanceId ( ) ;
String ip = r e s . g e t I n s t a n c e ( ) . getPublicDNS ( ) ;
System . o u t . p r i n t f ( ‘% s ’ s I P : %s \n ’ , i d , i p ) ;
In the above code we pick the Amazon Machine Image
(AMI) representing an Ubuntu operating system, specify the
datacentre we wish the resource to reside in and pick an
Instance Type - a template specifying CPU cores, speed,
RAM and scratch disk size and quantity. Once these have
been specified we also define the SSH login key to use and
start the machine. Machines in Amazon start reasonably
quickly - generally within two minutes - allowing us to
rapidly acquire large numbers of resources.
These code snippets (above) are performing the same
simple operation–selecting a basic CPU type, suitable op-
erating system and basic configuration–which is a basic
operation of a dynamic multi-provider cloud application. In
the Flexiscale and EC2 examples, the available operating
systems and resource specifications (CPU, RAM, disk) are
somewhat static– when a new template is added the de-
veloper (or deployment team) must modify the application
to enable the use the new resource. This static approach
reduces the flexibility of applications and tends to lock
applications into particular providers and particular known
configurations. The differences are significant for such a
basic cloud operation and become larger when underlying
features such as network configuration, security and data
storage are used.
III. A N APPLICATION - CENTRIC API
We are interested in dynamic service-centric systems that
are deployed as dynamic application clouds. The application
cloud is hosted in a resource cloud implemented by a
collection of resource providers, and is intended to remain
agnostic to the underlying provider using cloud resources
from whichever provider meets the needs of the application.
In this model, a resource-provider-agnostic API is required
to enable an application dynamically to
1) specify the CPU and operating system types that are
suitable for the application or a component;
2) specify the associated storage and networking infras-
tructure that are required for components;
3) specify configuration of a component or infrastructure;
4) specify software versions within the application stack
that are suitable;
5) specify online sources from which software should be
taken when required;
6) manage the application life-cycle, such as instantia-
tion, discard and shutdown; and
7) monitor the resource and application behaviour during
its life-cycle.
As we already described, there are many APIs and libraries.
The problem is that few of these enable an application
to remain agnostic to the provider environment and thus
enable the provider cloud to be viewed as a generic resource
marketplace for resource allocation and trading. In such a
trading environment, an application establishes the underly-
ing providers with which it has a financial arrangement in
order to enable those resources to be accessible. Forming
an agreement may be as simple as creating an account
and providing credit card details - but it could also involve
personally auditing the provider’s data centres.
Once a pool of resources is defined, an application can
select and allocate suitable resources within it. But what
model should the API take in specifying resource properties
to cope with the differing resource provider models? Given
the range of possible hardware and software requirements
for applications, defining a flexible and extensible API is
a challenge. We take a discovery based approach where
an application attempts to find resources (from the pool of
acceptable providers) that meet its requirements.
These requirements express constraints on the acceptable
resources and resource configurations in order to satisfy the
needs of the application. Each constraint expresses a simple
testable property; for example, that a particular CPU type,
RAM size, operating system versions or storage access type
is to be used. The idea is that a collection of these simple
constraints can be used to express more complex needs and
provide for systematic and automated comparison of what
is available within the provider, thereby allowing us, for
example, to define a Windows 7 OS hosted on dual core
processor with 3GB of RAM, with input network capacity
of 100Mbyte/sec and using storage resilience of at least 99%.
The capability to specify constraints to select a resource
rather than mandating a design-time specified solution is
very powerful since the developer can utilise the best avail-
able solution at the application’s runtime based on their
current situational requirements. For example, if the user
could express “I need 2GB of RAM but I’d be willing to
pay $0.10 more per hour for 4GB” or “the resource must be
in an ISO 27001 accredited datacentre” then any approved
provider capable of satisfying those requirements at runtime
could be automatically considered. Thus by expressing the
requirements of the application explicitly it is possible to
take advantage of any new resource type or capability when
it becomes available within the provider without any change
in the application code.
The find operation returns a list of suitable templates from
which an application can choose an appropriate resource.
The application chooses the most appropriate resource by
assigning a cost to each suitable template. The cost is,
ideally, an estimate of the cost of a typical usage scenario
to a particular application. A usage scenario is a collection
of chargeable operations such as:
1) allocating/deallocating a resource
2) reserving a resource
3) keeping a resource switched on for a certain period of
time
4) using a certain amount of incoming/outgoing band-
width within the provider (over a given period of time)
5) performing a number of IO operations on a local or
SAN disk (over a given period of time)
6) storing a certain volume of data on a local or SAN
disk (for a given period of time)
These scenarios are simple to create, however predefined
scenarios with the API are available for compute-only,
network-only and storage-only applications to allow devel-
opers to us the API without a significant effort.
Each template has a cost model which can be interrogated
about the monetary cost of all of the above chargeable
operations. We term the estimated cost of a usage scenario a
scenario cost. An application may have multiple scenarios,
of which it will pick one representative scenario based
on the available features of the resource. A good example
of this is where the resource must provide some storage
redundancy; there would be a scenario for redundant storage
(with fewer write operations and half as much data stored)
as well as a worst-case for non-redundant storage. Since
we can calculate the cost of providing redundancy on top
of a non-redundant infrastructure we can determine the
cost effectiveness of provider-managed redundancy versus
managing redundancy at the application or operating system
level.
Once an appropriate resource has been selected it can be
reserved. A reservation is a short-term hold on resources
(and is a no-op for many providers currently) designed to
provide a guarantee the resources will be available when
needed. Once resources are needed they are instantiated,
which provides the application with a running resource
which it can use as it sees fit. When the application finishes
with the resource it discards it, returning it to the provider.
Combining all the steps discussed so far provides a usage
model of define provider, find resource, reserve resource,
instantiate resource, use resource, discard resource.
This model is intentionally simple and attempts to reflect
an ideal for the application user who wishes to specify
resources without knowing the internal behaviour of the
resource provider. Currently, when developing cloud appli-
cations, many of the steps in our model are performed manu-
ally and updated frequently to reflect API or resource model
changes. This approach means that the application can take
a dynamic, commodity-centric approach to resource usage.
An application cloud can be deployed and scaled according
to application and system constraints, stay within a strict
budget and be mobile between all available infrastructure
providers. As an example we consider a large-scale example
which manages a on-demand media infrastructure for a
media test community and specifically a component which
manages video transcoding–this infrastructure has been in
field deployment and testing for more than 2 years and has
managed more than 1 petabyte of media content in that time.
IV. E XAMPLE : PRISM A U TILITY INFRASTRUCTURE
AND SERVICE MARKETPLACE
The PRISM[14] on-demand media infrastructure man-
ages large-scale and distributed media content creation and
distribution to a user and service community–the media
content is the daily television and radio output of a broad-
caster and contributed media from the user community.
PRISM developed ideas and infrastructure from the GridCast
project[15], [16] that created a cloud model for an internal
broadcasting infrastructure with the aim of exploring new
models for on-demand provisioning, access and delivery for
the media domain. Whereas Gridcast focused on the rather
static needs of a deployed broadcaster infrastructure with
known demand and usage patterns, PRISM is a dynamic
service infrastructure with user driven and more random
demand patterns within the evolving digital media economy.
The media economy is increasingly a marketplace for ser-
vices with shared infrastructure, collaborative development
and service trading between specialist companies. This mar-
ketplace is global, rapidly evolving and cost sensitive where
establishing a market service quickly and cost effectively
brings significant business benefits. The basic capabilities of
PRISM, as illustrated in Figure 1, within this marketplace
are
• content access providing a content portal, user interface
and media exchange; and
• collaborative sharing and production with B2B and
Media services;
These services are implemented as dynamic service clouds
for
• content management, replication, managed sharing, and
secure and authenticated user access;
• content services to process the content into a form that
is sharable and available to users;
• content metadata management, indexing, replication
and sharing; and
• content management including release, withdrawal and
access rights.

Figure 1. Media Economy and PRISM Services
The components within these clouds are scaled by our cloud
infrastructure management layer Zeel (outlined below) in
line with the needs of the infrastructure in order to stay
within established service level agreements. A basic internal
scenario is that new media content is being released (to
users or collaborators): the content is processed to its correct
distributable format(s), shared with authorised distributors
and supplied with appropriate metadata to enable discovery
and access. The PRISM services infrastructure provide a
platform for distributed service provision between media
service companies and supplying content to distributors and
other end-users.
The services within the PRISM cloud, as shown in Figure
1, are hosted on a collection of owned resource providers,
in this instance owned by BBC, BT and BeSC, and utility
providers, such as Amazon and Flexiscale. Each of the
resource cloud providers is managed identically as outlined
above using the provider agnostic library–with each provider
advertising available templates that may be purchased in
order to host application cloud services. The balance of
use between providers will depend on the availability of
resources–in the past we have lost one of our owned
providers due to network failure and the services were
migrated automatically to a utility provider.
To deploy and manage the PRISM infrastructure we use
the above API to allocate and scale the resources on which
services are hosted. PRISM software has a wide range
requirements. Some components, such as media transcoders,
require high performance resources with fast network con-
nectivity to enable sharing of the processed content. Other
services, such as user interfaces require lower powered
resources with connectivity to search and streaming engines–
these components are most likely to scale as demand
changes. Some services have large data storage requirements
in order to host large-scale archives accessible to users.
Moreover, the allocation of services to a provider cannot
be handled in a per-service way as some services form
logical groups that should be deployed together, reflecting
a need to share data. For example, a content repository
usually requires supporting transcoding services to enable
content to be delivered to a user in the format required. The
provider API has the capability to support multi-resource
allocation enabling a group of templates to be output from
a find operation to support costing based on service-group
hosting.
All of the software within the PRISM infrastructure is
annotated with metadata that defines its particular require-
ments when being deployed–this metadata is generated as an
integral part of the development process and stored as part of
the system definition. For commercial software, the metadata
is generated by the developer when the software is integrated
into the PRISM development. A system’s metadata defines
• resource requirements such as CPU, RAM, network
capacity security requirements;
• hosting operating systems and acceptable versions;
• supporting software stack listing software, acceptable
versions and acceptable online repositories from which
the software can be sourced.
• deployment costing scenarios.
The deployment costing scenarios define a costing model for
particular patterns of use. For example, the requirements for
a transcode component are different when it is deployed as
an on-demand/on-the-fly transcoder compared to one that is
used as a batch transcoder.
The deployment of the PRISM infrastructure and the
management of its day-to-day operation is performed by the
Zeel management system developed by BeSC.
V. Z EEL - A CLOUD MANAGEMENT LAYER
In developing projects at BeSC (some five years ago)
we faced a task that many cloud developers now face. We
have a collection of resources that we wish to treat as
utility resources that are configured as we require them and
in a form we require–sometimes these will be Windows
flavours, other times these will be Linux flavours and each
should be pre-configured with an application stack to suit
its purpose. The other problem we faced was that much of
our infrastructure was remote to BeSC and often required a
plane journey in order to access the physical hardware. Our
solution was to develop a resource manager and application
deployment framework, called Zeel, which has been in use
(in various forms) within BeSC for more than four years
to manage and monitor resources, manage virtual machines,
deploy/undeploy software, and configure storage, security
and network. Zeel is capable of managing machines securely
across multiple administrative domains using the above
provider agnostic API (which within BeSC is usually called
Zeel infrastructure layer or simply Zeel/i) to control physical
resource clouds.
In essence, Zeel is a management framework rather than
a software solution in that it ties together available software

Figure 2. A high-level view of Zeel’s components
solutions to create a management layer–the Zeel whole is
more significant than the sum of it parts. For example,
the Zeel deployment solution is a framework that provides
generic access to custom solutions provided by the resource,
such as rpm on RedHat linux or msi under windows; and
the Zeel virtualisation solution is a framework with plugins
for VMWare, Xen, OpenVZ etc. Thus the Zeel management
layer talks about virtualisation and deployment in a generic
fashion rather than in particular technology terms–it is then
relatively easy to integrate a new operating system or vir-
tualisation technology without changes in the management
layer.
Zeel provides core management layers for deployment
(internally referred to as zeel/d), tasks such as configuration
(zeel/t) and monitoring (zeel/m). These management layers
exist to allow the co-ordinating framework, eZeel, to operate
at a very abstract level.
A. eZeel
eZeel is designed around deploying groups of software
onto sets of machines–for example a storage and transcode
group that are part of the PRISM infrastructure. The ma-
chines can either be directly specified (by IP address, for
instance) or searched for (for instance, a machine with
SSSE3 and at least 4GB of RAM as constraints to Zeel/i).
The high level operation of eZeel is shown in Figure
2. eZeel takes abstract deployment plans and enacts them–
generally this would be a request to deploy a variety of
services onto a collection of resources with specific com-
pute or storage capabilities–based on the currently available
software and infrastructure. Plans can be flexible (such as
a request for a transcoding service) or highly prescriptive
(such as a request for a specific transcoder to be installed
and attached to a particular storage system and work queue).
Flexible plans can deliver major benefits to the end user
since a variety of software and platforms can be used –
a requirement for a transcoder could potentially be solved
using a Software as a Service (SaaS) transcode provider
from a 3rd party. A plan can be undeployed when it is no
longer needed, allowing the user’s system to be torn down
and resources discarded or restored to their original state.
At eZeel’s core is a software registry and a machine
registry; the software registry defined security policies and
obligations for using various pieces of software and the ma-
chine registry detailed the state of the resource, the software
installed on it and the policies and obligations in effect as
a result of either its location, role or the software installed.
This allows the user to express high-level restrictions such
as “software x cannot be on the same machine as software
y or data z” and this can be enforced in an auditable
way. Policies are specified in XACML and enforced by
an XACML engine, such as Sun XACML engine or the
HERAS-AF XACML engine.
eZeel is a framework to allow a system to be managed and
monitored in its own terms: a system is comprised of one
or more capabilities. Capabilities encapsulate all monitoring
and management tasks for a software component, putting
them in terms that is meaningful to the wider system. For
example:
• a webserver capability would provide monitoring data
relevant to serving pages (hits per second, the cost to
serve the average request, etc.)
• a storage capability would show storage terms (usage,
storage cost per gigabyte per hour, current latency)
• a policy engine capability would show policy evaluation
terms (requests evaluated per second, number of denied
requests)
Capability objects have access to the Zeel APIs for
deployment, monitoring and task execution; they are also
free to make contact with the service they represent to
perform additional functions. Each capability has one or
more Hosts upon which its software is running; the Host
object encapsulates all the operating system and provider-
specific tasks. This encapsulation allows the Capability to
be completely agnostic to hardware terms: in fact, it makes
it possible for multiple Capabilities to be co-located on
a single host when the cost of running them on separate
hosts cannot be justified (and where the Capabilities permit
such co-location). A Capability could also be a composite
capability: comprised of other capabilities (and generally
adding value to the grouping - for instance exposing average
or peak throughput data for a group of webservers)
We have discussed systems, capabilities and hosts; these
exist when our system is running, however in order to
construct our system we have other types which are closely
related: a CapabilityTemplate will set up the software so the
associated Capability can manage it; a HostTemplate will
set up the hardware so the associated Host type can manage
it. A System is constructed from a Recipe - a recipe can
be configured to take custom parameters (such as budgets,

Figure 3. transcoder high-level model
static external service endpoints, etc) using an ingredients
list. The ingredients list can include information such as:
1) The recipe name
2) The instance name
3) The load balancer to use within the system
4) The providers we are willing to use for this system
5) Access control requirements
6) Storage budgets
7) System budgets
8) A minimum / maximum number of resources to in-
stantiate
VI. T RANSCODING IN THE C LOUD
Video transcoding is the process of converting video
files between container formats, video and audio codecs.
It is an interesting task for a cloud because it has high
compute, storage and bandwidth requirements and scales
very well (individual video files are usually quite short so
many transcodes can be run in parallel). We developed a
scalable budget-aware transcoding solution to work around
the great expense and inflexibility of existing transcoding
hardware: they are generally deployed on very expensive
fixed machines with little sharing. We wanted to be able
to quickly transcode the daily output of our broadcasting
partner’s many TV and Radio channels without having
expensive transcoding hardware idle for most of the day
but whilst also keeping down the latency between when a
piece of content is broadcast and when it is transcoded and
available online for users.
The general transcoding model, shown in Figure 3 allows
video to be ingested and converted into different formats
while minimising the number of resources used. To ac-
complish this, a Transcode Coordinator adopts groups of
transcode jobs submitted through the Transcode Queue API.
A group specifies its deadline and a budget for the con-
version. Individual jobs specify the source and destination
formats, along with a link to the source video. The Transcode
Coordinator ensures that transcodes are completed before
they are needed, potentially increasing parallelism by provi-
sioning more worker nodes if the current level of throughput
is not high enough.
The Transcode Coordinator constantly re-evaluates the
value for money delivered by worker nodes. If a particular
node is not providing sufficient value for money then it is
discarded just before its next billing cycle. The system tries
to ensure it does not deliver content significantly in advance
of its deadline: by delivering in a JIT (Just In Time) fashion
it can get the best value for money.
The Transcode Coordinator also records the performance
of various machine types; this is useful in a number of
system components:
1) to determine whether a machine’s performance is in
line with expectations
2) to form the usage scenarios to evaluate machines
against
3) to allow new machines from various providers to be
used instantly without the need for benchmarks to be
run
Using historical data to drive decisions is very flexible
since it allows new providers to be added quickly and
automatically avoids slow resources – and will react instantly
to pricing changes (if using, for instance, Amazon EC2 Spot
Instances)
Jobs are sent to the Transcode Coordinator in batches with
a common deadline. Each batch is provisionally planned
by the Transcode Coordinator, which allocates the longer-
running jobs to appropriate resource types, with the intention
of completing within an hour if possible. Shorter jobs are left
to be allocated opportunistically by the Transcode Coordi-
nator, running either during unused time at the end of longer
jobs, or on resources that turn out to be substandard. Each
planned resource is started at a time chosen by the Transcode
Coordinator, which aims to finish the work well ahead of
the deadline, but spread it evenly across that time, allowing
high utilisation of the best-performing machines. Multi-core
machines can be used to run several jobs simultaneously,
one per core, as this is more efficient than transcoding a
job with multiple threads - this is done only if necessary to
complete a long job within the deadline.
The Transcode Coordinator continually monitors the per-
formance of the running nodes. Historical data is used to
determine what is acceptable performance for each resource
type, and resources which fall short of this have their
allocated jobs reassigned to another resource. Such resources
are never kept for more than an hour, and are used for
running shorter jobs until their hour is up. Once any node
has finished its planned work, it uses the performance data
to decide whether to keep the node and allocate another
planned node’s jobs to it, or to discard on its next billing
cycle and use to run short jobs until then.
 VII. F UTURE W ORK
PRISM as an infrastructure is still in field deployment
and testing with an active test user group that ranges from
children as young as 8 to teenagers and adults. This broad
age group enables a range of different types of services
and usage patterns to be investigated. For example, young
children require simpler user interfaces and integration of
content with associated online games, teenagers generally
watch streamed content which is of a reduced quality and
that has peaks at well defined points in the day, while adults
often prefer high quality content and are willing to wait
while that content downloads to their home. The ideas within
PRISM are currently being developed by commercial part-
ners for deployment as a commercial product that manages
film content for in-home viewing.
Zeel is open source and is in active development within
BeSC and in deployment with a number of our industrial
partners. Its primary purpose within BeSC is to provide a sta-
ble platform for the development of novel dynamic service-
centric infrastructures and is being developed to support the
projects we are involved in–these currently include financial
services with high computational and sporadic behaviour,
military media with strict security and high volume media
traffic, and utility hosting providers creating utility resource
offerings. Zeel is largely an integration framework and
much of its basic development is integrating developments
from utility providers, such as Amazon etc, and generic
frameworks such as OpenNebula [7]. We are developing
our ideas in the area of system recipes to define system
deployment and configuration and the development of our
marketplace ideas that guide resource selection and mobility
between resource providers. A standard API to a current
strand of development is attempting to optimise the layout
of software on resources.
VIII. C ONCLUSION
In this paper we have presented a simple and resource
provider agnostic approach to resource management within
cloud applications. This API has been in use for several
years and is the core technology for a number of large-scale
applications in digital media, financial services, military and
utility hosting that are field deployed with established user
groups. The API is developed around the idea that it is an
integration framework rather than a solution technology–
the approach defines a management framework that brings
together the technologies that are required rather than rein-
venting new variants of existing and accepted technolo-
gies. This integration approach has permitted us to include
new virtualisation and provider solutions with few changes
to our core applications that are our primary focus–the
development of Zeel began as an effort to simplify our
applications development and we did not view it as an
end in itself. Our applications view the resource cloud in
generic terms and interact with them by expressing solution-
centric requirements and selecting resources and resource
locations using solution-centric scenarios that reflect the
application’s view of resource cost. The use of (on the face
of it) a simplistic approach to expressing requirements as
constraints has proven a powerful and automated way of
filtering the resources that are available from providers to
find the resources that are suitable for an application. A
service or application can have a long list of constraints in
our model but these are defined once and the process is an
integral part of our development approach–the creation of
a software/service/service group metadata repository and its
management and update has been fundamental to our work.
R EFERENCES
[1] Nurmi et al., in CCGRID ’09: Proceedings of the 2009 9th
IEEE/ACM International Symposium on Cluster Computing
and the Grid (IEEE Computer Society, Washington, DC,
USA, 2009), pp. 124–131
[2] W.J. Lizhe Wang, Jinjun Chen, Grid Computing: Infrastruc-
ture, Service, and Applications (CRC Press, 2009)
[3] Teragrid, (http://www.teragrid.org, 2008)
[4] T. Harmer, P. Wright, C. Cunningham, R. Perrott, in Euro-
Par ’09: Proceedings of the 15th International Euro-Par
Conference on Parallel Processing (Springer-Verlag, Berlin,
Heidelberg, 2009), pp. 454–465
[5] S. Garfinkel, An Evaluation of Amazon’s Grid Computing
Services: EC2, S3 and SQS. Tech. rep., Harvard University
(2007)
[6] Rackspace Cloud, (http://www.rackspacecloud.com, 2009)
[7] R.S. Montero, (Open Source Grid and Cluster Conference,
Oakland, CA, 2008)
[8] OCCI Working Group, (http://occi-wg.org, 2009)
[9] Microsoft Azure, (http://www.microsoft.com/windowsazure,
2010)
[10] NewServers, Inc, (http://www.newservers.com, 2008). URL
http://www.newservers.com
[11] libcloud.org, (http://libcloud.org, 2009)
[12] Dasein Multi-cloud API, (http://dasein-cloud.sourceforge.net,
2009)
[13] Xcalibre, Inc, (http://www.flexiscale.com, 2008)
[14] R. Perrott, T. Harmer, R. Lewis, Computer 41(11), 67 (2008)
[15] T. Harmer, Cluster Computing 10(3), 277 (2007)
[16] T. Harmer, J. McCabe, P. Donachy, R. Perrott, C. Chambers,
S. Craig, R. Lewis, B. Mallon, L. Sluman, in SCC ’05:
Proceedings of the 2005 IEEE International Conference on
Services Computing (IEEE Computer Society, Washington,
DC, USA, 2005), pp. 35–42