Unified Cloud Platforms Interface Model and API. Deliverable 4.1. Date: November 2014

Transcription

1 A semantically enhanced marketplace of interoperable platform-as-a-service offerings for the deployment and migration of business applications of SMEs Unified Cloud Platforms Interface Model and API Deliverable 4.1 Date: November 2014 PaaSport is funded by the European Commission Seventh Framework Programme Contract no.:

2 Deliverable Title Filename 1.0 Author(s) Date November 2014 Unified Cloud Platforms Interface Model and API Kostas Kalaboukas (SILO), Giannis Ledakis (SILO), Panagiotis Gouvas (SILO), Nikos Drosos (SILO), Nick Bassiliades (IHU), Andreas Papadopoulos (UCY) Start of the project: 01/12/2013 Duration: 36 months Project coordinator organisation: BITMI BUNDESVERBAND IT-MITTELSTAND EV Deliverable title: Unified Cloud Platforms Interface Model and API Deliverable no.: 4.1 Due date of deliverable: 30/11/2014 Actual submission date: Dissemination Level PU PU Public PP Restricted to other programme participants (including the Commission Services) RE Restricted to a group specified by the consortium (including the Commission Services) CO Confidential, only for members of the consortium (including the Commission Services) Deliverable status version control Version Date Organisation Authors September October October December 2014 SILO Kostas Kalaboukas Giannis Ledakis Panagiotis Gouvas Nikos Drosos December 2014 UCY Andreas Papadopoulos December December 2014 NUIG Nick Bassiliades December December December 2014 PaaSport is funded by the European Commission Seventh Framework Programme Contract no.:

3 Abstract The present document is Deliverable 4.1 Unified Cloud Platforms Interface Model and API (henceforth referred to as D4.1) of the PaaSport project. This deliverable documents the work done in the scope of project tasks T4.1 Common PaaS Platforms Interface and T4.2 Common, Unified Cloud API and describes the Unified Cloud Platforms Interface Model and the Unified Cloud API. Keywords Broker, interoperability, portability, cloud computing, Platform as a Service, platform architecture PaaSport is funded by the European Commission Seventh Framework Programme Contract no.:

4 Table of Contents LIST OF ABBREVIATIONS... 9 Executive Summary Introduction Document Scope Document Structure Scope of the Unified Model and API, definition of portability and interoperability Interoperability Portability Existing Approaches on PaaS Models and APIs Existing Modeling Approaches for PaaS and PaaS APIs Models produced by European projects Models produced by standardization bodies Conclusion Elaboration on APIs of existing PaaS Providers Cloud Foundry Red Hat OpenShift Apache Stratos Google App Engine Heroku AWS Elastic Beanstalk CloudBees cloudcontrol Common PaaS Characteristics and Functionalities PaaSport Unified Platforms Interface Model Overview of offered PaaS functionalities from public APIs Unified Cloud API specification API Methods Overview Defined Methods Details PaaSport Solution for Portability Resource Binding Application Configuration Spring Cloud Connectors D 4.1 Unified Cloud Platforms Interface Model and API 4 / 76

5 4.4 PaaSport Solution to Portability PaaSport SPI Unified Cloud API resource binding related methods Conclusion REFERENCES D 4.1 Unified Cloud Platforms Interface Model and API 5 / 76

6 Table of Figures: FIGURE 1: ADAPTER PATTERN USAGE IN PAASPORT FIGURE 2: CLOUD4SOA SEMANTIC MODEL [7] FIGURE 3: CLOUD4SOA HARMONIZED API MODEL FIGURE 4: MOSAIC API LAYERS [12] FIGURE 5: MOSAIC CORE ONTOLOGY FIGURE 6: MAIN CAMP RESOURCES FIGURE 7: CLOUD COMPUTING RESOURCES ONTOLOGY FIGURE 8: CLOUD FOUNDRY LOGO FIGURE 9: PIVOTAL CF LOGO FIGURE 10: APPFOG LOGO FIGURE 11: STACKATO LOGO FIGURE 12: IBM BLUEMIX LOGO FIGURE 13: OPENSHIFT LOGO FIGURE 14: APACHE STRATOS LOGO FIGURE 15: WSO2 CLOUD LOGO FIGURE 16: GOOGLE APP ENGINE LOGO FIGURE 17: HEROKU LOGO FIGURE 18: AMAZON ELASTIC BEANSTALK LOGO FIGURE 19: CLOUDBEES LOGO FIGURE 20: CLOUDCONTROL LOGO FIGURE 21: PAASPORT UNIFIED PLATFORMS INTERFACE MODEL FIGURE 22: APPLICATION CONFIGURATION ON A PRIVATE DEPLOYMENT FIGURE 23: APPLICATION CONFIGURATION ON CLOUD FOUNDRY FIGURE 24: APPLICATION CONFIGURATION ON HEROKU FIGURE 25: APPLICATION CONFIGURATION USING SPRING CLOUD CONNECTORS FIGURE 26: SERVICE PROVIDER INTERFACE (SPI) AT A GLANCE FIGURE 27: PAASPORT SPI OVERVIEW FIGURE 28: SPRING CLOUD CONNECTORS REQUIRED LIBRARIES D 4.1 Unified Cloud Platforms Interface Model and API 6 / 76

7 List of Tables: TABLE 1: REST API CALLS DEFINED BY CLOUD4SOA TABLE 2: MOSAIC APIS TABLE 3: CLOUD FOUNDRY SUPPORTED LANGUAGES, RUNTIMES AND FRAMEWORKS TABLE 4: CLOUD FOUNDRY IDENTIFIED ENTITIES TABLE 5: OPENSHIFT SUPPORTED LANGUAGES, SERVERS AND DATABASES TABLE 6: OPENSHIFT IDENTIFIED ENTITIES TABLE 7: APACHE STRATOS IDENTIFIED ENTITIES TABLE 8: HEROKU IDENTIFIED ENTITIES TABLE 9: AMAZON ELASTIC BEANSTALK IDENTIFIED ENTITIES TABLE 10: CLOUDCONTROL IDENTIFIED ENTITIES TABLE 11: PAASPORT DEFINED ENTITIES TABLE 12: UNIFIED CLOUD API REST CALLS OVERVIEW TABLE 13: CREATE AN APPLICATION TABLE 14: RETRIEVE AN APPLICATION TABLE 15: UPDATE AN APPLICATION TABLE 16: DELETE AN APPLICATION TABLE 17: GET LIST OF APPLICATIONS TABLE 18: MANAGE APPLICATION STATE TABLE 19: SCALE AN APPLICATION TABLE 20: MONITOR AN APPLICATION TABLE 21: CREATE A USER TABLE 22: RETRIEVE A USER TABLE 23: UPDATE A USER TABLE 24: DELETE A USER TABLE 25: ADD KEY TABLE 26: DELETE A KEY TABLE 27: CREATE A NEW CONTAINER TABLE 28: RETRIEVE A CONTAINER TABLE 29: UPDATE A CONTAINER TABLE 30: DELETE A CONTAINER TABLE 31: GET CONTAINERS TABLE 32: CREATE A DEPLOYMENT PACKAGE TABLE 33: RETRIEVE A DEPLOYMENT PACKAGE TABLE 34: UPDATE A DEPLOYMENT PACKAGE TABLE 35: DELETE A DEPLOYMENT PACKAGE TABLE 36: CREATE A SERVICE TABLE 37: RETRIEVE A SERVICE TABLE 38: UPDATE A SERVICE TABLE 39: DELETE A SERVICE TABLE 40: GET AVAILABLE SERVICES TABLE 41: CREATE A SERVICE BINDING TABLE 42: RETRIEVE A SERVICE BINDING TABLE 43: UPDATE A SERVICE BINDING TABLE 44: DELETE A SERVICE BINDING TABLE 45: GET BOUND SERVICES TABLE 46: CREATE A DOMAIN TABLE 47: RETRIEVE A DOMAIN TABLE 48: UPDATE A DOMAIN TABLE 49: DELETE A DOMAIN TABLE 50: GET CONFIGURED DOMAINS TABLE 51: CREATE A SECURITY POLICY D 4.1 Unified Cloud Platforms Interface Model and API 7 / 76

8 TABLE 52: RETRIEVE A SECURITY POLICY TABLE 53: UPDATE A SECURITY POLICY TABLE 54: DELETE A SECURITY POLICY TABLE 55: GET CONFIGURED SECURITY POLICIES TABLE 56: UNIFIED CLOUD API METHODS RELATED TO SERVICE BINDING D 4.1 Unified Cloud Platforms Interface Model and API 8 / 76

9 LIST OF ABBREVIATIONS API CAMP CRUD HTTP IaaS JSON LDAP PaaS PDP QoS REST SLA SME SOA SPI SSH TOSCA UML XML Application Programming Interface OASIS Cloud Application Management for Platforms Create, Retrieve, Update and Delete Hypertext Transfer Protocol Infrastructure as a Service JavaScript Object Notation Lightweight Directory Access Protocol Platform as a Service Platform Deployment Package Quality of Service Representational State Transfer Service-level agreement Small and medium-sized enterprises Service-oriented architecture Service Provider Interface Secure Shell OASIS Topology and Orchestration Specification for Cloud Applications Unified Modeling Language Extensible Markup Language D 4.1 Unified Cloud Platforms Interface Model and API 9 / 76

10 Executive Summary The present document is Deliverable 4.1 Unified Cloud Platforms Interface Model and API (henceforth referred to as D4.1) of the PaaSport project. This deliverable documents the work done in the scope of project tasks T4.1 Common PaaS Platforms Interface and T4.2 Common, Unified Cloud API described in DoW [1]. This document identifies and describes the PaaSport Components that allow the cloud interoperability and the application portability between PaaS offerings. Initially the PaaSport Unified Platforms Interface model is concluded. This model is used as the base for the PaaSport Unified Cloud API, a REST API that attempts to provide interoperability by encapsulating common functionalities offered by the PaaS offerings API. Also, the PaaSport Dynamic Configuration Interface (PaaSport SPI) is defined along with the approach that allows the portability of applications. D 4.1 Unified Cloud Platforms Interface Model and API 10 / 76

11 1 Introduction The aim of this section is to present the background of the work pursued during Tasks 4.1 and 4.2. The scope and the main objectives which have guided this work are introduced in section 1.1 while section 1.2 presents the organization of the current deliverable. 1.1 Document Scope The PaaSport project focuses on resolving the data and application portability issues that exist in the Cloud PaaS market through a flexible and efficient deployment and migration approach. The vision of the PaaSport project is to enable European Cloud vendors to roll out semantically interoperable PaaS offerings, while benefiting European Software SMEs by allowing them to deploy business applications on the best-matching Cloud PaaS and to migrate these applications on demand to heterogeneous PaaS offerings, thus overcoming the vendor lock-in problem. In order to achieve this, PaaSport specifies and will implement a semantically-enhanced Cloud-broker architecture and marketplace. The goal of this Cloud-broker is to resolve the application and data portability issues that exist in the Cloud PaaS market through a flexible and efficient deployment and migration approach. The scope of this document is to define and document the PaaSport Unified PaaS API, i.e. a common API that will allow the deployment, management and migration of applications transparently to the user and independent of the specificities of a PaaS offering, by building upon and extending CAMP and the Cloud4SOA APIs. The PaaSport Dynamic Configuration Interface that boosts the portability of applications deployed to the cloud will also be defined and documented. 1.2 Document Structure The document consists of five (5) main sections. The first section is the introduction. The second section tries to give a better understanding of the problem to be addressed, by defining the portability and interoperability terms in the scope of PaaSport. Section 3, initially gives an overview of current solutions related to PaaS modeling and common APIs and then describes in detail the proposed solution of the PaaSport Unified Cloud API. Section 4 describes how portability issues are resolved through the PaaSport Dynamic Configuration Interface. Section 5 summarizes the main conclusions of the document. D 4.1 Unified Cloud Platforms Interface Model and API 11 / 76

12 2 Scope of the Unified Model and API, definition of portability and interoperability The market of PaaS is being constantly extended by new offerings, and already existing solutions are getting more universal in terms of supporting languages. This gives consumers more options than ever for deploying applications to the cloud with PaaS usage. However, as each PaaS provider introduces its own platform, model and programming paradigm, heterogeneity remains a problem. Therefore, the need for a unified model and API is valid and also critical for the terms of the project, where portability and interoperability of applications are critical goals. 2.1 Interoperability Interoperability in PaaSport is defined as the ability of the brokerage platform to alleviate and harmonize the diversification and inconsistencies that exist at the API-level of the various PaaS offerings regarding semantically-equivalent functions. Interoperability is also considered as a synonym of integration enabling products/software components to work with or integrate with each other seamlessly, in order to achieve a desired result. This is enabled by either integrating through standard interfaces or by means of a broker that converts one product interface to another [2]. In other words, interoperability targets the harmonization of the PaaS APIs. From the software engineering perspective this is mapped to the traditional Object Oriented Adapter pattern according to which the pattern helps two incompatible interfaces to work together (see Figure 1). Figure 1: Adapter pattern usage in PaaSport Therefore, it should be clear that PaaSport will try to address diversification through the implementation of concrete Adaptors accompanied by respective clients for selected PaaS providers. D 4.1 Unified Cloud Platforms Interface Model and API 12 / 76

13 Given that each PaaS offering uses its own API, the PaaSport approach suggests that a PaaSport adapter is needed as a middleware between the PaaSport Unified Cloud API and the native API of the PaaS offering. More specifically, the adapter translates the functions of the PaaSport Unified PaaS API to the native API of the PaaS offering, and vice versa. The PaaSport Unified Cloud API capitalizes heavily on the PaaSport Platform-as-a-Service model. The use of the adapter enables the seamless communication between the PaaSport Marketplace and individual PaaS offerings and contributes significantly to the removal of vendor lock-in and application portability barriers [3]. 2.2 Portability On the other hand, portability refers to the ability of the Application to be ported from one container to the other and remain functional without any changes at the source-level. In order to achieve this there are two main prerequisites: a) the developer must follow portability guidelines and b) the application should be accompanied by libraries that abstract the interaction with the container (connect to database, register queue, use logger, etc.). In the framework of PaaSport both of these prerequisites will be tackled as follows: a) specific guidelines for the developer will be provided and b) concrete libraries that abstract the container usage will be created. As a result, while interoperability is application-agnostic and PaaS-specific, portability is exactly the opposite, i.e. application-specific and PaaS agnostic. As explained, PaaSport will concretely deal with both issues [3]. D 4.1 Unified Cloud Platforms Interface Model and API 13 / 76

14 3 Existing Approaches on PaaS Models and APIs For the scope of integrating PaaS offerings to PaaSport and offering the desired interoperability and portability of applications among them, one of the functional requirements is that PaaS offerings provide public APIs. These APIs are important in order to offer functionalities that can be used for the governance of applications. This section studies available initiatives that provide formal and standardized meta-modeling descriptions of PaaS offerings, with special focus on API modeling, although other Cloud meta-modeling technologies that could complement the former ones will be considered. 3.1 Existing Modeling Approaches for PaaS and PaaS APIs For the modeling of PaaS offerings many initiatives exist, either as part of EU funded projects or from standardization bodies. These initiatives have been already examined thoroughly and were presented in the scope of the project in other deliverables, such as D1.1 Requirements Analysis Report [4] and D1.3 PaaSport Semantic Models [5]. However, as these modeling approaches focus on the PaaS model in general, in this chapter we try to identify the ones that are more relevant to PaaS APIs. With regards to the Unified Cloud Platforms Interface model, we are mostly interested in functionalities offered by the API from the PaaS providers. For this reason the following analysis is mostly focused on the models and the parts of the API that can be expressed by the model Models produced by European projects Many EU projects, active or completed, have focused on Cloud computing, and fewer on the PaaS paradigm. Most related projects that have been examined and taken into account are briefly described, while Cloud4SOA, which is the most relevant and also re-used and extended in the scope of the project, is described with more technical details Cloud4SOA Cloud4SOA[6] is a completed FP7 project that focuses on resolving the interoperability and portability issues existing in current Clouds infrastructures and on introducing a user-centric approach for applications which are built upon and deployed using Cloud resources. The approach suggested by Cloud4SOA focuses on semantically interconnecting heterogeneous PaaS offerings across different Cloud providers that share the same technology. The design of Cloud4SOA consists of a set of interlinked collaborating software components and models that provide developers and platform providers with a number of core capabilities: matchmaking, management, monitoring and migration of applications. Cloud4SOA focuses on resolving the semantic incompatibilities that rise both within the same as well as across different Cloud PaaS systems and enable Cloud-based application development, deployment and migration across heterogeneous PaaS offerings. Cloud4SOA combines three complementary computing paradigms, namely cloud computing, Service Oriented Architectures (SOA) and lightweight semantics. The Cloud4SOA project architecture consists of three key components: (a) intelligent front-end (i.e. management through a userfriendly dashboard), (b) adapters for bridging multiple Cloud platforms and for translating D 4.1 Unified Cloud Platforms Interface Model and API 14 / 76

15 PaaS offerings through the use of a common API, and (c) a unified monitoring service for comprehensive SLA management. Cloud4SOA has produced a Semantic Model that is used through project layers. The Cloud4SOA semantic model is an ontology designed to enable PaaS semantic compatibility and interoperability among the different and usually incompatible PaaS offerings, through the Cloud4SOA platform. The Cloud4SOA semantic model defines a vocabulary, in the context of a Cloud Platform as a Service (PaaS), for expressing concepts or entities and their relationships, concerning both developer applications and PaaS offerings from different providers. The Semantic Model produced is depicted in Figure 2. Figure 2: Cloud4SOA Semantic Model [7] The Cloud4SOA semantic model is structured into 5 ontology layers: The Infrastructure layer contains definitions for concepts used to capture knowledge related to the infrastructure (hardware and software) utilized by the Platform and Application layers, as well as metrics to measure the values of hardware/software attributes. Hardware and software resources are classified by categories. Examples of hardware categories are: network, storage or processing. In case of processing, the semantic model defines equivalencies between different processing types and their measurement units. The Platform layer contains definitions for concepts used to capture knowledge related to a Cloud-based platform (e.g. supported programming language, offered software/hardware functionalities, offered APIs for programmatic access and supported communication channels, pricing policies, ratings, SLA, etc). The platform relies on the Infrastructure layer in order to operate. The Application layer contains definitions for concepts used to capture knowledge related to a Cloud-based Application during the whole application Cloud engineering cycle, such as the application description, its deployment description, its status after deployment, etc. A Cloud-based Application is developed/deployed/managed in a Cloud Platform. D 4.1 Unified Cloud Platforms Interface Model and API 15 / 76

16 The Enterprise layer contains definitions for concepts used to capture knowledge related to the enterprises involved as Cloud suppliers (e.g. PaaS providers, IaaS providers, service providers, software providers, etc) and their role in the Cloud. The User layer contains definitions for concepts used to capture knowledge related to the users of a Cloud platform, such as the Cloud-based application developers and the Cloud PaaS providers. In support of the Cloud4SOA ontology model, Cloud4SOA also created other classes, and some of them represent a common, harmonized API offering a seamless interconnection and management over the various PaaS offerings. Moreover, the API can be seen as a mediator between the PaaS offerings and Cloud4SOA system. The harmonized API is able to handle the heterogeneous provider APIs. Adaptors help to translate the functions between the harmonized API of the Cloud4SOA and the API of the PaaS vendors [7]. The REST API calls defined by Cloud4SOA according to the latest release 1 are presented in the Table 1 that follows: Table 1: REST API calls defined by Cloud4SOA HTTP method GET PUT POST DELETE GET GET GET GET PUT POST POST DELETE GET GET PUT POST DELETE GET GET GET REST call /ems/application/${applicationname /ems/application/${applicationname /ems/application/${applicationname/operation/${operationname /ems/application/${applicationname /ems /ems/application /ems/application/${applicationname/deployment /ems/application/${applicationname/deployment/${deploymentname /ems/application/${applicationname/deployment/${deploymentname /ems/application/${applicationname /ems/application/${applicationname/deployment/${deploymentname /ems/application/${applicationname/deployment/${deploymentname /ems/application/${applicationname/deployment/${deploymentname/dat abase /ems/application/${applicationname/deployment/${deploymentname/dat abase/${databasename /ems/application/${applicationname/deployment/${deploymentname/dat abase/${databasename /ems/application/${applicationname/deployment/${deploymentname/dat abase/${databasename /ems/application/${applicationname/deployment/${deploymentname/dat abase/${databasename /monitor /monitor/detail /ems/sshkey 1 D 4.1 Unified Cloud Platforms Interface Model and API 16 / 76

17 HTTP method POST DELETE /ems/sshkey /ems/sshkey REST call By analyzing the REST calls and the source code of the Harmonized API, the following artifacts have been identified: Application: Describes an application, with high level details like name, language and deployed application, after the application has been deployed. Operation: Defines the governance operations that can be managed through Cloud4SOA. Application Deployment: Describes different deployments that can use different subdomains. Database: Describes a database and the connection details needed to connect. Module: Can be used to define modules offered by PaaS offerings (although defined in source code, this artifact wasn t part of the final Harmonized API). Metric: Defines monitoring metrics with a key-value logic. SSH keys: Used for the creation of SSH keys needed by some PaaS offerings. These are also the classes that compose the Cloud4SOA Harmonized API model, which is presented in Figure 3. Figure 3: Cloud4SOA Harmonized API Model D 4.1 Unified Cloud Platforms Interface Model and API 17 / 76

18 This API will be adapted and further developed in PaaSport for the creation of the PaaSport Unified Cloud API REMICS REMICS[8] is a STREP project started in 2010 focusing on the migration of legacy systems to the cloud. It applies model-driven techniques to recover the legacy system into UML models, and then transform them into SOA models that can be deployed in a cloud setting, and continuously evolved later on. REMICS focuses on model-driven interoperability to facilitate the replacement of a migrated service with another service in case of service failure and recovery. The PIM4Cloud modeling language, which was developed during the REMICS FP7 project with focus in both private and public clouds, provides support for modeling the applications and for describing the system deployment on the cloud environment. The PIM4Cloud is implemented as a profile for UML and a meta-model which is capable to describe most of the features of a system that will be deployed in a cloud environment. It is organized in four packages in order for the way that the different elements of the meta-model have been implemented to be more understandable. The four packages are summarized as follows: Cloud Provider Domain: It describes the IaaS provider concept and it covers the modeling of the deployment of cloud applications on public and private cloud computing platforms. Cloud Application Domain: It describes the model of the technical architecture of an application. Physical Infrastructure Domain: It includes servers and networks and the entire physical infrastructure used for the deployment of the application. Resource Domain: It includes the modeling of the representation of type Property/Type ARTIST ARTIST [9], is an ongoing EU funded project that plans to reuse some of the REMICS results, and will in addition focus on the business aspect of the migration i.e., how to also modernize the business models of SME and companies migrating to the Cloud. The PIM4Cloud generic architecture (see previous sub-section) will be used in terms of resource descriptions but will be extended by implementing new subtypes mainly in resources models which are related with performance, through the metrics identified by ARTIST [10] mosaic The mosaic [11] FP7 project is one of the most relevant related work approaches with respect to PaaSport, aiming at improving the state of the art in the field of Cloud Computing. mosaic s main goal is to create, promote and exploit an open-source cloud application programming interface and a platform targeted for developing multi-cloud oriented applications. An additional key goal is to ensure transparent and simple access to heterogeneous cloud computing resources and to avoid locked-in proprietary solutions. D 4.1 Unified Cloud Platforms Interface Model and API 18 / 76

19 Furthermore, it aims to improve interoperability among existing cloud solutions, platforms and services, both from the end-user s and the developer s perspectives. Within the project, an ontology has been developed for describing services and their wrapped interfaces that consists of 15 different base classes. The underlying platform enables interoperability among different cloud services, eases the portability of the developed services on different platforms, enables the intelligent discovery of services and services composition and allows management of SLAs. The mosaic API[12] is subdivided in layers, with the native resource protocol at the bottom up to the user components at the top, as displayed in Figure 4. Figure 4: mosaic API layers [12] Table 2 shows the mosaic APIs and a short description of their functionality. Table 2: mosaic APIs API Native API Driver API Interoperability API Connector API Cloudlet API Library for a certain language, provided by the cloud vendor. Wraps the native API and allows all resources of the same type be exported with the same interface. Abstracts addressing and provides the driver API with stubs and the connector API proxies. Cloud independent API to access cloud resources. Enables developers to create components. Its focus is the lifecycle of the software component. D 4.1 Unified Cloud Platforms Interface Model and API 19 / 76

20 Figure 5: mosaic core ontology 2 This ontology provides a common definition of concepts related to Cloud domains and attempts to describe Cloud components like infrastructures, platforms and services. The defined mosaic Cloud ontology is being included in the Standard IEEE P2302 Intercloud Standard for Intercloud Interoperability and Federation (SIIF), which is also described in section SeaClouds SeaClouds [13] is an ongoing FP7 project, funded by the EU that aims at giving to organizations the capability of Agility after Development on MultiClouds Infrastructures. SeaClouds promises application lifecycle management with the ability to dynamically deploy, migrate, replicate and distribute the modules that compose cloud-based applications among multiple PaaS offerings, while checking both possible QoS violations and dynamic changes in the offer of the providers and the current demand. SeaClouds management will be focused on the PaaS level, but also takes advantage of selected monitoring indicators and management actions provided by IaaS supported by available tools. By extending and incorporating CAMP into SeaClouds, SeaClouds covers all future CAMP-compliant providers or tools, allowing application developers to manage applications hosted on multiple Clouds environments. Application packaging will be implemented using the TOSCA specification for multi-cloud applications, and deployed being CAMP-compliant. Thus results delivered by SeaClouds will be compatible with the current standards related to cloud interoperability, OASIS CAMP and TOSCA. SeaClouds seems to be relevant to PaaSport, as both share some common goals and both are focused on the PaaS paradigm. SeaClouds Open Reference Architecture is a White Paper published by SeaClouds [14] and it was examined in the scope of the project for the definition of PaaSport Unified Cloud API. 2 D 4.1 Unified Cloud Platforms Interface Model and API 20 / 76

21 3.1.2 Models produced by standardization bodies On the recent years a variety of standardization bodies have focused on Cloud computing. However OASIS Cloud Application Management for Platforms (CAMP) is the most relevant standardization attempt on the PaaS paradigm. In the following sub-sections, most related projects that have been examined and taken into account are briefly described, while CAMP, which is the most relevant and re-used in the scope of the project, is described with more technical details TOSCA The Topology and Orchestration Specification for Cloud Applications (TOSCA)[15] is an OASIS project towards enhancing the portability of cloud applications and services. TOSCA provides a standard language to describe the topology of cloud based services, components, relationships and the processes that manage them as well as the operational behavior of these services (e.g., deploy, patch, shutdown). The TOSCA approach suggests that in order to support in a certain environment the execution and management of the lifecycle of a cloud application, all corresponding artifacts have to be available in that environment. This means that besides the service template of the cloud application, the deployment artifacts and implementation artifacts have to be available in that environment. To ease the task of ensuring the availability of all of these, this specification defines a corresponding archive format called CSAR (Cloud Service ARchive). A CSAR is a container file, i.e. it contains multiple files of possibly different file types. These files are typically organized in several subdirectories, each of which contains related files (and possibly other subdirectories, etc.). The organization into subdirectories and their content is specific for a particular cloud application. CSARs are zip files, typically compressed. Each CSAR MUST contain a subdirectory called TOSCA-Metadata. This subdirectory must contain a so-called TOSCA meta file. This file is named TOSCA and has the file extension.meta. It represents metadata of the other files in the CSAR. This metadata is given in the format of name/value pairs. These name/value pairs are organized in blocks. Each block provides metadata of a certain artifact of the CSAR. All elements needed to define the TOSCA metadata are provided by TOSCA standard. The elements are the extension mechanism, the import features, the Service Templates, Node Types, Node Type Implementations, Relationship Types, Relationship Type Implementations, Requirement Types, Capability Types, Artifact Types, Artifact Templates, Policy Types and Policy Templates [15]. Although the CSAR container will not be used in the scope of PaaSport and the defined elements are not directly mapped to PaaSport, TOSCA outcomes were examined and were used in the conceptualization of the PaaSport overall solution CAMP Cloud Application Management for Platforms (CAMP)[16] is a project aimed at defining the interoperability standard of managing applications in PaaS environments. The CAMP approach is to define the artefacts and APIs that need to be offered by a Platform as a Service (PaaS) cloud for managing the building, running, administration, monitoring and D 4.1 Unified Cloud Platforms Interface Model and API 21 / 76

22 patching of applications in the cloud. Its purpose is to enable interoperability among selfservice interfaces to PaaS clouds by defining artefacts and formats that can be used to any conforming cloud and enable independent vendors to create tools and services that interact with any conforming cloud using the defined interfaces [16]. However, as CAMP is a protocol, PaaS providers that want to be CAMP compatible should either alter their API based on CAMP protocol, or use these interfaces to develop new PaaS offerings that will interact with independently developed tools and components. CAMP specification base functionality can be grouped in the following 5 major categories: i. Building and packaging an application in a local Application Development Environment (ADE). ii. Building an application in an ADE running in the cloud. iii. Importing a Platform Deployment Package into the cloud. iv. Uploading application artifacts into the cloud. v. Run, stop, suspend, snapshot, and patch an application. More specifically, for PaaS consumers the management API offers the following benefits: i. Portability between clouds, which is emerging as one of the primary concerns of cloud computing. By standardizing a management API for the use cases around deploying, stopping, starting, and updating applications, this specification increases consumers ability to port their applications between PaaS offerings. ii. It is likely that implementations of this specification will appear as plugins for ADEs and application management systems. Past experience has shown that, over time, such generic implementations are likely to receive more attention and be of higher quality than the implementations written for solitary, proprietary application management interfaces. For PaaS providers the management API offers the following benefits: i. Because the strength and features of a PaaS offering s application management API are unlikely to be perceived as key differentiators from other PaaS offerings, the existence of a consensus management API allows providers to leverage the experience and insight of the specification s contributors and invest their design resources in other, more valuable areas. ii. By increasing the portability of applications between PaaS offerings, this management API helps grow the pie of the PaaS marketplace by addressing one of the key pain points for PaaS consumers. Regarding the technical aspects, CAMP API is made up of resources in a REST protocol, representing elements of the underlying system. The protocol enables interaction with the resources through HTTP requests. The UML Class Diagram in Figure 6 illustrates the main CAMP resources. D 4.1 Unified Cloud Platforms Interface Model and API 22 / 76

23 Figure 6: Main CAMP resources. In more detail, the resources defined by CAMP are the following: Platform The platform resource is the primary view of the platform and what is running on it. The platform resource references collections of resources that represent the services provided by the platform (as Services), the applications running on this platform (as assembly resources), as well as collections of metadata resources that describe the resources supported by the platform as well as any extensions that the Provider has implemented. The platform resource also determines the scope of access for sharing amongst multiple applications. Platform Deployment Package A Platform Deployment Package (PDP) is an archive containing a Plan file together with application content files such as web archives, database schemas, scripts, source code, localization bundles, and icons; and metadata files such as manifests, checksums, signatures, and certificates. It can be used to move an Application and its Components from Platform to Platform, or between an Application Development Environment and a Platform. Overall, it provides a means for easily transferring an application and its components from Platform to Platform, or between an Application Development Environment and a Platform. Assembly An assembly resource represents running applications. Operations on an assembly resource affect the components and elements of that application. An assembly resource is comprised of one or more component resources. Component A component resource represents a discrete and, in most cases, dynamic element of an application such as such as a deployed Ruby gem, a database instance, or a set of entries in a D 4.1 Unified Cloud Platforms Interface Model and API 23 / 76

24 LDAP directory. A component resource can be related to other component resources through producer/consumer or other kinds of relationships. Plan A Plan is meta-data that provides a description of the artifacts that make up an application, the services that are required to execute or utilize those artifacts, and the relationship of the artifacts to those services. Plans can be expressed in two forms; either as a YAML file or, optionally, as a CAMP resource. The Artifacts described in a Plan represent discrete, static elements of an application such as a Ruby gem file, an SQL script, or a PKCS #12 file. Service A service resource represents a blueprint for creating component resources that utilize or embody a platform-provided service in some way. For example, a Service may represent the platform s ability to create a message queue for use by an application. Operation Operations provide a way of interacting with an application through the CAMP API. An operation resource represents actions that can be taken on a resource. Sensor A sensor resource represents dynamic data about resources, such as metrics or state. A sensor resource is useful for exposing data that changes rapidly, or that might need to be fetched from a secondary system. A sensor resource can also offer Operations to allow resetting metrics, or adjusting frequency collection settings. The combination of Operations and Sensors enables ongoing management. Multiple operation resources and sensor resources can be exposed both on assembly resources and component resources. Parameters Parameters can be defined on the assemblies resource, services resource, and, if supported, plans resource. Parameters affect the resources that are generated from these resources. The design and structure of CAMP resources (i.e. classes) enabled us to identify key attributes that need to be integrated in PaaSport models in order to properly represent application aspects. Also as PDP ensures portability across multiple platforms by defining the formats for on-boarding new applications onto a CAMP-compliant Provider it can be further exploited by PaaSport IEEE P2302 IEEE P2302 Intercloud Standard for Intercloud Interoperability and Federation (SIIF) creates an economy amongst cloud providers that is transparent to users and applications, which provides for a dynamic infrastructure that can support evolving business models. In addition to the technical issues, an appropriate infrastructure for economic audit and settlement must exist. This standard defines topology, functions, and governance for cloudto-cloud interoperability and federation. Topological elements include clouds, roots, exchanges (which mediate governance between clouds), and gateways (which mediate data exchange between clouds). Functional elements include name spaces, presence, messaging, resource ontologies (including standardized units of measurement), and trust infrastructure. D 4.1 Unified Cloud Platforms Interface Model and API 24 / 76

25 Governance elements include registration, geo-independence, trust anchor, and potentially compliance and audit. The standard does not address intra-cloud (within cloud) operation, as this is cloud implementation-specific, nor does it address proprietary hybrid-cloud implementations [17]. Also, mosaic Cloud ontology has been included in this standard creation [18]. Figure 7: Cloud Computing Resources Ontology Conclusion Although all the presented initiatives refer to models that can be used for describing PaaS offerings, most of them are not closely related to the PaaS API model. Regarding EU funded projects the models representing the Cloud4SOA Unified API and the mosaic Interoperability API are the most relevant; this is why they are important for developing the PaaSport Unified Platforms Interface model and the PaaSport Unified Cloud API. Regarding standardization bodies, although none is directly linked to PaaS APIs, CAMP is the most promising initiative, has the most common features with real PaaS providers APIs and will thus be used for the modeling purposes of the PaaSport Unified Platforms Interface Model. 3.2 Elaboration on APIs of existing PaaS Providers This section reports the current State of the Art in PaaS platforms, by focusing on the available PaaS offerings and their diversities regarding the API they provide. This way, the fact that current Cloud computing solutions have not been built with interoperability as a 3 IEEE P2302 D0.2, working draft, subject to change D 4.1 Unified Cloud Platforms Interface Model and API 25 / 76

26 primary concern will become more obvious. More detailed analysis is done for the open source PaaS solutions, as they can be used both for private cloud installations and for different public offerings. For the elaboration of the state-of-the-art analysis, different PaaS offerings APIs have been analyzed. The main goals of the analysis were the definition of entities used in each PaaS API and the identification of the most important REST calls of each API Cloud Foundry Cloud Foundry[19] is an open source cloud computing platform as a service (PaaS) developed by Pivotal Software - a joint venture by EMC, VMware and General Electric. Figure 8: Cloud Foundry logo Deploying Cloud Foundry to private clouds is possible as well as some public clouds offered as commercial products (Pivotal CF, AppFog, Stackato and IBM BlueMix). The supported frameworks (Cloud Foundry buildpacks) are provided in Table 3. More buildpacks can be created for specific languages, runtimes or frameworks. Table 3: Cloud Foundry supported languages, runtimes and frameworks. Language Runtime Framework Java Java 6, Java 7, Java 8 Spring Framework 3.x, 4.x Ruby Ruby 1.8, Ruby 1.9, Ruby 2.0 Rails, Sinatra Node.js V8 JavaScript Engine Node.js Scala Scala 2.x Play 2.x, Lift Python PHP Python PHP Applications deployed to Cloud Foundry access external resources via Services. In a Cloud Foundry environment, all external dependencies such as databases, messaging systems and file systems are Services. When an application is pushed to Cloud Foundry, the user can specify the services it should also use. Depending on the application language, autoconfiguration of services is possible (for example a Java application requiring a MySQL database will pick up the MySQL service on Cloud Foundry if it is the only one defined in the current Space). Services have to be deployed to the platform first and then are available to D 4.1 Unified Cloud Platforms Interface Model and API 26 / 76

27 any application using it. Cloud Foundry offers many pre-defined services that can be deployed directly via the web interface or the API. Users of the Open Source Cloud Foundry must make services available by writing and running BOSH scripts. I. Defined Entities Based on the analysis contacted on Cloud Foundry API [20], the following entities that are presented in Table 4 have been identified: Table 4: Cloud Foundry identified entities Entity App Buildpack Files Info Jobs Organization Domain (Private/Shared) Route Security Group Service Service Binding Service Broker Service Instance Service Plan Applications deployed by the user. Applications typically depend on services, such as databases or third-party SaaS providers. When a developer provides and binds a service to an application, the service broker for that service is responsible for providing the service instance. Buildpacks provide framework and runtime support for applications. Buildpacks typically examine user-provided artifacts to determine what dependencies to download and how to configure applications to communicate with bound services. Files available in Cloud Foundry. Encapsulates current information of the App. Gives the ability to schedule jobs to run in the PaaS offering. An organization ( org ) consists of users grouped together for management purposes. All members of an organization share a resource quota plan, services availability, and custom domains. Represents domain names like example.com. Domains can also be multi-level and contain sub-domains like the myapp in myapp.example.com. Domain objects belong to an organization and are not directly bound to apps. A route, based on a domain with an optional host as a prefix, may be associated with one or more applications. For example, myapp is the host and example.com is the domain when using the route myapp.example.com. It is also possible to have a route that represents example.com without a host. Routes are children of domains and are directly bound to apps. Security groups define all the network security parameters needed for a deployed application. Services that Apps can use. New services can be integrated with Cloud Foundry by implementing the Service Broker API. Bindings of deployed services with deployed applications. Service Broker is the term we use to refer to a component of the service which implements the service broker API. A reserved resource provisioned by a service. The resource provisioned will differ by service; could be a database or an account on a multi-tenant application. Plan that can be applied to a service D 4.1 Unified Cloud Platforms Interface Model and API 27 / 76

28 Space Stack User Environment Variable Group Every application and service is scoped to a space. Each org contains at least one space. A space provides to a set of users access to a shared location for application development, deployment, and maintenance. Each space role applies only to a particular space. A stack is a prebuilt file system, including an operating system that supports running applications with certain characteristics. Currently, Cloud Foundry supports one stack, called lucid64, that is based on Ubuntu bit system and contains a number of common programs and libraries including MySQL, PostgreSQL, sqlite, imagemagick, Git, ruby. A user can have one or more roles. The combination of these roles defines the user s overall permissions in the org and within specific spaces in that Organization. Encapsulates information of Services and Applications that has been set in the form of environmental variables. II. Most Important API calls Based on the analysis contacted on Cloud Foundry API[20], the following API calls have been identified: Create / Retrieve / Update / Delete Users Create / Retrieve / Update / Delete / Start / Stop Applications Create / Retrieve / Update / Delete Keys Create / Retrieve / Update / Delete Domains Create / Retrieve / Update / Delete Routes Create / Retrieve / Update / Delete Security Groups Create / Retrieve / Update / Delete Service Instance Create / Retrieve / Update / Delete Service Binding Retrieve Information Retrieve File As Cloud Foundry is open source, many PaaS providers use it as a basis for their own PaaS offerings. Pivotal CF, AppFog, Stackato and IBM BlueMix are the major public clouds recognized and presented as follows Pivotal CF Pivotal CF is commercial product available from Pivotal. It is based on Cloud Foundry but provides extra tools for installation and administration not included in the Open Source Cloud Foundry. Pivotal CF can be used to rapidly set up and manage a PaaS environment on a various choice of infrastructure - including private data centers. Figure 9: Pivotal CF logo D 4.1 Unified Cloud Platforms Interface Model and API 28 / 76

29 AppFog / CenturyLink Cloud AppFog is a Cloud Platform for web applications that has been built on Cloud Foundry. Figure 10: AppFog logo CenturyLink had created a PaaS product built on Cloud Foundry and Iron Foundry. The latter is an open source project started by CenturyLink Cloud to extend Cloud Foundry to the.net ecosystem. However, after acquiring AppFog, CenturyLink Cloud has been enhanced as CenturyLink Technology Solutions and AppFog has committed to meeting the needs for public cloud PaaS deployments and most recently to private PaaS as well. Both products are based on Cloud Foundry and extend it in similar ways. CenturyLink cloud extends CF with support for some languages that are unavailable in any other PaaS today, as Erlang and.net CLR v2 and v Stackato ActiveState Stackato is a commercial Platform-as-a-Service (PaaS) that is built on Cloud Foundry and utilizes Docker for its Linux Containers (LXC). Figure 11: Stackato logo ActiveState is a Cloud Foundry partner, Community Lead for Python, member of the Cloud Foundry Community Advisory Board (CAB), and a founding gold member of the Cloud Foundry foundation. Stackato shares the same architecture, concepts and API as Cloud Foundry, but some components have been modified and extended to suit the specific needs of enterprise customers and OEM partners IBM BlueMix IBM Bluemix 4 is a cloud platform as a service (PaaS) developed by IBM. It supports several programming languages and services as well as integrated DevOps to build, run, deploy and manage applications on the cloud. 4 D 4.1 Unified Cloud Platforms Interface Model and API 29 / 76

30 Figure 12: IBM BlueMix logo BlueMix is based on Cloud Foundry open technology and runs on SoftLayer infrastructure. BlueMix supports Java, Node.js, Ruby and can be extended to support other languages such as PHP, Python or Scala. In addition to the services that Cloud Foundry already supports, BlueMix adds pre-packaged services and capabilities on top of the Cloud Foundry itself. These add-on capabilities include among others Messaging Service (WebSphere MQ based), SQL Service (DB2 based), Cache Service, Big Data service, Analytics Service, Mobile Service, Connector Services, Data Transformation Services and Non-Relational DB service. As BlueMix is based on CloudFoundry, concepts and API functions defined by CloudFoundry also apply to BlueMix Red Hat OpenShift OpenShift is an open-source PaaS solution from Red Hat. Source code is offered for private installations as OpenShift Origin and Red Hat also offers the OpenShift Online version as public cloud. Figure 13: OpenShift logo Developers can use Git to deploy web applications in different languages on the platform. OpenShift provides a wide range of languages and services, deployed in applications through a cartridge. Cartridges can be web frameworks, databases, monitoring services, or connectors to external back-ends. By packaging services and frameworks within a cartridge, developers and administrators can focus on the delivery of their code and the security of their systems. The supported languages, servers and databases are provided in Table 5. With the creation of new cartridges, this list can be extended. Table 5: OpenShift supported languages, servers and databases. Supported Servers JBoss EAP, JBoss AS / Wildfly Tomcat (JBoss EWS) Jenkins SwitchYard D 4.1 Unified Cloud Platforms Interface Model and API 30 / 76

31 Cron Supported Languages PHP Python Ruby Node.js Vert.x Perl Supported Databases MongoDB MySQL PostgreSQL I. Defined Entities Based on the analysis contacted on OpenShift, the following entities that are presented in Table 6 have been identified: Table 6: OpenShift identified entities Entity Domains Applications Application Aliases Cartridge User Subscription plan SSH Keys A domain must be created before an OpenShift application can be created. Domain names on OpenShift are non-strict, meaning there is no preceding period, and form part of the application name. Therefore, the syntax for the application name is ApplicationName DomainName.rhcloud.com. Each username can only support a single domain, but multiple applications can be created within a domain. Applications deployed by users. Aliases allow users to use their custom domain names on applications deployed on OpenShift. OpenShift cartridges provide the necessary command and control for the functionality of software that is running users' applications. OpenShift currently has many language cartridges (JBoss EAP, JBoss EWS, PHP, Ruby, Rails, etc.) as well as many DB cartridges (Postgres, Mysql, Mongo, etc.). More cartridges can be written in order to extend OpenShift functionalities. Cartridge configuration and setup is convention based, with an emphasis on minimizing external dependencies in cartridge code. The user that has been registered to OpenShift and is given the ability to deploy applications under a specific domain. For OpenShift Online, there are different pricing options that define different subscription plans. Each plan provides certain capabilities that are assigned when users subscribe to a particular plan. Currently the free and silver plans are offered, with each offering different capabilities that determine what type of resources are available to the user. SSH keys are used in order to authenticate user and give the ability to OpenShift to connect with Git repositories. D 4.1 Unified Cloud Platforms Interface Model and API 31 / 76

32 II. Important REST calls Based on the analysis contacted on OpenShift API[23], the following API calls have been identified: Retrieve User Information Create / Retrieve /Update / Delete / Start / Stop / Scale Up / Scale Down Application Check DNS availability Create / Retrieve /Update / Delete SSH Keys Create / Retrieve /Update / Delete Domains Create / Retrieve /Update / Delete Application Aliases List Cartridges Create / Retrieve /Update / Delete / Start / Stop Cartridge Apache Stratos Apache Stratos[24] is a highly-extensible open source PaaS framework supported by the Apache community that helps run Apache Tomcat, PHP, and MySQL applications and can be extended to support many more environments on all major cloud infrastructures. Figure 14: Apache Stratos logo For developers, Stratos provides a cloud-based environment for developing, testing, and running scalable applications. IT providers benefit from high utilization rates, automated resource management, and platform-wide insight including monitoring and billing. One of the advantages Stratos promises is the high interoperability by supporting heterogeneous IaaS environments, multiple application platforms, languages, and frameworks. The Apache Stratos cartridge model and jcloud abstraction layer enables deployment on popular IaaS environments (Amazon AWS, OpenStack, vcloud), and teams can incorporate their preferred application servers via cartridge extensions. The cartridge model enables runtime extensibility and polyglot support for any desired programming language, platform framework, or server. By creating a cartridge or choosing pre-built cartridge options, teams may easily deploy traditional application platform software into a managed PaaS environment. Apache Stratos supports in-container multi-tenancy, which optimizes resource utilization, lowers tenant footprints, and efficiently supports PaaS deployments serving large-scale customer bases (hundreds of thousands or millions of tenants) and also supports both http and non-http based auto scaling. Finally, Apache Stratos includes a Cloud-native load balancer and policy-aware load balancing algorithms that analyze traffic by tenant, service, D 4.1 Unified Cloud Platforms Interface Model and API 32 / 76

33 and partition. The Apache Stratos PaaS framework will also integrate with any on-premise third party load balancer and external, hybrid cloud traffic balancers through a message broker component and will auto-scale Cloud instances across a diverse hybrid environment while respective quality of service policies. I. Defined Entities Based on the analysis contacted on Apache Stratos [25], the following entities that are presented in Table 7 have been identified: Table 7: Apache Stratos identified entities Entity Tenants Cartridge Cartridge Instance Partition Auto-Scaling Policy Load Balancing Cartridge A tenant is a group of users sharing the same view of Apache Stratos installation. Multitenancy of Stratos offers both container and incontainer multi-tenancy capability. A cartridge is a virtual machine (VM) on an IaaS that has software components to interact with Apache Stratos PaaS. Apache Stratos provides cartridges for PHP, MySQL and Tomcat based applications on OpenStack and Amazon EC2 out of the box. Cartridges will vary based on the operating system (OS) and IaaS. Therefore, for each OS and IaaS a custom cartridge should be created. All cartridges in Apache Stratos provide a very secure, OS level isolated environment for cloud applications. Cartridges can operate in two modes: Single tenant and Multi-tenant. Furthermore, the cartridge type will vary based on the method it has been created: Generic cartridge and Fully-configured cartridge. In a live Stratos environment each virtual machine (VM) is known as a cartridge instance in Stratos terminology. If a tenant user subscribes to a single tenant cartridge, a separate cartridge instance will be spawned for each tenant user thus providing tenant users process level isolation and instance level dedicated tenancy. Multi-tenant cartridges in Apache Stratos are cartridges that allow multiple tenants to share a single cartridge instance. A partition depicts the division in an IaaS and defines an area of an IaaS cloud used by a service subscription. A partition can be made at one of the following levels: Provider level, Region level, Zone level or Rack level. A partition should at least have a provider defined. If required, partition groups can be defined in the partition definition. DevOps, for the purpose of high availability, can define multiple partitions in order to instruct Apache Stratos to spawn instances in multiple areas (e.g., region, zone or rack). For example, if you spawn instances in multiple availability zones in EC2, your system will be still functional even if one availability zone is down. The auto-scaling policy is one of the most important parts of Stratos and can be configured based on needs As Apache Stratos has a default Load Balancer and also as a cartridge can be deployed without a Load Balancer, it is not mandatory to D 4.1 Unified Cloud Platforms Interface Model and API 33 / 76

34 Deployment Policy deploy a Load Balancer cartridge. Deployment policy defines the design of the partitions and partition groups (network partitions) used in the PaaS. Partitions are defined in Apache Stratos to manage the instance count. Thereby, when defining the deployment policy the maximum number of instances allowed in a partition per cartridge subscription and the minimum number of instances allowed in a partition per cartridge subscription is specified. II. Important REST calls Based on the analysis contacted on Apache Stratos API [25], the following API calls have been identified: Add a tenant / list all the tenants Deploy a partition / list all the partitions Deploy an auto-scaling policy definition / list the auto-scaling policies Deploy a deployment policy definition / list deployment policies Deploy a multi-tenant service cluster /undeploy a multi-tenant service cluster Deploy a cartridge definition / undeploy a cartridge definition List all the available cartridges (single tenant and multi-tenant) Subscribe to a cartridge / List all the subscribed cartridges Retrieve information on a cartridge that is already subscribed to by a user Retrieve cluster details of a specific cluster Unsubscribe from a cartridge Manually synchronize the GIT repository for subscribed cartridges As Apache Stratos is an open source project, PaaS providers can use it as a basis of their own PaaS offering. WSO2 App Factory and WSO2 App Cloud have been are based on Apache Stratos and are presented in the following section WSO2 App Factory / WSO2 App Cloud WSO2 offers App Factory, a PaaS-enabled DevOps platform for the enterprise providing a set of integrating tools for creating, managing and governing applications along with the necessary runtimes to run those applications in the cloud. Figure 15: WSO2 Cloud logo WSO2 Private PaaS delivers standard, on-premise, application, integration, data, identity, governance, and analytics PaaS to IT project teams. It is a multi-tenant, self-service, metered, middleware cloud built on top of the Apache Stratos project. It also adds functionality to host pre-integrated, fully multi-tenant WSO2 Carbon middleware products as cartridges that deliver a wide range of cloud PaaS. D 4.1 Unified Cloud Platforms Interface Model and API 34 / 76

35 Based on App Factory, a public cloud called WSO2 App Cloud is also offered Google App Engine Google App Engine 5 (GAE) is a PaaS offering that lets users build and run applications on Google s infrastructure. Figure 16: Google App Engine logo App Engine applications are easy to build, easy to maintain, and easy to scale as traffic and data storage needs change. GAE is also focused into making easy to use Google Services when creating an application. This however leads to applications that are not portable to other PaaS offerings, although some providers like AppScale promise portability of GAE applications [26]. Regarding its API, GAE offers a RESTful API that supports server lifecycle management, threading and namespaces/multitenancy[27]. Also management of Google Services is offered through REST calls Heroku Heroku is a public PaaS supporting several programming languages and one of the first cloud platforms, as it has been in development since June 2007 and was acquired by Salesforce.com in It supports Ruby, Java, Node.js, Scala, Clojure, Python and PHP and Perl. Heroku offers a PaaS provider to build maintainable and scalable applications without worrying about the infrastructure. Figure 17: Heroku logo The base operating system is the Debian-based Ubuntu. The secure container inside a Heroku instance is called Dyno. A Dyno is like a virtualized UNIX container to run user application components. Three different Dyno sizes are available, each size having different memory and CPU characteristics. Languages or frameworks support is offered by means of Buildpacks: Ruby, Python, Java, Clojure, Node.js and Scala are all implemented as buildpacks. 5 D 4.1 Unified Cloud Platforms Interface Model and API 35 / 76

36 I. Defined Entities Based on the analysis contacted on Heroku [28], the following entities that are presented in Table 8 have been identified: Table 8: Heroku identified entities Entity Organization Organization member Account Add-on service Add-on App Domain Dyno Source Stack Plan Slug Build Keys Env vars Organizations allow you to manage access to a shared group of applications across your development team. An organization member is an individual with access to an organization. An account represents an individual signed up to use the Heroku platform. An account feature represents a Heroku labs capability that can be enabled or disabled for an account on Heroku. Add-on services represent add-ons that may be provisioned for apps. Endpoints under add-on services can be accessed without authentication. Add-ons represent add-ons that have been provisioned for an app. An app represents the program to be deployed and run on Heroku. Domains define what web routes should be routed to an app on Heroku. Dynos encapsulate running processes of an app on Heroku. A source is a location for uploading and downloading an application s source code. Stacks are the different application execution environments available in the Heroku platform. Plans represent different configurations of add-ons that may be added to apps. Endpoints under add-on services can be accessed without authentication. A slug is a snapshot of your application code that is ready to run on the platform. A build represents the process of transforming a code tarball into a slug Keys represent public SSH keys associated with an account and are used to authorize accounts as they are performing Git operations. Env vars allow the management of the configuration information provided to an app on Heroku, while mixing in rich annotations on them. II. Important REST calls Based on the analysis contacted on Heroku API [28], the following API calls have been identified: Retrieve User Information Create / Retrieve /Update / Delete / Start / Stop Application Create / Retrieve /Update / Delete SSH Keys Create / Retrieve /Update / Delete Domains D 4.1 Unified Cloud Platforms Interface Model and API 36 / 76

37 List Stacks Build Application Get environment variables for application List existing add-on-services. Create add-on / Delete add-on / List add-on (Add-on on Heroku represent add-ons services that have been provisioned for a specific app.) AWS Elastic Beanstalk Amazon with AWS offers reliable and scalable cloud computing services, and AWS comprises dozens of services, each of which exposes an area of functionality. While the variety of services offers flexibility for how you want to manage your AWS infrastructure, it can be challenging to use all services together. For this reason AWS Elastic Beanstalk is a PaaS offered from Amazon Web Services and allows users to create applications and push them to a definable set of AWS services, including Amazon EC2, Amazon S3, Amazon Simple Notification Service (SNS), Amazon CloudWatch, auto scaling, and elastic load balancers. Figure 18: Amazon Elastic Beanstalk logo AWS Elastic Beanstalk supports a wide range of programming languages and databases. I. Defined Entities Based on the analysis contacted on Amazon Elastic Beanstalk [29], the following entities that are presented in Table 9 have been identified: Table 9: Amazon Elastic Beanstalk identified entities Entity Application Application Version Instance Environment Environment Resource Configuration Option StorageLocation / S3Location Events AutoScaling SolutionStack Describes the properties of an application. Describes the properties of an application version. The description of an Amazon EC2 instance. Describes the properties of an environment. Describes the AWS resources in use by this environment. Describes the possible values for a configuration option. Specification of a location in Amazon S3. Describes the logging functionalities provided with events filtering. Describes an Auto Scaling launch configuration. Describes the whole stack that is deployed for the specific solution. D 4.1 Unified Cloud Platforms Interface Model and API 37 / 76

38 II. Important REST calls Based on the analysis contacted on Amazon Elastic Beanstalk API [29], the following API calls have been identified: CheckDNS name Availability Restart Application Server Create Application / Delete Application / Get Applications / Update Application Create Application Version / Delete Application Version / Get Application Versions / Update Application Version Create Environment / Terminate Environment / Get Environments / Update Environment / Create Storage Location Describe Events Describe Configuration Options / Describe Configuration Settings / Describe Environment Resources / Delete Environment Configuration List Available Solution Stacks Request Environment Info / Retrieve Environment Info CloudBees CloudBees offers a PaaS that can build, run, and manage web applications. CloudBees was the first production PaaS to support the entire application lifecycle from development to deployment, and consisted from two different solutions, DEV@Cloud and RUN@Cloud. DEV@Cloud is a framework that allows not only deploying an application in the cloud like a traditional PaaS, but also allowing continuous integration of a project in the cloud. It offers Jenkins as a Service along with maven, SVN and Git implementations. RUN@Cloud, on the other hand, is a traditional PaaS offering. Figure 19: CloudBees logo However, as CloudBees plans to focus exclusively on the Jenkins market and ecosystem, and as a part of its strategic shift to Jenkins, CloudBees will be retiring its RUN@cloud. CloudBees has set a deadline for users to transition off of RUN@cloud by the end of December 2014 and offered transition assistance to its customers through October 31, This caused the removal of CloudBees from list of PaaS that is possible to use through PaaSport. 6 D 4.1 Unified Cloud Platforms Interface Model and API 38 / 76

39 3.2.8 cloudcontrol cloudcontrol 7 is a European PaaS based in Berlin, Germany. Although cloudcontrol is programming language agnostic, the officially supported languages for development and deployment are Java, PHP, Python and Ruby via the open buildpack API originally developed by Heroku. Custom buildpack support has been announced for The platform supports multiple environments for production, staging or development for each app. Figure 20: cloudcontrol logo I. Defined Entities Based on the analysis contacted on cloudcontrol API [33], the following entities that are presented in Table 10 have been identified: Table 10: cloudcontrol identified entities Entity App User Deployment Deployment Worker Addon Version Environment Alias Key Applications created by users. The user that has been registered to cloudcontrol and has been given the ability to create and deploy applications. Application deployments. Mechanism that configures and automates deployments. Addons are services offered as add-ons from the PaaS offering. Versioning of the deployment. Development, Staging and Production Environments are offered for deployment of applications Aliases allow users to use their custom domain names on applications deployed on cloudcontrol. Keys represent public SSH keys associated with an account and are used to authorize accounts as they are performing Git operations. II. Important REST calls Based on the analysis contacted on cloudcontrol API [33], the following API calls have been identified: Create a new user / Delete user / Get user details. Create a new application / Delete an application / Get application details Get list of applications Add a key to User / Remove key 7 D 4.1 Unified Cloud Platforms Interface Model and API 39 / 76

40 Create a new deployment / Get deployment details / Update a deployment (deploy new versions) Get a deployment's log Creates an alias for a deployment / Get deployment aliases / Delete Alias Return list of all Addons Add an Addon to a deployment Add a user to an application / Remove a user from an application. 3.3 Common PaaS Characteristics and Functionalities As already clarified, interoperability is related to the ability of the brokerage platform to alleviate and harmonize the diversification and inconsistencies that exist at the API-level of the various PaaS offerings regarding semantically-equivalent functions. In other words, interoperability targets the harmonization of the PaaS APIs [2]. For this reason, the objective here is to identify the common PaaS API characteristics and entities and create the Unified Platforms Interface Model. PaaS APIs have major differences on the functionalities they support, but also diversities can refer to the functional abstractions they make, the entities that they identify, differences on programming models and syntax PaaSport Unified Platforms Interface Model Based on the analysis of the PaaS offerings API and the outcomes of the initiatives related to PaaS, the following entities have been identified to be used by PaaSport for the definitions of PaaSport Unified Platforms Interface Model and Unified Cloud API. Common Entities The first step for the definition of PaaSport Unified Platforms Interface Model and the Unified Cloud API is to define common entities that have been identified and are presented in Table 11 that follows: Table 11: PaaSport defined entities Entity Application User Container Deployment It describes the application. It can be used for the application creation and lifecycle management. For the application lifecycle management the following functionalities are supported: Manage {start, stop, restart, check name availability Scale {up, down, auto, off Monitor {get status and information User that can manage PaaS and application The container that defines the underlying platform with details available at PaaS level. These details can be the application server, installed runtimes, or OS installed packages. These refer to Buildpacks of Cloud Foundry, Cartridges of OpenShift and Stacks of Heroku. The application resources to be deployed (source or packaged code, D 4.1 Unified Cloud Platforms Interface Model and API 40 / 76

41 Package Service Service Binding Domain Security Policy Key dependencies, etc). This entity has been based on the PDP entity of CAMP specification. Services offered by PaaS offering. Commons services are relational databases, NoSQL databases, queuing and messaging services. Relevant to the Component entity of CAMP specification. Binding of a deployed Service to a deployed application. Relevant to the Service entity of CAMP Specification. Domains that a created application can use. Defines the policy of network security for specific created application. Keys associated with an User account Based on the identified entities, the model depicted in Figure 21 has been developed. Figure 21: PaaSport Unified Platforms Interface Model D 4.1 Unified Cloud Platforms Interface Model and API 41 / 76

42 3.3.2 Overview of offered PaaS functionalities from public APIs Common functionalities offered by PaaS in terms of public APIs are generally based on Create, Retrieve, Update and Delete (CRUD) functions on the identified common concepts. Apart from these, some functionalities related to application lifecycle management, application scalability and application information have been identified as common. For lifecycle management the application start, stop are the usual functions offered from public API, and also sometimes a restart function is present. For scalability purposes the following options have been identified: Scale Up, Scale Down, Off and Auto. Finally for monitoring all providers provide some of information regarding the application and its status. These functionalities can be encapsulated in a common API that can be used for cloud interoperability. 3.4 Unified Cloud API specification Based on the Unified Platforms Interface model, a REST API is defined as a reference implementation. This API is called the PaaSport Unified Cloud API API Methods Overview The entities of Unified Cloud API are the same with the Unified Platforms Interface model. For most of them CRUD methods have been created and apart from these, some functionalities related to application lifecycle management, application scalability and application information have been created as well. However, as not all PaaS offerings support the same functionalities, the fact that defined Unified Cloud API methods are not supported by all providers is an expected difficulty. For this reason the most important methods of Unified Cloud API have been also identified. If a PaaS offering does not support at least these methods through API, it cannot be registered to PaaSport marketplace. In Table 12 the defined REST calls that comprise the Unified Cloud API are presented. Also the table presents the methods that PaaSport expects to be supported from PaaS offerings for providing the basic functionality through a common API. Table 12: Unified Cloud API REST calls overview Method Expected Support from PaaS Create Application Needed Retrieve Application Needed Update Application Where available Delete Application Needed Get List of Applications Where available Manage Application Needed Scale Application Where available Monitor Application Needed Create User Where available Retrieve User Where available D 4.1 Unified Cloud Platforms Interface Model and API 42 / 76

43 Update User Delete User Add Key Delete Key Create Container Retrieve Container Update Container Delete Container List available Containers Create Deployment Package Retrieve Deployment Package Update Deployment Package Delete Deployment Package Create Service Retrieve Service Update Service Delete Service Get List of Available Services Create Service Binding Retrieve Service Binding Update Service Binding Delete Service Binding Get List of Bound Services Create Domain Retrieve Domain Update Domain Delete Domain Get List of configured Domains Create Security Policy Retrieve Security Policy Update Security Policy Delete Security Policy Get List of configured Security Policies Where available Where available Where available Where available Where available Where available Where available Where available Where available Needed Where available Needed Where available Where available Needed Where available Where available Needed Needed Where available Where available Needed Where available Where available Where available Where available Where available Where available Where available Where available Where available Where available Where available Defined Methods Details This chapter provides a detailed description of the methods. For each method of the Unified Cloud API the details of the REST call are presented in a separate table. The used HTTP methods are POST, GET, PUT, and DELETE. These correspond to create, read, update, and delete (or CRUD) operations, respectively. The POST method is utilized for creation of new resources. The HTTP GET method is used to retrieve (or read) a representation of a resource. PUT is utilized for update capabilities, PUT-ing to a known resource URI with the request body containing the newly-updated representation of the original resource. DELETE is used to delete a resource identified by a URI. D 4.1 Unified Cloud Platforms Interface Model and API 43 / 76

44 Create Application Table 13: Create an application Create an Application /Application POST Sample Request Body { "applicationname": "appname", "applicationurl": "appurl", "Container":{ "containertype":"containertype", "User": { "useridentifier": "identifier", "credentials":{"publickey": "public", "privatekey": "private" Sample Response Body { "applicationidentifier":"identifier", "result": "success", "description": " Success ", " status ": Retrieve Application Table 14: Retrieve an application Retrieve Application details /Application GET Sample Request Body - Sample Response Body { "applicationidentifier":"identifier", "applicationname": "appname", "applicationurl": "appurl", "Container":{ "containertype":"containertype" D 4.1 Unified Cloud Platforms Interface Model and API 44 / 76

45 Update Application Table 15: Update an application Update an Application /Application PUT Sample Request Body [ { "applicationidentifier":"identifier", "applicationname": "appname", "applicationurl": "appurl", "Container":{ "containertype":"containertype", "User": { "useridentifier": "identifier", "credentials":{"publickey": "public", "privatekey": "private" ] Sample Response Body { "result": "success", "description": " Success ", " status ": Delete Application Table 16: Delete an application Delete an Application /Application DELETE Sample Request Body - Sample Response Body { "result": "success", "description": " Success ", " status ": 200 D 4.1 Unified Cloud Platforms Interface Model and API 45 / 76

46 Get List of Applications Table 17: Get List of Applications Get application lists /Application/List GET Sample Request Body - Sample Response Body [ { "applicationidentifier":"identifier", "applicationname": "appname", "applicationurl": "appurl", "Container":{ "containertype":"containertype", { "applicationidentifier":"identifier2", "applicationname": "appname", "applicationurl": "appurl", "Container":{ "containertype":"containertype", ] Manage Application State Table 18: Manage application state Manage an Application s state (Start, Stop, Restart) /Application/Manage POST Sample Request Body { "applicationidentifier":"identifier", "operation":"stop", "User": { "useridentifier": "identifier", D 4.1 Unified Cloud Platforms Interface Model and API 46 / 76

47 "credentials":{"publickey": "public", "privatekey": "private" Sample Response Body { "result": "success", "description": " Success ", " status ": Scale Application Table 19: Scale an application Scale an Application (Scale Up, Scale Down, Auto, Off) /Application/Manage POST Sample Request Body { "applicationidentifier":"identifier", "scaleoption":"auto", "User": { "useridentifier": "identifier", "credentials":{"publickey": "public", "privatekey": "private" Sample Response Body { "result": "success", "description": " Success ", " status ": Monitor Application Table 20: Monitor an application Get Application status and information /Application/Monitor POST Sample Request Body { D 4.1 Unified Cloud Platforms Interface Model and API 47 / 76

48 "applicationidentifier":"identifier", "monitoringoption":"default", "User": { "useridentifier": "identifier", "credentials":{"publickey": "public", "privatekey": "private" Sample Response Body { "result": "success", "description": " Success ", " status ": Create User Table 21: Create a User Create a new User /User POST Sample Request Body { "User": { "useriname": "username", "credentials":{"publickey": "public", "privatekey": "private" Sample Response Body { "useridentifier": "identifier", "result": "success", "description": " Success ", " status ": Retrieve User Table 22: Retrieve a user Retrieve User details /User GET D 4.1 Unified Cloud Platforms Interface Model and API 48 / 76

49 Sample Request Body - Sample Response Body { "User": { "useridentifier": "identifier", "credentials":{"publickey": "public", "privatekey": "private" Update User Table 23: Update a user Update a User /User PUT Sample Request Body { "User": { "useridentifier": "identifier", "credentials":{"publickey": "public", "privatekey": "private" "username":"username", Sample Response Body { "result": "success", "description": " Success ", " status ": Delete User Table 24: Delete a User Delete a User /User DELETE Sample Request Body - D 4.1 Unified Cloud Platforms Interface Model and API 49 / 76

50 Sample Response Body { "result": "success", "description": " Success ", " status ": Add Key Table 25: Add Key Add a Ssh key for a user /Key POST Sample Request Body { "Key":{ "sshkey":"value", "User": { "useridentifier": "identifier", "credentials":{"publickey": "public", "privatekey": "private" Sample Response Body { "keyidentifier": "identifier", "result": "success", "description": " Success ", " status ": Delete Key Table 26: Delete a key Delete a key /Key DELETE Sample Request Body - Sample Response Body { D 4.1 Unified Cloud Platforms Interface Model and API 50 / 76

51 "result": "success", "description": " Success ", " status ": Create Container Table 27: Create a new Container Create a new Container /Container POST Sample Request Body { "Container":{ "server":"servertype", "runtime":"runtime", "User": { "useridentifier": "identifier", "credentials":{"publickey": "public", "privatekey": "private" Sample Response Body { "containeridentifier":"identifier", "result": "success", "description": " Success ", " status ": Retrieve Container Table 28: Retrieve a container Retrieve Container details /Container GET Sample Request Body - Sample Response Body { "Container":{ D 4.1 Unified Cloud Platforms Interface Model and API 51 / 76

52 "containeridentifier":"identifier", "server":"servertype", "runtime":"runtime" Update Container Table 29: Update a container Update a Container /Container PUT Sample Request Body { "Container":{ "containeridentifier":"identifier", "server":"servertype", "runtime":"runtime", "User": { "useridentifier": "identifier", "credentials":{"publickey": "public", "privatekey": "private" Sample Response Body { "result": "success", "description": " Success ", " status ": Delete Container Table 30: Delete a Container Delete a Container /Container DELETE Sample Request Body - Sample Response Body { "result": "success", D 4.1 Unified Cloud Platforms Interface Model and API 52 / 76

53 "description": " Success ", " status ": Get List of Containers Table 31: Get Containers Get list of available containers /Container/List GET Sample Request Body - Sample Response Body [{ "Container":{ "containeridentifier":"identifier", "server":"servertype", "runtime":"runtime", "Container":{ "containeridentifier":"identifier2", "server":"servertype", "runtime":"runtime" ] Create Deployment Package Table 32: Create a Deployment Package Create a Deployment Package /DeploymentPackage POST Sample Request Body { "Application":{ "applicationidentifier":"appidentifier", "DeploymentPackage":{ "type":"packaged", "repository":"null", D 4.1 Unified Cloud Platforms Interface Model and API 53 / 76

54 "User": { "useridentifier": "identifier", "credentials":{"publickey": "public", "privatekey": "private" Sample Response Body { "deploymentpackageidentifier":"deppackageidentifier", "result": "success", "description": " Success ", " status ": Retrieve Deployment Package Table 33: Retrieve a Deployment Package Retrieve Deployment Package details /DeploymentPackage GET Sample Request Body - Sample Response Body { "Application":{ "applicationidentifier":"appidentifier", "DeploymentPackage":{ "type":"packaged", "deploymentpackageidentifier":"deppackageidentifier" Update Deployment Package Table 34: Update a Deployment Package Update a Deployment Package (update deployed application source) /DeploymentPackage PUT Sample Request Body { "Application":{ D 4.1 Unified Cloud Platforms Interface Model and API 54 / 76

55 Sample Response Body { "result": "success", "description": " Success ", " status ": 200 "applicationidentifier":"appidentifier", "DeploymentPackage":{ "type":"packaged", "deploymentpackageidentifier":"deppackageidentifier", "User": { "useridentifier": "identifier", "credentials":{"publickey": "public", "privatekey": "private" Delete Deployment Package Table 35: Delete a Deployment Package Delete a Deployment Package /DeploymentPackage DELETE Sample Request Body - Sample Response Body { "result": "success", "description": " Success ", " status ": Create Service Table 36: Create a Service Create a new Service /Service POST Sample Request Body { D 4.1 Unified Cloud Platforms Interface Model and API 55 / 76

56 "Service":{ "servicename":"servicename", "servicetype":"servicetype", "service":"description", "User": { "useridentifier": "identifier", "credentials":{"publickey": "public", "privatekey": "private" Sample Response Body { "serviceidentifier":"serviceidentifier", "result": "success", "description": " Success ", " status ": Retrieve Service Table 37: Retrieve a Service Retrieve Service details /Service GET Sample Request Body - Sample Response Body { "Service":{ "serviceidentifier":"serviceidentifier", "servicename":"servicename", "servicetype":"servicetype", "service":"description" Update Service Table 38: Update a Service Update a Service /Service PUT D 4.1 Unified Cloud Platforms Interface Model and API 56 / 76

57 Sample Request Body { "Service":{ "serviceidentifier":"serviceidentifier", "servicename":"servicename", "servicetype":"servicetype", "service":"description", "User": { "useridentifier": "identifier", "credentials":{"publickey": "public", "privatekey": "private" Sample Response Body { "result": "success", "description": " Success ", " status ": Delete Service Table 39: Delete a Service Delete a Service /Service DELETE Sample Request Body - Sample Response Body { "result": "success", "description": " Success ", " status ": Get List of Available Services Table 40: Get available Services Get list of available services /Service/List GET D 4.1 Unified Cloud Platforms Interface Model and API 57 / 76

58 Sample Request Body - Sample Response Body [ { "Service":{ "serviceidentifier":"serviceidentifier", "servicename":"servicename", "servicetype":"servicetype", "service":"description",{ "Service":{ "serviceidentifier":"serviceidentifier2", "servicename":"servicename", "servicetype":"servicetype", "service":"description" ] Create Service Binding Table 41: Create a Service Binding Create a Service Binding /ServiceBinding POST Sample Request Body { "Application":{ "applicationidentifier":"appidentifier", "Service":{ "serviceidentifier":"serviceidentifier", "User": { "useridentifier": "identifier", "credentials":{"publickey": "public", "privatekey": "private" Sample Response Body { "bindingidentifier":"bindingidentifier", "result": "success", D 4.1 Unified Cloud Platforms Interface Model and API 58 / 76

59 "description": " Success ", " status ": Retrieve Service Binding Table 42: Retrieve a Service Binding Retrieve Service Binding details /ServiceBinding GET Sample Request Body - Sample Response Body { "bindingidentifier":"bindingidentifier", "Application":{ "applicationidentifier":"appidentifier", "Service":{ "serviceidentifier":"serviceidentifier" Update Service Binding Table 43: Update a Service Binding Update a Service Binding /ServiceBinding PUT Sample Request Body { "bindingidentifier":"bindingidentifier", "Application":{ "applicationidentifier":"appidentifier", "Service":{ "serviceidentifier":"serviceidentifier", "User": { "useridentifier": "identifier", "credentials":{"publickey": "public", "privatekey": "private" D 4.1 Unified Cloud Platforms Interface Model and API 59 / 76

60 Sample Response Body { "result": "success", "description": " Success ", " status ": Delete Service Binding Table 44: Delete a Service Binding Delete a Service Binding /ServiceBinding DELETE Sample Request Body - Sample Response Body { "result": "success", "description": " Success ", " status ": Get List of Bound Services Table 45: Get bound services Get list of services that have binding to a specific application /ServiceBinding/List GET Sample Request Body - Sample Response Body [ { "bindingidentifier":"bindingidentifier", "Application":{ "applicationidentifier":"appidentifier", "Service":{ "serviceidentifier":"serviceidentifier" D 4.1 Unified Cloud Platforms Interface Model and API 60 / 76

61 ,{ "bindingidentifier":"bindingidentifier2", "Application":{ "applicationidentifier":"appidentifier", "Service":{ "serviceidentifier":"serviceidentifier" ] Create Domain Table 46: Create a Domain Create a new Domain /Domain POST Sample Request Body { "Application":{ "applicationidenitifier":"appidentifier", "Domain":{ "domain":"mydomain", "User": { "useridentifier": "identifier", "credentials":{"publickey": "public", "privatekey": "private" Sample Response Body { "domainidentifier":"domainidentifier", "result": "success", "description": " Success ", " status ": Retrieve Domain Table 47: Retrieve a Domain Retrieve Domain details D 4.1 Unified Cloud Platforms Interface Model and API 61 / 76

62 /Domain GET Sample Request Body - Sample Response Body { "Application":{ "applicationidenitifier":"appidentifier", "Domain":{ "domain":"mydomain", "domainidentifier":"domainidentifier" Update Domain Table 48: Update a Domain Update a Domain /Domain PUT Sample Request Body { "Application":{ "applicationidenitifier":"appidentifier", "Domain":{ "domain":"mydomain", "domainidentifier":"domainidentifier", "User": { "useridentifier": "identifier", "credentials":{"publickey": "public", "privatekey": "private" Sample Response Body { "result": "success", "description": " Success ", " status ": 200 D 4.1 Unified Cloud Platforms Interface Model and API 62 / 76

63 Delete Domain Table 49: Delete a Domain Delete a Domain /Domain DELETE Sample Request Body - Sample Response Body { "result": "success", "description": " Success ", " status ": Get List of configured Domains Table 50: Get configured Domains Get list of Domains that are already added /Domain/List GET Sample Request Body - Sample Response Body [{ "Application":{ "applicationidenitifier":"appidentifier", "Domain":{ "domain":"mydomain", "domainidentifier":"domainidentifier",{ "Application":{ "applicationidenitifier":"appidentifier", "Domain":{ "domain":"mydomain", "domainidentifier":"domainidentifier" ] D 4.1 Unified Cloud Platforms Interface Model and API 63 / 76

64 Create Security Policy Table 51: Create a Security Policy Create a new Security Policy /SecurityPolicy POST Sample Request Body { "Application":{ "applicationidenitifier":"appidentifier", "SecurityPolicy":{ "ip":" ", "action":"allow", "protocol":"tcp", "port":80, "User": { "useridentifier": "identifier", "credentials":{"publickey": "public", "privatekey": "private" Sample Response Body { "policyidentifier":"policyidentifier", "result": "success", "description": " Success ", " status ": Retrieve Security Policy Table 52: Retrieve a Security Policy Retrieve Security Policy details /SecurityPolicy GET Sample Request Body - Sample Response Body { "Application":{ "applicationidenitifier":"appidentifier" D 4.1 Unified Cloud Platforms Interface Model and API 64 / 76

65 , "SecurityPolicy":{ "policyidentifier":"policyidentifier", "ip":" ", "action":"allow", "protocol":"tcp", "port": Update Security Policy Table 53: Update a Security Policy Update a Security Policy /SecurityPolicy PUT Sample Request Body { "Application":{ "applicationidenitifier":"appidentifier", "SecurityPolicy":{ "policyidentifier":"policyidentifier", "ip":" ", "action":"allow", "protocol":"tcp", "port":80, "User": { "useridentifier": "identifier", "credentials":{"publickey": "public", "privatekey": "private" Sample Response Body { "result": "success", "description": " Success ", " status ": Delete Security Policy Table 54: Delete a Security Policy Delete a Security Policy D 4.1 Unified Cloud Platforms Interface Model and API 65 / 76

66 /SecurityPolicy DELETE Sample Request Body - Sample Response Body { "result": "success", "description": " Success ", " status ": Get List of configured Security Policies Table 55: Get configured Security Policies Get list of Security Policies that have been already added /SecurityPolicy/List GET Sample Request Body - Sample Response Body [ { "Application":{ "applicationidenitifier":"appidentifier", "SecurityPolicy":{ "policyidentifier":"policyidentifier", "ip":" ", "action":"allow", "protocol":"tcp", "port":80,, "Application":{ "applicationidenitifier":"appidentifier", "SecurityPolicy":{ "policyidentifier":"policyidentifier", "ip":" ", "action":"allow", "protocol":"tcp", "port":80 D 4.1 Unified Cloud Platforms Interface Model and API 66 / 76

67 ] D 4.1 Unified Cloud Platforms Interface Model and API 67 / 76

68 4 PaaSport Solution for Portability Portability refers to the ability of applications to be ported from one container to the other and remain functional without any source-level changes. Portability in terms of PaaSport is application-specific and PaaS agnostic. However, there are diversities between PaaS offerings on how they deal with databases, underlying infrastructure, servers, and administrative options. The goal of PaaSport is to offer a solution that sets the goal of enhancing portability of applications deployed to the cloud with PaaSport Dynamic Configuration Interface. 4.1 Resource Binding A blocking factor on the vision for cloud portability and interoperability is the resource binding, because many resources need configuration in order to be bounded to an application. This configuration is usually done in application source code and this limits cloud portability and is a blocking factor for creating complex migration scenarios. The resources can be relational or NoSQL databases, message queues and other types of resources that an application can use. On a PaaS ecosystem, these resources are usually offered like services. For this reason many offerings provide the functionality of service binding with applications, but this is limited to the scope of giving the permission to the application to connect with the specific service. However, as the configuration needed is app-specific, further configuration of the application is needed. 4.2 Application Configuration In order to use a specific resource the application must be configured. This configuration can be part of a specific configuration file of the application or it can be part of the source code of the application. In any case, the application configuration is an app-specific process that has to take place before the deployment of the application on a container; either a private deployment on an application server or on a PaaS. In order to clarify the meaning of application configuration, an example based on one of the most common resource bindings will be presented. The resource selected is a relational database, and more specifically a PostgreSQL DB. I. Case of Private Deployment: manually set connection parameters Figure 22: Application configuration on a private deployment. D 4.1 Unified Cloud Platforms Interface Model and API 68 / 76

69 This is a generic way of connecting to a resource like a database. However, the application has to be aware of the username, password and database path before the deployment. This may sometimes be possible in a private environment, but it is not possible to know these values when working on a PaaS ecosystem. Also, this approach blocks portability in the cloud and cannot be used in migration scenarios. II. Case of a PaaS deployment: CloudFoundry - usage of Environment Variable VCAP_SERVICES Figure 23: Application configuration on Cloud Foundry. This approach is used by Cloud Foundry and it provides a way to give the application the ability to connect to the database without requiring the username, password and database path at deployment time. Instead, it is possible to find services bound with the application during runtime through parsing the VCAP_SERVICES environment value. However, this blocks the portability to other providers and cannot be used in migration scenarios. III. Case of a PaaS deployment: Heroku - usage of Environment Variable DATABASE_ Figure 24: Application configuration on Heroku. Similar to Cloud Foundry, Heroku provides a way to give the application the ability to connect to the database without requiring the username, password and database path at deployment time. Instead, it is possible to find services that are bound with the application during runtime through parsing the DATABASE_ environment value. However, this blocks the portability to other providers and cannot be used in migration scenarios. D 4.1 Unified Cloud Platforms Interface Model and API 69 / 76

70 In all these cases, the application needs reconfiguration in order to move to another PaaS provider, so it blocks portability. For this reason, we enable portability with the Autoconfiguration functionality provided by Spring Cloud Connectors. 4.3 Spring Cloud Connectors Spring Cloud Connectors is an open source project 8 that simplifies connecting to services and gaining operating environment awareness in PaaS platforms. Spring Cloud Connectors project currently offers cloud connectors for Cloud Foundry and Heroku. However, it can be easily extended to support more platforms. Support of popular services (relational databases, MongoDB, Redis, RabbitMQ) offered by PaaS is provided, while it is also extensible for more services[34]. Spring Cloud Connectors project focuses on providing good out-of-the-box experience for typical use cases but also features an extensibility mechanism to also cover exceptional cases. It features extensibility both in terms of PaaS offerings and supported services. Neither of these modifications requires modifying Spring Cloud itself. Instead, based on the Service Provider Interface (SPI) pattern, extending is possible by adding libraries (.jar files) for the extensions to application classpath. Two basic notions of extensibility are introduced by Spring Cloud Connectors: I. Cloud Platform Extensibility Through the concept of Cloud Connector, it allows extending Spring Cloud functionality to other cloud platforms. II. Service Information and Connector Extensibility Spring Cloud allows connecting to any kind of service as long as there is a way to extract its connection information from the application operating environment and (optionally) transform it into a service connector. With the usage of Spring Cloud Connectors, the application configuration becomes portable between supported PaaS offerings. The example of section 4.2 can be modified accordingly as shown in Figure 25. Figure 25: Application configuration using Spring Cloud Connectors. 8 D 4.1 Unified Cloud Platforms Interface Model and API 70 / 76

71 The above code that provides application configuration for resource binding is portable and the application that uses this code can be used in a migration scenario. 4.4 PaaSport Solution to Portability PaaSport is aimed at resolving the application and data portability issues that exist in the PaaS market through a flexible and efficient deployment, as well as at enabling migration by providing deployment conversion, so that it is suitable for different targets. PaaSport will reach these goals by defining PaaSport Dynamic Configuration Interface (PaaSport SPI). PaaSport SPI will be based on Spring Cloud Connectors but will be extended by supporting more PaaS offerings and services that are available for each PaaS. From the software engineering perspective, a Service Provider Interface (SPI) is the set of public interfaces and abstract classes that a service defines. An SPI may be represented by a single interface (type) or abstract class or a set of interfaces or abstract classes that define the service contract. This gives the advantage of dynamic loading of a library that implements a specific behavior in a specific container, as also depicted in Figure 26. Figure 26: Service Provider Interface (SPI) at a glance PaaSport SPI The PaaSport SPI will be created as part of the PaaSport solution. For each supported PaaS a reference implementation should exist and be included in the container that the application is deployed. This is illustrated in Figure 27. D 4.1 Unified Cloud Platforms Interface Model and API 71 / 76

72 Figure 27: PaaSport SPI overview. In order to achieve the desired portability, the developer must follow the portability guidelines of PaaSport SPI. The application should be accompanied by libraries provided by PaaSport that abstract the interaction with the container. For supporting the migration between different PaaS offerings, the PaaSport SPI reference implementation library of each PaaS is required. This is also used in Spring Cloud Connectors approach and a Maven example is provided in Figure 28. Figure 28: Spring Cloud Connectors required libraries. D 4.1 Unified Cloud Platforms Interface Model and API 72 / 76