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

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.

2011 Eighth IEEE International Conference on e-Business Engineering

978-0-7695-4518-9/11 $26.00 © 2011 IEEE

DOI 10.1109/ICEBE.2011.32

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.

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.

330

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

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.

331

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.

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

332

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,

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

333

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

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?OpenView&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.

334