A Case Study for Deploying Applications on ...

A Case Study for Deploying Applications on Heterogeneous PaaS Platforms Eman Hossny, Sherif Khattab, Fatma Omara, Hesham Hassan Computer Science Dept. Faculty of Computers and information, Cairo University Cairo, Egypt {e.hossny, s.khattab, f.omara, h.hassan}@fci-cu.edu.eg

Abstract—Cloud Platform-as-a-Service (PaaS) model provides developers with the ability to deploy and manage their applications remotely through the cloud and pay only for actual usage hours. Currently, there is no standard API for PaaS management and deployment; each PaaS provider has its own specific APIs (e.g., Google AppEngine (GAE), OpenShift (OS), Cloud Foundry (CF), and Windows Azure). Therefore, deploying applications on heterogeneous PaaS platforms is considered one of the challenges that make some developers worry about using PaaS services. Such challenge can be solved by providing a standard or a generic API that overcomes PaaS API heterogeneity. The aim of this paper is to report on our effort to use and extend a generic API, namely the COAPS API, which supports deployment and management on Cloud Foundry and OpenShift. According to the work in this paper, an extension of the COAPS API is provided to include the deployment on Google AppEngine as a case study to demonstrate COAPS API generality. Keywords—PaaS; Heterogeneous PaaS; Generic API; and COAPS API.

I.

INTRODUCTION

The cloud computing model aims to provide a pool of virtualized resources as a service. These resources are shared by end users and accessed, remotely through the cloud, on demand. They can be scaled up/down based on the user needs and the users can only pay for their actual use. The cloud computing provides three main service models namely: Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS) [1] [2] [3]. The work in this paper focuses on the PaaS service model, specially, deployment and management of applications on heterogeneous PaaS platforms. The PaaS service model aims to provide the developers with APIs to develop, test, deploy, and manage their applications remotely through the cloud [1] [2]. The main benefit of the cloud PaaS platform is to provide the developers the ability to concentrate on their major tasks without worrying about the installation and maintenance of operating system, Integrated Development Environment (IED), and data storage

[4] [5]. The cloud PaaS platforms shift the load of software installation and maintenance to the PaaS cloud providers. However, each PaaS provider has its own specific APIs (which may be divided into two parts namely: implementation API and deployment API). In this paper, the deployment API is concerned. Since it is difficult for the developers to be aware of all those heterogeneous APIs, a vendor lock-in problem occurs. This latter, means that the developers are locked inside a specific PaaS platform and cannot migrate their applications (i.e., applications become not portable) between the heterogeneous PaaS platforms. Also, the vendor lock-in problem did not allow the heterogeneous PaaS platforms to interoperate (i.e., cooperate) with each other [5] [6]. Examples for currently available specific APIs are GAE1, Windows Azure2, OS3, CF4, and Amazon Web Service (AWS)5. The vendor lock-in problem distracts the developers because of many issues, such as PaaS cloud providers can increase the price, change service level, remove security polices, etc. [7]. Although, this problem is likely to lead to violation in the Service Level Agreement (SLA), it is very difficult for the developers to migrate their applications to another PaaS platform because two issues: 1) the lock-in may occur on the application level and this may require more refactoring for the application. 2) the lock-in may occur on the data level; where the data cannot be transferred between the different PaaS providers because each cloud provider has its own data format [6]. Many efforts have been done to provide a standard or a generic API that allows the heterogeneous PaaS platforms to interoperate with each other seamlessly and also allow the PaaS applications to be migrated between the heterogeneous PaaS platforms. Sellami et al. [8] have provided a generic API, called COAPS API, that helps the developers to deploy and manage 1

http://code.google.com/appengine www.microsoft.com/azure 3 https://www.openshift.com/ 4 http://www.cloudfoundry.com/ 5 http://aws.amazon.com/ 2

their applications independently of any PaaS platform. The COAPS API requires the PaaS applications to be described through a PaaS Application Description Model (PADM). PADM is used to specify the PaaS application properties, its required software components (runtime, framework, and services), and its source archive independently of any PaaS platform. Currently, COAPS API provides the deployment and management APIs for only two PaaS platforms namely: Cloud Foundry (CF-PaaS API) and Openshift (OS-PaaS API) [9]. The main objectives of this paper are that reporting our efforts to use and test COAPS API as a generic API to deploy and manage applications on heterogeneous PaaS platforms and providing a case study to prove the generalization of COAPS API. This case study extends the COAPS API to include the deployment on Google App Engine (i.e., providing GAE-PaaS API). The rest of the paper is organized as follows. An overview of the COAPS API, how to describe the PaaS applications independently of any PaaS platform using PaaS Application Description Model (PADM), and the scenario that should be followed to deploy applications to a specific PaaS platform using COAPS API is provided in section II. A case study for extending the COAPS API is specified in section III. In section IV, the implementation and testing of the new version of COAPS API is discussed by deploying an application to GAE. The state of the art for the related literature to hide the heterogeneity of PaaS platforms is presented in section V. Finally, the conclusion and future work are clarified in section VI. II.

COAPS API OVERVIEW

COAPS API stands for Compatible One Application and Platform Service API [10]. It is implemented as Representational State Transfer (REST) API [11]. REST is an architectural style for designing and developing distributed applications. The main idea of REST is to use the HTTP protocol to connect between the clients and the servers. The RESTful applications use HTTP methods (i.e., GET, POST, PUT, and DELETE) for all CRUD operations (i.e., Create, Read, Update, and Delete) [12].

spring), and services (e.g., database) [8] [10]. Also it provides two generic interfaces to handle the operations of the application and environment resources namely: RESTApplicationManager and RESTEnvironmentManager respectively. The RESTApplicationManager interface provides prototypes to manage the application (e.g., create, deploy, start, stop, and delete application). The RESTEnvironmentManager interface provides prototypes to manage the environment (e.g., create and delete environment). Those prototypes of both RESTApplicationManager and RESTEnvironmentManager can be re-implemented by each specific PaaS platform which needs to be included to the COAPS API. Before using COAPS API to deploy an application to a PaaS platform, it is required to use PADM to define the application manifest. This latter, describes mainly two components; PaaS application and PaaS environment. A UML diagram for the main components that constitute the PADM of the COAPS API is illustrated in Fig. 2. The main components of the PaaS application manifest are elaborated in section II-A and II-B. The deployment scenario through COAPS API is specified in section II-C. Finally, the advantages and disadvantage for using COAPS API are clarified in section IID. A. The PaaS application It is identified by a unique name and is tightened with an environment. It should define a set of application versions. Each application version defines a set of application version instances, which can be run after the application is deployed, and specifies the application deployable (i.e., source archive, its content-type, location, and multitenancy supportability) [8] [10]. The content-type of an application deployable may be "artifact" or "file". The "artifact" value refers to the application's source packaging format which may be bundled as (e.g. WAR, JAR, EAR, ZIP, etc.) or may be extracted as a local folder. The "file" value refers to a configuration file to upload/execute in the target folder once the application is deployed (e.g., an XML file or a script). Deployable entities can be a set of artifacts and configuration files. Currently, COAPS supports only artifacts format (personal communication with Yangui, June 12, 2013).

COAPS API is a generic API that provides the developers with a middleware layer to hide the heterogeneity of the different PaaS platforms. This middleware layer allows developers to deploy and manage their applications on any PaaS platform [8] [10]. The developers need only to learn the COAPS API to deploy their applications on any PaaS platform as long as that PaaS platform is supported by COAPS API. Currently, COAPS API supports only two PaaS platforms namely: Cloud Foundry and Openshift. To allow COAPS API to support a new PaaS platform, one needs to add a specific implementation for this new PaaS platform in the COAPS API. The COAPS API architecture is illustrated in Fig. 1. The COAPS API provides two main resources; application and environment. The Application resource represents any software program that can be deployed on a PaaS platform. The environment resource refers to the required configurations that are needed by an application to be deployed, such as runtime (e.g., php, ruby, or java), framework (e.g., tomcat or

Fig. 1. COAPS API architecture [10]

x Select "Create" environment method; it takes a PaaS environment manifest as input. This manifest specifies the required software components that are needed by an application (e.g., container such as tomcat or database such as SQL Server). The create environment method returns an XML file of the newly created environment with a unique envID. This created environment will be used later to deploy applications on it. x

Fig. 2. UML diagram for PaaS Application Description Model (PADM) of the COAPS API

B. The PaaS environment It is identified by a unique name and should define an environment template. An environment template should specify the required memory that will be needed by the deployed application instances. For example, when the developers need to scale up/down the memory of their application instances, it is required to create a new environment (or update an existing one) with the new memory size and then deploy the application again. Also, each environment template should define a set of environment nodes and their types (e.g., container such as tomcat or database such as SQL server). These environment nodes represent the software components that will be needed by the deployed application [8] [10]. A sample of a PaaS application manifest is depicted in Fig. 3. C. Deployment scenario through COAPS API After a PaaS application manifest is identified for an application, the COAPS API can be used to deploy that application. A summary of some of the available methods inside the COAPS API is specified in TABLE 1[10]. The required steps to deploy an application through COAPS API are: x The developer should select one of the supported PaaS platforms (e.g., CF-PaaS API or OS-PaaS API) that will be used to deploy the applications on it.

Fig. 3. PaaS Application manifest sample

Select “Create” application method; this method takes a PaaS application manifest as input. This manifest specifies a unique name of the created application, its hosted environment, application deployable and its properties (i.e., location and type of the source archive, multitenancy supportability, and required number of instances). The “create” application method returns an XML file of the newly created application with a unique appID.

x Select “Deploy” application method; this method takes an appID and an envID as inputs. It calls a specific API of the targeted PaaS platform to deploy the given app on that PaaS platform. x Select “Start” application method; it takes an appID as an input. It calls a specific API of the targeted PaaS platform to start the given app. Now, the application is ready to be executed by end users. D. Tradeoff for using COAPS API Finally, the main advantage of COAPS API is that it allows the developers to use a generic API (i.e., COAPS API) to deploy one or more applications on heterogeneous PaaS platforms. Thereby, there is no need for the developers to learn the different deployment APIs of all the targeted heterogeneous PaaS platforms. However, the disadvantage of COAPS API is its limitation to deploy and manage the applications on heterogeneous PaaS platforms. It did not provide consideration about how to monitor the running applications and manage their resources (e.g., scale the resources up/down through the run time, migrate the applications in case of fault, etc.) [8].

TABLE 1. COAPS API METHODS Application Management Methods Operation

REST Method

REST URL

Description

Create Application

POST

/app

Creates a new application given the app manifest. It returns an XML application descriptor with a unique appID

Deploy Application

POST

/app/{appId}/action/ deploy/env/{envId}

Deploy an app given its appID on an env given its envID

Start Application

POST

/app/{appId}/start

Start an app given its appID

Stop Application

POST

/app/{appId}/stop

Stop an app given its appID

Destroy Application

DELETE

/app/{appId}

Delete an app given its appID

Describe Application

GET

/app/{appId}

Returns an XML application descriptor for the given appID Environment Management Methods

Create Environment

POST

/environment

Creates a new environment given the env manifest. It returns an XML environment descriptor with a unique envID

Describe Environment

GET

/environment/{envId}

Returns an XML environment descriptor for the given appID

III. CASE STUDY: EXTENDING THE COAPS API A. Motivation for Extending the COAPS API Actually, we have three motivations to extend the COAPS API: Firstly, the COAPS API is a generic API and is provided as a RESTful java open source under Apache 2.0 license and can be downloaded from [9]. Secondly, it is already tested and used in two international research projects [8] namely: CompatibleOne6, which is an open source projects and its objective is to provide open cloud broker, and EASICLOUDS7, which aims to provide open source cloud infrastructure with a set of features (such as interoperability, portability, reliability, security, etc.) [13]. Therefore, the COAPS API is used by CompatibleOne and EASI-CLOUDS to allow them to interact with the heterogeneous PaaS platforms seamlessly. Thirdly, the PADM of COAPS is based on Open Cloud Computing Interface8 (OCCI) standards. B. Road Map to extend the COAPS API to support GAE Since COAPS API supports the deployment on only two PaaS platforms namely: CloudFoundry and Openshift, we proved the generalization of this API by extending it to allow the deployment of applications on another PaaS platform (in our case, Google App Engine) besides CF and OS. Thereby, the following points elaborate the steps that are followed to extend the COAPS API 1.

Fig. 4. GAE module is added to the COAPS API

2.

COAPS API provides PaaS application manifest schema that can be used to generate the manifest classes. This schema is used by GAE-PaaS API to generate the PaaS application manifest classes which will be used later to process an application manifest that is given by the developer to deploy an application.

3.

GAE-PaaS API includes the deployment and management operations to GAE platform through COAPS API. However, deploying applications on GAE require an account (with email and password). Therefore, account info is defined in the credentials file inside GAE-PaaS API. The developer can update this file to include his account. A snapshot of the credentials file is clarified in Fig. 5.

4.

GAE-PaaS API creates EnvironmentManagerRessource class which implements the RestEnvironmentManager interface that is inside the COAPS API. The EnvironmentManagerRessource class provides a specific implementation for GAE to the methods (create, delete, describe, etc.) environments.

A new dummy module is added to the COAPS-Core to include the GoogleAppEngine-api (we will call it GAE-PaaS API) as it is depicted in Fig. 4. The COAPS-Core includes the PaaS platforms that are supported the COAPS.

Fig. 5. Credentails file for GAE-PaaS API 6

http://www.compatibleone.org 7 http://easi-clouds.eu/ 8 http://occi-wg.org/

5.

GAE-PaaS API creates ApplicationManagerRessource class which implements the RestApplicationManager

interface that is inside the COAPS API. The ApplicationManagerRessource class provides a specific implementation for GAE to the methods (create, deploy, and start applications). 6.

7.

Google provides Appcfg command line tool to be used by developers to deploy their applications to GAE platform [14]. Therefore, we have used appcfg tool in the ApplicationManagerRessource class to deploy applications to GAE platform through the COAPS API. Many other classes are added to GAE-PaaS API to provide utilities to be used by both ApplicationManagerRessource and EnvironmentManagerRessource (e.g., some of these utilities are preserving a pool of the created applications and the created environment, generating links for all the REST methods that are defined in the ApplicationManagerRessource and EnvironmentManagerRessource, etc.).

C. Discussion Both of CloudFoundry and Openshift platforms provide developers with client APIs to deploy and manage (i.e., start, stop, and delete) their applications and these applications must be provided as WAR archive to be deployed. On the contrary, Google App Engine platform did not provide developers with client API to deploy and manage their applications. The developers can deploy their applications to GAE platform either by using GAE plugin for Eclipse or using Appcfg command line tool [14]. Since GAE plugin for Eclipse cannot be called as a standalone API and it requires Eclipse Integrated Development Environment (IDE), we have used Appcfg command line tool to implement the deployment methods inside GAE-PaaS API. In general, to deploy an application to GAE platform, the application must be implemented by Google plugin. This is because Google plugin generates WAR directory for the application to be deployed later to GAE platform. This WAR directory contains the compiled classes of an application and a set of configuration files (e.g., appengine-web.xml and web.xml). It is worth to mention that GAE-PaaS API did not provide methods to stop, restart, and delete the deployed applications. This is because GAE platform is proprietary and did not provide the developers with management API to stop, restart, and delete their deployed applications. However, GAE platform allows the developers to manage their deployed applications online from the setting web page of their applications. Therefore, GAE-PaaS API implements all methods of COAPS-API except Stop Application, Restart Application, and Delete Application. These latter, are not supported by GAE-PaaS API. TABLE 2 clarifies a comparison between the currently supported PaaS platforms by COAPS API.

TABLE 2. COMPARISON BETWEEN THE SUPPORTED PAAS PLATFORMS BY THE COAPS API Feature Deployment API Management API

Deployable type

CF-PaaS API / OS-PaaS API org.cloudfoundry.client.lib and com.openshift.client respectively. org.cloudfoundry.client.lib and com.openshift.client respectively. WAR archive

GAE-PaaS API No API, only appcfg tool is provided No API, only the online setting web page of the application is used in the management. WAR Directory

According to the work in this paper, some concepts could be concluded: x The developers can use the same API (i.e., COAPS API) to deploy multiple applications on a set of heterogeneous PaaS platforms. x Adding a new PaaS platform to the COAPS API requires this new PaaS platform to provide a client API to be used in the deployment and management of the applications through the COAPS API. x Deploying an application through the COAPS API requires the developer to provide the application's source archive in the same format that is required by the targeted PaaS platform. In other words, the developer must provide WAR archive for his application to be deployed on Cloud Foundry or Openshift. However, the deployment on Google App Engine requires the developer to provide WAR directory. IV. EXTENDED COAPS API IMPLEMENTATION AND TESTING After illustrating the case study for extending the COAPS API, we can state that COAPS API provides three implementations namely: CF-PaaS API, OS-PaaS API, and GAE-PaaS API to support the deployment on CloudFoundry, Openshift, and Google App Engine platforms respectively. Similar to CF-PaaS API and OS-PaaS API, GAE-PaaS API is implemented using java programming language and is delivered as a RESTful web application (using Jersey JAX-RS library in the implementation). Sellami et al. [8] have created a generic web client to use COAPS API to test the deployment and management of applications on CloudFoundry and Openshift platforms. So, we will use the same web client to test the deployment of applications on Google App Engine platform. A snap shot of the COAPS API web client is depicted in Fig. 6. To deploy an application through the COAPS API, an application manifest needs to be identified based on the PADM of COAPS API. We will use the application manifest that is specified in Fig. 3 during our testing. It should remember that this application manifest is independent on the targeted PaaS platform (Google App Engine in this case). Besides the application manifest, we need the source archive of the application to start the deployment process. Now, the deployment process is ready to be started. So, we will follow

the deployment scenario that is specified in section II-C. Firstly, specify the URL of the targeted PaaS platform (i.e., GAE-PaaS API) that will be used by COAPS API to deploy applications on that platform. Secondly, select from the Action menu the "Create Environment" method and write the environment manifest in the Request Body section. An XML (that represents the newly created environment) with a unique envID is returned. Fig. 6 illustrates the create environment method. Thirdly, select from the Action menu the "Create Application" method and write the application manifest in the Request Body section. It should remember that the path of the application source archive is specified in the application manifest as it is clarified in Fig. 7. The create application method returns an XML (that represents the newly created application) with a unique appID. Finally, select from the Action menu the "Deploy Application" method and specify in the Path section the previously created envID and appID. Once an application is deployed, it is become ready to start running. The deploy application method returns the XML application descriptor (which includes a URL to run the deployed application) of the deployed application. The developers can use this URL to run their application as it is depicted in Fig. 8. Unfortunately, GAE-PaaS API did not support methods to allow developers to manage (restart, stop, and delete) their deployed applications. However, they can manage their applications online from the setting web page of the deployed applications. V.

Fig. 6. COAPS API web client (Create Environment)

RELATED WORK

Many efforts have been done to help the developers to deploy and manage their applications on heterogeneous PaaS platforms. These efforts could be organized into three categories namely: proprietary APIs, open source APIs, and standards under development. These categories are elaborated in section V-A, V-B, and V-C respectively. A. Proprietary APIs Some of the available PaaS platforms provide the developers with proprietary APIs which lead to vendor lock-in problem. For example, Google App Engine allows developers to deploy their application on Google cloud platform. Microsoft Windows Azure allows the application deployment and management on Azure cloud platform. Amazon Web Service Elastic BeansTalk (AWS) helps the developers to deploy their applications on Amazon cloud platform. Openshift is established by Redhat and it provides the developers with automatic deployment and management of their applications on the Openshift platform [15]. All of the previously mentioned PaaS platforms provide different representation of PaaS applications, different programming languages, and different frameworks which increase the heterogeneity among these PaaS platforms and did not allow the cooperation between them. Also, the developers need to learn different APIs to deploy on these heterogeneous PaaS platforms.

Fig. 7. COAPS API web client (Create Application)

Fig. 8. COAPS API web client (Deploy Application response)

B. Open Source APIs Cloud Foundry is an open source PaaS platform (only source code is available but there is no documentation) that is

established by VMware9. It provides the developers with proprietary APIs that can run on a private cloud. CF helps the developers to deploy and manage their applications on the Cloud Foundry platform [16]. Since the provided APIs by Cloud Foundry is proprietary, the vondor lock-in problem occurs when using this PaaS platform. Petcu et al. [17] aim to create an open source API that helps developers to implement portable applications that can work on multiple PaaS platforms (i.e., write once and deploy anywhere). Their project is called mOSAIC (Open Source API and platform for multiple Clouds). mOSAIC is similar to CloudFoundry. However, it is a fully open source [18] (i.e., source code and documentation is available) and it provides different levels of abstraction, e.g., Cloud Resources, Components, Drivers (i.e., Adapters), etc. mOSAIC helps developers to specify the application requirements through using ontology and to implement applications that are not dependent on any programming language because it provides generic protocols that can be re-implemented in any programming language. However, mOSAIC provides different levels (i.e., layers) of APIs, which may lead to overhead when mapping between each two successive layers. Also, the applications that are implemented by mOSAIC are not PaaS independent instead they are IaaS independent (personal communication with Craciun, Sept 6, 2013). Zeginis et al. [5] aim to provide the Cloud4SOA solution to deploy, manage, monitor, and migrate the applications across the heterogeneous PaaS platforms including both private and public clouds. Cloud4SOA is available as an open source and can be downloaded from [19]. Cloud4SOA allows the semantic interoperability between the different PaaS platform. Thus, Cloud4SOA combines three main paradigms namely: Cloud Computing, Semantics, and Service Oriented Architecture (SOA). However, when the authors compared between Cloud4SOA and other PaaS platforms (such as CloudFoundry), they found the Cloud4SOA requires overhead in time. Sellami et al. [8] provides the COAPS API as an open source and generic API that can be used to deploy and manage the applications on heterogeneous PaaS platforms. However, the COAPS API supports the deployment on only two PaaS platforms namely: Cloud Foundry and Openshift. In this paper, we tried to propose an extension for the COAPS API to allow the deployment on Google App Engine platform. C. Standards under Development Advancement of Structured Information Standards (OASIS) is providing two standards to describe the applications independently of any PaaS platform namely: Cloud Application Management for Platforms (CAMP) and Topology and Orchestration Specification for Cloud Applications (TOSCA). CAMP [20] aims to provide a standard API that helps the developers to develop, deploy, manage, and monitor their applications on any PaaS platform. Also, it allows the developers to migrate their applications between the heterogeneous PaaS platforms. CAMP allows the developers to 9

www.vmware.com/

specify their applications through Platform Deployment Package (PDP) which contains the application's dependencies and the meta-data to manage the application. This PDP can be used later to migrate the application from one PaaS platform to another. TOSCA [21] aims to provide a grammar to help the developers to describe the PaaS applications through topology and orchestration. Topology is used to define the structure of the application's services while orchestration is used to define how to manage these services. TOSCA represents an application as a set of nodes where each node has a set of requirements and provides a set of capabilities that can be needed by another node. Therefore, the relationships between nodes should be defined. TOSCA provides Cloud Service ARchive (CSAR) for each application. CSAR contains all the data (e.g., source archive and manifest) that is need to deploy and manage the application on a specific PaaS platform. The main problem with TOSCA and CAMP is that they are still under the development and may require more modifications. It is noted that besides the PADM of COAPS API is based on OCCI standards, it follows the same structure of TOSCA and CAMP to describe the PaaS applications [8]. TABLE 3 summarizes the currently available PaaS platforms. TABLE 3. AVAILABLE PAAS PLATFROMS

PaaS Platform Google App Engine (GAE) Amazon Web Service Elastic BeansTalk (AWS) Microsoft Windows Azure Openshift (OS) Cloud Foundry (CF) mOSAIC Cloud4SOA CAMP TOSCA COAPS

Proprietary

Open Source

Overhead

Standards under Development

√

Х

Х

Х

√

X

Х

X

√

Х

Х

Х

√

Х

Х

Х

Х

√

Х

Х

Х Х Х Х Х

√ √ Х Х √

√ √ Х Х X

X Х √ √ X

VI. CONCLUSIONS AND FUTURE WORK The aim of this paper is to report our efforts to use and test COAPS API as a generic API to deploy and manage applications on heterogeneous PaaS platforms, and provide a case study to ensure the generalization of COAPS API. This case study extends the COAPS API to include deployment on Google App Engine (i.e., providing GAE-PaaS API) besides the deployment on CF and OS. Since the COAPS API focus on providing deployment API to help the developers to deploy and manage their applications on heterogeneous PaaS platform, we plan to extend the COAPS

API to provide an implementation API besides the deployment API. This implementation API will be considered as a middleware layer (or abstraction layer) that helps the developers to develop their applications using only one format then use the COAPS API to deploy on any PaaS platform. By this way, the developers will develop their applications only once and deploy them on multiple PaaS platforms. ACKNOWLEDGMENT This work was funded by ITIDA ITAC under the umbrella of the ITEA2 EASI-CLOUDS project. REFERENCES [1] [2] [3]

[4]

[5]

[6]

[7]

[8]

[9] [10] [11]

[12] [13] [14]

[15] [16]

[17]

B. Furht and A. Escalante, Handbook of Cloud Computing. SpringerVerlag New York Inc, 2010. R. Buyya, J. Broberg, and A. Goscinski, Cloud Computing Principles and Paradigms. Wiley Press, New York, USA, 2011. E. Hossny, S. Salem, and S. Khattab, “Towards automated user-centric Cloud Provisioning: Job provisioning and Scheduling on heterogeneous virtual machines,” in proceedings of the 8th international conference on informatics and Systems (INFOS), 2012. Cloud4SOA, “D1.2 Cloud Semantic Interoperability Framework,” 2011. [Online]. Available: http://www.cloud4soa.eu/sites/default/files/D1.2_Cloud4SOA Cloud Semantic Interoperability Framework.pdf. D. Zeginis, F. D’Andria, S. Bocconi, J. Gorronogoitia Cruz, O. Collell Martin, et al., “A user-centric multi-PaaS application management solution for hybrid multi-Cloud scenarios,” Scalable Computing: Practice and Experience, vol. 14, no. 1, pp. 17–32, April. 2013. M. A. Babar and M. A. Chauhan, “A Tale of Migration to Cloud Computing for sharing experiences and observations,” in Proceedings of the 2nd International Workshop on Software Engineering for Cloud Computing, 2011, pp. 50–56. I. Roth, “Cloud Got You Locked-in? Avoid it by Choosing an Open PaaS,” 2011. [Online]. Available: https://www.openshift.com/blogs/cloud-got-you-locked-in-avoid-it-bychoosing-an-open-paas. M. Sellami, S. Yangui, M. Mohamed, and S. Tata, “PaaS-independent Provisioning and Management of applications in the Cloud,” in IEEE 6th International Conference on Cloud Computing (CLOUD 2013) ., 2013. “COAPS API Open Source.” [Online]. Available: git://gitorious.ow2.org/ow2-compatibleone/coaps.git. T. Sudparis, “The Compatible One Application and Platform Service ( COAPS ) API specification.” R. T. Fielding, “Architectural Styles and the Design of Network-based Software Architectures,” Ph.D. thesis, University of California, Irvine, 2000. D. M. ELKSTEIN, “Learn REST: A Tutorial.” [Online]. Available: http://rest.elkstein.org/2008/02/what-is-rest.html. “The EASI-CLOUDS Project Description.” [Online]. Available: http://easi-clouds.eu/2012/02/03/project-description/. “Appcfg Command Line Tool.” [Online]. Available: https://developers.google.com/appengine/docs/java/tools/uploadinganap p. “What is OpenShift?” [Online]. Available: https://openshift.redhat.com/app/platform. “VMware Unveils Open Source PaaS Cloud Foundry.” [Online]. Available: http://www.infoq.com/news/2011/04/VMWare-CloudFoundry. D. Petcu, M. Frˆ, C. Craciun, S. Panica, M. Neagul, et al., “Towards Open-Source Cloudware,” in 2011 Fourth IEEE International Conference on Utility and Cloud Computing, 2011, pp. 330–331.

[18] “mOSAIC.” [Online]. Available: http://developers.mosaiccloud.eu/confluence/display/MOSAIC/mOSAIC. [19] “Cloud4SOA source code.” [Online]. Available: https://github.com/Cloud4SOA/Cloud4SOA. [20] M. Carlson, M. Chapman, A. Heneveld, S. Hinkelman, D. JohnstonWatt, et al., “Cloud Application Management for Platforms,” Tech. Rep., 2012. [21] TOSCA_Committee, “Topology and Orchestration Specification for Cloud Applications,” Tech. Rep., November 2012.