2011 Eighth IEEE International Conference on e-Business Engineering
Application Centric Lifecycle Framework in Cloud
Kai Tang, Jian Ming Zhang, Chen Hua Feng
IBM Research China
Beijing, China
{tangkai, zhangjm, fengch}@cn.ibm.com
Abstract—Cloud computing is expected to provide powerful
and easy-to-use model for application design, development,
operation and maintenance. There are mainly two models of
cloud: IaaS and PaaS model. In IaaS model, application
developer and operator have the biggest flexibility for they can
control owned virtual machines and most resources totally, but
this model needs high technical skills in application
development and operation phase. PaaS model claims easy to
development, deployment and maintenance, but all these
advantage are based on the specific programming model and
application architecture. Migration to PaaS cloud for existing
applications usually brings big effort and cost increasing. In
this paper, we discuss the advantages and disadvantages of the
two models from enterprise class application developer angle.
Then present an application lifecycle model in which
developers could design, develop and deploy their application
or legacy systems without programming limitation and
migration effort. The application lifecycle model takes
application as the centric concept and supported by a set of
cloud platform tools. We discuss the application lifecycle
framework defined in this model, and then we discussed the
possible supporting cloud architecture.
Keywords-Cloud, Application Lifecycle, IaaS, PaaS
I. INTRODUCTION
Cloud carries expectation that provide IT delivery
services powerful, low cost, easy-to-manage new models. It
is anticipated that in 2015 about 75% IT infrastructure will
be delivered as a service from public, private or hybrid cloud
provider [1]. There are a lot of reasons for the population of
cloud, especially in enterprise service level. Enterprises
depend on businesses that need flexible IT infrastructure can
get benefits from some aspects such as: quick IT service
acquire; less deployment risk, lower cost, easy to scale
out/down; no special IT technical needed. Service provider,
who could be the enterprise IT department or external
strategy outsourcing service provider, can offer greater
process maturity and more effective services as well as
reduce invents in infrastructure and labor costs. In industry
there are many success stories in delivering both short-term
and long-term traditional IT services by cloud manner
[2][3][4].
We focus on applications that implements business
process or high value services to support enterprise class
customers. This kind of enterprise applications may serve
customers which have thousands or more employees or end
users, including mobile devices. This paper we focus on
cloud application provider who will be a main user group of
978-0-7695-4518-9/11 $26.00 © 2011 IEEE
DOI 10.1109/ICEBE.2011.32
Authorized licensed use limited to: b-on: Universidade Aberta. Downloaded on November 08,2020 at 12:29:34 UTC from IEEE Xplore. Restrictions apply.
cloud. Although there are many mature cloud services from
multiple cloud providers, most of clouds limit applications
with specific programming model and related technologies,
therefore application enterprise class cloud application
providers have to adopt different of technical challenges.
In this paper, we take a step towards understanding and
resolving some issues in cloud application lifecycle
management. Cloud application providers, who design,
develop and operate applications in cloud, have different
perspective to cloud providers. We try to model the cloud
application lifecycle from this angle and then establish a
framework for abstraction purpose. First we identify some
issues from the perspective of application provider: how to
migrate to cloud in design and development time; how to
deploy a complex application to cloud in configuration and
deployment time; how to operate and maintenance the
application to align with SLA; how to update the application
seamlessly. Second we discuss the definition of application
lifecycle management and related work. Next we present a
framework based on previous issues and related
implementation in industry. Finally, we proposed some
possible future research directions in this topic.
II. BACKGROUND AND PROBLEMS
Generally, IaaS (Infrastructure-as-a-Service) and PaaS
(Platform-as-a-Service) are the two main types of cloud. IaaS
means clouds that offer virtual hardware infrastructures such
as virtual machines, networks and storages [5][6][7]. On the
contrary, Paas refers to another abstraction level. PaaS
clouds provide an integrated environment of web containers
and database containers to simplify application deployment
and management by a set of online services and, usually,
local integrated development environment (IDE) for
supporting application design, developing and operation [8].
We will compare the two type of cloud in some application
lifecycle state.
A. Design, Development and Migration
For applications targets on IaaS cloud, there are almost
no limits in programming model and architecture decision.
Therefore existing applications running on datacenter can
migrate to IaaS cloud with small cost. PaaS cloud
PaaS clouds are targets on building applications in a
faster manner. Many PaaS product have deployed such as
Google App Engine (GAE) and Microsoft Azure [10][11].
To facilitate rapid application development, PaaS clouds
usually provide IDE in which automated code generator tool,
programming templates, local libraries, simulation running
environment or sandbox, and other related tools are included.
329
With these toolkits, user can develop application quickly if
the requirement is compliant with PaaS programming model.
However, for those applications built in other programming
model or have complex dependency with other services, it
will be difficult to migrate to PaaS cloud. For example, an
existing J2EE application will be impossible to migrate to
Azure without significant modification. Another example is
that common session in J2EE application is not supported in
GAE (alternative is to save in Google datastore named
_ah_session). Those applications using distributed session
need to change to new mechanism.
B. Deployment and Configuration
IaaS clouds provide greater flexibility to users than
traditional datacenter. For example, Amazon EC2 provides
elastic virtual machines to users [9]. Application providers
can deploy their applications onto cloud without significant
modification. The deployment steps in IaaS cloud are similar
to the traditional non-cloud practices, usually including
hardware (VM in cloud) and software select; operation
system (OS) installation; middle-ware and related service
installation; application provisioning; configuration; and
initial data loading. In traditional practices, there are many
manual actions in these steps. As an advantage of cloud,
automation is provided by IaaS provider to facilitate these
steps. However, deployment and configuration are often
completed manually. The root cause of deployment failure
may come from OS, middleware, online services or
application components so that certain system administration
and operation technologies are required.
For applications developed in PaaS programming model,
deployment and configuration are often completed in IDE
which provide simple manner based on a pre-defined
application deployment and behavior model and expose
limited parameters to user. Once user submits the application
to PaaS, deployment and initial data loading will be
completed automatically. The simplification accelerates
application deployment significantly.
C. Operation time
Most of IaaS clouds provide VM management
capabilities to users but lack of mechanisms for dealing with
application as a centric object. It makes IaaS can neither
consider the relationships between VMs which deployed
different application components, nor support the
relationship between different tiers of software. Application
provider must deal with infrastructure terms and resource
problems by themselves. For instance, most of simple J2EE
application has 3-tiers architecture in which the IP of
database server must to be known by web application server
thus the database server must deployed first and then
configure web container [12]. Although load balance service
has been provided by some IaaS provider, such as EC2, Luis
M. et al points out [12] that this mechanism is not sufficient
to support huge concurrent access because network is always
ignored and more important, load balancer (LB) tire need to
be scaled for one LB will cause latency when it need to
forward requests to huge number of VMs.
330
Authorized licensed use limited to: b-on: Universidade Aberta. Downloaded on November 08,2020 at 12:29:34 UTC from IEEE Xplore. Restrictions apply.
PaaS clouds tend to scale application in instances, both
in container and database instance level. Therefore, users can
focus on their application and components rather than on
resource problems such as setting up the environment and
request new resources. Unfortunately, in some cases, not
only container and database need to scale. For example,
Azure offers inter-component communication services, but
this work is equivalent elementary [12]. Once an application
deployed to a PaaS cloud, it is bound to the specific
platform, which is totally different from each other because
of totally different application behavior model. The
application scale policy can not used by other platforms. For
application provider, to get control of application runtime
instances is desire in some cases. For instance, when
concurrency increases, only some core components need to
scale-out to deal with users transactions, but other
components, such as email, scheduled automatic task, and
reporting are unnecessary to scale.
D. Updating
As deployment and operation time in IaaS cloud,
application providers have fully control of VMs so that
incremental updating is possible, no matter manually or
automatically. In this manner, traditional practices of
seamless updating can be leveraged.
On the other hand, for PaaS cloud, updating is always
supported by platform. For example, GAE allows application
provider upload several versions. Once the latest version is
ready, application provider can set it as the default version
which uses the static URI of the application. However, as a
comparison, in SQL Azure, updating needs a more
complicated process [13].
E. Summary
Based on the discussion above, we can conclude that
application has different lifecycle in IaaS and PaaS clouds. In
short, IaaS provide almost fully control of VMs but low
degree of automation. Hence application providers need
certain knowledge and technical in application deployment
and operation time. On the contrary, PaaS clouds provide
environments that limited in programming model but
effective in maintenance for users. Application providers can
develop and deploy application rapidly. However it is almost
impossible to migrate existing complex enterprise class
application to PaaS cloud.
Neither IaaS nor PaaS treat application as an centric
object in their core model. IaaS play with resources such as
VMs and network, while PaaS services are built on their
capability encapsulation. In the next section, we will discuss
the application lifecycle and introduce some related work.
III. APPLICATION LIFECYCLE AND RELATED WORK
Application lifecycle in cloud composed 5 steps: design,
development, migration, deployment, operation,
maintenance and withdrawing. This model assumes that the
application provider design and develop the application
before targets cloud platform is decided. Thus the model
covers existing application migration. For applications
designed and developed for specific cloud target, e.g.
application for GAE, the step of migration can be omitted.
Figure 1 is the lifecycle diagram which starts from design in
the left and ends to withdrawing in the right. For each step in
the model, there are sub-steps which will be discussed in
next section.
Figure 1. Application Lifecycle in Cloud
There are some related works in cloud application
lifecycle management. Terence Harmer et al presented an
application centric model based on a common API for IaaS
clouds [14]. The proposal built an abstract level of existing
IaaS APIs and treated the application as the centric concept.
All capabilities were focus on application behavior. But this
work only aimed at IaaS clouds and covered operation and
maintenance time.
Luis M et al discussed the scalability of application both
in IaaS and PaaS [12]. This document summarizes some
exiting works both in industry and academic area. How to
auto-scaling an application in cloud and key issues are
discussed in detail.
Kunwadee Sripanidkulchai et al explored the readiness
of cloud in perspective of individual users and enterprise
users. 3 key issues were identified in cloud readiness: how to
deploy large-scale distributed services, how to deliver high
availability services, and how to perform problem resolution
on the cloud. These issues are also important in cloud
application lifecycle. The authors pointed out some key
challenges in these areas and presented some potential
directions [15].
Inigo Goiri et al described a proof-of-concept
framework for facilitating resource management in service
providers, which allows reducing costs and at the same time
fulfilling the quality of service agreed with the customers
[16]. This paper outlines their commodity and application-
centric approach to resource management, and describes an
integration framework for cloud application management–
illustrating its use in a field deployed application and a
particular dynamic component within that application.
Resource management is the key concept of this work, it is
helpful for application operation and maintenance, but not
cover the full cloud application lifecycle.
IV. DETAIL IN APPLICATION LIFECYCLE
This section presents a application centric lifecycle
management framework for cloud application. Application
lifecycle management governs the creation and management
of cloud enterprise class application. The framework exploits
a model-driven approach which captures information in
models that can be used to automatically generate code and
configuration. With information about cloud application
captured in a series of model states, the model try to describe
331
Authorized licensed use limited to: b-on: Universidade Aberta. Downloaded on November 08,2020 at 12:29:34 UTC from IEEE Xplore. Restrictions apply.
software and other resource from infrastructure provider
information.
The principle model of our approach is the Cloud
Application Lifecycle Model (CALM). CALM captures
application specific model information. The following
subsections describe each steps of CALM in detail. We will
identify some key features of an “application-centric” cloud.
A. Application Design
This is the start of a cloud application. Once customer
requirement is confirmed, application provider can start to
design the functionality and fulfill non-function requirements
in architecture. If the application targets on specific cloud
platform, especially on a PaaS cloud, e.g. GAE, limitation
from cloud should be considered in the beginning. And this
kind of limitation will affect following steps profoundly.
In an ideal cloud, the architecture of cloud itself should
not affect application design. From application provider
perspective, programming model, application architecture,
component topology and other application features should
not become a barrier or limitation to migrate cloud.
B. Development / Migration
As the design stage, application providers should
develop their components using favorite tools and
technologies. For existing application, migration to cloud is
the main task in this step. There are tremendous literatures in
cloud migration. In this paper, we only focus on convenience
for application providers.
To ease development work, there are some technical
should be supported. Session is a typical feature in
transaction based applications and it should be supported by
cloud. Another important technology in cloud is multitenant,
which ensures the security and performance by isolation in
multiple tiers. For application provider, multitenant is
usually not considered in design and development stage, so it
is better to make the migration to multitenant-supporting
cloud transparently. For facilitates developments, an IDE
that integrates toolkits for helping developer implement these
features easily is required.
C. Deployment
In IaaS cloud, application providers deploy their
applications to web container which can be installed by VM
owners manually or has been installed with basic OS in VM
creation. Some third party tools help user to deploy
applications into specific middleware automatically. For
instance, Cloudcat [17] is a deployment service for EC2 and
GoGrid users. For PaaS cloud users, deployment is a very
simple process – in GAE, for instance, user can complete
deployment in IDE by only several clicks. However, as
discussed before, PaaS is not fit for application has complex
component deployment topology. In our framework,
deployment could be divided into several sub-steps as shown
in Figure 2.

Figure 2. deployment process
1) Select deployment in service catalog
Cloud deployment service catalog is a list of services
that can be provided using our approach. Each entry in the
catalog describes a service that will trigger some automation
process for application deployment. The target of our
approach is to support enterprise class applications, including
newly developed and existing applications. So the catalog
collects abundant services from basic IaaS services to
advanced PaaS services. These services comprise of, for
example, VM with basic OS selection and web container
cluster; simplest single application instance and virtual
private network. Table 1 lists some potential deployment
services in our approach.
Table 1. Potential Deployment Services
Service Name Description
Basic VM with OS Basic virtual machines with OS. No other software
installed. Support windows and Linux.
VM with OS + Middleware VM with basic OS. Some middleware are provided
for installation.
LAMP Linux + Apache + MySQL + Php
Single instance Only one VM with one web container instance, all
components will be deployed to the instance.
More powerful VM Live migrate a VM to more powerful instance
without shutdown.
DB Backup Backup database by setting up more database
instances.
Auto scale with limitation Allow user specify the maximum VM numbers in
web container level auto-scaling.
Complex application template Allow user to create deployment templates and
corresponding instances. A template is comprise of
a group of VMs, which specified OS, installed
software and topology diagram.
Web container cluster Create some VMs for the application. Each VM is
a node in the cluster.
There are mainly 3 types in the service catalog. First is
basic IaaS service. Like Amazon Machine Image (AMI)
service, there are plenty of images with different content and
user can create VM instances from them and deploy
application manually. Second is basic deployment service.
Based on an embedded application behavior model and
simple express, this kind of service provides user simple
parameters to configure the application deployment. With
database backup service, for instance, application provider
can set the number of backup database instance and backup
policies. The last type is advanced PaaS services. To
automate complex application deployment, based on basic
PaaS service, our approach also provides some advanced
services which combines or enhance some basic services.
Web container clustering is a typical example: with this
service, user can specify how much nodes in the cluster and
the topology relationship among theses nodes and http server.
332
Authorized licensed use limited to: b-on: Universidade Aberta. Downloaded on November 08,2020 at 12:29:34 UTC from IEEE Xplore. Restrictions apply.
Although there are some research works in helping user
select deployment services automatically [12], manually
selection is used in our approach for accuracy considerations.
Once a service has been selected by the application
provider, a corresponding deployment process will be started
for the application. The following subsections describe the
model information that is captured in each state of the sub
process and give examples of tools that are used to support
the transition between states.
2) Original resource estimation.
In this state, resource requirements are extracted from
functional and non-functional requirements in application
instance. A resource estimation tool now is invoked to
calculate the Resource Profile. Resource profile describes the
type and quantity of resources based on the application
provider knowledge. For example, a business intelligence
application which offers sales data mining and intelligent
recommendation is designed for supporting about 10000 end
users and most of user will occupy disk space under 10M.
The resource profile converts these estimation to resource
requirements to the platform.
3) Customer Usage Pattern Matched
Customer Usage refers to the resource requests for
application instance, e.g., creation, querying and migration.
This step is to predict customer behavior and map to certain
pattern. The purpose of prediction is to calculate the trend of
the application instance resource change, which is related to
customer behavior pattern. Application instance change trend
predicts the storage node, size, and throughput curves.
4) Resource Planned
The application instance is prepared to bind to virtual
resource pool in this step. The result is a plan or a template
for application instances and resource binding. To optimize
the resource allocation, during the resource planning, there
are some factors should be considered:
Application provisioning conditions will be specified in
this step depends on current resource usage in cloud.
Provisioning conditions, such as provisioning location, data
security level, and data query response time are critical to
application instance auto-scaling.
Application customer behavior pattern is treated as
optional but important conditions in this step. For example,
suppose the data mining tool predicts that a new customer
may migrate from trial to production in 1 week by reference
of similar customers, then, resources with production will be
booked for that customer in advance.
Prediction of resource trend of a certain physical server
should also be considered to avoid frequent VM live
migration which potentially causes severe network latency.
The monitor is also responsible for the prediction of servers.
The server resource trend prediction will compare to the
service instance trend to find the best storage nodes for
provision.
5) Server Bound
Resource plan of an application instance need to be
bound to a certain VM and physical server in the virtual
resource pool. The real-time monitor refines the allocation
plan with the binding to real resources, such as host, storage
node and network throughput. Here an optimize-dispatch
tool is invoked to binding refined plans to certain servers,
and then Service instance is ready to enter next state.
6) Provisioned
This is the final state of the application instance in the
provisioning process. End users then can be authorized and
access the data by related service.
D. Maintenance
Application maintenance means a group of actions to
ensure some key metrics of application as guaranteed. From
application provider angle, application is the centric object
rather than the cloud environment. So to maintain application
running well is the centric task in this step. Again, the
service catalogue is used in to collect all these services and
then deliver them to application providers. These services are
defined to provide service level agreement (SLA) to
application provider from application lifecycle perspective.
Here is some examples for application maintenance services:
auto-scaling, update patch management, health checking,
configuration management.
The deployment process discussed in previous section is
executed automatically (using PaaS level deployment
services) or semi-automatically (using IaaS level services).
Once deployed, the application topology effects what
maintenance service can be used. For example, it doesn’t
make sense to select “response time guarantee” for an
application has only one instance without auto-scaling policy
configured. Thus for application provider, what and how to
choose maintenance services is not simple as deployment
process. Our approach uses a service recommendation tool
which analysis constrains and dependencies from
deployment topology and configurations and then select
workable services to application providers.
Dynamic scaling is the major advantages brought by
cloud and the most important function for application
providers. Our approach pays much more attention on auto
scaling than other maintenance aspects. Although there are a
lot of scaling solutions and proposals in cloud domain, no
ideal scaling fit for both PaaS and IaaS cloud [12]. We uses a
rule based scaling policy in our framework and application
model which will be discussed in the next section.
E. Withdraw
Application need to withdraw from cloud when needed.
This step allows application provider release resources
selectively, so that important data could be stored in cloud
and other resources such as network bandwidth or CPU
could be released quickly to reduce costs.
V. CLOUD ARCHITECTURE SUPPORTING
We treat application as the centric concept in our
approach and build our framework based on it. The
following subsections describe the application model and the
framework in detail.
A. Application Model
Application model is shown in Figure 3. In this diagram,
we only put important parts: component, deployment model,
333
Authorized licensed use limited to: b-on: Universidade Aberta. Downloaded on November 08,2020 at 12:29:34 UTC from IEEE Xplore. Restrictions apply.
and maintenance model. Component refers to independent
deploy unit in our model which means that each component
of application can associate to a deployment model. For
example, beside the core business components, a CRM
application would have some other components that can
deploy independently, e.g. email, scheduled tasks, and data
synchronization.
A deployment model is an instance of a deployment
template which also called pattern and contains information
of how to deploy the application. There are 4 main sub-
objects of deployment model: VM, static IP, software stack
and topology. VM is a group of basic OS images that will be
used to create VM. Each VM instance will have an IP
address after initialization and one or more IP can keep in
static if necessary. Software stack is used to describe all
dependent software of the application, including web
container, database management system (DBMS), other
middleware and libraries. VM relationship and dependency
are recorded in topology, which will guide the VM manager
to create instances in correct order, and provisioning engine
to install software in appropriate way.
Maintenance model used to describe the cloud platform
how to maintain the application running instance. We use the
extended application scaling model defined in Open Virtual
Format (OVF) [10]. Key performance indicator (KPI), VM
instance, IP address and scaling rules are 4 main parts of the
model. For application provider perspective, KPI is used to
define and measure application performance. These KPAs
can be used to define maintenance rules. For example, to
define a rule that tell the cloud platform do not create more
VM instances if the maximum is reached, whenever the rate
of request is. VM instance and IP address here is the
collector of active instances and IP addresses used by the
application. Purpose of these two collector is feed to
application monitor to generate the real-time application
performance reports. To support Scaling rules are used to
automate the resource resize process of cloud platform. Each
rule contains one or more condition to be monitored. When
the conditions are met, the rule is triggered and then one or
more actions are executed [18].
Figure 3. Application model
B. Application Centric Lifecycle Framework
To support the application centric lifecycle, we present a
framework of cloud architecture. This framework can be
used as platform independent model (PIM) in model driven
method. This is an abstract architecture of cloud platform
and need to bind to certain cloud implementation. Cloud
management platform, cloud server and IDE for application
provider comprise the framework. Figure 4 is the
architecture diagram.
For design and development stage in application
lifecycle, IDE provider tools to help application provider
“cloudize” their applications (existing system migration or
create new systems aim to run on the cloud). Moreover,
application provider can deploy application to cloud by
default configurations in IDE for simplification purpose.
In the deployment stage, deployment model is used to
feed to deployment request manager, which starts the process
of resource estimation and allocation based on the topology.
With other deployment related services (shown in the left of
Cloud management platform part in Figure 3), cloud
platform creates VMs with dependency software installed.
Similarly, maintenance services support the maintenance
model of application model.
Figure 4. Architecture of Cloud Management Platform
VI. CONCLUSION AND FUTURE WORK
In this paper, we introduce an application centric
lifecycle with a supporting framework. With the reference of
the framework, cloud provider can provide a set of services
and tools rounding to application so that cloud application
provider can focus on their application rather than cloud
environment issues.
For a running application when the concurrency
increasing we need to scale out. Of course we can create
more application instances and load balancer (if necessary),
but it will be better if we only scale some components (e.g.
to scale out the message component). We will put our focus
334
Authorized licensed use limited to: b-on: Universidade Aberta. Downloaded on November 08,2020 at 12:29:34 UTC from IEEE Xplore. Restrictions apply.
on better scaling solution in the future research work as well
as better abstraction on different cloud platforms.
REFERENCES
[1] Gartner Research, June 2007, ID Number: G00148987.
[2] 2011 Introduction to Cloud Computing and Amazon Web Services.
http://www.slideshare.net/simone.brunozzi/2011-introduction-to-
cloud-computing-and-amazon-web-services
[3] Windows Azure Cloud Development Success Story,
http://www.outlookexchangeserver.co.uk/news12.html
[4] IBM cloud computing client success stories: http://www-
01.ibm.com/software/success/cssdb.nsf/solutionareaL2VW?OpenVie
w&Count=30&RestrictToCategory=corp_CloudComputing&cty=en_
us
[5] L. M. Vaquero, L. Rodero-Merino, J. Caceres, and M. Lindner, “A
break in the clouds: towards a cloud definition,” SIGCOMM Comput.
Commun. Rev., vol. 39, no. 1, pp. 50–55, 2009.
[6] (2010, Aug) Amazon auto scaling service. [Online]. Available:
http://aws.amazon.com/autoscaling/
[7] L. Rodero-Merino, L. Vaquero, V. Gil, F. Gal´an, J. Font´an, R.
Montero, and I. Llorente, “From infrastructure delivery to service
management in clouds,” Future Generation Computer Systems, vol.
26, pp. 1226–1240, October 2010.
[8] A. Lenk, M. Klems, J. Nimis, S. Tai, and T. Sandholm, “What’s
inside the cloud? An architectural map of the cloud landscape,” in
ICSE 2009: Proceedings of the 2009 ICSE Workshop on Software
Engineering Challenges of Cloud Computing, Vancouver, Canada,
May 2009, pp. 23–31.
[9] Amazon Elastic Compute Cloud (Amazon EC2).
http://aws.amazon.com/ec2/
[10] Google Application Engine . http://code.google.com/appengine/
[11] Microsoft Azure. http://www.microsoft.com/windowsazure/
[12] Luis M. Vaquero Luis Rodero-Merino Rajkumar Buyya, Dynamically
Scaling Applications in the Cloud, ACM SIGCOMM Computer
Communication Review, Volume 41, Number 1, New York, NY,
USA, January 2011, p45-52
[13] MSDN http://msdn.microsoft.com/en-us/library/ff487134
[14] Terence Harmer, Peter Wright, Christina Cunningham, John Hawkins
and Ron Perrott, An application–centric model for cloud management,
Services (SERVICES-1), 2010 6th World Congress on Service,
Miami, FL, USA, July 2010. p439-446.
[15] Kunwadee Sripanidkulchai, Sambit Sahu, Yaoping Ruan, Anees
Shaikh, and Chitra Dorai. Are Clouds Ready for Large Distributed
Applications? ACM SIGOPS Operating Systems Review, Volume 44
Issue 2, New York, NY, USA, April 2010. p18-23.
[16] Inigo Goiri, Ferran Julia, Jorge Ejarque, Marc de Palol, Rosa M.
Badia, Jordi Guitart, and Jordi Torres. Introducing Virtual Execution
Environments for Application Lifecycle Management and SLA-
Driven Resource Distribution within Service Providers. 2009 Eighth
IEEE International Symposium on Network Computing and
Applications. Cambridge, MA USA, Feb, 2009.
[17] CloudCat. http://www.mulesoft.com/cloudcat-apache-tomcat-cloud
[18] F. Gal´an, A. Sampaio, L. Rodero-Merino, I. Loy,V. Gil, and L. M.
Vaquero, “Service specification incloud environments based on
extensions to openstandards,” in COMSWARE ’09: Proceedings of
theFourth International ICST Conference onCOMmunication System
softWAre and middlewaRE.New York, NY, USA: ACM, 2009, pp.
1–12.