In order to develop the project the following material goods have been required:
• A laptop with all the necessary software installed, valued in 1000e.
• A negligible cost of less than 10 efrom Amazon usage fees, both from EC2 and from S3.
• Books and electronic resources valued in 125 e approximately, which includes some paperback books and a subscription to an electronic library.
We have also used the infrastructure in the company data center to host the CloudFoundry installation. However, given that the server in which it has been deployed is shared with other applications, it is difficult to estimate its actual cost.
Part II
Exploring interoperability at the PaaS
layer
Chapter 5
Introduction
This part of the project focuses on interoperability at the Platform-as-a-Service (PaaS) layer. Platform-as-a-Service is a fairly new concept that has emerged from the evolution of the ser- vices offered by some of the major Cloud providers. It comprises a middle layer between the IaaS and the SaaS aimed at providing a scalable development and hosting environment for all sorts of applications. The main goal of a PaaS is to “make the developer’s life easier” by providing a set of tools and resources to help in the development and deployment of scalable applications, be them simple or complex.
Since the emergence of this concept it has gained a fair amount of popularity and, today, we can find lots of PaaS providers in the market: Amazon Elastic Beanstalk, Google App Engine, Heroku, OpenShift, etc. In such a competitive field, where each provider imposes its own “lock” in an effort to become thede factoplatform, interoperability and application portability gets highly damaged. This heterogeneity prevents the establishment of an agreement on a widely accepted, standardized way to input/output Cloud details and specifications [MHS09].
However, cloud developers could highly benefit from an interoperable cloud environment, where applications can be migrated from one vendor to another with minimal hassles and risks. This would let them compare Cloud offerings across a set of characteristics such as resources, pricing, available application services, Quality of Service (QoS), etc. and choose the most cost- effective provider. Furthermore, this would let them easily migrate an application in case that the chosen provider stops delivering the expected results.
The Cloud4SOA European research project pretends to make a step forward in this direction by providing a broker-like multi-cloud platform that connects multiple heterogeneous PaaS providers into a single location. The platform allows developers to search among a variety of PaaS for the one that best fits their requirements and to seamlessly deploy, govern and monitor application on it. Furthermore, Cloud4SOA also allows migrating applications from one PaaS to another when an unexpected condition happens, such as an SLA violation.
Currently, Cloud4SOA only manages public clouds (Amazon Benstalk, CloudBees and Heroku, among others). The goal of this part of the project is to explore the possibility of making hybrid deployments through the platform. To this end, a private PaaS platform will be selected and installed on-premise in the Atos infrastructure, and Cloud4SOA will be extended to support this platform. Once this test-bed is set up, several hybrid deployment scenarios will be used to evaluate the usability and performance of Cloud4SOA when facing such scenarios.
The rest of this part is structured as follows. Chapters 6 and 7 provide some background that will help the reader understand the rest of the document. Next, chapter 8 evaluates and com-
pares a set of private PaaS platforms and explains which one has been selected. Then, chapter 9 provides an overview of the selected platform along with an explanation of the installation environment and process. Following, chapter 10 analyzes how the selected platform can be integrated with Cloud4SOA. Chapter 11 shows the design and implementation of the adapter (the extension to the Cloud4SOA platform). After that, chapter 12 shows the evaluation results of the different hybrid deployment scenarios. Finally, chapter 13 concludes the part.
Chapter 6
Cloud4SOA
Cloud4SOA is a European research project started in 2010 and with 3 years of duration. The goal of the project is to provide a platform to reduce the semantic interoperability barriers between different cloud vendors in order to move a step forward in the realization of a global Cloud market [DBG+12]. Cloud4SOA introduces a broker-based architecture whose main goal
is to address and tackle semantic interoperability challenges at the PaaS layer.
The Cloud4SOA tool aims at facilitating Cloud-based application developers in searching for, deploying and governing their business applications in the PaaS that best fits their needs. Additionally it provides support for migrating an application from one PaaS to another with- out compromising the integrity of the application or the data. This functionality is achieved by semantically interconnecting heterogeneous PaaS offerings through a set of adapters that transform Cloud4SOA-based requests into platform-specific requests for each different PaaS.
In order to handle the interoperability issues, Cloud4SOA introduces a three-dimensional semantic interoperability framework [LKT11] that aims to capture any sort of semantic inter- operability conflict at the PaaS layer, while also mapping it to the appropriate PaaS entity and type of semantics.
Cloud4SOA focus its functionality in four use cases: Matchmaking, Deployment, Migra- tion and Monitoring.
6.1
Matchmaking
This use case allows to search among the existing PaaS offerings for those that best match the user’s requirements. The matchmaking mechanism uses semantic technologies to align the user requirements with the PaaS offering features, even if they are expressed in different forms.
The matchmaking algorithm capitalizes on the PaaS and Application semantic models, and aligns them in order to be able to compare them. The PaaS model captures technical infor- mation and characteristics about the platform such as supported Programming Languages and pricing model. The Application model represent an application created by a cloud-based ap- plication developer that needs to be hosted by a PaaS offering and it captures information such as the programming language, required services, required QoS (Quality of Service), etc. Using these models, “PaaS offering requests” are matched with the available “PaaS offerings” in order to provide the set of offerings that best match the requests.
Moreover, the matchmaking algorithm is able to identify equivalent concepts between di- verse PaaS offerings and “harmonize” them in order to be able to match them with the user’s
requirements. For example, Heroku uses dynosas the basic unit of computation while other PaaS providers use the number of CPUs.
6.2
Deployment
After the developer decides, driven by the recommendations of the matchmaking, on the best PaaS to deploy, she can easily deploy an application to it by providing a set of required details, such as his credentials on the platform. The deployment performs an analysis of the applica- tion’s requirements and builds a specific application deployment descriptor. This descriptor is compliant with the format defined by the selected PaaS offering. The deployment is made through the harmonized Cloud4SOA API, which is implemented by all the platform-specific adpaters.
6.3
Migration
After an application has been running for some time on a PaaS, the developer may realize that the platform is not delivering good enough results and may decide to change to another provider. In this direction, migration offers the functionality to achieve this. First, it retrieves the deployed application archive and translates the application requirements into a platform- specific deployment understandable by the new PaaS provider.
6.4
Monitoring
Once the developer has deployed an application into a PaaS provider, she can get real-time performance statistics such as response time and application health. The Monitoring module “harmonizes” metrics offered by different PaaS providers in a similar way to the matchmaking algorithm.
One of the key aspects of Cloud4SOA with respect to monitoring is the management of Service Level Agreements (SLAs). SLAs describe the service that is delivered, the functional and non- functional properties of the resources, and the duties of the parties involved. Additionally, SLAs define guarantees for the functional and non-functional resources properties. These guarantees define service level objectives that must be met in order to fulfill the agreement along with the compensation action to take in case that the guarantee is not fulfilled.
Cloud4SOA provides a RESTful implementation of the WS-Agreement standard in order to implement the SLA control and enforcement. Additionally it provides a negotiator com- ponent to perform automatic negotiations on behalf of PaaS providers, based on the semantic description of offerings and the QoS requirements specified by an application developer.
Chapter 7
Interoperability at the PaaS layer
This section dives a little deeper into the current interoperability issues at the PaaS layer and briefly describes the most important standardization initiatives that have appeared with the purpose of solving these issues.