ElaaS: An innovative Elasticity as a Service framework for dynamic management across the cloud stack layers

Pavlos Kranas Distributed, Knowledge and Media Systems Laboratory

National Technical University of Athens Athens, Greece

e-mail: pkranas@mail.ntua.gr

Vasileios Anagnostopoulos Distributed, Knowledge and Media Systems Laboratory

National Technical University of Athens Athens, Greece

e-mail: vanag@mail.ntua.gr

Andreas Menychtas Distributed, Knowledge and Media Systems Laboratory

National Technical University of Athens Athens, Greece

e-mail: ameny@mail.ntua.gr

Theodora Varvarigou Distributed, Knowledge and Media Systems Laboratory

National Technical University of Athens Athens, Greece

e-mail: dora@telecom.ntua.gr

Abstract—Nowadays the general interest on Cloud Computing as a technical and business solution is growing. The pool of available cloud applications, services and platforms is increasing leveraging new features for the cloud assets provisioned to the end user. This massive amount and divergence of cloud features across the cloud stack layers introduces considerable management overhead to the various stakeholders for the effective management of both the offered products and the system itself. In this paper we focus on the challenges arise for providing dynamic elasticity management as one the fundamental features of Clouds. To this direction, we introduce the concept of Elasticity as a Service and present a generic, service-oriented framework capable to fulfill, in a personalized manner, the elasticity management needs of any cloud environment and cloud-enabled application.

Keywords-cloud computing; elasticity; scalability; monitoring; quality of service

I. INTRODUCTION Cloud computing [16] is best known nowadays for its

ability to enable effective use and access to large pools of resources and services that are virtualized and dynamically provisioned to adjust to variable workloads and usage optimization. This pool of resources is typically exploited by a pay-as-you-go pricing model [1] with the cost of using a cloud asset depending on the resources consumed. To this direction, cloud computing offers mechanisms to automatically scale applications in order to meet the user's needs, thus making possible for the users to rapidly adapt their resources to the workload minimizing the cost of overprovisioning.

Scalability is the need to marshal resources in such a way that an application continues running smoothly even as the number of users grows [4]. Basically two approaches are used to make new resources available [3]: Vertical and Horizontal scalability. Vertical scalability (scale up/down) increases or decreases the resources of a specific element in

the system; typically by changing the CPU number, adapting the memory or bandwidth of a single Virtual Machine (VM). Horizontal scalability (scale out/in) replicates (or removes) instances of system elements (typically VMs) to balance the load. Horizontal scalability usually requires also the addition of another component that has the role of the Load Balancer (LB). Elasticity on the other hand, is the ability to scale an infrastructure on demand within minutes or even seconds, instead of days or weeks, thereby avoiding under-utilization and over-utilization of in-house resources [13]. Systems have to autonomously execute predefined scalability actions to fulfill the contracted performance requirements with the minimum of resource demands. The mechanisms and workflows that are used by the system to fulfill elasticity as well as the evaluation criteria and the decision-making process itself varies from one system to the other or from one application to the other, even in the same system. Several approaches to trigger corrective actions by the elasticity mechanisms are possible. On one hand the observation of the external performance parameters, e.g. response time, may be implemented, or on the other the observation of the allocated resources. Both are reactive approaches where a “violation” of a given threshold has to occur before the system reacts. Predictive approaches may also predict future violations based on predictive-performance models and load forecasts [25].

Forrester defines an elastically aware cloud platform as a platform that automates elasticity of application transactions, services, and data, delivering high availability and performance using elastic resources [19]. To this end there should be no need for an application provider to make estimations on the expected workload, since he can always deploy the application on the cloud and let the system allocate the required resources accordingly. According to [5] cloud platforms can add significant value to enterprise IT by rapidly delivering application solutions to business partners. In this sense, applications can scale easily with respect to the

2012 Sixth International Conference on Complex, Intelligent, and Software Intensive Systems

978-0-7695-4687-2/12 $26.00 © 2012 IEEE

DOI 10.1109/CISIS.2012.117

1042

current workload and the rules specified by the provider, without the need to reconfigure and redeploy manually the services to new VMs. In addition the application provider is charged only for the exact resources needed for the application at any given time which minimizes the total operational cost for the application. After a peak load, the elastic platform will decrease the allocated resources accordingly, releasing the unnecessary VMs. As a matter of fact, he can confront unexpected peak loads, being available at any time, while on the other hand continue paying for exact the resources it uses, without investing on duplicate hardware that will be unused during the majority of the application's lifecycle.

In this paper we present an innovative framework that provides elasticity capabilities to cloud environments. With respect to the Service Oriented Architecture (SOA) paradigm, our approach is implemented as a loosely coupled set of web services, being easily deployed to any cloud platform that can react on dynamically defined requirements coming either from the system or the user of it. We name our solution Elasticity-as-a-Service (ElaaS) due to the fact that the offered functionality is provided "as-a-Service" to any cloud infrastructure, platform or cloud-enabled application, enabling dynamic management across all layers of the cloud stack. The proposed framework can be considered as another cloud application that can be consumed by other applications to provide elasticity functionality and evaluating the operational status of the application and triggering corrective actions when required according its configuration. It is a generic solution, allowing any party to make use of its capabilities in order to implement its own scalability engine evaluation and resolution methodology and/or process. It is also distributed and multi-tenant, with the ability to be adjusted to the specific requirements of any user, application or platform.

The remainder of this paper is structured as follows: Section II describes our motivation for developing this framework and section III presents the related work that solves the problem of elasticity in cloud platforms. Section IV presents the ElaaS concept and the basic design principles; while in section V the main architecture is being analyzed. Section VI describes the innovations coming from our solution. The main outcomes of the proposed solution are discussed in section VII and finally section VIII concludes our work.

II. MOTIVATION Today, one of the biggest barriers regarding cloud's

elasticity is the fact that current applications cannot take full advantage of the elastic infrastructure capabilities [12]. There are two common approaches on how to scale efficiently. The first approach is based on rule criteria, defined by the application provider, while the latter provisions application resources statically in order to identify the ordinary traffic load, and to investigate how often load-peaks occur. In sequel, it specifies rules, which are being submitted to the platform in order to orchestrate its use and take the appropriate corrective actions when needed. The basic disadvantage of these approaches is that they implement the

scaling capabilities according to what the platform can offer and not considering the application's needs.

Another approach is to rely on the platform's scalability engine itself, thus making use of the generic-purpose APIs that are being exposed by the cloud provider. However, the limit of this approach is that the scaling is designed to meet the platform's specific components' needs, which is not always appropriate for any kind of application. As a matter of fact, the service provider can take advantage of the existing scaling mechanism; however the triggered actions are not always optimized for each application.

According to Berkeley’s view [2], one of the major obstacles to the growth of cloud computing is the lack of dynamic scalability. So how can we actually be sure that our application will scale appropriately, taking full advantage of the platform's capabilities, for any traffic load at any given time? The proposed framework is totally generic, relying on both reactive or predictive approaches about how to enable elasticity changes, while it takes corrective actions based either on a rule-based resolution engine, either on machine learning or neural networks technologies in order to direct the platform on how to scale, allowing the user to select the solution that fits best to its needs. It is decoupled, abstracting the underlying cloud infrastructure so that the user can only focus on his particular application with no need to take into consideration the platform's limitations. Moreover, our framework is making use of the underlying platform's services -not limiting to a specific platform- which ensure appropriate load balancing of the incoming requests, data replication and rebalanced services and data in order to scale effectively. It also relies on the underlying monitoring service in order to provide the necessary input to the scaling evaluator, and on the accounting and billing services to check if the proposed actions are feasible and acceptable with respect to predefined SLAs.

III. RELATED WORK Elasticity is a central concept in cloud computing

environments although it can be implemented by vendors in various ways and in different degrees. Amazon EC2 [1] allows vertical scalability of a VM by the customer in order to fit the instantaneous resource requirements. The customers can change the resource requirements of a VM but in order to achieve horizontal scalability it is necessary to create a cluster of VMs and configure them according to his needs. This is a truly manual process that does not include the application configuration of a VM with the possible exception of running exactly the same application bundle as the other virtual machines in the cluster. Amazon EC2 facilitates the allocation and preparation of the VM but not the automatic configuration which is a requirement for a truly elastic aware cloud platform.

Google App Engine [11] is a platform for traditional web applications hosted in Google-managed data centers. It provides the same privacy, security and data protection services that are applied to all Google's applications. It also handles the deployment, monitoring, failover and launching service instances as necessary, making use of the Google's core engine. Due to this, automatic scalability is transparent

1043

to the application providers. There is no capability for a developer to write his own rules for scaling, depending on his application specific needs. Instead he has to rely only to the Google's automatic scaling engine.

Microsoft’s Windows Azure [23] platform on the other hand, consists of three main components that provide a specific set of services to cloud users, namely windows based environment for running applications and storing data, data services based on the SQL server and distributed infrastructure services that provide single identity verification across applications. The latter helps an application to register its services on a Service Bus, allowing them to be accessed by other applications whether on-premises or in the cloud. Azure offers specific virtual machine instances with predefined size in terms of CPU cores and memory. Automatic scaling is offered in terms of application rules via a configuration file specified by users. Azure's fabric controller monitors the VM instances, and whenever there is a recession on traffic load, it may switch to a smaller instance, thus scaling down the application.

Cloud Foundry is the open platform as a service project initiated by VMware. It can support multiple frameworks, multiple Cloud providers, and multiple application services all on a Cloud scale platform [6]. Scalability is supported by the number of instances of one application. The user can define how many instances should be created initially and he is also allowed to modify this number during runtime. The available resources for a running instance cannot be modified. This can be attributed to the fact that it does not include scaling rules or pricing. Although is developed with the use of a software PaaS platform, the applications are not automatically elastic and an automated scaling could be implemented only by the developer of the application himself.

RightScale [18] is a web-based application management platform for IaaS Clouds, assisting the user in designing, deploying and managing complex applications on a number of underlying IaaS Clouds. Automatic scaling is implemented on top of monitoring and alerting. Firstly, RightScale provides performance monitoring and then, on top of the monitoring service, users can define alerts for any monitored metric. Alerts typically do not trigger a scaling action. Instead, RightScale supports a voting system. Every single entity (i.e. cluster members, load balancer or any other related entity) votes for horizontal scaling. Other alert and scaling action parameters are defined by the application provider. This is a reactive approach: any performance metric can trigger scaling actions, as customized by the user.

Instead of emphasizing directly elasticity in the resource level, Salesforce stresses the multi-tenancy aspects of its application. Force.com [8] is Salesforce's main PaaS that can be used to develop applications. The main offerings that are of concern in terms of elasticity/scalability are the provisioning of database objects and storage capacity. Other parts of the offering are not of concern here. The fact that their database is internal (and multi-tenant) is reflected by the fact that only higher level resources are exported to the end user. On the other hand, the low level resources are not described, since they are not of concern. Force.com changes

the offering limitations according to the plan purchased. For this reason the offering cannot be described as elastic.

IV. DESIGN PRINCIPLES & PLATFORM CAPABILITIES

A. The aaS concept for elasticity Each application deployed over a cloud execution

environment consumes resources in three levels: IaaS resources (CPU, memory, and network), PaaS resources (VMs, software products, platform software) and SaaS resources (application artifacts, other services). The reservation, deployment, release, monitoring and pricing of these resources is functionality of the cloud environment itself. However, it is not clear whether the scaling of these resources to meet application load is inherent in the cloud environment. This can be attributed to the fact that the cloud environment should implement a scaling rule for every product and every artifact that exists or will be included in the system. This is cumbersome and the composition of an elasticity strategy from individual scaling rules is not necessary optimal for every setup. For this reason recent PaaS platforms try to overcome the elementary elasticity based on IaaS KPIs either by delegating the elasticity strategy to the client or by restricting the possible products available by the PaaS. However a solution that allows the dynamic scaling of an application remains elusive in the general case. For this reason elasticity is more suitable to be implemented as a SaaS application with deep insight on both the execution environment and the executing application. For this reason it is a system utility that can be provided as a service with many alternatives offered by different vendors. The ElaaS solves many problems elegantly:

• The system provides a series of interfaces to its different components allowing generic service development. This facilitates the development of platform or alternative ElaaS offerings. It is also generic enough in order to avoid imposing a specific elasticity strategy but providing mechanisms to implement optimized strategies for SaaS specific offerings.

• The SaaS provider can evaluate different ElaaS offerings to meet SLAs and decrease operational costs. If the elasticity strategy is included in the platform, specific issues of trust arise. For example there is no other measure of comparison for the scaling action. This situation is familiar. The Windows OS uses a defragmentation utility. However the efficiency can be evaluated because of popular alternatives that can be installed and used. For this reason the user is not restricted in any way. This is possible because of the interfaces exported by the system. All the defragmentation utilities use the same mechanisms but implement different policies.

• One other problem that is elusive in other approaches is the fact the elasticity strategy is unavoidably multi-tenant. For this reason it consumes a great deal of resources that is expected to increase when more complex and more resource saving strategies are deployed. For this reason the

1044

scaling of this application is problematic if it is introduced in the system. However if it is a deployed SaaS, it can be scaled as every other SaaS and in this case it can scale itself by making scaling calls to the underlying platform. In this respect it can also offer efficient pricing to its users and be distributed at the same time.

• ElaaS can be an imported service to the specific platform where a SaaS is running and for this reason it can run on another vendor’s platform or on a private cloud but by using the generic platform interfaces it can achieve its goal. In this case a web-service implementation is the most appropriate.

B. Required execution environment capabilities In order to create an ElaaS offering deployed on a

specific PaaS, the platform must provide various interfaces possibly implemented in the form of a web service. Central to ElaaS is the concept of deployment graph. An application can be coarsely described with a graph of dependencies. For example an online shop running over a specific PaaS could be described as a set of required software products and a set of required service references. More specifically, it can be defined as a .war file that runs in a GlassFish application server [10], using a MongoDB [14] for persistence and consuming a Google Analytics service. We call this high level set of dependencies, the “application graph”.

Figure 1. a) Aplication and b) Deployment Graphs

When the application is deployed on the cloud execution environment this coarse graph is transformed to a finer graph, “the deployment graph” that records its selection of IaaS products, software products and instances of them. Figure 1 displays the diagrams corresponding to the example above. In this figure, the providers of the VMs are not shown but they could be different. The software/virtualized router shown signify the existence of an IaaS provided network. In case of different vendors, it is expected that different subnets are necessary. An application providing ElaaS functionality should be able to identify possible evolutions of the deployment graph in order to meet SLAs. Within all the possible evolutions, application and product constraints could filter out a subset and for this reason a feasible deployment graph could be communicated to the PaaS for deployment. For security reasons only changes to the number of instances and the amount of resources should be possible and these changes should be communicated to the PaaS with a suitable interface. As it is obvious from the above discussion, there are two instances of the deployment graph. One residing in the ElaaS application and the other residing in the PaaS. The ElaaS can retrieve the deployment graph from the PaaS and then it can communicate feasible updates to the latter. It is obvious that the product instance/resource evolution constraints should be accessible from both, through a product descriptor repository. This repository should provide the increase/decrease actions for the resources consumed and instances of the product. It should be possible for both the PaaS and ElaaS application to retrieve the SLAs pertaining to the specific user and application. This way PaaS can validate the feasibility of the updates and the ElaaS can filter out non-compliant evolutions. The ElaaS application should be able to access the KPIs of the nodes (products and instances) of the deployment graph in order to decide on graph evolutions. For all the above reasons, suitable interfaces should be provided by the PaaS layer.

V. ELASTICITY AS A SERVICE FRAMEWORK ARCHITECTURE

A. Architectural Design The architecture of ElaaS framework is following

service-oriented design in order to a) allow for decoupling its functionality from the cloud platform and infrastructure capabilities, b) enable interoperability and smooth integration with any Cloud system and c) support multi-tenant operation.

In that sense, ElaaS is designed and implemented as a set of services deployed on the Cloud, which, based on the notion of multi-tenancy, are initialized and configured independently for each user/application elasticity request. Each service component offers specific base functionality which can be adapted and extended to enable advanced features such as the usage of a specific evaluation methodology or the communication with external monitoring sources. The overall architecture of ElaaS is presented in Figure 2:

1045

Figure 2. ElaaS Components

The ElaaS framework consists of five components: ElaaS Core, Application Manager, Monitoring Manager, Business Logic Manager and Action Manager. Its lifecycle consists of three distinct phases: a) Initialization, b) Runtime and c) Clean-up. The components and its role in each phase are explained in the following sections.

B. ElaaS Components 1) ElaaS Core

The role of ElaaS Core component is to coordinate the activities and processes taking place in all operational phases (initialization, runtime and clean-up). It is the only component of the proposed framework that is not extendable and cannot “load” plugins to provide additional or special functionality. During the initialization phase, ElaaS Core relays the appropriate initialization and configuration parameters to the rest ElaaS components, establishes the required communication channels between them (endpoints and message types) and create any data repositories that are required. During runtime, ElaaS Core monitors the smooth operation of the system and enforces any configuration changes posed to the other components, while in the clean-up phase the components are de-configured for the specific user/application (since the ElaaS supports multi-tenancy) and the storage resources are released.

2) Application Manager Application Manager is responsible for acquiring and

analyzing the user and application related information during the initialization phase. Typical types of information are the Application Deployment Graph, the products that is composed of, the SLAs and the KPIs that are monitored. This input is examined by the Application Manager and forwarded though ElaaS Core to the appropriate system components. Depending on the application type, this component can be configured so as to communicate with the appropriate cloud platform services to obtain and be able to understand any type of information that is required for the effective operation of ElaaS for the given user and

application combination. For instance, though Application Manager, ElaaS can be configured to query the respective platform services for alternative deployment options or Product Elementary Scaling Options and Actions which will be exploited from the Business Logic for advanced decision-making on the application’s elasticity management.

3) Monitoring Manager Monitoring Manager is in charge of the communication

with the monitoring sources. These monitoring sources can be the typical monitoring subsystems of the platform or the infrastructure as well as application specific monitoring APIs for acquiring application specific information e.g. number of users, frames per second etc. The Monitoring Manager component will be initialized and configured to consume only the necessary information based on the KPIs of the application. In addition it will be able to handle specific events indicating misbehavior or failure of the application elements and relay the aggregated information to the Business Logic layer to decide on potential corrective actions. Modern evaluation mechanisms require past information for making improved predictions on application performance characteristics and resource requirements. In that sense the Monitoring Manager can be configured to store KPI data with different history lengths (as a whole, aggregated or related only with specific KPIs) and make it available to the Business Logic layer. A Monitoring Repository is implemented for that purpose and is enabled ad-hoc. During runtime, the data from the Monitoring Repository stored possibly in an in-memeory datastore are combined and refreshed with the real-time events and monitoring information for personalized actions.

4) Business Logic Manager The Business Logic Manager is the decision making

component of ElaaS Framework. Focusing on the dynamicity and extendibility, Business Logic Manager follows a pluggable architectural design which allows for advanced configuration. The business logic itself is not included by default in this component and is “loaded” ad-hoc as an extension based on the specific requirements of each application. The mechanisms and methodologies for evaluating the status of cloud-based applications vary and follow different approaches, from rule-based to artificial neural networks, and therefore is not possible to include all these in ElaaS. For this reason it can be accessed as primitives through third party web services, application packages or even plugins. Business Logic Manager is initialized with the mechanism and methodology that will be used, either as executable code that will run within an execution sandbox in the component or as a third-party service, and the appropriate elementary scaling actions for each product of the application. During runtime, the aggregated monitoring information is communicated to the Business Logic to decide on corrective actions that may be required to guarantee the required performance and QoS level for the application. The pool of corrective actions consists of a) application specific actions which are defined in the initialization and b) generic elasticity actions supported by the cloud platform and infrastructure layers. As

1046

soon as a corrective action is decided, a message is communicated to Action Manager.

5) Action Manager The role of the Action Manager is to relay the action

messages to the appropriate components of the application and/or platform. This process requires an intermediate step to prepare these messages based on the configuration during the initialization phase and the action decided by the Business Logic Manager. For instance, if the Business Logic Manager triggers an action for replicating the single instance of an application server, the Action Manager will produce the new deployment graph, with the new virtual machines that are required, a load balancer and the network links and forward it to the cloud platform.

C. ElaaS Phases In initialization phase ElaaS acquires all required

information from user and the cloud platform and in sequel the components are configured. Even though the overall initialization process is coordinated by the ElaaS Core, each component analyzes the initialization parameters to ensure that the configuration is valid before applied. During this phase, the components, based on their role in ElaaS, communicate with the cloud platform and/or other external sources to acquire additional input, such as the deployment graph from the platform using the application/user ids. In addition they may establish persistent communication with third-party services i.e. with monitoring mechanisms or application dedicated evaluation tools.

The runtime phase is described in the following sequence diagram:

Figure 3. Runtime Sequence

During runtime, the ElaaS framework and more specifically the ElaaS Monitoring Manager is capable to interpret specific Cloud and application parameters based on the KPIs defined in the user’s elasticity request. In addition,

the framework is able to react on particular event, and in sequel on that, aggregate all the required information, as defined in the initial configuration, and push it to the Business Logic Manager for evaluation. This information may include historical performance or behavioral data which are exploited for more effective decision-making, e.g. in cases where time-series algorithms are implemented. The Business Logic Manager, can either use a model “loaded” in the framework or communicate with third-party evaluation mechanisms. The outcome of this process is a list of actions that should be performed to realize elasticity management. These actions may include dependencies and an additional step is required before they are applied to the cloud and the application. An example for that is the replication action of a single-instance application server, which requires the deployment of an additional element with the role of load balancer in the deployment graph. The final preparation and formulation of these actions, as well as triggering them, to the respective actuators is responsibility of the Action Manager.

VI. ELAAS INNOVATIONS In the proposed framework for elasticity management

cloud environments, there are a significant number of innovations that can be identified. First of all, one of its most innovative characteristic is that decouples the framework from the core business logic engine. ElaaS is designed to be pluggable and extendable to any third party’s elasticity mechanism. It offers a well defined set of interfaces that can be implemented by anyone who wants to offer scalability capabilities. In this sense, one could implement a neural network to predict traffic peak loads and suggest corresponding solutions, then adapt it to our proposed framework and deploy it to a compatible platform provider. Another enabler’s offering could be relied on machine learning technologies. There is always the capability for an application provider, to define their own rules for scaling, implement a custom rule-based system and plug it to the ElaaS. The only requirement is to implement the exposed interfaces.

Our framework is also designed to support different types of multi-tenancy [17]. There can be an instance of the ElaaS that serve a number of applications, and at the same time, different instances of the same framework, differently initialized that are suitable for other types of applications. For example, during the first time ElaaS is initialized to serve product A. The same instance could serve also the product B. The application manager component will only have to pass the product B’s specific parameters (KPIs, SLAs) to the ElaaS core component, so that the latter could correlate them with the corresponding monitoring data, forward them to the business logic engine, and scale accordingly. In this case, the same instance serves more than one products. If there is the need for another product C to exploit different business logic engine capabilities, then a new instance of the same ElaaS framework could be deployed, configured and begin to scale. It is also worth to mention, that the ElaaS framework can make use of its own

1047

elasticity mechanisms to scale itself, thus being able to serve an ideally infinite number of applications.

Additionally, our proposed solution can support multiple and custom monitoring sources (application specific or generic ones) and ad-hoc custom corrective actions and evolution graphs, thus extending the scaling options that a typical elastically aware cloud platform could offer. The problem of mapping application parameters with specific infrastructure metrics is well known [9], [24]. Our framework not only confront this by letting the application provider to define its own application parameters and implement its own resolution engine based on those, but also to monitor whichever type of parameter. Let’s assume a supportive application for a stock market. The application provider may expect an increased traffic load every time a stock price exceeds an upper limit. He could implement a custom monitoring system taking sources directly from its supportive application and configure the ElaaS framework accordingly, in order for the monitoring manager to consume these data feeds. Then, its custom business resolver could exploit this information and trigger corresponding scaling actions. As a matter of fact, the ElaaS can take into consideration the business aspects of the deployed application and it is not limited to the technical runtime parameters.

Another important innovation is that our framework is totally generic, thus it is not tightly coupled to a specific application or platform infrastructure. It can be adapted to every platform that ensures the required execution environment capabilities, as described at the relevant section. Additionally, it can provide elasticity mechanisms to multiple products, supporting distributed and multilayer application architectures. For instance, a target application may be consisted of a war file running on an application server, using a typical database and consuming external third party’s services. The database and the external services can be hosted either on the same platform provider or on different ones. Whatever the case, the ElaaS can scale the application as a whole, taking into account application specific parameters, or there can be different configurations on each application’s components, taking into account the component’s specific characteristics.

Due to the fact that the ElaaS is deployed as another cloud application, it can also support persistent storage for monitoring data and scalability models. It could later make use of those in order to predict future traffic peaks, or use the existing models for similar types of applications. Its multi-tenancy capabilities allow for sharing this information between users that use the same products. Given the support for distributed application architectures, a service provider may benefit from the experience gained from previous uses of a specific application component.

VII. DISCUSSION AND FUTURE EXTENTIONS Our proposed architecture tackles the problem of scaling

horizontally or vertically a given deployment graph. We do not investigate the equally important problem of product vendor changing. Central to this problem is the requirement that some of the products can change vendor in order to

enjoy cost benefits or move VMs and network elements in and out of a private cloud (federation). The complications arise because small changes can create big graph changes (instability) and unpredictable hidden performance variations even in the simplified investigation of this work certain problems arise.

The biggest of these problems is the description of instance increase or decrease. This problem is equivalent to the problem of decrease or increase of product instance by one. As we have already seen, a product instant increase can be accompanied by other product increases, like network links, deployment of extra VMs and the introduction of a load balancer among others. Moreover the resource assignment of a VM is not necessary linear, but there are different “sizes” which the user, fortunately, can navigate by unit increases or decreases. A first step in the description is shown in the product description in Figure 1. However in deployment time, late binding of variables like port numbers and deployment precedence is necessary. A system of this kind already exists in preliminary form and was formerly called Configuration Description, Deployment, and Lifecycle Management (CDDLM) [20]. It has attracted little interest in the past but it reappeared recently as SmartFrog [15] in an enhanced incarnation accompanied with a reference implementation. The necessary extensions are not described in the present work but it is the aim of a forthcoming publication.

Another typical question that arises from ElaaS applications is that of security [21][7]. Typically when a contract with an ElaaS provider is terminated, access to the deployment graph and KPI subscriptions must be invalidated. There is also the problem of secure access for the third party in order to scale a deployment graph that possibly manages sensitive data. Different attacks can increase considerably the price of the service or destabilize service provisioning of the client by executing rapid elastic actions. This is also an interesting problem common to all exported services for third party consumption by the PaaS.

The business logic encapsulated in the ElaaS is also a vast subject in its own respect. Different ways of scaling a graph based on KPI knowledge could be designed. Others are based on machine learning techniques like manifold learning, modeling techniques like non-linear parametric modeling and rule based system with artificial intelligence AI extensions. Methods to assess the effectiveness and the suitability for a deployment graph are necessary. What makes the problem more difficult is impossibility the simulation of offered traffic and the resulting resource consumption for a general deployment graph. For this reason, real deployments serving considerable usage loads should be examined. This also proves to be difficult because of the sensitivity of data carried by such deployments. However the generality of our approach allows the business logic to be controlled directly by a user. In other words the monitoring of the deployment and the deployment graph modifications could be done directly by a user through a suitable graphical user interface. We believe this is what makes the ElaaS a killer cloud application though as PaaS mature this control could be also automated.

1048

VIII. CONCLUSIONS In this paper we presented a new generic solution for

addressing the elasticity aspects across all layers of the cloud stack. The proposed concept of Elasticity as a Service realized in the ElaaS framework is capable of providing elasticity management for applications and/or cloud platforms and infrastructures in a transparent and decoupled from the cloud approach. Being generic, but also extendable and independently configurable for each user/application request, ElaaS is able to cover the elasticity management needs of any existing or future cloud environment. An ElaaS prototype is implemented in the frame of 4CaaSt EU project and shortly an open source version will be made publicly available for use by the research community. This prototype focuses on the evaluation of the ElaaS APIs which will be used for the configuration of each ElaaS component and for the development of plugins extending its functionality.

ACKNOWLEDGMENT The research leading to these results has partially

received funding from the 4CaaSt project (http://www.4caast.eu) from the European Union’s Seventh Framework Programme (FP7/2007-2013) under grant agreement no. 258862. This paper expresses the opinions of the authors and not necessarily those of the European Commission. The European Commission is not liable for any use that may be made of the information contained in this paper.

REFERENCES [1] Amazon EC2: http://aws.amazon.com/ec2/ [2] Armbrust, Michael, Armando Fox, Rean Griffith, Anthony D. Joseph,

Randy Katz, Andy Konwinski, Gunho Lee, David Patterson, Ariel Rabkin, Ion Stoica and Zaharia, Matei (2009). Above the Clouds: A Berkeley View of Cloud Computing. UC Berkeley Reliable Adaptive Systems Laboratory.

[3] B. P. Rimal, E. Choi, and I. Lumb. A Taxonomy and Survey of Cloud Computing Systems. Fifth International Joint Conference on INC, IMS and IDC, pages 44–51, 2009

[4] Brian Hayes. Cloud computing. Communications of the ACM, (7):9–11, July 2008.

[5] Cheng, D.: PaaS-onomics: A CIO’s Guide to using Platform-as-a-Service to Lower Costs of Application Initiatives While Improving the Business Value of IT. Technical report, Long Jump (2008)

[6] Cloud Foundry: http://www.cloudfoundry.org/ [7] D. Owens, “Securing elasticity in the cloud,” Queue, vol. 8, no. 5, pp.

10–16, 2010 [8] Force.com: http://www.force.com/ [9] George Kousiouris, Dimosthenis Kyriazis, Spyridon V. Gogouvitis,

Andreas Menychtas, Kleopatra Konstanteli and Theodora A. Varvarigou, "Translation of Application-level Terms to Resource-level attributes across the Cloud Stack Layers ,", Computers and Communications (ISCC), 2011 IEEE Symposium on , vol., no., pp.153-160, June 28 2011-July 1 2011

[10] Glassfish Application Server: http://glassfish.java.net/ [11] Google App Engine: http://code.google.com/appengine/ [12] Jeffery K, Schubert H and Neidecker-Lutz B, “The Future for Cloud

Computing: Opportunities for European Cloud Computing Beyond 2010”, Expert Group report, public version 1.0, January 2010.

[13] Jeremy Geelan. Twenty one experts define cloud computing. Virtualization, August 2008.

[14] MongoDB: http://www.mongodb.org/ [15] P. Goldsack et al., “The Smartfrog Configuration Management

Framework” ACM SIGOPS Operating Sys. Rev., vol. 43, no. 1, 2009, pp. 16–25

[16] P. Mell and T. Grance, NIST Definition of Cloud Computing, Version 15, 2009, available online at: http://csrc.nist.gov/groups/SNS/cloud-computing

[17] R. Mietzner, T. Unger, R. Titze, and F. Leymann, “Combining Different Multi-tenancy Patterns in Service-Oriented Applications,” 2009 IEEE International Enterprise Distributed Object Computing Conference, pp. 131–140, 2009

[18] Righscale: http://www.rightscale.com/ [19] Rymer J., Gualtieri M., et al, "Cloud Computing Brings Demand For

Elastic Application Platforms", Forrester, April 2011 [20] S. Loughran et al. Configuration Description, Deployment, and

Lifecycle Management (CDDLM) Deployment API. Grid Forum Document GFD.69, Global Grid Forum, March 2006

[21] Subashini, S. and Kavitha, V., 2011. A survey on security issues in service delivery models of cloud computing. Journal of Network and Computer Applications, 34, 1-11

[22] Vaquero, L., Rodero-Merino, L., Caceres, J., & Lindner, M. (2009). A break in the clouds: Towards a cloud definition. ACM SIGCOMM Computer Communications Review, 39(1), 50–55.

[23] Windows Azure: http://www.microsoft.com/windowsazure/ [24] Y. Chen, S. Iyer, X. Liu, D. Milojicic, A. Sahai, Translating service

level objectives to lower level policies for multi-tier services, Cluster Computing 11 (3) (2008) 299-311

[25] Z. Gong, X. Gu, and J. Wilkes, “PRESS: PRedictive Elastic ReSource Scaling for cloud systems,” in CNSM 2010, October, pp. 9 –16.

1049