Travel & Places

A Case Study for Deploying Applications on Heterogeneous PaaS Platforms

Description
A Case Study for Deploying Applications on Heterogeneous PaaS Platforms
Published
of 8
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Share
Transcript
  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.I  NTRODUCTION 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 providesthree 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 GAE 1 , Windows Azure 2 , OS 3 , CF 4 , 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 2 www.microsoft.com/azure 3 https://www.openshift.com/ 4 http://www.cloudfoundry.com/ 5 http://aws.amazon.com/    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.COAPSAPIO VERVIEW 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]. 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 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-Aand 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 II-D.  A.The PaaS application Itis 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). Fig. 1. COAPS API architecture [10]  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:  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 " 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.  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.  Select “  Deploy ” app lication 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.  Select “ Start  ” applicatio n 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].  TABLE1.COAPSAPIMETHODS Application Management Methods Operation REST  Method  REST URLDescription Create Application POST/appCreates 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}/stopStop 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.C ASE S TUDY :E XTENDING THE COAPSAPI  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: CompatibleOne 6 , which is an open source projects and its objective is to provide open cloud broker, and EASI-CLOUDS 7 , 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 Interface 8  (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.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. 6   http://www.compatibleone.org 7 http://easi-clouds.eu/   8 http://occi-wg.org/   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. Asnapshot 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. Fig. 5. Credentails file for GAE-PaaS API 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.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. 7.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. TABLE2.C OMPARISON BETWEEN THE SUPPORTED P AA S PLATFORMS BY THE COAPSAPI FeatureCF-PaaS API / OS-PaaS APIGAE-PaaS APIDeployment API org.cloudfoundry.client.liband com.openshift.clientrespectively. No API, only appcfg tool is provided Management API org.cloudfoundry.client.libandcom.openshift.clientrespectively. No API, only the online setting web page of the application is used in the management. Deployable type WAR archiveWAR Directory According to the work in this paper, some concepts could  be concluded:  The developers can use the same API (i.e., COAPS API) to deploy multiple applications on a set of heterogeneous PaaS platforms.  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.  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.E XTENDED COAPSAPII MPLEMENTATION 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 inFig. 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
Search
Similar documents
View more...
Tags
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks