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

(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

(2)

PaaSport is funded by the European Commission Seventh Framework Programme

Deliverable Title Unified Cloud Platforms Interface Model and API

Filename 1.0

Author(s) Kostas Kalaboukas (SILO), Giannis Ledakis (SILO), Panagiotis Gouvas (SILO), Nikos Drosos (SILO), Nick Bassiliades (IHU), Andreas Papadopoulos (UCY)

Date November 2014

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 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 23 September 2014 13 October 2014 20 October 2014 5 December 2014 12 December 2014 17 December 2014 19 December 2014 23 December 2014 28 December 2014 31 December 2014

SILO Kostas Kalaboukas Giannis Ledakis Panagiotis Gouvas Nikos Drosos

UCY Andreas Papadopoulos NUIG Nick Bassiliades

(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

(4)

Table of Figures:

FIGURE 1: ADAPTER PATTERN USAGE IN PAASPORT ... 12

FIGURE 2: CLOUD4SOA SEMANTIC MODEL [7] ... 15

FIGURE 3: CLOUD4SOA HARMONIZED API MODEL ... 17

FIGURE 4: MOSAIC API LAYERS [12] ... 19

FIGURE 5: MOSAIC CORE ONTOLOGY ... 20

FIGURE 6: MAIN CAMP RESOURCES. ... 23

FIGURE 7: CLOUD COMPUTING RESOURCES ONTOLOGY ... 25

FIGURE 8: CLOUD FOUNDRY LOGO ... 26

FIGURE 9: PIVOTAL CF LOGO ... 28

FIGURE 10: APPFOG LOGO ... 29

FIGURE 11: STACKATO LOGO ... 29

FIGURE 12: IBM BLUEMIX LOGO ... 30

FIGURE 13: OPENSHIFT LOGO ... 30

FIGURE 14: APACHE STRATOS LOGO ... 32

FIGURE 15: WSO2 CLOUD LOGO ... 34

FIGURE 16: GOOGLE APP ENGINE LOGO ... 35

FIGURE 17: HEROKU LOGO ... 35

FIGURE 18: AMAZON ELASTIC BEANSTALK LOGO ... 37

FIGURE 19: CLOUDBEES LOGO ... 38

FIGURE 20: CLOUDCONTROL LOGO ... 39

FIGURE 21: PAASPORT UNIFIED PLATFORMS INTERFACE MODEL ... 41

FIGURE 22: APPLICATION CONFIGURATION ON A PRIVATE DEPLOYMENT. ... 68

FIGURE 23: APPLICATION CONFIGURATION ON CLOUD FOUNDRY. ... 69

FIGURE 24: APPLICATION CONFIGURATION ON HEROKU... 69

FIGURE 25: APPLICATION CONFIGURATION USING SPRING CLOUD CONNECTORS. ... 70

FIGURE 26: SERVICE PROVIDER INTERFACE (SPI) AT A GLANCE. ... 71

FIGURE 27: PAASPORT SPI OVERVIEW. ... 72

(7)

List of Tables:

TABLE 1: REST API CALLS DEFINED BY CLOUD4SOA ... 16

TABLE 2: MOSAIC APIS ... 19

TABLE 3: CLOUD FOUNDRY SUPPORTED LANGUAGES, RUNTIMES AND FRAMEWORKS... 26

TABLE 4: CLOUD FOUNDRY IDENTIFIED ENTITIES ... 27

TABLE 5: OPENSHIFT SUPPORTED LANGUAGES, SERVERS AND DATABASES. ... 30

TABLE 6: OPENSHIFT IDENTIFIED ENTITIES ... 31

TABLE 7: APACHE STRATOS IDENTIFIED ENTITIES ... 33

TABLE 8: HEROKU IDENTIFIED ENTITIES ... 36

TABLE 9: AMAZON ELASTIC BEANSTALK IDENTIFIED ENTITIES ... 37

TABLE 10: CLOUDCONTROL IDENTIFIED ENTITIES ... 39

TABLE 11: PAASPORT DEFINED ENTITIES ... 40

TABLE 12: UNIFIED CLOUD API REST CALLS OVERVIEW ... 42

TABLE 13: CREATE AN APPLICATION ... 44

TABLE 14: RETRIEVE AN APPLICATION ... 44

TABLE 15: UPDATE AN APPLICATION ... 45

TABLE 16: DELETE AN APPLICATION ... 45

TABLE 17: GET LIST OF APPLICATIONS ... 46

TABLE 18: MANAGE APPLICATION STATE ... 46

TABLE 19: SCALE AN APPLICATION ... 47

TABLE 20: MONITOR AN APPLICATION ... 47

TABLE 21: CREATE A USER ... 48

TABLE 22: RETRIEVE A USER ... 48

TABLE 23: UPDATE A USER ... 49

TABLE 24: DELETE A USER ... 49

TABLE 25: ADD KEY... 50

TABLE 26: DELETE A KEY ... 50

TABLE 27: CREATE A NEW CONTAINER ... 51

TABLE 28: RETRIEVE A CONTAINER ... 51

TABLE 29: UPDATE A CONTAINER ... 52

TABLE 30: DELETE A CONTAINER ... 52

TABLE 31: GET CONTAINERS ... 53

TABLE 32: CREATE A DEPLOYMENT PACKAGE ... 53

TABLE 33: RETRIEVE A DEPLOYMENT PACKAGE... 54

TABLE 34: UPDATE A DEPLOYMENT PACKAGE ... 54

TABLE 35: DELETE A DEPLOYMENT PACKAGE ... 55

TABLE 36: CREATE A SERVICE ... 55

TABLE 37: RETRIEVE A SERVICE ... 56

TABLE 38: UPDATE A SERVICE ... 56

TABLE 39: DELETE A SERVICE ... 57

TABLE 40: GET AVAILABLE SERVICES ... 57

TABLE 41: CREATE A SERVICE BINDING ... 58

TABLE 42: RETRIEVE A SERVICE BINDING ... 59

TABLE 43: UPDATE A SERVICE BINDING ... 59

TABLE 44: DELETE A SERVICE BINDING ... 60

TABLE 45: GET BOUND SERVICES ... 60

TABLE 46: CREATE A DOMAIN ... 61

TABLE 47: RETRIEVE A DOMAIN ... 61

TABLE 48: UPDATE A DOMAIN ... 62

TABLE 49: DELETE A DOMAIN ... 63

(8)

TABLE 52: RETRIEVE A SECURITY POLICY ... 64

TABLE 53: UPDATE A SECURITY POLICY... 65

TABLE 54: DELETE A SECURITY POLICY ... 65

TABLE 55: GET CONFIGURED SECURITY POLICIES ... 66

(9)

LIST OF ABBREVIATIONS

API Application Programming Interface

CAMP OASIS Cloud Application Management for Platforms

CRUD Create, Retrieve, Update and Delete

HTTP Hypertext Transfer Protocol

IaaS Infrastructure as a Service

JSON JavaScript Object Notation

LDAP Lightweight Directory Access Protocol

PaaS Platform as a Service

PDP Platform Deployment Package

QoS Quality of Service

REST Representational State Transfer

SLA Service-level agreement

SME Small and medium-sized enterprises

SOA Service-oriented architecture

SPI Service Provider Interface

SSH Secure Shell

TOSCA OASIS Topology and Orchestration Specification for Cloud Applications

UML Unified Modeling Language

(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.

(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.

(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.

(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].

(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.

3.1.1 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.

3.1.1.1Cloud4SOA

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 user-friendly dashboard), (b) adapters for bridging multiple Cloud platforms and for translating

(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.

(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 release1 are presented in the Table 1 that follows:

Table 1: REST API calls defined by Cloud4SOA

HTTP

method REST call

GET /ems/application/${applicationName} PUT /ems/application/${applicationName} POST /ems/application/${applicationName}/operation/${operationName} DELETE /ems/application/${applicationName} GET /ems GET /ems/application GET /ems/application/${applicationName}/deployment GET /ems/application/${applicationName}/deployment/${deploymentName} PUT /ems/application/${applicationName}/deployment/${deploymentName} POST /ems/application/${applicationName} POST /ems/application/${applicationName}/deployment/${deploymentName} DELETE /ems/application/${applicationName}/deployment/${deploymentName} GET /ems/application/${applicationName}/deployment/${deploymentName}/dat abase GET /ems/application/${applicationName}/deployment/${deploymentName}/dat abase/${databaseName} PUT /ems/application/${applicationName}/deployment/${deploymentName}/dat abase/${databaseName} POST /ems/application/${applicationName}/deployment/${deploymentName}/dat abase/${databaseName} DELETE /ems/application/${applicationName}/deployment/${deploymentName}/dat abase/${databaseName} GET /monitor GET /monitor/detail GET /ems/sshkey 1 https://github.com/cloudpier/cloudpier-adapters/wiki/Creating-New-Adapter

(17)

HTTP

method REST call

POST /ems/sshkey

DELETE /ems/sshkey

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 URL, 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.

(18)

This API will be adapted and further developed in PaaSport for the creation of the PaaSport Unified Cloud API.

3.1.1.2REMICS

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”.

3.1.1.3ARTIST

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].

3.1.1.4mOSAIC

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.

(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 Description

Native API Library for a certain language, provided by the cloud vendor.

Driver API Wraps the native API and allows all resources of the same type be

exported with the same interface. Interoperability

API

Abstracts addressing and provides the driver API with stubs and the connector API proxies.

Connector API Cloud independent API to access cloud resources.

Cloudlet API Enables developers to create components. Its focus is the life-cycle of the software component.

(20)

Figure 5: mOSAIC core ontology2

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 3.1.2.3.

3.1.1.5SeaClouds

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

(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.

3.1.2.1TOSCA

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.

3.1.2.2CAMP

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

(22)

patching of applications in the cloud. Its purpose is to enable interoperability among self-service 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.

(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

(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.

3.1.2.3IEEE 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 cloud-to-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.

(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 Ontology3

3.1.3 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

(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.

3.2.1 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 Python

PHP 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, auto-configuration 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

(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 Description

App 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.

Buildpack 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 Files available in Cloud Foundry.

Info Encapsulates current information of the App.

Jobs Gives the ability to schedule jobs to run in the PaaS offering.

Organization 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.

Domain

(Private/Shared)

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.

Route 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 Group Security groups define all the network security parameters needed for a deployed application.

Service Services that Apps can use. New services can be integrated with

Cloud Foundry by implementing the Service Broker API.

Service Binding Bindings of deployed services with deployed applications.

Service Broker Service Broker is the term we use to refer to a component of the service which implements the service broker API.

Service Instance 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.

(28)

Space 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.

Stack 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 10.04 64-bit system and contains a number of common programs and libraries including MySQL, PostgreSQL, sqlite, imagemagick, Git, ruby.

User 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.

Environment Variable Group

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.

3.2.1.1Pivotal 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.

(29)

3.2.1.2AppFog / 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 v4.

3.2.1.3Stackato

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.

3.2.1.4IBM BlueMix

IBM Bluemix4 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.

(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.

3.2.2 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

(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

Domains 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 Applications deployed by users.

Application Aliases Aliases allow users to use their custom domain names on applications deployed on OpenShift.

Cartridge 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.

User The user that has been registered to OpenShift and is given the ability

to deploy applications under a specific domain.

Subscription plan 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.

(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

3.2.3 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,

(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.

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

Tenants A tenant is a group of users sharing the same view of Apache Stratos

installation. Multitenancy of Stratos offers both container and in-container multi-tenancy capability.

Cartridge 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.

Cartridge Instance 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.

Partition 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.

Auto-Scaling Policy The auto-scaling policy is one of the most important parts of Stratos and can be configured based on needs

Load Balancing

Cartridge

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

(34)

deploy a Load Balancer cartridge.

Deployment Policy 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.

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 3.2.3.1.

3.2.3.1WSO2 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.

(35)

Based on App Factory, a public cloud called WSO2 App Cloud is also offered.

3.2.4 Google App Engine

Google App Engine5 (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.

3.2.5 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 2010. 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.

(36)

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

Organization Organizations allow you to manage access to a shared group of

applications across your development team.

Organization member

An organization member is an individual with access to an organization.

Account 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 service Add-on services represent add-ons that may be provisioned for apps.

Endpoints under add-on services can be accessed without authentication.

Add-on Add-ons represent add-ons that have been provisioned for an app.

App An app represents the program to be deployed and run on Heroku.

Domain Domains define what web routes should be routed to an app on

Heroku.

Dyno Dynos encapsulate running processes of an app on Heroku.

Source A source is a location for uploading and downloading an application’s

source code.

Stack Stacks are the different application execution environments available

in the Heroku platform.

Plan Plans represent different configurations of add-ons that may be

added to apps. Endpoints under add-on services can be accessed without authentication.

Slug A slug is a snapshot of your application code that is ready to run on

the platform.

Build A build represents the process of transforming a code tarball into a

slug

Keys Keys represent public SSH keys associated with an account and are

used to authorize accounts as they are performing Git operations.

Env vars Env vars allow the management of the configuration information

provided to an app on Heroku, while mixing in rich annotations on them.

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

(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.)

3.2.6 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.

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

Application Describes the properties of an application.

Application Version Describes the properties of an application version.

Instance The description of an Amazon EC2 instance.

Environment Describes the properties of an environment.

Environment Resource

Describes the AWS resources in use by this environment.

Configuration Option

Describes the possible values for a configuration option.