PaasPort D1 1 v12 · D1.1!–!Requirements!analysis!report!! ... [!AWS!Elastic!Beanstalk! ......

PaaSport is funded by the European Commission Seventh Framework Programme Contract

no.: 605193

A semantically-‐enhanced marketplace of interoperable platform-‐as-‐a-‐service offerings for the deployment and

migration of business applications of SMEs

PaaSport Requirements Analysis Report

Deliverable 1.1

Date: 17th of November 2014


no.: 605193

Deliverable Title PaasPort Requirements Analysis Report

Filename 1.1

Author(s) Sébastien Kicin, Bernhard Kölmel

Date 17th November 2014

Start of the project: 01/12/2013

Duration: 36 months

Project coordinator organisation: BITMI “BUNDESVERBAND IT-‐MITTELSTAND EV”

Deliverable title: PaaSport Requirements Analysis Report

Deliverable no.: 1.1

Due date of deliverable: 31/05/2014

Actual submission date: 17/11/2014

Dissemination Level

X 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)


no.: 605193

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

19 March 2014

4 May 2014

21 May 2014

22 May 2014

29 June 2014

3 July 2014

15 July 2014

29 July 2014

29 September 2014

15 October 2014

SBZ Sébastien Kicin

Bernhard Kölmel

1.01 17 November 2014

SBZ

Sébastien Kicin

Bernhard Kölmel

Reviewers: Rolf Chung (BITMi), Erdem GULGENER and Ozgur Sahin CAKMAK (DIYALOGO)


no.: 605193

Abstract

This report documents the review of the State-‐of-‐the-‐Art and the market shareholder

expectations related to Cloud Computing interoperability. This report is focusing on

the needs from members of the participating Software SMEs Associations. It provides a

prioritized list of requirements that will be addressed by PaaSport.

Keywords

Cloud interoperability requirements

5

D1.1 – Requirements analysis report

Table of Content

Table of Figures .......................................................................................................... 8

List of Tables ............................................................................................................ 10

List of Abbreviations ................................................................................................ 11

1 Executive summary ............................................................................................ 13

1.1 Document Scope ................................................................................................... 13

1.2 Methodology ......................................................................................................... 13

1.3 Document Overview ............................................................................................. 14

2 Introduction ....................................................................................................... 16

2.1 Reaching the “Plateau of Productivity” ................................................................. 16

2.2 Problem Statement ............................................................................................... 18

3 State of the art in Cloud Computing ................................................................... 20

3.1 Cloud Computing Characteristics .......................................................................... 20

3.2 Cloud Services Models .......................................................................................... 21

3.3 Occurrences and requirements of PaaS ................................................................ 23

3.4 Cloud Deployment Models .................................................................................... 26

3.5 Hype Cycle for Cloud Computing .......................................................................... 27

3.6 Actual Players ........................................................................................................ 29 3.6.1 Amazon -‐ AWS Elastic Beanstalk ......................................................................... 29 3.6.2 Microsoft Azure ................................................................................................... 29 3.6.3 Google App Engine .............................................................................................. 30 3.6.4 Oracle .................................................................................................................. 30 3.6.5 IBM SmartCloud Application Services ................................................................. 31 3.6.6 Salesforce ............................................................................................................ 31 3.6.7 Heroku ................................................................................................................. 31 3.6.8 Red Hat Open Shift .............................................................................................. 31 3.6.9 Other vendors ..................................................................................................... 32 3.6.10 Comparison of the biggest vendors .................................................................... 32

4 State of the Art in Cloud Computing Interoperability ......................................... 38

4.1 Definition Cloud Computing Interoperability ........................................................ 38

6


4.1 Interoperability and portability ............................................................................. 39

4.2 Definition Semantic Interoperability ..................................................................... 39

4.3 Cloud Computing interoperability approaches ..................................................... 39

5 Interoperable Cloud Computing Models ............................................................. 42

5.1 Role of standardization for the Service Models .................................................... 42

5.2 Interoperability Initiatives Overview ..................................................................... 43

5.3 Existing Results ...................................................................................................... 45 5.3.1 NIST Cloud Computing Interoperability and Portability Working Group ............ 47 5.3.2 Cloud4SOA .......................................................................................................... 50

5.4 mOSAIC ................................................................................................................. 55 5.4.1 OASIS CAMP TC ................................................................................................... 57

5.5 Other initiatives ..................................................................................................... 58

6 Effect of Cloud Computing for stakeholders ....................................................... 63

6.1 Target groups ........................................................................................................ 63

6.2 PaaS Providers ....................................................................................................... 65 6.2.1 General Information ............................................................................................ 65 6.2.2 Impact of Cloud Computing interoperability ...................................................... 66

6.3 PaaS Customers ..................................................................................................... 68 6.3.1 General Information ............................................................................................ 68 6.3.2 General reasons for Cloud Computing implementation ..................................... 69 6.3.3 General reasons against Cloud Computing implementation .............................. 70 6.3.4 Considerations .................................................................................................... 70 6.3.5 Impact of Cloud Computing interoperability ...................................................... 70 6.3.6 Key Performance Indicator ................................................................................. 71

6.4 Cloud broker – Provider – Players ......................................................................... 78 6.4.1 AWS Marketplace ................................................................................................ 78 6.4.2 Cloudability ......................................................................................................... 79 6.4.3 Heroku ................................................................................................................. 79 6.4.4 SnapLogic ............................................................................................................ 80

6.5 Cloud broker – Enabler – Players .......................................................................... 80 6.5.1 CompatibleOne ................................................................................................... 80 6.5.2 Infosys ................................................................................................................. 81 6.5.3 Jamcracker .......................................................................................................... 81 6.5.4 Vordel (Axway) .................................................................................................... 82

7


6.6 Cloud marketplaces ............................................................................................... 82

7 Requirement analysis scheme ............................................................................ 84

7.1 Justification of the positioning .............................................................................. 84 7.1.1 Target group ........................................................................................................ 84

7.2 Detailed requirement scheme .............................................................................. 87 7.2.1 Functional Requirements of development Engineers ......................................... 87 7.2.2 Functional Requirements of PaaS Providers ....................................................... 88

8 Questionnaire .................................................................................................... 90

8.1 Concept of the questionnaire ............................................................................... 90

12.1 Evaluation ............................................................................................................ 94 12.1.1 General information about the companies ......................................................... 95 12.1.2 Companies which use cloud services .................................................................. 96 12.1.3 Companies which do not use cloud services ..................................................... 106

13 Interviews ...................................................................................................... 109

13.1 Interview guide ................................................................................................. 109

13.2 Requirements (Functional & Non-‐Functional) .................................................. 109 13.2.1 Functional Requirements of development Engineers ....................................... 110 13.2.2 Functional Requirements of PaaS Providers ..................................................... 111 13.2.3 Non-‐functional Requirements of PaaS Providers .............................................. 111

14 Conclusion ..................................................................................................... 114

15 Annex 1 -‐ Questionnaire ................................................................................ 116

16 Annex 2 -‐ Interview guide .............................................................................. 127

17 Literature ....................................................................................................... 139

8


Table of Figures Figure 1 – Interview and questionnaire approach ......................................................... 15 Figure 2 -‐ Hype Cycle for Emerging Technologies (Gartner 2013) .................................. 16 Figure 3 -‐ Public Cloud Service Market ........................................................................... 17 Figure 4 -‐ Cloud Types (College of Engineering and Computer Science at Wright

State University 2014) ............................................................................... 22 Figure 5: Separation of Responsibilities (Chou 2010) ..................................................... 23 Figure 6: Intel Cloud Computing Taxonomy (Intel 2010a, 1) .......................................... 23 Figure 7 -‐ Gartner’s Hype Cycle for Cloud Computing (Gartner 2013) ........................... 27 Figure 8: Current and planned use of private Cloud Computing services. Adapted

from: (Wallraf and Pols 2014, 22) ............................................................. 28 Figure 9: Cloud Management Interoperability (Department of Defense Information

Network Global In-‐formation Grid Cloud Computing Services Guidance Working Group 2013) ............................................................... 49

Figure 10: Cloud4SOA Reference Architecture. Source: (Zeginis, et al. 2013, 22) ......... 51 Figure 11: Cloud4SOA Semantic Model. Source: (Kamateri, Loutas and Zeginis

2013, 73) ................................................................................................... 53 Figure 12: mOSAIC API layers (Rak, Sandru und Di Martino 2011, 57-‐60) ..................... 56 Figure 13: mOSAIC -‐ Component view of the integration platform (Petcu, et al.

2013, 6) ..................................................................................................... 57 Figure 14: CAMP Resources as UML Classes (Durand, et al. 2014, 16) .......................... 58 Figure 15 -‐ Target groups ............................................................................................... 64 Figure 16 -‐ Services which will be offered ...................................................................... 64 Figure 17: The shift to the Cloud. Source: (Saugatuck Technology 2012, 4) .................. 66 Figure 18: Du-‐Pont-‐System of Financial Control. ........................................................... 72 Figure 19: Formula to Calculate Simple ROI. Source: (ISACA 2012, 7) ........................... 77 Figure 20: Do ROI calculations adequately describe the benefits of cloud

adoption?. Source: (Bourne 2012, 8) ........................................................ 78 Figure 21: Tasks -‐ PaaS Vendors ..................................................................................... 86 Figure 22: Tasks -‐ PaaS Customers ................................................................................. 86 Figure 23: Number of employees ................................................................................... 95 Figure 24: Usage of cloud services ................................................................................. 95 Figure 25: Web service offering ..................................................................................... 96 Figure 26: Change cloud provider or employ more than one provider .......................... 96 Figure 27: Used programming languages ....................................................................... 97 Figure 28: Used frameworks .......................................................................................... 97 Figure 29: Used databases ............................................................................................. 98

9


Figure 30: Kind of monitoring which is needed .............................................................. 98 Figure 31: Need of dynamically scaling resources .......................................................... 99 Figure 32: Challenges of companies using cloud services ............................................ 100 Figure 33: Awareness of the vendor lock-‐in issue ........................................................ 101 Figure 34: Assessment of the vendor lock-‐in ............................................................... 101 Figure 35: Challenges of companies which do not use cloud services ......................... 107 Figure 36: Usage of cloud services in the future .......................................................... 108 Figure 37: Sophisticated view on requirements ........................................................... 108

10


List of Tables Table 1: Types of PaaS solutions (Loutas, Kamateri, et al. 2011, 29) ............................. 24 Table 2 -‐ Comparison of the biggest vendors -‐ scheme table ........................................ 34 Table 3: Vendor comparison -‐ Application ..................................................................... 36 Table 4: Vendor comparison -‐ Infrastructure ................................................................. 37 Table 5: Vendor comparison -‐ Deployment .................................................................... 37 Table 6: Vendor comparison – Security .......................................................................... 37 Table 7: Interoperability Elements of a Cloud Platform (Paoli 2010) ............................. 42 Table 8: Cloud/PaaS semantic interoperability initiatives .............................................. 45 Table 9: Cloud interoperability initiative analysis frame ................................................ 47 Table 10: Comparison of Performance between Cloud4SOA and the PaaS API.

Source: (Zeginis, et al. 2013, 30) ............................................................... 54 Table 11: mOSAIC APIs (Rak, Sandru und Di Martino 2011, 57-‐60) ............................... 56 Table 12: Cloud Computing Market. Source: (Columbus 2013b) ................................... 65 Table 13: Boundary-‐free Enterprise (Saugatuck Technology 2012, 8) ........................... 68 Table 14: AWS Marketplace classification ...................................................................... 78 Table 15: Cloudability classification ............................................................................... 79 Table 16: Heroku classification ....................................................................................... 79 Table 17: SnapLogic classification .................................................................................. 80 Table 18: CompatibleOne classification ......................................................................... 80 Table 20: Jamcracker classification ................................................................................ 81 Table 21: Overview PaaS Marketplaces ......................................................................... 83 Table 22: PaaSport Functional Requirements of development Engineers ..................... 87 Table 23: PaaSport Functional Requirements for PaaS Providers .................................. 88 Table 24: PaaSport Non-‐Functional Requirements ........................................................ 88 Table 25: List of the Functional Requirements (Seventh Framework Programme

2013, 11f. (Part B)) .................................................................................... 90 Table 26: List of the Non-‐Functional Requirements (Seventh Framework

Programme 2013, 11f. (Part B)) ................................................................ 92 Table 27: Functional Requirements sorted by rating average ..................................... 104 Table 28: Non-‐Functional Requirements sorted by rating average .............................. 106 Table 29: PaaSport Functional Requirements of development Engineers ................... 110 Table 30: PaaSport Functional Requirements of PaaS Providers ................................. 111 Table 31: PaaSport Non-‐Functional Requirements ...................................................... 111

11


List of Abbreviations

ACCORDS Advanced Capabilities for CompatibleOne Resource De-‐

scription System

ADF Application Deployment Framework

API Application Programming Interfaces

AWS Amazon Web Services

CADF Cloud Auditing Data Federation

CAMP Cloud Application Management for Platforms

CCA Cloud Computing Association

CCIF Cloud Computing Interoperability Forum

CDMI Cloud Data Management Interface CFP Call for proposals

CIF Cloud Industry Forum

CIMI Cloud Infrastructure Management Interface

CPIP Cloud Portability and Interoperability Profiles CSA Cloud Security Alliance

CSCC Cloud Standards Customer Council

CSB Cloud Service Broker

DaaS Data as a Service

DMTF Distributed Management Task Force

DoD Department of Defense

DoDIN Department of Defense Information Network

DCCSGWG Department of Defense Information Network Global In-‐

formation Grid Cloud Computing Services Guidance

Working Group (DCCSGWG)

EC European Commission

ETSI European Telecommunications Standards Institute

GAE Google App Engine

GICTF Global Inter-‐Cloud Technology Forum

GIG Global Information Grid

GRS Geographically Redundant Storage

HTTP Hypertext Transfer Protocol IaaS Infrastructure as a Service

12


IEEE Institute of Electrical and Electronics Engineers

ISC International Standardization Council

IT Information Technology

Java EE Java Enterprise Edition JSON JavaScript Object Notation

LRS Locally Redundant Storage

OASIS Organization for the Advancement of Structured Infor-‐

mation Standards OCA Open Computing Alliance

OCC Open Cloud Consortium

OCCI Open Cloud Computing Interface ODCA Open Data Center Alliance

OGF Open Grid Forum OMG Object Management Group

OVF Open Virtualization Format

PaaS Platform as a Service

PSIF PaaS Semantic Interoperability Framework RA-‐GRS Read-‐Access Geographically Redundant Storage

SaaS Software as a Service SMAs Small and Medium Enterprises SNIA Storage Networking Industry Association

SSO Single Sign On TC Technical Committee VHD Virtual Hard Disk

13


1 Executive summary

The aim of this deliverable is to present the background of the work pursued during

Task 1.1 in the PaaSport project. The scope and the main objectives which have guided

this work are introduced in section 1.1. The methodology followed is described in sec-‐

tion 1.2. Finally, section 1.3 presents the organization of the current deliverable.

1.1 Document Scope

This report documents the review of the State-‐of-‐the-‐Art and the market shareholder

expectations related to Cloud ComputingCloud Computing interoperability. This report

is focusing on the needs from members of the participating Software SMEs Associa-‐tions. It provides a prioritized list of requirements that will be addressed by PaaSport.

Based on this result, the reference components of a platform supporting interoperabil-‐ity can be designed within Task 1.2 (PaaSport Reference Architecture).

1.2 Methodology

This deliverable analyzed the requirements for an interoperable PaaS offering in the

scope of Task 1.1 (“European-‐wide Requirements Analysis and Prioritization”) coordi-‐

nated by SBZ.

The work was based on the following steps:

• Building of a common understanding of Cloud Computing characteristics, ser-‐vice models and deployment models.

• Presentation of the different Cloud Computing interoperability points of view and analysis of the various interoperability initiatives

• Demonstration of how the main stakeholders, PaaS-‐Provider, Developer and Customer could benefit from interoperability.

• Identification, analysis, homogenization and prioritization of the requirements

and needs based on the state of the art, the interviews and the structured

questionnaires submitted to members of the participating Software SMEs As-‐sociations

14


1.3 Document Overview

The research started by searching information through search engines like google

scholar. Many findings were because of the rapid progress in Cloud Computing. Only

sources were used that are not older as the launch year 2008. Then we analyzed the current Cloud Computing market situation and compared the offers of the big vendors.

The first domain, research of the state of the art, considered and analyzed existing

standards and specifications and evaluated its relevance for the PaaSport project goals. Furthermore, the existing solutions in PaaS offerings and marketplaces were

considered. It shows the heterogeneity of the environment and the main challenges

that the project has to deal with. To ensure, or at least to enable the interoperability

between PaaS offerings and open the market for the SME, it is necessary to know the requirements that should be considered.

The requirement analysis results from the Cloud4SOA project was identified as the

most adequate baseline for the PaaSport approach. Further work was led to adapt the-‐se results to support the specific questionnaire and interview approaches of PaaSport.

The questionnaire gave information about the frameworks, programming languages,

databases and others that are used by the companies. Many companies already use

cloud services although they are aware of the challenges that still have to be ad-‐dressed like security and vendor lock-‐in problems. Nevertheless, because of clear cloud

services advantages (cost saving, scalability etc.), even companies which do not use

cloud services today state that they will probably use them in a near future. The ques-‐tionnaire also revealed that security problems are the most important challenge for

companies which use cloud services as well as companies which do not use cloud ser-‐

vices. Most of the companies are aware of the vendor lock-‐in problem and its disad-‐vantages. Besides an interview guide was designed and verified in order to locate aris-‐

ing problems and to find out which functionalities are important for the companies.

The requirements analysis based on the questionnaire led to a first priority.

Further requirements collected from the results of the interviews led to an updated

prioritized list in order to guide the development of the PaaSport Framework and Ref-‐

erence Architecture as well as to help defining the PaaSport Use Cases.

15


Figure 1 – Interview and questionnaire approach

16


2 Introduction

2.1 Reaching the “Plateau of Productivity”

The word “cloud” is not anymore used just in the lingo. It is a widespread term in the

meantime. Companies like Apple, Amazon and Google offer their cloud-‐services to

private customers as well as to companies and organization (Marshall 2013). Cloud Computing was identified by BITKOM as the most important trend of the German IT-‐

Branch in the year 2013 (BITKOM 2013).

Gartner tried to illustrate this “Hype” of Cloud Computing in form of a “Hype Cycle for

Emerging Technologies”. The Cloud Computing is categorized on the time scale in “Through of Disillusionment”, what means that industry expected more from this

Technology, therefore the expectations scale is now low. Consequently the Cloud Computing is not on the Plateau of Productivity till now (Gartner 2013).

Figure 2 -‐ Hype Cycle for Emerging Technologies (Gartner 2013)

Despite the disillusionment Gartner predicted that the spending for Cloud Computing

will be the biggest part of the total IT spending in 2016 (Shetty 2013) .The growth will be constantly over 15% annually, so that there will be a revenue of 210 billion USD in

total worldwide in 2016 (Columbus 2013).

17


Figure 3 -‐ Public Cloud Service Market

A survey mandated by SAP (TNS Infratest 2012) figured out that 59% of the large com-‐

panies already use cloud solutions. Further 21% of the remaining surveyed partici-‐pants, answered that they plan to use cloud solutions in the future. Cloud Computing is considered by 79% of the respondents as an important factor for the business success

of their companies.

The development in usage of apps on smart phones in everyday life is also an indicator

for the direction the development in the usage of IT will take. Upcoming technologies

like augmented reality, the integration of IT into transport and mobility and many

more will create a huge demand on services – probably provided in the cloud.

One of the main aspects why Cloud Computing is so attractive is the opportunity to

lower costs by outsourcing IT-‐responsibilities to a cloud provider (Cooter 2013). How-‐

ever, many potential customers reject Cloud Computing solutions, because Cloud

Computing has also disadvantages and holds potential risks. An often mentioned dis-‐

advantage is the lack of Cloud Computing standards, what leads to a vendor-‐lock in

(Lewis 2012, 4). Many companies are afraid of this vender dependency (Microsoft

2011, 5). Some initiatives and project teams want to change the current situation and

aim to achieve Cloud Computing interoperability (Loutas 2011, 23).

18


But what would be the economic impact, when Cloud Computing interoperability

would be achieved? The status of standardization and the current influence of Cloud

Computing have to be determined. After this step the Cloud Computing impacts have

to be expanded by possible impacts of an achieved Cloud Computing interoperability.

2.2 Problem Statement

Nowadays there is the apprehension, that the Cloud Computing market could become

an oligopolistic market or even in some submarkets a monopolistic market (Rogers 2013).

Oligopolys prone to lead to inefficiencies because there is the tendency that compet-‐

ing companies in the same market cooperate (Satija 2009).

As result of the oligopolistic market a vender lock-‐in problem was identified that rep-‐resents one of the main difficulties for little and middle sized companies to enter the

market. The lock-‐in problem prevents the change of cloud providers due to the high risks and costs for the cloud service customers. This problem emerged because of the lack of standardization (Catteddu und Hogben 2009).

Interoperability has not been a priority concern for the construction of current Cloud Computing solutions (Sheth and Ranabahu 2010).

A further problem is that many potential cloud service customers do not know, what

benefits Cloud Computing, in particular interoperable systems have to improve their

cost structure and subsequently their competitiveness.

The heterogeneity and complexity of the PaaS sector makes it almost impossible for a

PaaS customer, and especially for SMEs, to generate interoperability by their own. For

this purpose, this deliverable will define the requirements for the PaaSport platform which enables interoperability between PaaS offerings. As an expected result of this

interoperability, the disadvantages of SMEs PaaS vendors compared to big vendors will

decrease.

Enabling the interoperability between PaaS offerings means to enable PaaS customers to choose an offer out of a pool of comparable and, in best case, of equivalent ser-‐

vices. The concept divides the locked packages of single PaaS offers into slices or lay-‐

ers, which can be substituted easily and independent. That means, that the customer

19


doesn’t have to choose between packages of the vendors with all its pros and cons,

but the customer can arrange his own PaaS solution with a modular design.

20


3 State of the art in Cloud Computing

This section introduces and illustrates the term Cloud Computing including the essen-‐

tial characteristics, deployment models and service models, which will be introduced

exactly in this sequence. As main source the NIST definition were chosen for this part.

The NIST definition of Cloud Computing is

“Cloud Computing is a model for enabling ubiquitous, convenient, on-‐demand network

access to a shared pool of configurable computing resources (e.g., networks, servers,

storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model is com-‐posed of five essential characteristics, three service models, and four deployment mod-‐

els.” (Mell und Grance 2011)

3.1 Cloud Computing Characteristics

On-‐demand self-‐service: There is a one sided possibility to use computing capabilities by the consumer. Computing resources are for example server time and network stor-‐

age. These capabilities are provided automatically in the required volume that is de-‐

manded by the consumer. No human interaction is necessary. (Mell und Grance 2011)

Broad network access: The proficiencies are feasible over the network. This network can be accessed by heterogeneous different sized client platforms. Platforms are for

example mobile phones, laptops and PDAs. (Mell und Grance 2011)

Resource pooling: The physical and virtual resources that are demand by the consumer

are dynamically evaluated and commissioned by the provider. This can be achieved by

using a multi-‐tenant model. Moreover, there is an impression of location autonomy. The consumer does not know where exactly the provided resources are located. Re-‐

sources are for example storage, processing, memory, network bandwidth and virtual

machines. On a higher level of abstraction it is possible to determine the location of these resources. (Mell und Grance 2011)

Rapid elasticity: Cloud services can be expeditiously and elastically provisioned. In few

cases automatically, to instantaneously scale out and immediately released to quickly scale in. It seems for the consumer that the resources are limitless and can be ordered

regardless at what time and the capacity size. (Mell und Grance 2011)

21


Measured service: The resources of Cloud Computing can be measured, checked and

reported to make it transparent for the provider as well as for the consumer. The re-‐

sources are controlled and optimized by the use of the implemented metering capabil-‐

ity. This means that a pay per use for the cloud service is possible, what implies exem-‐plified the more the service is utilized by a consumer, the higher the bill will be for the

consumer (Mell und Grance 2011).

Multi Tenacity: The Cloud Security Alliance expanded the NIST Cloud Computing char-‐

acteristics and suggested Multi Tenacity as the 6th characteristic (Cloud Security Alliance 2011). Multi Tenacity helps service providers to offer very efficient and highly

scalable network infrastructures and data architectures to the customers. These re-‐

sources are shared by the consumers (Juniper Networks 2012).

3.2 Cloud Services Models

• Infrastructure as a Service (IaaS): The service vendor provides processing, stor-‐age, networks and other crucial capabilities. Based on these provided resources

the customer can use and run any software as for example operating systems

and applications. The basic infrastructure is controlled and managed by the

Service provider but the customer has the possibility to change settings of se-‐lected network components (Mell und Grance 2011).

• Platform as a Service (PaaS): The service vendor provides processing, storage, networks and other crucial capabilities. Additionally, a solutions stack is provid-‐

ed by the vendor as a service. The basic infrastructure is controlled and man-‐aged by the Service provider but the customer has the possibility to change set-‐

tings of the deployed applications and potentially configuration setting authori-‐

ty for network components (Mell und Grance 2011).

• Software as a Service (SaaS): The service vendor provides processing, storage, networks and other crucial capabilities. Additionally, the vendor provides appli-‐

cations that are deployed on a cloud infrastructure. Cloud infrastructure is de-‐

fined as a software and hardware compilation that facilitates the fundamental

Cloud Computing characteristics. The provided applications can be accessed

from numerous consumer devices. For the utilization of the applications a thin

client interface, a program interface or a web browser are necessary. The client

has not the authority to control the basic infrastructure but it is possible that

22


the client has the control over the configuration of customized applications

(Mell und Grance 2011).

The following illustration shows the cloud service models under consideration of port-‐

ability1 and automation. Furthermore, the cloud user responsibilities are shown and providers are mentioned for each cloud type.

Figure 4 -‐ Cloud Types (College of Engineering and Computer Science at Wright State University 2014)

Figure 4 presents the cloud service models and shows the responsibilities of the cloud

service provider and the customer for each model.

1 Portability defines the ability to be transferred from one machine or system to another

23


Figure 5: Separation of Responsibilities (Chou 2010)

A Cloud Computing taxonomy was created by Intel (Figure 5). It is used as a basis for developing strategies for Intel’s products and services as well as for Intels IT environ-‐ment. Moreover, it aims to identify efficient Cloud Computing solutions and is used for

discussions (Intel 2010a, 1-‐3).

Figure 6: Intel Cloud Computing Taxonomy (Intel 2010a, 1)

3.3 Occurrences and requirements of PaaS

While the overall definitions related to PaaS are broadly accepted, different under-‐standing of the precise role and position of PaaS in the market can be identified.

24


SaaS with extensions Customize and extend the capabilities of a SaaS application

Purpose-‐built PaaS A framework that simplifies the development of a specific class of applications

PaaS tied to a single appli-‐

cation paradigm

Provides general capabilities, but supports only one programming model or

development/deployment environment

PaaS tied to a single Cloud May provide general capabilities, but can be used only in the context of a single

public Cloud or a single type of private Cloud infrastructure

Middleware hosted in the

Cloud

Eases distribution of middleware across the organization, but adds no other

value

General-‐purpose PaaS Comprehensive, open, and flexible solution that simplifies the process of devel-‐

oping, deploying, integrating, and managing applications in public and private

Clouds.

Table 1: Types of PaaS solutions (Loutas, Kamateri, et al. 2011, 29)

Dave Mitchell described the following six PaaS elements as the key elements (Mitchell

2008):

1) Develop, Test, Deploy, Host and Maintain on the Same Integrated Environment: Developers should not be responsible for building an environment. The envi-‐

ronment should be provided by the vendors. The frame conditions should facili-‐tate developers to focus on creating software. Facilities for source code control, application testing, staging, rollout and roll-‐back, in an auditable, work-‐flow-‐

friendly environment should be covered by a finished PaaS.

2) User Experience without Compromise: Best available user experience has to be supplied by PaaS. Software downloads, plug-‐in installation, browser dependen-‐

cies have to be avoided because of security, maintenance and handling issues.

3) Built-‐in Scalability, Reliability, and Security: A PaaS should provide scalability, multi tenancy, reliability and security.

4) Built-‐in Integration with Web Services and Databases: Multiple data sources

should be accessible by the platform. To achieve this function, many connectiv-‐ity options are needed.

5) Support Collaboration: A PaaS has to support collaboration during the whole software lifecycle. Furthermore, the PaaS has to secure the source codes and the intellectual property of the collaboration. Moreover, the Service should

help to raise productivity and lower project risks and costs.

25


6) Deep Application Instrumentation: PaaS has to provide the ability to make ap-‐

plications and user activities transparent for the developers in order to show

them the effect of their work. Furthermore, this measure can be used to devel-‐

op customer oriented solutions and solve application crashes.

In contrast to Dave Mitchell, Subraya Mallya identified following ten requirements that

a PaaS has to fulfill (Mallya 2010):

1) Application Development Technology Framework: The application develop-‐

ment technology framework should be based on a technology that is very popular. Over the whole application lifecycle the management of design, test-‐

ing, development, change control, delivery and update should be guaranteed

by the applied framework. 2) Ease-‐of-‐Use: The PaaS should be created in a way, that the customers are able

to use the service easily. This can be achieved by cloud vendors through providing intuitive WYSIWIG tools with pre-‐built widgets, drag-‐and-‐drop tools

and canned UI components. A very quick iterative Application Development

should be possible.

3) Business Process Modeling: The business processes should be modeled with help of a business process modelling framework. Afterwards, the application

should be built based on the business process.

4) Ubiquitous: The platform should always be available has to facilitate the access from all over the world.

5) Scalable: A PaaS has to have the ability to leverage the elastic capacity of the la-‐tent infrastructure in order to manage the stress peaks and valleys of the appli-‐cations.

6) Adaptive: Due to the rapid change of technologies, a PaaS should provide the capability to deliver developed applications to several run time platforms be-‐

sides the web.

7) Secure: The services has to be made more secure by implement Denial of Ser-‐vice, SQL injection, Cross-‐site scripting, Encryption of traffic into the develop-‐

ment of the applications.

8) Inclusive: The capability to integrate, include and embed other applications re-‐gardless of the platform should be supported by the PaaS.

26


9) Portable: The change of the Infrastructure as a Service provider should be pos-‐sible. For this reason, the platform has to have the capability to transfer appli-‐

cations to a different infrastructure.

10) On-‐boarding tools: The migration of data from on-‐premises applications to the platform based applications has to be easy and fast. So a toolkit should be pro-‐

vided including transformation tools and a bulk import tool.

3.4 Cloud Deployment Models

• Private Cloud: The infrastructure of the cloud is created and implemented in a

manner that it can be used only by a single entity (organization). It includes multiple consumers that are using this infrastructure (e.g., business units).

There are different approaches to whom this cloud infrastructure belongs and

by whom it is organized and maintained. The infrastructure can be deployed on

the property organization property or can be outsourced (Mell und Grance 2011).

• Public Cloud: The cloud infrastructure is created and implemented in a manner that it can be used by the general public. There are different approaches to

whom this cloud infrastructure belongs and by whom it is organized and main-‐tained. Combinations of business, academic, or government organizations that operate and maintain the cloud infrastructure are possible. The cloud infra-‐

structure is based on the property of the cloud provider (Mell und Grance

2011).

• Community Cloud: The cloud infrastructure is created and implemented in a

manner that it can be used by definite community of users from entities that

have common interests. Common interest can for example be a shared mission,

common security requirements, policy and compliance considerations. There are different approaches to whom this cloud infrastructure belongs and by

whom it is organized and maintained. It can be deployed on or off premises

(Mell und Grance 2011).

• Hybrid Cloud: The cloud infrastructure is a combination of several individual and definite cloud infrastructures as the aforementioned Private Cloud, Public

Cloud and the Community Cloud. The entities persist as separated organization

that are integrated and linked together by technology and standardization that

27


empowers data and application portability and flexibility (Mell und Grance

2011).

3.5 Hype Cycle for Cloud Computing

Because Cloud Computing has different service models and characteristics as afore-‐

mentioned, Gartner created an own “Gartner’s Hype Cycle for Cloud Computing”. This illustration shows that Technology PaaS is currently at the Peak of Inflated Expecta-‐

tions. This shows the high expectations towards this Technology. Iaas and SaaS are in

the advanced phases “Trough Disillusionment and “Slope of Enlightenment”. None of all these Cloud Computing Technologies has already reached the “Plateau of Productiv-‐

ity”.

Figure 7 -‐ Gartner’s Hype Cycle for Cloud Computing (Gartner 2013)

German Companies that run the deployment model private cloud, use most often the Service model SaaS (38%), followed by IaaS (24%) and PaaS (17%). PaaS considerably

increased its importance within the last two years. Many companies are actually dis-‐

cussing or they have already planned the usage of cloud based service models. Conse-‐quently, it seems that the demand for these services will increase in the next years

(Wallraf und Pols, Cloud-‐Monitor 2014 2014).

28


Figure 8: Current and planned use of private Cloud Computing services. Adapted from:

(Wallraf and Pols 2014, 22)

The majority of the private Cloud Computing users have made positive experiences. 83% described their experiences as positively, the remaining 17% categorized their

experiences as neutral. Drivers for that positive result are the increased band width of the used services and good experiences with data and privacy protection (Wallraf und

Pols, Cloud-‐Monitor 2014 2014).

Nevertheless, hacker and espionage are seen as real danger by German companies. So 74-‐percent of the companies are afraid of cyber-‐attacks aiming computers and data

networks. Because of the NSA affair the awareness of it-‐security increased and influ-‐

enced the attitude towards Cloud Computing negatively. More than 50-‐percent of the respondents see Cloud Computing solutions now critical. These results can be seen as

a clear evidence for a common uncertainty, because internal systems and private

clouds have the same safety level. However, the half of the companies reacted with concrete actions because of the NSA affair (Wallraf und Pols, Cloud-‐Monitor 2014

2014).

The following actions were identified:

• Certifications and special Service Level Agreement were insisted to improve the

IT-‐Security (30%)

• Rejection of Cloud Computing service offers in the year 2014 (23%)

• Postponement of already planned cloud projects and/or abandon of existing

Cloud solutions (18 %)

29


3.6 Actual Players

The actual big players on the market offer their Paas offerings on their proprietary

platforms and with their own proprietary API. Their offer usually includes a range from

IaaS over PaaS to SaaS services. The following chapter delimits the PaaS offerings from

IaaS and SaaS, show the important information about the offerings and picks up the API of the vendor. To limit the list of vendors, a selection of the most representative

examples of PaaS APIs had to be achieved.

At the end of this chapter, the collected information will be used to compare the ven-‐dors and the attributes of their offers in the following areas:

• Application, • Infrastructure, • Deployment, • Security and • Portability.

3.6.1 Amazon -‐ AWS Elastic Beanstalk

Amazon was the first provider of Cloud Computing and offered a first beta release of

EC2 (Elastic Compute Cloud) in August 2006. The actual PaaS offer is named AWS (Am-‐

azon Web Services) Elastic Beanstalk which uses the Amazon IaaS infrastructure in an upper layer.

AWS Elastic Beanstalk uses Amazon services like EC2 or S3 to provide its service, but

the user doesn’t have to care about this layer. This means that, if needed, additional computing instances are added automatically via auto-‐scaling and load balancing with-‐

in the defined range of resources.

https://aws.amazon.com/elasticbeanstalk/details/

Languages

Java, Python, PHP, .NET, Node.js, Docker and Ruby

3.6.2 Microsoft Azure

Microsofts PaaS solution, Microsoft Azure, provides scalable and high available IaaS-‐

and PaaS-‐services on a hybrid platform.

Microsoft Azure uses the virtual hard disk (VHD) format which enables to interact with

other virtualization platforms (e.g. Microsoft Hyper-‐V, Virtualbox -‐ ).

30


http://azure.microsoft.com/

Languages

Java, Python, PHP, .NET, Node.js, Ruby, Mobile (iOS, Android, …) and Media Services

3.6.3 Google App Engine

Google’s PaaS solution is the Google App Engine (GAE). It enables to develop and exe-‐

cute web-‐apps on the Google infrastructure without having to manage servers. GAE

provides four programming languages, various kinds of data storage, including MySQL

databases and proprietary storage types, on demand pricing model and offers proprie-‐tary APIs and SDKs.

https://cloud.google.com/products/app-‐engine/

Languages

Java, Python, PHP in a preview state and Go in experimental state.

With Compute Engine, Node.js, Scala or C++ can be integrated.

3.6.4 Oracle

The tactics, Oracle is following up in its PaaS service Oracle Java Cloud Service, is very

simple. The offer bases just on Java Enterprise Edition (Java EE), Application Deploy-‐

ment Framework (ADF) and the Oracle database. In comparison with other vendors, this offer looks small, but their aim is more the portability than diversity. The offer gets

along without a proprietary API or tools.

https://cloud.oracle.com/_downloads/Datasheet_Java_CloudService/java-‐cloud-‐service-‐ds.pdf

https://cloud.oracle.com/_downloads/Datasheet_Database_CloudService/database-‐cloud-‐service-‐ds.pdf

The Oracle Java Cloud Service bases on proprietary Oracle WebLogic servers. The offer

is categorized in three categories: S1, S2 and S4 with one, two or four WebLogic Serv-‐

ers for small, medium and large web-‐sites and applications.

Languages

Java

31


3.6.5 IBM SmartCloud Application Services

IBMs PaaS solution is the SmartCloud Application Services. The PaaS service is a spe-‐

cial IBM concept which bases on patterns for configuration and administration of hard-‐

and software resources. The service itself is running on the IBM Public Self-‐Service-‐Cloud. The created services are portable and can be implemented into IBMs IBM Pure-‐

Application system, IBM Workload Deployer or the IBM SmartCloud Enterprise.

http://www.ibm.com/cloud-‐computing/de/de/paas.html

Languages

Java, PHP

3.6.6 Salesforce

Salesforce’s PaaS solution is Force.com which is part of the Salesforce1-‐Platform. It is a PaaS solution near the SaaS layer.

https://developer.salesforce.com/

Languages

Apex

3.6.7 Heroku

Heroku is a PaaS provider and a subsidiary of Salesforce.com. Differently from its par-‐ent’s strategy, Heroku offers a wider spectrum of languages and tools. In comparison,

it is farer away from the SaaS layer than Force.com.

https://www.heroku.com/

Languages

Ruby, Node.js, Python, Java, and PHP

Marketplace: https://addons.heroku.com/ Heroku and third party apps

3.6.8 Red Hat Open Shift

Open Shift is the PaaS offer from Red Hat and is available in three versions:

• OpenShift Online • OpenShift Enterprise and • OpenShift Origin.

32


OpenShift Origin is the usual PaaS solution in the public cloud and the foundation of

OpenShift Online and OpenShift Enterprise. OpenShift Online is reduces the interaction

with OpenShift to the cloud with the purpose of a fast and easy to use online service.

OpenShift Enterprise offers enterprises a private cloud.

https://www.openshift.com/developers

Languages

Java, JBoss, PHP, Node.js, Ruby, Python, Perl

3.6.9 Other vendors

Following is an overview of the other PaaS vendors.

• HP Cloud Service • Cloud Foundry • Cloud Bees • Heroku • SAP NetWeaver • WSO2 Strator • AppScale • GigaSpaces • Cloudify • Cordy PaaS • TCS Instant Apps • Force.com WOLF • Manjrasoft Aneka • COSCA • Cumulogic • EngineYard

3.6.10 Comparison of the biggest vendors

The following table presents the scheme used to lead a comparison of the offerings of

the biggest PaaS vendors.

PaaS Offerings

Application Application Framework

33


• Name • Runtime:

o Language o Version

Application Extensibility:

• Design Time • Runtime Support

Services:

• Name • Description • Type • Version

Status:

• Beta • Production

Development Project Management tools:

• Collaboration Tools • Project Tracker • Source code versioning

Infrastructure SLA:

• Policies etc…

Pricing:

• Model o Fixed o Hybrid on Resources o Usage

Scaling:

• Auto • Horizontal • Vertical

Hosting:

• Public • Private

Database:

• Name • Description • Version • Multi-‐tenant • Dependencies (MySQL or other db) • Persistence Layer

34


Deployment Testing tools:

• Live Deployment testing • Debugging facilities

Application Deployment

• Automatic deployment • Assisted Deployment • Versioning Deployment • Bug fixing deployment

Security Standard:

• Application • Data • Infrastructure

Portability Standard:

• Tools e.g. OpenAPI • Methodologies • SLA

o Service Description o Standard formats o Response Time o Availability (NFR)

Table 2 -‐ Comparison of the biggest vendors -‐ scheme table

The following tables show the comparison of the PaaS offerings of the biggest PaaS

vendors. The compared attributes are clustered in the following headlines:

• Application • Infrastructure • Deployment • Security and • Portability.

Application

Amazon

Google

Microsoft

Oracle

IBM

Salesforce

Force.com

Heroku

Red Ha

t Ope

nShift

General Status (Beta,

Production)

35


Usability GUI Develop-‐

ment tools

Eclipse PlugIn √ √ √ √

Visual Studio

PlugIn √ √

Git √ √ √

Administrative

interface with

menu, naviga-‐

tor, controls

Application .NET √ √ √ Go √2 X Docker √ X Java √ √ √ √ X √ √ Node.js √ √ X √ √ PHP √ √3 √ X √ √ Python √ √ √ X √ √ Ruby √ √ X √ √ Pearl X √ Proprietary Apex

Application

Extensibility:

Design Time Runtime Sup-‐port

Services Virtual M EC2 Virtual

Machine

Scaling Auto Scaling √ (auto) √

(auto)

CDN CloudFront Azure CDN

Loadbalancer ELB Traffic √

2 Go in an experimental stage. 3 PHP in a preview stage.

36


Manager

Monitoring CloudWatch √ (integrat-‐

ed)

DNS Route 53 Azure

Websites

Tech Protocol REST, JSON REST,

SOAP

REST

Table 3: Vendor comparison -‐ Application

Infrastructure Am

azon

Google

Microsoft

Oracle

IBM

Salesforce

Force.com

Heroku

Red

Hat

Ope

nShift

SLA CPU 99.95 99.95

Storage 99.9 99.9

Maintenance

is defined as

blackout

√ √ √

Replication √ √ √

Scaling Auto

Horizontal √ √ √ √

Vertical √ √ √ √

Hosting Public √ √ √

Private Via VPC OpenShift

Enterprise

Databases RDBMS RDS Azure

SQL-‐

DB

NoSQL DynamoDB Tables √ (Mon-‐

goDB)

PostgreSQL

IBM DB2 √ X

MS SQL

Server √ √

Oracle √ √

37


MySQL √ √ √

Table 4: Vendor comparison -‐ Infrastructure

Deployment

Amazon

Google

Microsoft

Oracle

IBM

Salesforce

Force.com

Heroku

Red

Hat

Ope

nShift

Testing tools Live Deploy-‐

ment testing

Debugging

facilities

Application

Deployment

Automatic

deployment

Assisted De-‐

ployment √ √

Versioning

Deployment √ √

Bug fixing

deployment

Table 5: Vendor comparison -‐ Deployment

Security

Amazon

Google

Microsoft

Oracle

IBM

Salesforce

Force.com

Heroku

Red

Hat

Ope

nShift

Standard ISO 27001

Application

Encrypted

Access √ √

Data Encrypted

Data √ √

Table 6: Vendor comparison – Security

38


4 State of the Art in Cloud Computing Interoperability

This section introduces the term “interoperability” with regards to Cloud Computing.

4.1 Definition Cloud Computing Interoperability

Interoperability is defined by the European Commission (EC) as an extensive concept

that embraces the capability of entities to exchange data and information work to-‐gether for their common goals.

“‘interoperability’ means the ability of disparate and diverse organizations to in-‐

teract towards mutually beneficial and agreed common goals, involving the shar-‐ing of information and knowledge between the organizations, through the busi-‐ness processes they support, by means of the exchange of data between their

respective ICT systems.” (European Commission 2009)

This is the definition of interoperability of the European Commission (EC).

In the literature there are many definitions of Cloud Computing interoperability.

Under consideration of the vendor lock problem that was explained in the problem statement, the definition “interoperability refers to costumers’ ability to use the same artifacts, such as management tools, virtual server images, and so on, with a variety of

Cloud Computing providers and platforms” (Sambyal, Jamwal und Sambyal 2010)

seems to be very adequate.

One of the most detailed definitions that clarify the terms “Cloud Computing interop-‐

erability, portability and compatibility” is the one of Reuven Cohen. He describes that

Cloud Computing interoperability focuses on the ability to cooperate across various

cloud platforms. The aim of cloud interoperability is to simplify the utilization of vari-‐

ous cloud providers due to their common set of application interfaces.

Compatibility and portability are describing how interoperability can be achieved. So

these two terms can be seen as subsets of interoperability. Cloud Compatibility implies

that data and applications are processed identically irrespective of the cloud provider.

Cloud Portability refers to the ability that application components can be simply trans-‐

ferred without any restrictions regarding cloud providers or platforms (Cohen 2009).

39


4.1 Interoperability and portability

In the research field Cloud Computing respectively PaaS, the concepts interoperability

and portability are frequently used, sometimes without drawing a distinction. The two

concepts can work together and help each other, but do not necessarily depend on

each other. Interoperability is the ability of different systems to work preferably seam-‐less together. Portability defines the ability to be transferred from one machine or sys-‐

tem to another. The important difference, which has to be highlighted, is the idea of

interoperating or cooperating systems.

4.2 Definition Semantic Interoperability

Semantic Interoperability extends the interoperability term by adding the ability that

exchanged information is automatically interpreted meaningful and exact according to

generate proper outcomes as specified by the end users of both systems. Semantic interoperabilty can be reached, when both sides use a common information exchange

reference model. The information exchange request content is clearly defined. The

sent information is the same as the understood information (Psaty und Burke 2006).

4.3 Cloud Computing interoperability approaches

There are different Cloud Computing interoperability points of view. It attempts to

illustrate the different interoperability classifications and to explore the characteris-‐

tics/aspects of each approach. The clear understanding and identification of the re-‐

quirements that ensure interoperability is definitely the first step towards the stand-‐

ardization of Cloud Computing platforms, APIs and services.

An approach in delimitating Cloud Computing interoperability is presented by Sheth

and Ranabahu (Sheth and Ranabahu 2010), where Cloud Computing interoperability is

closely associated with the type of heterogeneity that arises during the interoperation

of Clouds. Clouds interoperate to meet the needs of client applications using infra-‐

structure, platforms or services coming from different Clouds. Sheth and Ranabahu

recognize two types of heterogeneity; vertical and horizontal. Using the term “silo”,

they refer to IaaS, PaaS or SaaS Cloud level.

Vertical heterogeneity emerges within a silo, i.e. when a customer needs to utilize ser-‐

vices from different layers of the Cloud stack, but within the same silo. Horizontal het-‐

40


erogeneity depends on the level of the Cloud stack and therefore it is divided in three

subcategories, dealing with the interoperability at IaaS, PaaS and SaaS level, respec-‐

tively. It emerges when a customer opts to use simultaneously more than one services

hosted at different providers or to change service provider, while also remaining in the same Cloud stack layer.

Furthermore, they describe portability as inversely proportional to automation across

different layers (Figure 4). Since providers of higher layers offer customized services

with limited set of configurations, automation increases but it negatively affects the portability and the interoperability of the system.

ENISA focuses on the lock-‐in problem at each level of the Cloud stack separately, since

each level deals with different services (Catteddu and Hogben 2009). According to ENI-‐SA, IaaS computing offerings consist of software and virtual machine (VM) metadata

which are bundled together and distributed. Hence, the lock-‐in problem at the IaaS level depends on the infrastructure services utilized. Therefore, a customer using

Cloud storage will not be impacted by not-‐compatible VM formats. He will be affected

only by different features sets, which in this case are data characteristics, as well as

semantics (terminology) which describe these features and vary significantly in the storage offerings.

In the same document, PaaS lock-‐in occurs at both the API (i.e. platform specific API

calls) and the component level (i.e. a PaaS provider may offer a higher efficient back-‐end data store).

Therefore, even if a compatible API is offered, the data may not be portable across PaaS offerings, as different data access models may exist. For security reasons PaaS environments often use heavily customized runtimes which also affect interoperability.

Lock-‐in problems are also identified, according to ENISA, in the SaaS layer. They occur

at data and application level. Customer data is typically stored in a custom database

schema designed by the SaaS provider. Most SaaS providers offer API calls to read data

records, but lock-‐in can’t be prevented as they do not offer readymade data export routines. In such a case, the customer has to develop a program to extract its data and

write it to file ready for import to another provider.

On the other hand, SaaS providers usually develop custom applications tailored to the needs of their target market therefore switching between different providers may

need re-‐writing of applications to interact with the new provider’s API.

41


Following a different approach, Urquhart (Lee 2010) claims that Cloud Computing in-‐

teroperability is an issue that arises in i) application/service, ii) management and iii)

image/data level. In this approach, PaaS and SaaS are both referred as applications.

Application interoperability is then the ability of developers to create loosely coupling applications which are platform independent, while management interoperability de-‐

pends on APIs compatibility. Image or data interoperability is based on how a virtual

server image, a Java application or a database is defined, in order to be deployed on

another provider.

42


5 Interoperable Cloud Computing Models

This part indicates how beneficial interoperability is for the service models. Moreover,

this section shows how different interoperability problems can be tackled. Further-‐

more, different interoperable models are illustrated.

5.1 Role of standardization for the Service Models

Four main elements of an open cloud platform were outlined by Microsoft. These ele-‐

ments are data portability, standards, ease of migration & deployment and developer

choice (Paoli 2010). Microsoft defined for each of the 4 main elements a key question

and tried to answer it (See Table 7).

Table 7: Interoperability Elements of a Cloud Platform (Paoli 2010)

The Cloud4SOA project also identified the following five problems as the main PaaS

interoperability problems (Loutas 2011, 29-‐30):

• High variety of PaaS APIs

• It exists a high variety of programming languages, frameworks, SDKs and tool-‐

sets

• It exists no standard for services like accounting, billing, advertising and meter-‐

ing

• Different types of PaaS solutions are offered

43


• Different data types and storage approaches exist

against the alternative use of systems in the concept of portability.

5.2 Interoperability Initiatives Overview

The improvement of the current status is the target of many initiatives. The Cloud4SOA

community analyzed 14 of them. The Cloud4SOA R&D project aiming to achieve in-‐

teroperability was supported by the EU. The project has been done from September

2010 till August 2013 (Cloud4SOA 2013). This project is the baseline of the current

PaaSport project. However, since then, many initiatives that were analyzed at this

stage are not active anymore.

The interoperability initiatives basically try to tackle interoperability problems by

standardized APIs and cloud models. Standardization bodies, non profit groups and

member operated organizations work on advancing interoperability standards, with the collaboration of academia, researchers, governments and vendors (Loutas 2011,

23). Some of the most active standardization groups are for example the Cloud Com-‐

puting Interoperability Forum, the European Telecommunications Standards Institute

Technical Committee, the IEEE and NIST (Seventh Framework Programme 2013, 19 (Part B)).

Some of the R&D initiatives deal with more than just one service model. Summarized

it can be said that eight initiatives try to find interoperability solutions for IaaS and

SaaS. Just the four following initiatives focus on the standardization on the PaaS level

(Loutas 2011).

Most of the standardization bodies think that semantic interoperability is a key enabler

of seamless application portability. Semantic interoperability can be achieved by de-‐

veloping standardized models for Cloud PaaS, resources, services, etc. and by specify-‐ing and implementing a standardized Cloud API that will interface all different Cloud

PaaS. Furthermore, they argue that the creation of a Cloud broker/marketplace will

resolve many of the existing interoperability problems without spending significant

effort on a restructuring of the current systems of the Cloud vendors (Seventh Framework Programme 2013, 19 (Part B)).

44


Table 8 shows several initiatives, similar to PaaSport, which try to address the issues of

application and data portability as well as interoperability. The key characteristics (tar-‐

geted Cloud level, use of semantics, Cloud Computing interoperability, data and appli-‐

cation portability and user-‐centricity) are derived from the PaaSport goal. Most of the existing standardization efforts mainly focus on the Infrastructure as a Service (IaaS) or

the Software as a Service (SaaS) levels (Loutas 2011). Only the Cloud4SOA project fo-‐

cused on resolving the semantic incompatibilities raised both within the same as well

as across different Cloud PaaS systems. It enables Cloud-‐based application develop-‐ment, deployment and migration across heterogeneous PaaS offerings. Furthermore,

the Cloud4SOA project proposed a unified PaaS API, which will be re-‐used and further developed in PaaSport.

Cloud / PaaS Semantic Interoperability Initiatives

Initiative name

Targeted

Cloud

level

Use of

Semantics

Cloud Computing

Interoperability

Data and/or

Application

Portability

User-‐

centricity

4CaaSt PaaS R R

CumuloNimbo PaaS R R

Cloud-‐TM IaaS R R

mOSAIC IaaS R R

semantic R R

CONTRAIL IaaS &

PaaS R R

VISION Cloud IaaS R R

semantic R

REMICS SaaS R R

semantic R

RESERVOIR IaaS R R R

SLA@SOI IaaS R R R

SITIO SaaS R R

semantic R R

Cloud@Home IaaS R R R

Cloud4SOA PaaS R R R R

45


Cloud / PaaS Semantic Interoperability Initiatives

Initiative name

Targeted

Cloud

level

Use of

Semantics

Cloud Computing

Interoperability

Data and/or

Application

Portability

User-‐

centricity

Semantic

Table 8: Cloud/PaaS semantic interoperability initiatives

Besides, a group of Cloud platform vendors (CloudBees, Cloudsoft, Huawei, Oracle,

Rackspace, Red Hat, Software AG) recently released the Cloud Application Manage-‐

ment for Platforms (CAMP). CAMP proposes a generic application and platform man-‐agement API which is language, framework and platform neutral. PaaSport will capital-‐

ize on this initiative in order to leverage its applicability and broaden its scope to cover the needs of existing players and new-‐comers in the European PaaS market.

PaaSport will reuse and capitalize on existing standards, for example Cloud resource

models, architectures and APIs, to avoid developing yet another interoperability solu-‐tion that remains non-‐interoperable with others.

5.3 Existing Results

Following is an analysis of the existing results of the latest initiatives in the area of cloud interoperability.

While studying the different initiatives, we considered the following issues.

PaaS Offerings

Application Application Framework

• Name • Runtime

o Language o Version

Application Extensibility:

• Design Time • Runtime Support

Services:

• Name

46


• Description • Type • Version

Status:

• Beta • Production

Development Project Management tools:

• Collaboration Tools • Project Tracker • Source code versioning

Infrastructure SLA:

• Policies etc…

Pricing:

• Model o Fixed o Hybrid on Resources o Usage

Scaling:

• Auto • Horizontal • Vertical

Hosting:

• Public • Private

Database:

• Name • Description • Version • Multi-‐tenant • Dependencies (MySQL or other db) • Persistence Layer

Deployment Testing tools:

• Live Deployment testing • Debugging facilities

47


Application Deployment

• Automatic deployment • Assisted Deployment • Versioning Deployment • Bug fixing deployment

Security Standard:

• Application • Data • Infrastructure

Portability Standard:

• Tools e.g. OpenAPI • Methodologies • SLA

o Service Description o Standard formats o Response Time o Availability (NFR)

Usability • GUI Development tools • Administrative interface with menu, navigator, controls

Table 9: Cloud interoperability initiative analysis frame

5.3.1 NIST Cloud Computing Interoperability and Portability Working Group

The NIST Cloud Computing Interoperability and Portability Working Group (NIST

CIPWG) focuses on Cloud Computing and not primary on the PaaS sector. In its charter (May 19, 2014) the working group defines its initial focus:

• Types of Cloud Computing interoperability and portability; • Relationship and interactions between interoperability and portability; • Contexts where interoperability and portability are relevant in Cloud Compu-‐

ting with respect to the Cloud Computing reference architecture; and • Common terminology and concepts used to describe interoperability and port-‐

ability, and • Particularly as they relate to cloud services.

A part of the CIPWG, the Department of Defense (DoD) Information Network (DoDIN)

Global Information Grid (GIG) Cloud Computing Services Guidance Working Group (DCCSGWG), published an interoperability and portability technical framework and an

interoperability and portability reference architecture (Department of Defense

48


Information Network Global In-‐formation Grid Cloud Computing Services Guidance

Working Group 2013), which guides through Cloud Computing interoperability and

portability.

Interoperability and portability technical framework

The technical framework presents an overview over the existing standards in Cloud

Computing and establishes service guidelines to promote the usage of these specifica-‐

tions and protocols. The only two standards, which are evaluated as mature enough,

are the Open Virtualization Format (OVF) and the Cloud Data Management Interface (CDMI).

After the standards, common requirements and use cases are defined to describe the

technical framework with its vision of portability and interoperability.

The examined standards and the requirements and use cases have to be integrated

into the requirements analysis.

Interoperability and portability reference architecture

The reference architecture contains interoperability and portability requirements and

divides them into the three categories Cloud Management Interoperability, Cloud Re-‐

source Interoperability and Cloud Resource Portability, which are described by respec-‐tive principles and rules.

The second relevant part of the reference architecture is the technical position, which

serves a Standards Profile and a Standard Forecast, which describe a set of standards respectively of emerging standards. The technical position also defines Architectural

Patterns for Cloud Management Interoperability, Cloud Resource Interoperability and Cloud Resource Portability and a selection of use cases. The Architectural Pattern for Cloud Management Interoperability, shown in Figure 9, is evaluated as very useful to

visualize the interfaces, a Cloud Service Broker (CSB) has to provide.

49


Figure 9: Cloud Management Interoperability (Department of Defense Information Network Global In-‐formation Grid Cloud Computing Services Guidance Working Group 2013)

The third relevant part of the paper is the Functional Solution Analysis with the chap-‐ters

• IaaS – Compute Migration Interoperability, • IaaS – Storage Services Interoperability, • PaaS Interoperability, • Data as a Service (DaaS) Interoperability and • SaaS Interoperability.

This part examines the options to enable service providers to create interoperable ser-‐

vices.

50


5.3.2 Cloud4SOA

“The vision of Cloud4SOA is to open up the Cloud market to small-‐medium European

PaaS providers and strengthen their market position and to treat the vendor-‐lock in

problem. Cloud4SOA will thus enhance Cloud-‐based application development, de-‐ployment and migration by semantically interconnecting heterogeneous Platform as a

Service (PaaS) offerings both within the same as well as across different Cloud PaaS

providers and will facilitate the access of Cloudbased application developers to the

PaaS offering that best matches their computational needs.” (Cloud4SOA 2012)

Derived from a requirement analysis, the initiative defined core capabilities that have

to be covered by the system. These capabilities are semantic matchmaking, manage-‐

ment, migration and monitoring. Semantic matchmaking is the capability that is neces-‐sary to solve semantic conflicts that arise by changing the PaaS provider. Requirements

of the customer and PaaS offers are coordinated even when the requirements are ex-‐pressed differently. The matchmaking is possible due to the ability to match provider

concepts. A PaaS independent efficient governance and development of applications is

enabled by the second core capability management. Moreover, this capability enables

developers to manage their application life-‐cycle in a comparable way, regardless of the platform. Additionally, agreements between a developer and a PaaS offering can

be established through the SLA mechanism of the application management. Migration

is the third core capability that enables the migration of deployed applications on oth-‐er platforms. Two main steps are defined by Cloud4SOA that are necessary to move

the application from one PaaS offering to another. The first step is moving the applica-‐tion data, followed by the second step, moving and re-‐deploying of the application on the new PaaS offering. The fourth core capability is monitoring. The monitoring capa-‐

bility allows regardless of the platform, that the condition and the performance of business-‐crucial applications are monitored. Target of monitoring is to achieve that the

performance and expectations are met constantly. User expectations are defined

through the existing SLA. Because of the variety of PaaS offerings, Cloud4SOA decided to provide the mentoring capability based on a unified metrics which is platform inde-‐

pendent. (Kamateri, Loutas und Zeginis 2013)

Cloud4SOA Reference Architecture

Based on the paradigms, Cloud Computing, Service Oriented Architecture (SOA) and

light-‐weighted semantics, Cloud4SOA created a reference architecture. Operational prototypes help to improve this broker-‐based architecture. The reference architecture

51


consists of five layers, two of them are vertically and three are horizontally arranged.

(Kamateri, Loutas und Zeginis 2013)

Figure 10: Cloud4SOA Reference Architecture. Source: (Zeginis, et al. 2013, 22)

Front-‐end Layer

The front-‐layer facilitates the user-‐centric approach of Cloud4SOA. Moreover, the layer

enables PaaS providers and developers to access the Cloud4SOA functionalities. The

web based interface is designed in the style of a dashboard that gives the users an

overview regarding application performance and helps to manage the applications.

SOA Layer

This layer can be seen as mediator between the layers. It enables the Front-‐end layer

to access the core functionalities. The toolbox of the SOA layer consists of the follow-‐

ing modules: (Kamateri, Loutas und Zeginis 2013)

52


• Profile Management module: It uses the models of the semantic layer to allow

the management of PaaS offerings, applications and user profiles.

• PaaS Matchmaking module: is connected to the search mechanism of the Re-‐

pository layer. Semantic models and techniques are deployed, targeting to find

the best PaaS offering that is available.

• PaaS Recommendation module: Suggestions for the best fitting PaaS offerings

are provided by this module. Furthermore, this module facilitates to assess

PaaS offerings.

• Application Deployment module: This module uses the Harmonized API func-‐

tionalities to provide different capabilities of the back-‐end. These capabilities

are for instance the application deployment and governance on PaaS offerings.

• Application Migration module: This module tackles upcoming semantic in-‐

teroperability problems during a migration from one PaaS offering to another.

• Application Monitoring module: Enables the interaction with the monitoring

functionality and a parameter based search by an interface.

Semantic Layer and Cloud4SOA Semantic Model

This layer can be seen as the backbone of the architecture. The formal representation information is provided by this layer. The meant information are for example PaaS of-‐

ferings, applications and user profiles. Moreover, the semantic layer solves interoper-‐

ability conflicts in the whole architecture and sets a common basis for announcing and searching dissimilar PaaS offerings. Because of the different focuses, each of the three

main components, namely User Model, Application Model and PaaS Model, has its

own objective (Kamateri, Loutas und Zeginis 2013). The Cloud4SOA Semantic model consists of the Infrastructure tier, Platform tier, Appli-‐

cation tier, User tier and Enterprise tier which are explained more detailed in the fol-‐

lowing part.

• Infrastructure tier: This layer collects infrastructure knowledge about hardware

component, programming language, software component and QoS parameter.

Moreover, a common language that enables the matching of applications and

PaaS offerings.

53


• Platform tier: PaaS vendors use it to illustrate their platform, infrastructure and

enterprise.

• Application tier: Developers define their applications.

• User tier: The User Tier enables the user a creation of a semantic profile that is

able to reuse concepts from the FOAF ontology.

• Enterprise tier: The enterprise participants are described by this tier. Moreo-‐ver, relations of the enterprises to other entities are expressed and concepts of

the PaaS vendors and SLA agreements are shaped.

Figure 11: Cloud4SOA Semantic Model. Source: (Kamateri, Loutas and Zeginis 2013, 73)

Governance Layer

The business-‐centric focus of the Cloud4SOA is realized by the Governance layer. To

measure performance and mitigation violations developers can set up their user-‐

defined SLA metrics. Moreover, the governance layer allows the lifecycle execution

and management of applications, without disregarding monitoring of information,

SLAs and scalability concerns.

Repository layer and harmonized API

The repository layer stores semantic and syntactic data. The seamless interconnection

and management over the various PaaS offerings is enabled by the harmonized API.

Moreover, the API can be seen as a mediator between the PaaS offerings and

Cloud4SOA system. The harmonized API is able to handle the dissimilar provider APIs.

54


Adaptors help to translate the functions between the harmonized API of the

Cloud4SOA and the API of the PaaS vendors.

Cloud4SOA project evaluation and conclusion

Based on the deployment in two hybrid scenarios the Cloud4SOA system has been tested and evaluated regarding usefulness and performance. The result is that users

who want to use a hybrid model can benefit from the system due to the ability of de-‐

ploying, monitoring and governing the cloud parts from one place. Furthermore, useful

performance information about the applications is provided by the Cloud4SOA solu-‐tion.

Moreover, a comparison has been done between the direct execution of operations at

the provider and the indirect execution via Cloud4SOA. Each operation was repeated ten times and average result was calculated. Table 10 depicts the findings and shows

that the usage of Cloud4SOA leads to longer operation times but under the considera-‐tion of the added value by Cloud4SOA, the extension on this scale is adequate.

The Cloud4SOA solution offers a vendor independent management, monitoring and

migration system that overcomes the vendor-‐lock (Zeginis, et al. 2013).

The outcome of the Cloud4SOA project is available as Cloud Pier platform today. Cloud Pier continues the interoperability efforts of Cloud4SOA (Cloud Pier & Cloud4SOA

2013, 1).

However, Cloud4SOA has just achieved PaaS interoperability (Zeginis, et al. 2013). In-‐teroperability over different service models is much more complex and challenging to

achieve (Rashidi, Sharifi and Talieh 2013, 18).

Table 10: Comparison of Performance between Cloud4SOA and the PaaS API. Source:

(Zeginis, et al. 2013, 30)

55


5.4 mOSAIC

mOSAIC is an open source API and platform to ensure the portability of application

between cloud resources. mOSAIC solutions covers three business cases:

• Scenario 1: Changing the Cloud, • Scenario 2: Service brokerage and • Scenario 3: Development of Cloud applications.

The main components of the mOSAIC solutions are the followings:

(https://joinup.ec.europa.eu/software/mosaic/description)

1. Software platform support: Platform’s core components, Application service or support components

2. Application support: API implementations, Application tools, Semantic engine and Service discoverer;

3. Infrastructure support: Cloud agency, Agency service components; 4. Vendor back-‐ends: for Private or Public Clouds; 5. Cloud-‐based proof-‐of-‐the concept applications

Architectural design of mOSAIC's API and platform (v. 2.0)

The mOSAIC solution is based on a set of basic concepts, which help to visualize cloud applications and their behaviors (Rak, Sandru und Di Martino 2011, 26 f.). The most

relevant concepts are:

• Cloud resources, • Cloud component, • mOSAIC application, • Application descriptor, • Component list and • Call for proposals (CFP).

The main concept is the component. Developers are using the mOSAIC API to define components which represent entities that provide a specific functionality and use

cloud resources. An Application Descriptor summarizes a collection of components to a

mOSAIC Application. A CFP summarizes the constraints of the cloud resources, the

cloud agency provides.

The mOSAIC API

56


The mOSAIC API is subdivided in layers, with the native resource protocol at the bot-‐

tom up to the user components at the top (compare Figure 12). Table 11 shows the

mOSAIC APIs.

Figure 12: mOSAIC API layers (Rak, Sandru und Di Martino 2011, 57-‐60)

API Description

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

Driver API Wraps the native API and let 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 developer to create components. Its focus is the life-‐cycle

of the software component.

Table 11: mOSAIC APIs (Rak, Sandru und Di Martino 2011, 57-‐60)

mOSAIC conclusion

(Gonidis, Paraskakis und Kourtesis 2012, 6 f.) describes the mOSAIC API as an interme-‐

diary layer between developers and PaaS vendors avoiding proprietary APIs. The mO-‐

SAIC framework eases application portability and can be classified as an intermediation

57


approach helping to avoid vendor lock in (Petcu, et al. 2013), written after the comple-‐

tion of development, gives a component view of the integration platform (compare

Figure 13) and names the vendor-‐agnosticity as the main reason for using mOSAIC be-‐

side the possibility to migrate applications from one cloud provider to another.

Figure 13: mOSAIC -‐ Component view of the integration platform (Petcu, et al. 2013, 6)

5.4.1 OASIS CAMP TC

The advancing open standards for the information society (OASIS) cloud application

management for platforms (CAMP) technical committee (TC) is working at an interop-‐erable protocol, where interfaces for services and a generic application and platform

58


management API is defined. To this purpose, the CAMP specification (Durand, et al.

2014) defines artifacts and formats to foster the homogenization of PaaS and ease

running, administration, monitoring and patching of applications. Furthermore, CAMP

proposes to generate benefits for the consumers like

• Portability between clouds and • Increase attention and quality

and the providers like

• the increase the portability between PaaS offerings and • help to grow the PaaS pie. (Durand, et al. 2014, 9)

The CAMP API

In February 2014, the CAMP TC published the “Cloud Application Management for

Platforms Version 1.1” in the “public review draft 02”. The CAMP API is based on the

Hypertext Transfer Protocol (HTTP). It is made up of resources which are accessed via RESTful webservices.

Figure 14: CAMP Resources as UML Classes (Durand, et al. 2014, 16)

5.5 Other initiatives

The following table shows the reviewed work which were identified as useful under a specific focus.

59


Name Fo-‐

cus

Is a rele-‐

vant

Diskussion

Group/

Forum

Description/comments

CloudCamp X √ One conference where early adopters of Cloud Computing technolo-‐

gies exchange ideas. http://cloudcamp.org/

Cloud In-‐

dustry Fo-‐

rum

Vari-‐

ous

√ The CIF defines a “Code of Practice” for cloud service providers

(http://cloudindustryforum.org/code-‐of-‐practice/code-‐of-‐practice)

that cares about requirements of transparency, capability and ac-‐

countability. There is no direct technical focus.

Cloud Se-‐

curity Alli-‐

ance

Se-‐

curi-‐

ty

√ The Cloud Security Alliance (CSA) is a not-‐for-‐profit organization with a

mission to promote the use of best practices for providing security

assurance within Cloud Computing... CSA offers certification in security

issues and collaborates with the International Standardization Council

(ISC).

https://cloudsecurityalliance.org/

Cloud

Standards

customer

Council

(Object

Manage-‐

ment

Group

(OMG))

SLA √

useful

hints in

SLA

Cloud Standards customer Council (CSCC) offer a number of papers

(e.g. Practical Guide to Cloud Computing, Practical Guide to SLAs ...)

which contain sets of guidelines and strategies to help decision makers

in all major activities related to clouds and to solve business challeng-‐

es.

http://www.cloud-‐council.org/

http://www.omg.org/

http://www.cloudstandardscustomercouncil.org/PG2CC_v2.pdf

http://www.cloudstandardscustomercouncil.org/2012_Practical_Guid

e_to_Cloud_SLAs.pdf

Distributed

Manage-‐

ment Task

Force

(DMTF)

Vari-‐

ous

√ DMTF’s “…mission is to create standards that enable interoperable IT

management…” (http://www.dmtf.org/standards/cloud) As a result of

the work there are some DMTS specifications and whitepapers. Useful

could be DSP-‐IS0101 Interoperable Clouds, DSP0262 Cloud Auditing

Data Federation (CADF) -‐ Data Format and Interface Definitions Speci-‐

60


fication and particularly DSP0263 Cloud Infrastructure Management

Interface (CIMI) Model and RESTful HTTP-‐based Protocol. The DMTF

also provides the Open Virtualization Format (OVF), which is a packag-‐

ing standard that provides packaging and secure distribution of virtual

machines across various platforms.

European

Telecom-‐

munica-‐

tions

Standards

Institute

(ETSI)

√ √ ETSI defines a set of standards for Cloud Computing. Some of these

standards can be adopted for the requirements analysis respectively

for the offered features in the platform design.

http://www.etsi.org/index.php/technologies-‐

clusters/technologies/grid-‐and-‐cloud-‐computing

Global In-‐

ter-‐Cloud

Technology

Forum

(GICTF)

Vari-‐

ous

√ GICTF has a cloud approach… not a specific part (IaaS, PaaS, SaaS).

GICTF gives catalogues with functional requirements, structure and

interfaces without defining concrete numbers or services. The cata-‐

logues can be projected to the considered problem.

IEEE P2301

Working

Group

Port-‐

abil-‐

ity

√ The IEEE P2301 proclaims to develop the “Guide for Cloud Portability

and Interoperability Profiles (CPIP)” to assist cloud vendors and users

to standards-‐based products and services with the focus on portabil-‐

ity, commonality, and interoperability. The guide isn’t available yet!?

Open Grid

Forum

(OGF) and

its Open

Cloud

Computing

Interface

(OCCI)

Infra-‐

fra-‐

struc

ture

√ OGF is a community with a focus on grid computing. Its most relevant

work is the OCCI.

OCCI delivers a set of specifications for deployment, autonomic scaling

and monitoring across different cloud service providers and an API

that is adopted by some Cloud Computing stacks. With the open inter-‐

face and formats and the OCCI extensions, it might be a useful proto-‐

col/ possible supported standard on IaaS Layer. (claims to serve PaaS)

Open Data

Center

Alliance

(ODCA)

Vari-‐

ous

√

Procure-‐

cure-‐

ment à

The ODCA doesn’t define a standard. ODCA has a cloud approach… not

a specific part (IaaS, PaaS, SaaS). ODCA did research in this sector and

offers a “Cloud Service Provider Search” and various papers about

privacy and security, procurement of Cloud Services and about best

practices. The information (especially of the procurement part) could

61


manage

age-‐

ment

and SLA

be useful.

http://www.opendatacenteralliance.org/

PaaS Se-‐

mantic

Interoper-‐

ability

Framework

(PSIF)

√ √ PaaS Semantic Interoperability Framework (PSIF) proposed by Loutas

et al. aims at modelling semantic interoperability conflicts that may

occur during migration or deployment of an application on a cloud

platform. The framework is structured according to 3 dimensions, (i)

the different architectural entities in a PaaS environment, (ii) the type

of semantics of a PaaS entity’s description i.e. functional, non-‐

functional and execution semantics, (iii) and the level at which seman-‐

tic conflicts occur, i.e. the level of the information model and the level

of data. Semantic conflicts are identified and classified according to

these 3 dimensions.

Loutas et al., provide two examples of the framework’s operation. In

the first example, an application is ported from one platform to an-‐

other. A conflict arises when the application is trying to connect to a

database, because the two platforms use different function calls (e.g.

―connect a db‖ vs. ―insert a db‖). This semantic conflict occurs due

to differences in the definitions of the management interfaces of the

two platforms and specifically due to the way their functional seman-‐

tics are modelled. The conflict is raised at the data level, since it is

caused by different naming of the same functionality. Another seman-‐

tic conflict may occur due to differences in modelling of the PaaS of-‐

ferings. For example, one provider uses a field ―programming lan-‐

guage‖ to describe both the language and the version, e.g. Java 1.6,

while another platform offering uses two different fields. This conflict

is raised due to differences at the PaaS offering entity and specifically

to the way the non-‐functional semantics are modeled. The conflict

occurs at the information model level, since it is caused by different

logical representation of the same information. In a similar way, other

semantic conflicts which may occur while moving applications across

platforms are classified.

Having modelled in detail the fundamental PaaS entities in a particular

PaaS offering, a semantic layer will be implemented to provide a PaaS

Offering Model and an Application Model for the common description

of available PaaS offerings. PaaS providers will be able to publish their

62


offerings based on these common models. By letting providers adopt a

common model for their offerings the application portability across

the platforms will be enhanced. According to our understanding and

the available literature on the PSIF, we could classify this work as an

approach of defining a set of common standards.

Storage

Networking

Industry

Association

(SNIA)

Vari-‐

ous

√

Look if

it’s too

IaaS

specific

SNIA focuses on data storage but also on data analytics and protec-‐

tion. They proclaim the goal “…promote acceptance, deployment, and

confidence in storage-‐related architectures, systems, services, and

technologies, across IT and business communities.”

http://www.snia.org/

The Cloud Data Management Interface (CDMI) defines a interface

applications will use to create, retrieve, update and delete data ele-‐

ments from the Cloud.

http://www.snia.org/cdmi

Zend Sim-‐

pleCloud

Vari-‐

ous

√

SimpleCloud is an API that allows developers to use storage services

independently of particular cloud platforms. Among others, it offers

two key services: (i) File Storage Service and (ii) Document Storage

Service. The File Storage Service allows for performing operations on

files such as storing, reading, deleting, copying, storing metadata, etc.

It does so by providing so-‐called ―storage service adapters‖ that allow

developers to access storage services from Amazon, Microsoft Azure,

Rackspace and others, using the same application code. The Docu-‐

ment Storage Service abstracts the interfaces of all major document

databases, again allowing developers to access different providers

through a single API. SimpleCloud is supported by IBM, Microsoft,

Rackspace, GoGrid, and several other cloud service providers. By offer-‐

ing an API for storing data which abstracts/hides all proprietary ones,

SimpleCloud can be considered as an intermediary layer for decou-‐

pling applications from directly accessing the storage mechanisms of

specific platforms.

63


6 Effect of Cloud Computing for stakeholders

The following chapter focuses on IaaS, SaaS and in particular on PaaS-‐Systems and

aims, how the lock-‐in problem can be tackled. Different models are shown and evalu-‐

ated for that reason.

A further objective is to show the potential of cloud system, particularly interoperable

cloud systems for customers to reduce costs. This potential will be showed more spe-‐

cifically through Key Performance Indicators to give practitioner tools to make that

cost effectiveness tangible and measurable. Another target is also to illustrate synergy

effects and to show how every stakeholder benefits of the cloud system, when every-‐

body focuses on its core competences.

The objective of this section is to show how the main stakeholders, PaaS-‐Provider, De-‐

veloper and Customer could benefit from interoperability. The effects for the custom-‐ers are shown more detailed.

6.1 Target groups

On the way to the targeted PaaSport platform, first key topics have to be clarified:

• Which are the target groups of the PaaSport platform? • Which services will the platform offer?

The target groups for the PaaSport platform can be divided into two types, the PaaS

vendors and the PaaS customers. Each of these types of user can be subdivided into

further two groups. This differentiation is shown in the following figure.

64


Figure 15 -‐ Target groups

The target groups will respectively offer use services.

Figure 16 -‐ Services which will be offered

65


6.2 PaaS Providers

6.2.1 General Information

The PaaS market is in the hand of around 75 vendors. However, there are three big

market leaders, who generate 71,1% of the whole turnover of the market. In none of

all service models is the power of the market power more concentrated as in the PaaS. Moreover, in the PaaS market is the lowest number of vendors (Columbus 2013).

Table 12: Cloud Computing Market. Source: (Columbus 2013b)

This can be seen as an evidence for an oligopoly and assures the vender lock problem.

The future perspectives for PaaS providers are excellent. The PaaS market will grow to

over 14 billion USD in 2017 (Mahowald, Hilwa und Shirer 2013).

There will be a big change in the future. The first step will be the change from on-‐

premise to a Hybrid model based of Cloud Computing and on-‐premises. Afterwards the

hybrid model will change to a pure cloud based model. A number of 75% or more of

the new enterprise IT budgets will be invested in cloud-‐based or hybrid solutions. The

providers have to be aware, that there will be significant regional differences. Especial-‐

ly in the Asian area the pure cloud solutions will be very successful (McNee 2012).

66


Figure 17: The shift to the Cloud. Source: (Saugatuck Technology 2012, 4)

6.2.2 Impact of Cloud Computing interoperability

The cloud monitor 2014 gave cloud providers some recommendations what have to

changed or optimized in the future (Wallraf und Pols, Cloud-‐Monitor 2014 2014).

Interoperability would have positive effects on some points that have to be changed.

Trust: Cloud Computing providers lost a lot of trust due to the NSA affair (Wallraf und Pols, Cloud-‐Monitor 2014 2014). Interoperability would help to punish cloud providers that corporate with secret services because customers could change the cloud provid-‐

er easily.

Security: Safety concerns of the customers have to be cleared (Wallraf und Pols, Cloud-‐Monitor 2014 2014). Interoperability could help cloud providers to make together the

cloud services safer. Besides a safer cloud because of a common think tank, the pro-‐viders would decrease their costs due to synergy effects which save resources.

Experience: Providers have to show the positive experienced data of their users (Wallraf und Pols, Cloud-‐Monitor 2014 2014). Interoperability would convince more potential customers to enter the cloud because they would have the opportunity to

change the provider, if they are unsatisfied. The risk for the established providers to

lose customers would be low due to the positive experiences of their current custom-‐ers.

Business optimization: The target of decreasing the IT efforts is often not reached. In the future it is necessary to support the customers to define the needs and to achieve that these needs are covered by the cloud solution (Wallraf und Pols, Cloud-‐Monitor

67


2014 2014). Interoperability could help providers to identify together common key

needs of customers to build cloud interoperable framework that is able to cover the

needs. Synergy effects, like common researches and competence teams, could be used

to decrease costs of the providers and to achieve a better outcome as a single could possibly achieve.

The Consulting Saugatuck Technology mentioned that a new master architecture is

emerging. The basis for this master architecture will be multiple technologies and plat-‐

forms targeting to set up synergies among themselves. This Boundary-‐free Enterprise sets new missions for the IT. One core control mission over all IT change stages is

standardization. In the pre cloud stage it is the standardization of Technologies and

Providers. In the second stage Transitory the core control mission targets to standard-‐ize services and providers. In the third stage Boundary-‐Free Enterprise aims to stand-‐

ardize interfaces. So it can be said the provision of standardized services should be in the self-‐interest of each provider to participate in the future on the boundary free en-‐

terprise market. It can be supposed that companies that would not standardize their

services will face big problems in the future boundary free market due to the per-‐

ceived restrictions of the services by the customer. Interoperability includes all the aforementioned standards. To achieve the boundary free enterprise stage the hybrid

cloud model has to be used.

The KPMG cloud Monitor from 2013 shows that as a main barrier of hybrid cloud solu-‐tions is seen an insufficient interoperability of various cloud solutions by the compa-‐

nies and application designers (Wallraf und Weber, KPMG 2013). Consequently the provision of interoperable cloud services will be a future key factor for each provider, regardless of its size.

68


Table 13: Boundary-‐free Enterprise (Saugatuck Technology 2012, 8) Interoperability offers cloud service providers the huge chance to wide spread the Cloud Computing adoption by users and developers. Consequently, Cloud Computing would

be more and more attractive. The whole market volume and as result the revenues of the cloud vendors would increase (Teckelmann, Sulisto and Reich 2012, 50). The econ-‐omy of scale would help to lower costs of the vendors and to offer the services cheaper

what would make the Cloud Computing adaption even more attractive for users (Armbrust, et al. 2010, 50-‐51). Interoperability would help that the Cloud Computing technology could be become the new and important industry that John McCarthy men-‐

tioned at the MIT centennial in 1961 (Garfinkel 1999, 1).

6.3 PaaS Customers

6.3.1 General Information

PaaS is a trend-‐setting Cloud Computing model. Already, 90% of technical and man-‐

agement professionals are familiar with the term PaaS and even 64% have already im-‐

plemented or are planning to implement this cloud model. As the main seasons for this

development the three categories operational focus, application focus and the cost

related focus were identified (Platt 2012).

69


6.3.2 General reasons for Cloud Computing implementation

There are many drivers that encourage the Cloud-‐Computing adoption. Grace A. Lewis

identified and listed the following drivers (Lewis 2012) :

• Continuous Availability: Global access to data and applications is possible

• Consumers can access to data and applications from around the globe.

• Collaboration: Organizations are able to work at the same time on shared data and information

• Elasticity: Demand based resource allocation that fits to the changing needs

• Lower infrastructure costs: Only for sources are billed that has been used (Pay-‐

per-‐use).

This means a change from a fixed cost to a variable cost model that makes in-‐

vestments in IT-‐Infrastructure, maintenance or upgrades dispensable.

• The support of service agreements can be provided much more reliable and

more cost effective by a cloud provider as it could be done by a single organiza-‐

tion. However, reliability is seen as barrier due to the tendency that cloud venders use commodity hardware that known to fail.

• Risk reduction: Ideas and concepts can be tested in the cloud before investing in technology

• Scalability: Many accessible resources are scale based in consideration of the

client demands Palak Jain adds to these benefits, that Cloud Computing is also environmental friendly

because of the efficient resource usage what results in energy savings. For instance

system automatically scales down and shuts down resources that are not used. Energy is just needed for resources that are definitely used. One further advantage that is

mentioned by Palak Jain is the recovery and Backup advantage. Cloud providers offer

these activities as an additional service. In many cases the cloud is already used for backups of the local stored data by companies (Jain 2013).

Focus on core business through allocation of IT resources to strengthen core business

functions and an increasing employee satisfaction/innovation through higher mobility and faster performance are seen as further intangible advantages of Cloud Computing

by ISACA (ISACA 2012).

70


6.3.3 General reasons against Cloud Computing implementation

Despites numerous benefits of Cloud Computing, some organizational key concerns

are not covered by Cloud Computing and can act as barriers for the adoption. The un-‐

covered key concerns collected by Grace A. Lewis are the following (Lewis 2012):

• Interoperability: Risk of vender lock-‐in due to the lack of common standards

and interfaces

• Latency: Because of the communication via network, it exists a reaction time

• Legal issues: Jurisdiction, data protection, fair information practices and inter-‐national data transfer is seen by some Cloud Computing users with concerns

• Platform or language constraints:

• Security: Data privacy is the main issue. Often the organizations have no con-‐trol about their data. A further aspect is that the organizations do not know

where the cloud vendors store their data

6.3.4 Considerations

Particularly, large companies use cloud services. Middle sized companies prefer their own solutions. Up to 15% of all IT-‐services are bought by enterprises from a provider.

There is a tendency that international focused enterprises are quicker able to identify

data that can be shifted under consideration of compliance regulations to provider

clouds as small or middle sized companies. Moreover enterprises are more often con-‐fronted with the case that new requirements cannot be implemented quickly enough

into the complex IT environment. Consequently around 17% of the technology budget

of departments is spent to external IT cloud services to solve this problem. On one hand for the Cloud Computing usage standardization is necessary what can be seen by

companies as disadvantage, on the other hand Cloud Computing offers a high pace of

innovation (Capgemini 2014).

6.3.5 Impact of Cloud Computing interoperability

Around 58% of the respondents that were asked for the Capgemini study 2014 are

planning or already implementing an Enterprise collaboration Platform. Moreover the study predicts that more than 85% of all companies will collaborate over such plat-‐

forms in the future (Capgemini 2014). Interoperability of cloud systems supports col-‐

laboration because the companies could change easily to a service provider that offers

them suitable cloud solutions for the collaboration. Moreover, synergy effects could be

71


used like common data would be just stored in the cloud centrally and not with redun-‐

dancy at the servers located at the participating companies. So the cost structure could

be improved through this synergy effects what would convince companies to increase

their cooperation efforts.

6.3.6 Key Performance Indicator

“Key performance indicators (KPIs) are financial and non-‐financial metrics used to help

an organization define and measure progress toward organizational goals.” (Korman

2010, 196)

In other words, key performance indicators are defined to measure performance and

to make actions transparent.

There are many different KPIs. Every company and industry defined own KPIs that are suitable to track and quantify their goals.

To give a comprehensive overview the Du-‐Pont-‐System of Financial Control was cho-‐sen because it includes different important ratios from the balance sheet and the in-‐

come statement and it is one of the oldest holistic concepts for corporate manage-‐

ment (Schmitt 2009, 65). The central key performance indicator of the schema is the

profitability ratio ROI (Return on Investment) (Baumann and Reber 2011, 183). The ROI helps to evaluate the financial impact of investments and actions (Schmitt 2009, 65).

72


ROI

Profit in % of the

turnover

Asset turnover

Total Assets

Turnover

Equity Capital

Invested Capital

Borrowed Capital

WorkingCapital

Capital Assets

Inventory

AccountsReceivables

Liquid Assets

Turnover

Capital Profit

Profit

Interest on borrowed Capital

Contri-bution Margin

Fixed Costs

Turnover

Variable Costs

+

+

+

+

Or

+

-

/

/

X

-

10

1

3

2

4

5

6

7

8

11

12

13

14

15

9

1617

18

19

20

21

Figure 18: Du-‐Pont-‐System of Financial Control.

1) Turnover:

Cloud Computing can have a positive effect on the turnover due to affordable of-‐

fered CRM solutions that increase the customer satisfaction, what results in better

sales (Basset 2012).

2) Variable costs:

The variable costs can increase through Cloud Computing in the case, if the varia-‐

ble Cloud Computing costs can be allocated directly on a single product (Etro 2011,

1).

73


However, it is difficult to allocate the Cloud Computing costs on a single product.

So it is more likely, because of the complexity, that in the reality the variable Cloud

Computing costs will be bundled and are allocated to the fix costs of a product

(Kinsella 2014).

3) Contribution margin:

The Contribution margin is turnover minus variable costs (Gleich, et al. 2010, 48-‐

49).The usage of Cloud Computing solutions influences the contribution margin

positively because the leverage of the turnover increase is higher than the variable

cost increase under regular circumstances.

4) Fixed costs:

The Cloud Computing costs which cannot be allocated directly to a single product,

are fixed costs. These costs can be decreased drastically due to the pay per use

model of the cloud providers. Consequently the company has just to pay for re-‐

sources that it requires (Initiative Cloud Services Made in Germany 2013). Moreo-‐

ver, the fix cost position IT-‐maintenance exists not anymore because the full re-‐

sponsibility of maintenance and the linked costs are outsourced to the cloud ser-‐

vice providers (Groff 2014).

Interoperability can save additional money due to the possibility to compare dif-‐ferent billing models of cloud providers and the possibility to change the vendor

without big migration costs and high risks (Cloud Pier & Cloud4SOA 2013, 8).

5) Profit:

The calculation to calculate profit is contribution margin minus fixed costs (Gleich,

et al. 2010, 48-‐49). The profit increases when a company uses Cloud Computing so-‐

lutions because the total costs which is the sum of variable costs and fixed costs

are smaller as the total costs of an in-‐house IT-‐solution (ISACA 2012, 8). Moreover,

Cloud Computing solutions can raise the turnover as aforementioned in 1) Turno-‐

ver.

6) Interest on borrowed capital:

74


Cloud Computing replaces high on premise IT-‐investments by the pay per use

model. IT-‐investments have consequently not be financed over several years (Lewis

2012). As result the company has not to finance the long term investments by a

loan. Consequently there is no interest on borrowed capital for Cloud Computing solutions.

7) Capital profit:

The capital profit is calculated by profit plus interest on borrowed capital. Cloud Computing influences this number positively because as aforementioned, Cloud

Computing increases the profit.

Furthermore, it has to be considered that during the profit calculation, the interest

on borrowed capital was subtracted (Heesen and Wolfgang 2014, 31-‐33). Now the same number is added what results in a neutralization of the Interest on borrowed

capital (Hölscher 2010, 405).

Turnover: See point 1.

8) Profit in percentage of the turnover:

Profit in percentage of the turnover is calculated by dividing capital profit through

turnover (Heesen and Wolfgang 2014, 182-‐184). As already mentioned both num-‐

bers are positively affected by Cloud Computing.

The current main impulsion of Cloud Computing is to lower costs. Therefore, the

leverage of Cloud Computing is higher on capital profit as on turnover what conse-‐quently leads to a higher profit in percentage of the turnover.

9) Inventory:

Cloud Computing encourages and enables collaborations and supply chain man-‐agement over several tiers. These cloud solutions help to reduce inventory costs

through more precise forecasts and facilitate companies to produce demand based

(Schramm, Nogueira and Jones 2011).

10) Account receivables:

Cloud solutions have no obvious impact on the accounts receivables.

11) Liquid assets:

75


The usage of cloud services increases the liquid assets because the cost and IT-‐

investment savings are stated at this position. Besides the cost savings, there is a

second advantage of Cloud Computing at this position. The savings can be used for

investments in other fields, for payback of loans or for financial investments. In-‐vestments in other fields would lead to an increase of the capital assets. The pay-‐

back of loans would result in a balance sheet contraction. To determine the impact

on the balance sheet of the saving spending in financial investments is more diffi-‐

cult because depending on the type of the investment, it can be balanced in capital assets as well as in liquid assets. It is immaterial, for which of these three alterna-‐

tives the savings are used, all of them raise the profit of the organization. In the re-‐

ality a mixture of the alternatives will be the most probable approach.

12) Working capital:

Working capital is the sum of inventory, accounts receivables and liquid assets (Financial Memos 2013). The working capital is influenced by cloud solutions in a

positive way because as aforementioned the inventory can be decreased what leads to unbound capital that can be used more profitable. Furthermore, the raise of liquid assets can improve the liquidity and through investments the profitability

of the company.

13) Capital assets:

Cloud Computing solutions let decrease the capital assets because IT assets are re-‐

quired on that large scale as for on premise solutions (Lewis 2012). However, it is difficult to say if the capital assets are decreasing or be stable. Because on the oth-‐

er hand the saved money could be invested in capital assets in form of new ma-‐chines for the production or for other financial long term investments.

14) Invested capital:

Invested capital is the sum of working capital and capital assets. Consequently, the invested capital includes all assets (allocation of resources). The invested capital

stays stable or decreases due to a balance sheet contraction, because of a possible

repayment of loans and the decrease of IT assets.

15) Borrowed capital:

76


The borrowed capital is probably decreasing due to the absence of IT-‐investments

like buying servers or other hardware. Moreover, the cost savings can be used to

lower the portion of borrowed capital, what results in lower interest expenses.

16) Equity capital:

The utilization of Cloud Computing solutions increases the equity capital because of

higher profits. An increasing equity capital and a decreasing borrowed capital leads

to a higher equity ratio what is appreciated by investors and leads to lower inter-‐ests for coming loans.

17) Total assets:

Total assets are equal to the invested capital or the sum of equity capital and bor-‐rowed capital (Schierenbeck and Wöhle 2012). As before shown, the usage of

Cloud Computing solutions could lead to a decrease of the balance sheet which has

a positive effect on total asset due to the better allocation of resources.

18) Turnover:

See point 1

19) Asset turnover:

The asset turnover is calculated by dividing turnover through total assets (Heesen and Wolfgang 2014, 182-‐184). Cloud Computing utilization increases the assets

turnover because it raises on one side the turnover and lowers on the other side

the total assets.

20) ROI (Return on Investment):

The ROI is calculated by multiplying profit in percentage of the turnover and asset

turnover (Heesen and Wolfgang 2014, 182-‐184). Both multipliers are raised by Cloud Computing utilization what results in an increasing ROI.

The analysis, with help of the Du-‐Pont-‐System of Financial Control, shows the posi-‐

tive impacts of Cloud Computing on the return on investment. But it is difficult to

identify just based on the Du-‐Pont indicators the specific impacts. Often the im-‐

pacts of Cloud Computing lie deeper and are more specific, so that it makes sense

to complement the Du-‐Pont-‐System of Financial Control by other additional key

performance indicators.

77


Such appropriate complementary indicators are the following ones (Capgemini

2014, 17):

• Contribution of the IT to cycle times

• Contribution of the IT to increase the customer satisfaction

• Contribution of the IT to lower the product costs

• Portion of the IT for turnover increase

• Portion of the IT for profit increase

• Portion of the IT to gain market share

The ROI calculation of the Du-‐Pont analysis is calculated based on the total assets

(Gladen 2014, 87-‐88). But there exists a second approach, which calculates the

specific ROI of a Cloud Computing investment with the formula depicted in Figure 19. This formula is used to evaluate if the Cloud Computing adoption is beneficial. The formula has the weakness, that it does not include intangible risks and bene-‐

fits. For this reason it is also recommended to complement this investment based ROI calculation by other financial metrics (ISACA 2012, 7).

𝑅𝑂𝐼 =(𝐺𝑎𝑖𝑛 𝐹𝑟𝑜𝑚 𝐼𝑛𝑣𝑒𝑠𝑡𝑚𝑒𝑛𝑡 − 𝐶𝑜𝑠𝑡 𝑜𝑓𝐼𝑛𝑣𝑒𝑠𝑡𝑚𝑒𝑛𝑡)

𝐶𝑜𝑠𝑡 𝑜𝑓 𝐼𝑛𝑣𝑒𝑠𝑡𝑚𝑒𝑛𝑡

Figure 19: Formula to Calculate Simple ROI. Source: (ISACA 2012, 7)

The Claranet research programme 2013 shows that the ROI for Cloud Computing

investments is in the most of the cases predicted accurately by companies. Howev-‐

er, 79-‐percentage of all respondents have the opinion, that ROI calculation is help-‐

ful but that the calculation shows not the full impact of Cloud Computing (See Fig-‐

ure 20). Just 10-‐percent of the respondents fully agree, that the ROI is the right

measurement to identify the effectiveness of Cloud Computing (Bourne 2012, 8-‐9).

These results corresponds with the results of the DuPont analysis of the thesis that

the indicator ROI is helpful but that it is much more complex to measure the entire

impact of Cloud Computing.

78


Figure 20: Do ROI calculations adequately describe the benefits of cloud adoption?.

Source: (Bourne 2012, 8)

Interoperability encourages the adaption of cloud solutions by dissolving the ven-‐dor dependency of users (Microsoft 2011, 8). Moreover, the Du Pont analysis

shows that interoperability increases the positive impacts of Cloud Computing and comes consequently to the same result as The Open Group (The Open Group 2013) that interoperability maximizes the ROI of Cloud Computing.

6.4 Cloud broker – Provider – Players

The following chapter lists a set of cloud brokerage vendors respected to the work of

Verginadis, Patiniotakis and Mentzas (Verginadis, Patiniotakis und Mentzas 2013). The mentioned vendors will additionnaly be categorized by the CSB definitions of NIST and Gartner.

6.4.1 AWS Marketplace

AWS Marketplace is an online store, which offers services for SaaS and PaaS offerings. It offers development frameworks, databases, a.s.o. and bases on the AWS Elastic

Beanstalk.

Organization Classification

Broker@Cloud Discovery

NIST Service Aggregation

Gartner Aggregation Broker

Table 14: AWS Marketplace classification

79


6.4.2 Cloudability

The Cloudability platform offers the customer a set of managing tools for important

Key Performance Indicators (KPIs) and cost analytics, reports in a multi cloud environment.

Its focus is set to cost reports and analysis of IaaS, PaaS and SaaS offerings.


Broker@Cloud Customization

NIST Service Aggregation, Service Intermediation

Gartner Integration Broker, Customization Broker

Table 15: Cloudability classification

6.4.3 Heroku

Heroku is a platform for developing and running applications (compare chapter 3.6.7)

and offers the Heroku add-‐ons marketplace, where services can be offered.


Broker@Cloud Discovery, Customization

NIST Service Aggregation

Gartner Aggregation Broker

Table 16: Heroku classification

Heroku is the dominant platform for developing applications in the Ruby programming

language. Except Ruby, the platform supports several other technologies such as Node.js, Clojure, Java, Python, and Scala. Heroku offers an add-‐on provider program

for third-‐party Independent Software Vendors (ISVs) to offer services that extend its

capabilities. Third-‐party ISVs can use a self-‐service portal and development kit in order to offer their services and have them listed on the add-‐on catalog. The add-‐ons offer

features such as remote cloud-‐based data storage, application logging, text search,

email and SMS communications, data analytics, payments, etc, addressed to develop-‐ers who build and deploy their applications on Heroku. (D2.1 State of the art and re-‐

search baseline

80


6.4.4 SnapLogic

The SnapLogic Elastic Integration Platform offers REST-‐based integration services. Us-‐

ers can connect SaaS applications, online storage or other services via a Snap, which is

a modular collection of integration components to access applications or data sources. Furthermore, these Snaps can be modified or built on an available development envi-‐

ronment. The classification is not clearly caused by the various possible usage of Snap-‐

Logic.


Broker@Cloud Integration

NIST Service Intermediation, Service Aggrega-‐

tion

Gartner Integration Broker

Table 17: SnapLogic classification

6.5 Cloud broker – Enabler – Players

Cloud broker enablers provide a service which enables its customers, to deliver CSB

offers to its customers. This category mostly aims to organizations which need to de-‐

liver services to their customers or employees.

6.5.1 CompatibleOne

CompatibleOne is an open source project, which offers an interface to handle the re-‐

sources of multiple cloud service providers. The interface supports IaaS, PaaS and Saas services and bases on the OCCI standard. From the PaaS sight, the provided Advanced

Capabilities for CompatibleOne Resource Description System (ACCORDS) platform

helps to prevent provider lock in by using the PaaS Procci, which provisions the needed services and ACCORDS platform manages the interaction with the PaaS provider.


Broker@Cloud Discovery, Aggregation

NIST Service Intermediation


Table 18: CompatibleOne classification

81


6.5.2 Infosys

Infosys Cloud Ecosystem Hub consists of a set of modules, which enable to create,

adopt and govern services from various providers. The modules are Private cloud

module, Hybrid cloud module, Smart brokerage module, Cloud apps module, Data fed-‐eration module and the Service assurance module. The modules fulfill different tasks

such as in the Smart brokerage module offers can be compared on parameters like

costs or technology compatibility or the Data federation module helps to handle struc-‐

tured and unstructured data from multiple sources.


Broker@Cloud4 Discovery, Integration, Aggregation

NIST Service Intermediation, Service Aggrega-‐

tion, Service Arbitrage

Gartner Integration Broker, Customization Broker

Table 19: Infosys classification

6.5.3 Jamcracker

Jamcracker offers the Jamcracker Services Delivery Network to enable organizations to

act as an internal or external IaaS, PaaS and SaaS CSB. It allows to compare, customize

provision and launch resources of multiple providers. Jamcracker delivers three ser-‐

vices, or core components, the Jamcracker platform, the cloud services catalogue and

the managed services.


Broker@Cloud Discovery, Aggregation

NIST Service Intermediation, Service Aggrega-‐tion


Table 20: Jamcracker classification

4 The Broker@Cloud classification doesn’t include the type quality assurance. The service assurance

module fulfills the requirements of the quality assurance type by the SLA management framework. So Infosys should be picked up into this type.

82


6.5.4 Vordel (Axway)

Vordel merged with Axway in 2013 and the API solutions were added to the Axway 5

Suite. (http://www.axway.de/vordel-‐products) The service was integrated to the Ax-‐

way product and its categorization can’t be used clearly for which reason it is ab-‐stained to present a classification table. In the new context, the API solutions are used

to integrate IaaS, PaaS and SaaS services, mobile and On-‐Premise applications into the

organizations environment. It somehow still works as a broker, but in a changed envi-‐

ronment. (http://www.axway.de/produkte-‐und-‐l-‐sungen/axway-‐5-‐overview/steuerung-‐der-‐datenflusse-‐in-‐der-‐cloud) (http://www.axway.de/vordel-‐

products ) (http://vordel.com)

6.6 Cloud marketplaces

In contrast to the cloud brokers, the cloud marketplaces are places where services and applications based on the respective PaaS offering are served. The big PaaS vendors

offer such marketplaces, as u can see in Table 21. The applications in the marketplaces

usually are served by customers of the PaaS offer and can be used as a cloud service.5

Vendor URL

Amazon Web Services Marketplace

https://aws.amazon.com/marketplace

Google Apps Market-‐

place

https://www.google.com/enterprise/marketplace/home/ap

ps/

Heroku add-‐ons https://addons.heroku.com/

IBM Cloud marketplace http://www.ibm.com/cloud-‐computing/us/en/marketplace.html

Microsoft Azure Mar-‐ketplace

http://datamarket.azure.com/

OpenShift Marketplace https://marketplace.openshift.com/home

Oracle Cloud Market-‐

place

https://cloud.oracle.com/marketplace/faces/homePage.jspx

?_afrLoop=1471787961260192&_afrWindowMode=0&_adf.

5 Cloud broker providers (compare chapter 6.4) and Cloud broker enablers (compare chapter 6.5) can

also serve a marketplace or a similar offer. The presented marketplaces base on the PaaS vendors treated in chapter 3.6.

83


ctrl-‐state=4wle4od0f_4

Salesforce Ap-‐

pExchange

https://appexchange.salesforce.com/

Table 21: Overview PaaS Marketplaces

84


7 Requirement analysis scheme

7.1 Justification of the positioning

The final planned outcome of the PaaSport project is a platform for interoperable PaaS

offerings. To this aim and with the knowledge developed in the previous chapter, new

questions arise. The questions are presented below.

7.1.1 Target group

The state of the art detected new possible target groups which were not expected:

• Existing Brokers and • Companies who want to act as a SaaS broker.

Who is the target group? • PaaS vendors • PaaS customers • SME • Developer

How shall the pla{orm act? • NIST: • Service Intermedia|on • Service Intermedia|on • Service Arbitrage • Gartner: • Aggrega|on broker • Integra|on broker • Customisa|on broker

At which level shall the pla{orm approach be developed?

• Somewhere between the ques|ons resp. compare how to act and offered serviced

Which services will be offered? • Requirements analysis

85


Referring to the definitions of CSBs, the target platform was categorized into the NIST and Gartner schemes. The platform will act as a

• NIST: Service Intermediator • Gartner: Aggregation broker

with a toolset on top and a Proactive-‐Update-‐Messaging.

The PaaSport consortium defined the following overall project goals:

The platform design will ease SME to offer and use PaaS offerings with the focus on

reducing the vendor lock in. For this purpose, the platform will help to use the pos-‐sibility of changing offers without hurdles and in a transparent way.

According to this aim, a number of use cases can be created with a separation on the

major target groups PaaS vendors and PaaS customers.

86


Figure 21: Tasks -‐ PaaS Vendors

Figure 22: Tasks -‐ PaaS Customers

87


7.2 Detailed requirement scheme The PaaSport consortium identified from the work of the Cloud4SOA project a detailed list of functional and non-‐functional requirements that is very adequate to the target-‐

ed PaaSport requirement analysis. A derivate list to our specific target was set during

the preparation of the project and refined in the scope of this task.

The requirements were categorized according to two different points of view:

-‐ Development engineers -‐ PaaS providers

7.2.1 Functional Requirements of development Engineers

Table 22: PaaSport Functional Requirements of development Engineers

Functional Requirements Description F1 Enable transparent migration of data/applications (portability)

F2 Be able to manage instances across multiple Cloud providers

F3 Enable the use of metadata in the declaration of PaaS providers and during match making

F4 Monitor the execution performance in real-‐time

F5 Receive notification alerts for SLA violations

F6 Manage the complete lifecycle of a cloud service

(deployment, undeployment, start, pause, stop, delete and migration)

F7 Support PaaS offerings with elasticity features

F8 Reuse and share functions provided by existing application and enable applications to work

together using integration tools

F9 Support backup and restore

F10 Be able to use a common API (common set tools) that supports provision-‐

ing/deployment/configuration and control access different Cloud resources

F11 Be able to provide PaaSport interoperability libraries for defining and developing the service as

well as to develop the images associated with the service

F12 Be able to search for PaaS services that are held

F13 Access and view the provided services listed in a service catalog

F14 Enable user profiling in terms of personal workspace (e.g. user and notification settings, billing

and payment information, etc.)

F15 Be able to support a developer’s community

F16 Be able to support a marketplace (application selling business model, SLA adaptation and sup-‐

port, service billing policy)

88


F17 Be able to transfer monitoring, logging, auditing and control functions to the new provider by

the means of commonly defining formats

F18 Be able to verify that the migrated services or applications are operating correctly in the new

provider

F19 Be able to support self-‐service provisioning and management

F20 Be able to get recommendations in selecting a Cloud provider based on a hybrid recommender

system approach

F21 Ability to determine the privacy level of their data (user profile, personalized environment)

F22 Be able to manage the geographic region in which an application is deployed.

7.2.2 Functional Requirements of PaaS Providers

Table 23: PaaSport Functional Requirements for PaaS Providers

Functional Requirements Description F23 Automatic update of a Cloud system’s SLA as a result of a change in the provider’s policy after

SLA matching.

F24 Monitor the status of the resources (dead/alive) and application components, services, and

infrastructure to detect failures.

F25 Manage the access to resources/services

F26 Be able to publish service offerings in a service catalogue (service characteristics, policies, ap-‐

plication platform availability and performance)

F27 Manage the SLA contracts

F28 Define charging for services (billing functions, invoices, settlement, etc.)

Table 24: PaaSport Non-‐Functional Requirements

Requirement Type Non-‐functional Requirements Description Security NF1 Data and application security

NF2 Encryption

NF3 User authentication and single sign-‐on, authorization and

role-‐based access control, security proof

NF4 Secure storage and handling of payment data

NF5 Licensing and security issues to span different Cloud plat-‐

forms

Interoperability NF6 Supporting commonly used standards, standard syntax,

open APIs, widely available tools, technologies, methodol-‐

ogies, and best practices.

89


NF7 Supporting abstraction (it hides many details of systems

infrastructure and application infrastructure from devel-‐

opers and their applications)

NF8 Uniform service description (SLA offering), using standard

formats

NF9 SLAs with clear policies and guidelines for maintenance

and version management of the platform and policies for

version compatibility for APIs between the platform and

the application.

NF10

Transparency during interaction with user-‐adaptive sys-‐

tems

Reliability NF12 Reliable

Usability (Operability) NF13 Automatic and seamless deployment

NF14 Intercept component-‐to-‐component communication.

NF15 The development platform and the development tools are

hosted in the Cloud and accessed through a browser

NF16 It provides a presentation interface (menu and navigator,

user controls, display and rendering, reporting)

Usability (Understand

ability and Attractive-‐

ness)

NF17 Ease-‐of-‐Use

NF18 The interface should not be obtrusive

NF19 The interface should be understandable and predictable

NF20 The content and functionality of user interface layout will

be organized logically.

NF21 The intelligent user interface should use graphical ele-‐

ments instead of using text-‐based linear lists because a

graphical user interface can increase the level of user satis-‐

faction as well as the level of the communication of the

adaptive system with its users

Efficiency NF22 It can be accessed by multiple users at the same time

(multi-‐tenant)

Scalability NF23 It should be scalable and deployable on different cloud

platforms

Availability NF24 It should be accessible and available (at acceptable service

levels).

Other NF25 Ensuring developer choice on languages, runtimes and

tools

90


8 Questionnaire

A questionnaire was designed in order to collect information from the SME association

members. The final questionnaire can be found in Annex 1. The questionnaire was

filled by the members of participating associations. The results are presented in chap-‐ter 12.1.

8.1 Concept of the questionnaire

The questionnaire aimed at supporting the collection of the needs and requirements of developers and PaaS providers, with special emphasis on PaaS interoperability.

It consists into two information step:

• General information about the companies, existing offers, technology used, lock-‐in awareness, …

• Detailed requirement rank

As mentioned before, the basic structure of the PaaSport requirement analysis is based on research outcomes of Cloud4SOA.

However, the requirement analysis approach started completely independent from Cloud4SO. The basic definitions from the project annex1 (which derived from Cloud4SOA) were then taken into account in the empirical analysis (validation of priori-‐

tization).

The final questionnaire can be found in Annex 1.

Table 25: List of the Functional Requirements (Seventh Framework Programme 2013,

11f. (Part B))

91


9 Stakeholder

10 Functional Requirement

Cloud-‐based

application developer

F1. Transparently migrate data/applications (portability)

F2. Manage resources across multiple Cloud providers

F3. Configure (business rules, customizable data model and metadata set)

F4. Monitor execution performance in real-‐time

F5. Receive (SLA violation, failure) alerts

F6. Manage the complete lifecycle of a service (deployment, federation and migration)

F7. Orchestrate all the involved components

F8. Reuse and share functions provided by existing application, enabling applications to work together (integration tools)

F9. Support backup and restore

F10. Use testing tools

F11. Use a common API (common set of tools) that supports provision-‐ing/deployment/configuration and control across different Cloud re-‐

sources

F12. Use tools for defining and developing the service as well as to develop the images associated with the service

F13. Search for services (IaaS, PaaS) held by multiple Cloud systems

F14. Access and view the provided services listed in a service catalog

F15. Enable user profiling (personal workspace)

F16. Support a developers’ community

F17. Support a marketplace (application selling business model, SLA adapta-‐tion and support, service billing policy)

F18. Transfer monitoring, logging, auditing and control functions to the new

92


9 Stakeholder

10 Functional Requirement

provider by the means of commonly defining formats

F19. Verify that the migrated services or applications are operating correctly in the new provider

F20. Support self-‐service provisioning, management and scaling

F21. Get recommendations in selecting a Cloud provider based on a hybrid recommender system approach

F22. Ability to determine the privacy level of their data (user profile, person-‐alized environment)

Cloud PaaS Provider

F23. Automatic update of a Cloud system’s SLA as a result of a change in the provider’s policy after SLA matching.

F24. Monitor the status of the resources (dead/alive) and application com-‐ponents, services, and infrastructure to detect failures.

F25. Establish federations/collaborations of Cloud platforms

F26. Manage the access to resources/services

F27. Publish service offerings in a service catalog (service characteristics, policies, application platform availability and performance)

F28. Manage the SLA contracts

F29. Charge for services (billing functions, invoices, settlement, etc.)

Table 26: List of the Non-‐Functional Requirements (Seventh Framework Programme

2013, 11f. (Part B))

93


11 Requirement type

12 Non-‐Functional Requirement

Functionality

(Security)

NF1. Data and applications security

NF2. Encryption

NF3. User authentication and single sign-‐on, authorization and role-‐based access control, security proof

NF4. Secure execution of monetary transactions

NF5. Licensing and security issues to span different Cloud platforms

Functionality

(Interoperabil-‐ity)

NF6. Supporting commonly used standards, standard syntax, open APIs, widely available tools, technologies, methodologies, and best prac-‐

tices.

NF7. Supporting abstraction (it hides many details of systems infrastruc-‐ture and application infrastructure from developers and their ap-‐

plications)

NF8. Uniform service description (SLA offering), using standard formats

NF9. SLAs with clear policies and guidelines for maintenance and ver-‐sion management of the platform and policies for version compat-‐

ibility for APIs between the platform and the application.

NF10. Transparency during interaction with user-‐adaptive systems

NF11. Technology neutral and loosely coupled widgets while supporting location transparency

Reliability NF12. Reliable

Usability

(Operability)

NF13. Automatic and seamless deployment

NF14. Intercept component-‐to-‐component communication.

NF15. The development platform and the development tools are hosted in the Cloud and accessed through a browser

NF16. It provides a presentation interface (menu and navigator, user

94


11 Requirement type

12 Non-‐Functional Requirement

controls, display and rendering, reporting)

Usability

(Understandabil-‐ity and Attrac-‐

tiveness)

NF17. Ease-‐of-‐Use

NF18. The interface should not be obtrusive

NF19. The interface should be understandable and predictable

NF20. The content and functionality of UI layout will be organized logical-‐ly.

NF21. The intelligent user interface should use graphical elements in-‐stead of using text-‐based linear lists because a graphical user inter-‐face can increase the level of user satisfaction as well as the level

of the communication of the adaptive system with its users

Efficiency NF22. It can be accessed by multiple users at the same time (multi-‐tenant)

Scalability NF23. Scalable infrastructure provisioning as needed

NF24. Scalable deployment to multiple Cloud platforms and between Cloud systems and on-‐premise systems

Availability NF25. It should be accessible and available (at acceptable service levels).

Other NF26. Ensuring developer choice on languages, runtimes and tools

12.1 Evaluation

The questionnaire provided in Annex 1 was submitted to the participating associations

which engaged their members in the survey process. The questionnaire was imple-‐

mented into the online survey tool “Survey Monkey”. Following are the results of the survey.

95


12.1.1 General information about the companies

Altogether 146 companies participated in the online survey. The participating compa-‐

nies come from Germany, Turkey, Sweden, Italy, Greece, Latvia, Belgium, Australia and

Cyprus. Their target group are mainly SMEs and business customers. As illustrated in Figure 23, most of the companies (32.9%) which answered the online questionnaire

have less than ten employees. Approximately 27% of the companies employ ten to 50,

nearly 19% of them 51 to 250 and 22% more than 250 people. The questionnaire re-‐veals that approximately 65% of the participating companies use cloud services for

their software (Figure 24).

Figure 23: Number of employees

Figure 24: Usage of cloud services

32,9%

26,7%

18,5%

21,9%

How many employees does your company currently have?

< 10

10 -‐ 50

51 -‐ 250

> 250

65,8%

34,2%

Do you use a cloud service for your soiware?

Yes No

96


12.1.2 Companies which use cloud services

More than half of the companies which use cloud services offer their web service to

end-‐user and third parties (Figure 25). Besides every second company intends to

change the cloud provider or employ more than one provider (Figure 26).

Figure 25: Web service offering

Figure 26: Change cloud provider or employ more than one provider

In the next four questions multiple answers were possible. The most used program-‐

ming languages are Java Script (65.9%) and Java (64.6%). 50% of the companies use

42,9%

57,1%

Whom do you offer your web service?

Only end-‐user

52,7%

47,3%

Have you ever intended to change your cloud provider or do you employ more than one

cloud provider?

Yes No

97


PHP and only 17.1% Visual Basic (Figure 27). In addition to the proposed programming

languages, Python, Ruby and C are mentioned.

Java EE (47.4%) and .NET (41.3%) are the most used frameworks (Figure 28). Spring

and further frameworks for example WordPress and Django are already mentioned. In total, 90% of the companies use relational databases and only 37.5% NoSQL (Figure

29).

Figure 27: Used programming languages

Figure 28: Used frameworks

64,6%

50,0%

65,9%

17,1% 25,6%

0,0%

10,0%

20,0%

30,0%

40,0%

50,0%

60,0%

70,0%

Java PHP Java Script Visual Basic Other

Which programming language is used? (Mulkple answers possible)

42,3%

29,5%

47,4%

19,2%

0,0% 5,0% 10,0% 15,0% 20,0% 25,0% 30,0% 35,0% 40,0% 45,0% 50,0%

.NET Spring Java Enterprise Edi|on

Other

Which framework is used? (Mulkple answers possible)

98


Figure 29: Used databases

Mainly applications (76%), services (70.9%) and resources (63.3%) are monitored (Figure 30). Only 53.2% of the companies monitor the infrastructure and just 7.6%

monitor nothing. Besides approximately 64% of surveyed companies think there is a

need do dynamically scale resources (Figure 31).

Figure 30: Kind of monitoring which is needed

90,0%

37,5%

0,0%

20,0%

40,0%

60,0%

80,0%

100,0%

Rela|onal database NoSQL database

Which kind of database is used? (Mulkple answers possible)

63,3%

53,2%

76,0% 70,9%

7,6% 2,5%

0,0%

10,0%

20,0%

30,0%

40,0%

50,0%

60,0%

70,0%

80,0%

Resources Infrastructure Applica|on Service None Other

Which kind of monitoring is needed for your cloud services? (Mulkple answers possible)

99


Figure 31: Need of dynamically scaling resources

Technical resources or hardware requirements which are needed are for example load balancer, application server, database server, storage, DNS routing, compiler and fire-‐

walls. The advantages of using cloud services include mainly scalability, cost saving,

flexibility, ease of deployment, reliability and availability.

More than half of the companies are mostly facing security issues (55.6%), followed by

issues integrating with internal systems (48.1%) and control issues (46.3%). More than

a third of the companies have performance problems, issues managing multiple cloud

environments and cost issues. Only 7.4% think there are no challenges. Further men-‐tioned challenges are the vendor lock-‐in issue and problems with bandwidth. A more

detailed view is shown in Figure 32.

63,6%

36,4%

Is there a need to dynamically scale resources for traffic peaks etc.?

Yes No

100


Figure 32: Challenges of companies using cloud services

Two questions of the questionnaire deal with the vendor lock-‐in issue. As explained in

the question, vendor lock-‐in makes the customer dependent on a PaaS offering. There-‐

fore there is a trade-‐off between ease of use and reducing the customer´s freedom of choice. 60% of the participating companies become aware of this problem (Figure 33)

and more than two thirds of them estimate that the disadvantages predominate

(Figure 34).

55,6%

46,3%

31,5%

48,1%

35,2%

24,1%

33,3%

24,1%

14,8% 5,6% 7,4%

1,9%

0,0%

10,0%

20,0%

30,0%

40,0%

50,0%

60,0% Security issue

s

Control issue

s

Cost issues

Issues integra|

ng with

internal

system

s

Performance issues

Lack of resou

rces/exper|se

with

cloud

techno

logies

Issues m

anaging mul|p

le cloud

en

vironm

ents

Compliance issue

s

Lack of sup

port from

IT

Lack of sup

port from

decision

maker

No challenges

Other

What challenges does your company face by using cloud services? (Mulkple answers possible)

101


Figure 33: Awareness of the vendor lock-‐in issue

Figure 34: Assessment of the vendor lock-‐in

Finally the participants were asked whether they would like to take a look on the Func-‐tional and Non-‐Functional Requirements which were introduced in chapter 8.1. More

than half of them take a look (Error! Reference source not found.) and assess the pro-‐

posed requirements by their importance. The two most important Functional Re-‐quirements are F24 “Monitor the status of the resources (dead/alive) and application

60,0%

40,0%

Vendor lock-‐in makes the customer dependent on a PaaS offering. Therefore there is a tradeoff between ease of use and reducing the customer´s freedom of

choice. Are you aware of this?

Yes No

35,3%

64,7%

If yes,how would you rate the vendor lock-‐in?

advantages predominate

disadvantages predominate

102


components, services, and infrastructure to detect failures” and F26 “Manage the ac-‐

cess to resources/services” (see Table 27 )..

Besides the most Non-‐Functional Requirements are NF23 “Scalable infrastructure pro-‐

visioning as needed” and NF22 “It can be accessed by multiple users at the same time

(multi-‐tenant)” (Error! Reference source not found.). The two most important re-‐

quirements have a rating average of four. The most unimportant requirement is “Se-‐

cure execution of monetary transactions” (NF4) with a rating average of 1.43. Both tables include a detailed description of the requirements’ meaning.

Figure 35: Sophisticated view on requirements

57,1%

42,9%

Would you like to provide a more sophiskcated view on the requirements?

Yes No

103


Functionality

Rating

Average

(0 not important, …, 5

very important) F24. Monitor the status (dead/alive) of the resources (for example storage, server

and networks) and application components, services, and infrastructure to detect failures.

3,14

F26. Manage the access to resources/services. (The PaaS model allows the customers to consume resources on-‐demand and

to spend more time developing their application and less time managing hardware and software.)

3,00

F1. Transparently migrate data/applications (portability) (Portability refers to the ability to migrate applications between different

clouds. This is required to allow customers of cloud services to avoid the situa-‐tion of being locked into a specific cloud provider, having made the decision to

run an application in the cloud.)

2,86

F2. Manage resources across multiple Cloud providers 2,86 F11. Use a common API (Application Programming Interface, common set of tools)

that supports provisioning/deployment/configuration and control across dif-‐ferent Cloud resources

(All PaaS vendors that use a common API are interoperable, hence guarantee-‐ing seamless data and application migration.)

2,57

F22. Ability to determine the privacy level of their data (user profile, personalized environment)

2,57

F29. Charge for services (billing functions, invoices, settlement, etc.) (Cloud Computing employs a pay-‐per-‐use pricing model. The pricing scheme

can vary from service to service (pay per hour, user, request etc.)). 2,57

F4. Monitor execution performance in real-‐time (Once an application is deployed, appropriate monitoring is required to verify

that the application behaves as anticipated.) 2,57

F5. Receive (SLA violation, failure) alerts (A rule can be created to trigger an alert when the metric reaches a value that

is specified. The customer receives an email or SMS.) 2,57

F8. Reuse and share functions provided by existing application, enabling applica-‐tions to work together (integration tools)

2,57

F3. Configure (business rules, customizable data model and metadata set) 2,50 F14. Access and view the provided services listed in a service catalog

(A service catalog contains templates with specifications that define parame-‐ters and features of a service.)

2,43

F25. Establish federations/collaborations of Cloud platforms (Facilities to package, share, and obtain reusable source code and software components increase productivity and reduce project risk and costs. Connec-‐tion with other developers in order to solicit advice, share information and

form ad-‐hoc teams, while maintaining privacy and security.)

2,29

104


F27. Publish service offerings in a service catalog (service characteristics, policies, application platform availability and performance)

2,29

F6. Manage the complete lifecycle of a service (deployment, federation and migra-‐tion)

(The service is started and stopped, when needed.) 2,29

F13. Search for services (IaaS, PaaS) held by multiple Cloud systems 2,14 F15. Enable user profiling (personal workspace) 2,14 F18. Transfer monitoring, logging, auditing and control functions to the new pro-‐

vider by the means of commonly defining formats 2,14

F20. Support self-‐service provisioning, management and scaling (A consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human

interaction with each service’s provider.)

2,14

F23. Automatic update of a Cloud system’s SLA as a result of a change in the pro-‐vider’s policy after SLA matching.

2,14

F7. Orchestrate all the involved components 2,14 F9. Support backup and restore 2,14 F10. Use testing tools

(special tools created to test sources and developing systems) 2,00

F19. Verify that the migrated services or applications are operating correctly in the new provider

2,00

F21. Get recommendations in selecting a Cloud provider based on a hybrid recom-‐mender system approach

(Hybrid recommender systems combine two or more recommendation tech-‐niques to gain better performance with fewer of the drawbacks of any individ-‐

ual one.)

1,86

F28. Manage the SLA contracts (Service Level Agreement is a contract that specifies the consumer’s requirements and the provider’s commitment to them. Generally includes things like uptime, privacy, security and backup procedures, level of service, performance and guarantees.)

1,86

F12. Use tools for defining and developing the service as well as to develop the images associated with the service

1,71

F16. Support a developers’ community 1,57 F17. Support a marketplace (application selling business model, SLA adaptation and

support, service billing policy) 1,57

Table 27: Functional Requirements sorted by rating average

105


Functionality Rating Average

(0 not important, …, 5

very important) NF23. Scalable infrastructure provisioning as needed

(As the load fluctuates, the PaaS model allows infrastructure to scale computing resources to meet demand while facilitating uninterrupted end-‐user experience.)

4,00

NF22. It can be accessed by multiple users at the same time (multi-‐tenant) (Multiple independent instances of one or multiple applications operate in a shared environment. The instances (tenants) are logically isolated, but physi-‐

cally integrated.)

4,00

NF3. User authentication and single sign-‐on, authorization and role-‐based access control (for example users can be assigned specific

roles and privileges), security proof 3,71

NF17. Ease-‐of-‐Use (A PaaS should offer easy to use tools with pre-‐built widgets, canned UI compo-‐

nents, drag-‐and-‐drop tools and support for standard IDEs. These also facilitate the rapid application development.)

3,71

NF1. Data and applications security (Security is all about isolating and protecting IT resources from both known and

unknown problems. Data protection addresses the aspect of preventing undesired disclosure or manipulation of personal or otherwise sensitive information.)

3,71

NF19. The interface should be understandable and predictable 3,57 NF25. It should be accessible and available (at acceptable service levels).

(Availability means applications on the system won’t go down even if some servers go down. Generally, to achieve this, a system or network must have backups and

failover processing.)

3,43

NF20. The content and functionality of UI layout will be organized logical-‐ly.

3,43

NF18. The interface should not be obtrusive 3,43 NF12. Reliable 3,43 NF26. Ensuring developer choice on languages, runtimes and tools. 3,29 NF24. Scalable deployment to multiple Cloud platforms and between

Cloud systems and on-‐premise systems. (The platform is in able to leverage the elastic capacity from the

underlying infrastructure, when needed.)

3,14

NF21. The intelligent user interface should use graphical elements instead of using text-‐based linear lists because a graphical user interface can increase the level of user satisfaction as well as the level of the

communication of the adaptive system with its users

3,00

NF13. Automatic and seamless deployment (PaaS environments automate the process of deploying applications to infrastruc-‐

ture, configuring application components, provisioning and configuring) 2,86

NF6. Supporting commonly used standards, standard syntax, open APIs, widely available tools, technologies, methodologies, and best prac-‐

2,71

106


tices. (Proprietary APIs controlled by one company will lead to lock-‐in and higher costs. Open APIs based on open source software de-‐veloped by a collaboration of companies will lead to a cloud ecosys-‐

tem with more choice, innovation, and lower costs.) NF2. Encryption

(Messages or information are encoded in such a way that only au-‐thorized parties can read it.)

2,71

NF14. Intercept component-‐to-‐component communication. 2,57 NF16. It provides a presentation interface (menu and navigator, user con-‐

trols, display and rendering, reporting) 2,43

NF15. The development platform and the development tools (e.g. librar-‐ies and APIs that give access to the computational and storage re-‐sources) are hosted in the Cloud and accessed through a browser

2,43

NF9. SLAs with clear policies and guidelines for maintenance and version management of the platform and policies for version compatibility

for APIs between the platform and the application. 2,29

NF11. Technology neutral and loosely coupled widgets while supporting location transparency

2,29

NF10. Transparency during interaction with user-‐adaptive systems 2,29 NF8. Uniform service description (SLA offering), using standard formats 2,00 NF7. Supporting abstraction (it hides many details of systems infrastruc-‐

ture and application infrastructure from developers and their appli-‐cations) (Abstraction eliminates the complexity of deployment and

infrastructure configuration.)

2,00

NF5. Licensing and security issues to span different Cloud platforms 1,57 NF4. Secure execution of monetary transactions 1,43

Table 28: Non-‐Functional Requirements sorted by rating average

12.1.3 Companies which do not use cloud services

As noticed previously, one third of the companies do not use cloud services. Mostly

mentioned challenges considering using cloud services are security issues (82.8%) fol-‐lowed by control issues (58.2%) and issues integrating with internal systems (48.3%)

(Figure 35). Further challenges are cost and performance issues. Another challenge is

for example lack of bandwidth. Only 6.9% think that there are no challenges.

107


Figure 35: Challenges of companies which do not use cloud services

Although there are many challenges, nevertheless 76.5% of the companies are able to consider using cloud services in the future (compare Figure 36). Despite 14.3% of the

companies wanted to take a look at the before mentioned requirements in chapter

12.1.2, no participant filled out the list (Figure 37).

82,8%

58,6%

41,4% 48,3%

41,4% 37,9%

17,2% 20,7% 27,6%

13,8% 6,9% 6,9%

0,0%

10,0%

20,0%

30,0%

40,0%

50,0%

60,0%

70,0%

80,0%

90,0% Security issue

s

Control issue

s

Cost issues

Issues integra|

ng with

internal

system

s

Performance issues

Lack of resou

rces/exper|se

with

cloud

techno

logies

Issues m

anaging mul|p

le cloud

en

vironm

ents

Compliance issue

s

Lack of sup

port from

IT

Lack of sup

port from

de

cisio

nmakers

No challenges

Other

What kind of challenges are you facing considering using cloud services? (Mulkple answers possible)

108


Figure 36: Usage of cloud services in the future

Figure 37: Sophisticated view on requirements

76,5%

23,5%

Is there a chance you will be using cloud services for your soiware in the future?

Yes No

14,3%

85,7%

Would you like to provide a more sophiskcated view on the requirements?

Yes No

109


13 Interviews

In addition to the questionnaire a detailed interview guide was designed to locate aris-‐

ing problems and find out which functionalities are important for a company distrib-‐

uting applications by using Cloud Computing and PaaS.

13.1 Interview guide

The interview guide was based on the Functional and Non-‐Functional Requirements

which were already introduced in chapter 8.1. Besides questions about the company and its use of cloud services, the interview guide includes several usages scenarios to

find out which problems the companies expect to get and how they would behave in a

specific situation. The goal was to achieve further requirements and needs of develop-‐ers and PaaS providers.

13.2 Requirements (Functional & Non-‐Functional)

This section documents the requirements gathered for D1.1 from PaaS providers and Software development Engineers. The prioritization of the requirements was carried

out according to the following three levels:

• Top priority was given to all the requirements that originated both in the usage scenarios, studies from literature and the feedback from the SMEs’ question-‐naires and interviews.

• Medium priority was assigned to all the requirements coming only from the us-‐age scenarios.

• Low priority was given to all the requirements that derived only from the litera-‐ture review.

For the design of the PaaSport Reference Architecture only the top and medium priori-‐

ty requirements will be addressed. Table 29 lists the final functional requirements for

the Software development Engineers stakeholder. Table 30 lists the functional re-‐quirements for the PaaS provider. Table 31 presents the non-‐functional requirements

grouped in eight categories of software qualities.

110


13.2.1 Functional Requirements of development Engineers

Table 29: PaaSport Functional Requirements of development Engineers

Functional Requirements Description Priority

F1 Enable transparent migration of data/applications (portability) Top

F2 Be able to manage instances across multiple Cloud providers

F3 Enable the use of metadata in the declaration of PaaS providers and during

match making

F4 Monitor the execution performance in real-‐time

F5 Receive notification alerts for SLA violations

F6 Manage the complete lifecycle of a cloud service

(deployment, undeployment, start, pause, stop, delete and migration)

F7 Support PaaS offerings with elasticity features Medium

F8 Reuse and share functions provided by existing application and enable applica-‐

tions to work together using integration tools

Low

F9 Support backup and restore Top

F10 Be able to use a common API (common set tools) that supports provision-‐

ing/deployment/configuration and control access different Cloud resources

Top

F11 Be able to provide PaaSport interoperability libraries for defining and develop-‐

ing the service as well as to develop the images associated with the service

Medium

F12 Be able to search for PaaS services that are held Top

F13 Access and view the provided services listed in a service catalog

F14 Enable user profiling in terms of personal workspace (e.g. user and notification

settings, billing and payment information, etc.)

F15 Be able to support a developer’s community Medium

F16 Be able to support a marketplace (application selling business model, SLA ad-‐

aptation and support, service billing policy)

Top

F17 Be able to transfer monitoring, logging, auditing and control functions to the

new provider by the means of commonly defining formats

Top

F18 Be able to verify that the migrated services or applications are operating cor-‐

rectly in the new provider

F19 Be able to support self-‐service provisioning and management Top

F20 Be able to get recommendations in selecting a Cloud provider based on a hy-‐

brid recommender system approach

Top

F21 Ability to determine the privacy level of their data (user profile, personalized

environment)

Top

F22 Be able to manage the geographic region in which an application is deployed. Top

111


13.2.2 Functional Requirements of PaaS Providers

Table 30: PaaSport Functional Requirements of PaaS Providers

Functional Requirements Description Priority F23 Automatic update of a Cloud system’s SLA as a result of a change in the provid-‐

er’s policy after SLA matching.

Top

F24 Monitor the status of the resources (dead/alive) and application components,

services, and infrastructure to detect failures.

Top

F25 Manage the access to resources/services Top

F26 Be able to publish service offerings in a service catalogue (service characteris-‐

tics, policies, application platform availability and performance)

Top

F27 Manage the SLA contracts Top

F28 Define charging for services (billing functions, invoices, settlement, etc.) Top

13.2.3 Non-‐functional Requirements of PaaS Providers

Table 31: PaaSport Non-‐Functional Requirements

Requirement Type Non-‐functional Requirements Description Priority

Security NF1 Data and application security Top

NF2 Encryption Medium

NF3 User authentication and single sign-‐on,

authorization and role-‐based access con-‐

trol, security proof

Top

NF4 Secure storage and handling of payment

data

NF5 Licensing and security issues to span differ-‐

ent Cloud platforms

Interoperability NF6 Supporting commonly used standards,

standard syntax, open APIs, widely available

tools, technologies, methodologies, and

best practices.

NF7 Supporting abstraction (it hides many de-‐

tails of systems infrastructure and applica-‐

tion infrastructure from developers and

their applications)

112


NF8 Uniform service description (SLA offering),

using standard formats

NF9 SLAs with clear policies and guidelines for

maintenance and version management of

the platform and policies for version com-‐

patibility for APIs between the platform and

the application.

NF10

Transparency during interaction with user-‐

adaptive systems

Reliability NF12 Reliable Top

Usability (Operability) NF13 Automatic and seamless deployment

NF14 Intercept component-‐to-‐component com-‐

munication.

Medium

NF15 The development platform and the devel-‐

opment tools are hosted in the Cloud and

accessed through a browser

Low

NF16 It provides a presentation interface (menu

and navigator, user controls, display and

rendering, reporting)

Top

Usability (Understanda-‐

bility and Attractiveness)

NF17 Ease-‐of-‐Use Top

NF18 The interface should not be obtrusive

NF19 The interface should be understandable

and predictable

NF20 The content and functionality of user inter-‐

face layout will be organized logically.

NF21 The intelligent user interface should use

graphical elements instead of using text-‐

based linear lists because a graphical user

interface can increase the level of user sat-‐

isfaction as well as the level of the commu-‐

nication of the adaptive system with its

users

Efficiency NF22 It can be accessed by multiple users at the

same time (multi-‐tenant)

Top

Scalability NF23 It should be scalable and deployable on

different cloud platforms

Low

113


Availability NF24 It should be accessible and available (at

acceptable service levels).

Top

Other NF25 Ensuring developer choice on languages,

runtimes and tools

Top

114


14 Conclusion

The State Of the Art demonstrated the overall high variety of approaches and under-‐

standing while dealing with Cloud Computing or specifically with PaaS. The heteroge-‐

neity of the different cloud models makes interoperability much more complex and

challenging. Different APIs, programming languages, frameworks and service process-‐

es are also used.

The Du-‐Pont System for Financial Analysis shows that the implementation of Cloud

Computing has a positive impact on the cost-‐effectiveness of Cloud Computing cus-‐

tomers. Cloud Computing solutions cut costs, improve business processes and raise

sales. All these positive aspects are getting in the end measurable through the Du-‐Pont

analysis. However, the Du-‐Pont of Financial analysis just scratches on the surfaces. If a

company want to identify more concrete, what is improved by Cloud Computing and where the improvements are, other complementary indicators have to be applied like

contribution of the IT to cycle times or the contribution of the IT to increase the cus-‐

tomer satisfaction. Interoperability acts as a catalyst for the Cloud Computing demand,

because it eliminates the scare of the customers of being bound on a service provider. Moreover, interoperability reinforces Cloud Computing benefits like further cost cut-‐

tings and collaboration simplifications. Customers will shift from on premises solutions

to cloud solutions to profit from these advantages.

On the first view the cloud vendors look like the loser when interoperability would be

achieved because an easy change can lead to a price fight between the providers. On

the other hand, interoperability is a big chance for the cloud providers to increase the

attraction of cloud services what could lead to a huge demand increase. The Cloud

Computing service market would grow rapidly and would enable the service providers

to increase their profits, despite lowering their prices for the services. The economy of

scale could fully unfold. These is probably one of the reasons why the most cloud ser-‐

vice providers participate in initiatives and projects which aim to achieve Cloud Com-‐

puting interoperability. A second reason could be, that the IT and especially the Cloud

Computing future is seen in the boundary free enterprise which requires interoperabil-‐

ity. The providers know, that when they want to sustain in the future, they have to

provide interoperable services.

115


The results of previous initiatives show that Cloud Computing interoperability is not an

unreachable goal.

However, it has to be considered that, if PaaSport is targeting an interoperability solu-‐

tion for PaaS. it will take much more time till Cloud Computing interoperability will be achieved over all layers (IaaS, PaaS and SaaS). Cloud Computing interoperability will be

also in the future a big topic because it helps to fully exploit the potential of Cloud

Computing. Moreover interoperability offers the chance to improve the security of

cloud services what could be a big driver for Cloud Computing adoption.

The future will show if interoperability can help Cloud Computing to become finally to

the “(…) new and important industry” 6 that John McCarthy mentioned in his speech at

MIT’s (Massachusetts Institute of Technology) centennial celebration in 1961.

The survey gave feedback about the frameworks, programming languages, databases

and others that are used by the companies. As you can see in chapter 12.1.1 many companies use already cloud services although they are aware of the challenges like

security and vendor lock-‐in problems. Nevertheless they retrieve many advantages by

using cloud services like cost saving and scalability. Even companies which do not use

cloud services state that there will be a chance to use cloud services in the future. The questionnaire reveals that security problems are the most important challenge for

companies which use cloud services as well as companies which do not use cloud ser-‐

vices. Most of the companies are aware of the vendor lock-‐in problem and its disad-‐vantages. Besides an interview guide was designed and verified in order to locate aris-‐

ing problems and to find out which functionalities are important for the companies.

Based on the requirements identified in this deliverable, the project should lift the bar-‐riers that cause the vendor lock-‐in problem, empower Cloud customers and Cloud ap-‐

plication developers and allowing them to choose freely the Cloud PaaS offering that

best fits their needs. This will also lead to encourage the entrance of European SME

Cloud vendors in the PaaS market and to strengthen their market position relative to

the big vendors.

6 John McCarthy, speaking at the MIT Centennial in 1961, (Garfinkel 1999, 1)

116


15 Annex 1 -‐ Questionnaire

This survey addresses software companies who distribute or want to distribute appli-‐

cations using Cloud Computing and PaaS ("Platform as a Service") providers. In the

frame of the project "PaaSport" (www.paasport-‐project.eu) we want to collect the

requirements of developers and PaaS providers, with special emphasis on PaaS in-‐

teroperability. The goal of PaaSport is to resolve the data and application portability

issues that exist in the Cloud PaaS market.

There are nine to 20 questions depending on your choice of answer and it takes you

about five to ten minutes to complete the questionnaire.

If you would like to receive the survey results, please enter your e-‐mail address at the

end of the survey.

Thank you very much for your support!

1. How many employees does your company currently have?

□ < 10 □ 10-‐50 □ 51-‐250 □ >250

2. Do you use a cloud service for your software?

□ Yes (Go on with question 3 to 20)

□ No (Go on with question 21 to 27)

3. What challenges does your company face by using cloud services? (Multiple

answers possible)7

□ Security issues

□ Control issues

7 (DZone Research 2013, 17)

117


□ Cost issues

□ Issues integrating with internal systems

□ Performance issues

□ Lack of resources/expertise with cloud technologies

□ Issues managing multiple cloud environments

□ Compliance issues

□ Lack of support from IT

□ Lack of support from decision maker

□ No challenges

□ Other

If other, please specify (optional):

4. Have you ever intended to change your cloud provider or do you employ

more than one cloud provider?

□ Yes

□ No

5. Whom do you offer your web service?

□ Only end-‐user □ End-‐user and third parties

6. Which programming language is used?

□ Java

□ PHP

□ JavaScript

□ Visual Basic

□ Other

If other, please specify

(optional):

118


7. Which framework is used?

□ .NET

□ Spring

□ Java Enterprise Edition

□ Other

If other,

please specify

(optional):

8. Which kind of database is used?

□ Relational database

□ NoSQL database

9. Which kind of monitoring is needed for your cloud services? (Multiple an-‐swers possible)

□ Resources

□ Infrastructure

□ Application

□ Service

□ None

□ Other


10. Is there a need to dynamically scale resources for traffic peaks etc.?

□ Yes

□ No

11. What kind of technical resources or hardware requirements are needed? (op-‐tional)

119


12. What are your benefits by using cloud services for your software? (optional)

13. Vendor lock-‐in makes the customer dependent on a PaaS offering. Therefore there is a tradeoff between ease of use and reducing the customer´s freedom of choice. Are you aware of this?

□ Yes (Go on with question 14 to 20)

□ No (Go on with question 15 to 20)

14. How would you rate the vendor lock-‐in?

□ advantages predominate

□ disadvantages predominate

15. Would you like to provide a more sophisticated view on the requirements?

□ Yes (Go one with question 16 to 20)

□ No (Go one with question 17 to 20)

16. How important are these functionalities to your company?

Functionality 0 not important, …, 5 very important

Transparently migrate data/applications (portability)

Manage resources across multiple Cloud providers

Configure (business rules, customizable data model and metadata

set)

Monitor execution performance in real-‐time

Receive (SLA violation, failure) alerts

Manage the complete lifecycle of a service (deployment, federation

120


and migration)

Orchestrate all the involved components

Reuse and share functions provided by existing application, enabling

applications to work together (integration tools)

Support backup and restore

Use testing tools

Use a common API (common set of tools) that supports provision-‐

ing/deployment/configuration and control across different Cloud

resources

Use tools for defining and developing the service as well as to develop

the images associated with the service

Search for services (IaaS, PaaS) held by multiple Cloud systems

Access and view the provided services listed in a service catalog

Enable user profiling (personal workspace)

Support a developers’ community

Support a marketplace (application selling business model, SLA adap-‐

tation and support, service billing policy)

Transfer monitoring, logging, auditing and control functions to the


Verify that the migrated services or applications are operating cor-‐

rectly in the new provider

Support self-‐service provisioning, management and scaling

Get recommendations in selecting a Cloud provider based on a hybrid

recommender system approach

Ability to determine the privacy level of their data (user profile, per-‐

sonalized environment)

Automatic update of a Cloud system’s SLA as a result of a change in

the provider’s policy after SLA matching.

Monitor the status of the resources (dead/alive) and application

components, services, and infrastructure to detect failures.

Establish federations/collaborations of Cloud platforms

Manage the access to resources/services

Publish service offerings in a service catalog (service characteristics,

policies, application platform availability and performance)

121


Manage the SLA contracts

Charge for services (billing functions, invoices, settlement, etc.)

Data and applications security

Encryption

User authentication and single sign-‐on, authorization and role-‐based

access control, security proof

Secure execution of monetary transactions

Licensing and security issues to span different Cloud platforms

Supporting commonly used standards, standard syntax, open APIs,

widely available tools, technologies, methodologies, and best practic-‐

es.

Supporting abstraction (it hides many details of systems infrastruc-‐

ture and application infrastructure from developers and their applica-‐

tions)

Uniform service description (SLA offering), using standard formats

SLAs with clear policies and guidelines for maintenance and version

management of the platform and policies for version compatibility for

APIs between the platform and the application.

Transparency during interaction with user-‐adaptive systems

Technology neutral and loosely coupled widgets while supporting

location transparency

Reliable

Automatic and seamless deployment

Intercept component-‐to-‐component communication.

The development platform and the development tools are hosted in

the Cloud and accessed through a browser

It provides a presentation interface (menu and navigator, user con-‐

trols, display and rendering, reporting)

Ease-‐of-‐Use

The interface should not be obtrusive

The interface should be understandable and predictable

The content and functionality of UI layout will be organized logically.

The intelligent user interface should use graphical elements instead

of using text-‐based linear lists because a graphical user interface can

122


increase the level of user satisfaction as well as the level of the com-‐

munication of the adaptive system with its users

It can be accessed by multiple users at the same time (multi-‐tenant)

Scalable infrastructure provisioning as needed

Scalable deployment to multiple Cloud platforms and between Cloud

systems and on-‐premise systems

It should be accessible and available (at acceptable service levels).

Ensuring developer choice on languages, runtimes and tools

17. What country does your company come from? (optional)

18. Please characterise your target group or customer type (optional):

19. Company name (optional):

20. Your email address (optional):

Thank you for answering this questionnaire!

21. Is there a chance you will be using cloud services for your software in the fu-‐ture?

□ Yes

□ No

If no, please specify (optional):

22. What kind of challenges are you facing considering using cloud services?

(Multiple answers possible)

□ Security issues

123


□ Control issues

□ Cost issues

□ Issues integrating with internal systems

□ Performance issues

□ Lack of resources/expertise with cloud technologies

□ Issues managing multiple cloud environments

□ Compliance issues

□ Lack of support from IT

□ Lack of support from decision maker

□ No challenges

□ Others


23. Would you like to provide a more sophisticated view on the requirements?

□ Yes (Go one with question 24 to 28)

□ No (Go one with question 25 to 28)

24. How important are these functionalities to your company?

Functionality 0 not important, …, 5

very important

Transparently migrate data/applications (portability)

Manage resources across multiple Cloud providers

Configure (business rules, customizable data model and metadata

set)

Monitor execution performance in real-‐time

Receive (SLA violation, failure) alerts

Manage the complete lifecycle of a service (deployment, federa-‐

124


tion and migration)

Orchestrate all the involved components

Reuse and share functions provided by existing application, ena-‐

bling applications to work together (integration tools)

Support backup and restore

Use testing tools

Use a common API (common set of tools) that supports provision-‐

ing/deployment/configuration and control across different Cloud

resources

Use tools for defining and developing the service as well as to

develop the images associated with the service

Search for services (IaaS, PaaS) held by multiple Cloud systems

Access and view the provided services listed in a service catalog

Enable user profiling (personal workspace)

Support a developers’ community

Support a marketplace (application selling business model, SLA

adaptation and support, service billing policy)

Transfer monitoring, logging, auditing and control functions to the


Verify that the migrated services or applications are operating

correctly in the new provider

Support self-‐service provisioning, management and scaling

Get recommendations in selecting a Cloud provider based on a

hybrid recommender system approach

Ability to determine the privacy level of their data (user profile,

personalized environment)

Automatic update of a Cloud system’s SLA as a result of a change

in the provider’s policy after SLA matching.

Monitor the status of the resources (dead/alive) and application

components, services, and infrastructure to detect failures.

Establish federations/collaborations of Cloud platforms

Manage the access to resources/services

Publish service offerings in a service catalog (service characteris-‐

tics, policies, application platform availability and performance)

125


Manage the SLA contracts

Charge for services (billing functions, invoices, settlement, etc.)

Data and applications security

Encryption

User authentication and single sign-‐on, authorization and role-‐

based access control, security proof

Secure execution of monetary transactions

Licensing and security issues to span different Cloud platforms

Supporting commonly used standards, standard syntax, open APIs,

widely available tools, technologies, methodologies, and best

practices.

Supporting abstraction (it hides many details of systems infra-‐

structure and application infrastructure from developers and their

applications)

Uniform service description (SLA offering), using standard formats

SLAs with clear policies and guidelines for maintenance and ver-‐

sion management of the platform and policies for version compat-‐

ibility for APIs between the platform and the application.

Transparency during interaction with user-‐adaptive systems

Technology neutral and loosely coupled widgets while supporting

location transparency

Reliable

Automatic and seamless deployment

Intercept component-‐to-‐component communication.

The development platform and the development tools are hosted

in the Cloud and accessed through a browser

It provides a presentation interface (menu and navigator, user

controls, display and rendering, reporting)

Ease-‐of-‐Use

The interface should not be obtrusive

The interface should be understandable and predictable

The content and functionality of UI layout will be organized logi-‐

cally.

The intelligent user interface should use graphical elements in-‐

126


stead of using text-‐based linear lists because a graphical user in-‐

terface can increase the level of user satisfaction as well as the

level of the communication of the adaptive system with its users

It can be accessed by multiple users at the same time (multi-‐

tenant)

Scalable infrastructure provisioning as needed

Scalable deployment to multiple Cloud platforms and between

Cloud systems and on-‐premise systems

It should be accessible and available (at acceptable service levels).

Ensuring developer choice on languages, runtimes and tools

25. What country does your company come from? (optional)

26. Please characterise your target group or customer type (optional):

27. Company name (optional):

28. Your email address (optional):

Thank you for answering this questionnaire!

127


16 Annex 2 -‐ Interview guide

Company name:

Number of employees: (approx.)

Country:

General Questions

1) Which kind of application do you provide?

2) Is your Cloud provider an EU or an US company?

□ EU company

□ US company

3) Do you use multiple cloud providers for your solution(s)?

□ Yes

If yes : a) What is the reason?

b) Is there a necessity of using multiple cloud providers?

□ Yes □No

c) Do you use multiple cloud providers for locality closeness to the

customers? □ Yes □ No

d) How difficult is it to support multiple cloud providers in one organ-‐isation?

128


e) How difficult is it to manage resources across multiple cloud pro-‐viders?

□ No

If no: f) Why not?

4) What resources are managed through cloud providers?

5) Do interoperability issues exist?

□ Yes

If yes: What kind of interoperability issues exist?

□ No

Questions about support and service

6) What is important considering lifecycle management?

7) What is particularly well supported considering lifecycle management?

8) Is there something missing considering lifecycle management?

9) Is there any support for deployment across different locations?

□ Yes

□ No

a) How important is this functionality to your organisation (High (H), Middle (M),

Low (L))?

129


10) Is there any support for migration e.g. between different locations or different pro-‐

viders?

□ Yes

□ No

a) How important is this functionality to your organisation (H, M, L)?

11) Is a common set of cloud provider API or tools for provision-‐

ing/deployment/configuration and control across different cloud resources available for you?

□ Yes

If yes: a) Do you use this feature?

□ Yes □ No

□ No

If no: b) If it was available for you, would you use this feature?

□ Yes □ No

c) How important is this functionality to your organisation (H, M, L)?

12) How do you monitor your applications/resources/components/infra-‐

structure/services to detect failures?

13) Do you use any monitoring tools?

□ Yes

If yes: a) Which tool(s)?

□ Nagios

130


□ Icinga

□ Shinken

□ Other

□ No

b) How important is monitoring to your organisation (H, M, L)?

14) Do you use real-‐time monitoring?

□ Yes

□ No

15) What parameters are monitored?

16) Are there any parameters you would need to get monitored which are not provided by your existing provider?

□ Yes

If yes: Which parameters?

□ No

17) Do you monitor SLA conformance of your cloud provider?

□ Yes

If yes: a) How do you monitor SLA conformance of your cloud provider? b) Do you receive any notification from them?

□ Yes

□ No

131


□ No


18) Does your cloud provider support customised GUIs (e.g. dashboard) according to the

user preference?

□ Yes

□ No

19) Would you need this support of customised GUIs?

□ Yes

If yes: a) What is needed?

□ No

20) Does your PaaS provider provide any tools for defining and developing the service as

well as to develop the images associated with the service?

□ Yes

□ No

If no: a) Do you expect any specific tools?

□ Yes □ No

b) How important is this functionality to your organisation (H, M, L)?

c) What functionality would you expect to have?

21) Does your cloud provider provide any testing/debugging tools or interfaces (e.g. re-‐

sponse time tools)?

□ Yes

132


If yes: a) Which tools or interfaces?

□ No


22) Are your applications backed up /restored in case of failures by the cloud provider?

□ Yes

If yes: a) Is this functionality provided by your cloud provider?

□ Yes

□ No

b) Is this functionality sufficient or what would you like to be provid-‐

ed?

□ No


23) Does your application use any third party applications/services?

□ Yes

If yes: a) Which kind?

□ Billing □ Email support □ Other

b) What tools/interfaces support their integration?

□ No

133


If no:

c) Are there any services like billing (e.g. per user, per resource) inte-‐grated in the PaaS stack of your provider?

24) How did you find the PaaS provider for your application?

25) How did you match your requirements against the PaaS providers' offerings?

26) What was the decision process to select the best PaaS?

27) Which support is provided by your existing provider?

□ FAQ support

□ Documentation

□ Programmer’s support

□ Forums

□ Other

28) Which kind of support would you expect from the developers’ community?

□ FAQ support

□ Documentation

□ Programmer’s support

□ Forums

□ Other

134


Opinion survey

In case you want to change PaaS providers:

29) Which difficulties and challenges do you expect?

30) Would you consider transferring information like existing monitoring, logging, audit-‐

ing, billing, and control functions to the new provider?

□ Yes

□ No

31) What functionality do you think is useful in a marketplace to find and compare dif-‐

ferent PaaS provider?

32) Would you consider a recommender system which is part of the marketplace for the selection of cloud provider(s) as useful?

□ Yes

□ No

33) How should recommendations look like?

34) Do you consider service catalogue to access and view provided services as useful?

□ Yes

If yes: a) Are there any important ones?

b) What information should it contain?

□ No

35) In which case will you need to migrate data and application?

135


36) Would you need the functionality to transparently migrate data and application?

□ Yes

□ No

a) How important is this functionality to your organisation (H, M, L)?

37) Will automatic migration be accepted?

□ Yes

□ No

38) Would you consider verifying that the migrated services or applications are operating correctly in the new provider?

□ Yes

If yes: a) How would you verify that the migrated services or apps run cor-‐

rectly?

□ No


39) Do you use any standardization for your data and application?

□ Yes

If yes : a) Any standardization body (e.g. IEEE)?

□ Yes □ No

□ No

40) How should support for scalability look like?

136


41) Do you consider the ability to ensure the privacy of users of your application/data as

being important?

□ Yes

□ No

42) What further functionalities, tools, services etc. do you expect from cloud providers

in the future?

43) Regarding current data security issues and other problems, will your company keep

using cloud services in the future?

□ Yes

□ No

Scenarios

In the following five scenarios are shown.

Scenario 1:

Your company wants to migrate a business application from a legacy information system and deploy it on a PaaS offering.

44) How relevant is this scenario for your company? (0 not relevant, …,5 very relevant)

45) What approach would you use?

46) Assuming that there exists a marketplace for PaaS offerings to support you, which are

137


the most important functionalities you would expect from it?

47) What tools would you like to have?

Scenario 2:

Your company wants to decouple an application's business logic from its data and deploy it cross-‐platform.




Scenario 3:

Your company wants to migrate business application from one PaaS platform to another.




Scenario 4:

A new Cloud PaaS vendor joins a marketplace for PaaS offerings. The new vendor is able to seamlessly communicate with the marketplace and transparently exchange data and applications with other providers that are already present on the marketplace.


138


55) What are the main advantages that you would expect from this scenario (technical,

economical)?

56) Do you expect the marketplace to send for example notifications to you in case new

providers become available?

□ Yes

If yes: a) Which information should they contain?

□ No

Scenario 5:

Please come up with an own scenario.

Thank you very much for your support!

139


17 Literature

Armbrust, Michael, et al. "A view of cloud computing." ACM Digital Library. April 2010.

http://dl.acm.org/citation.cfm?id=1721672 (accessed July 29, 2014).

Basset, Meghan. 10 Reasons Why Your Sales Team Should Adopt CRM Technology.

November 13, 2012. http://www.trackvia.com/blog/technology/10-‐reasons-‐why-‐your-‐

sales-‐team-‐should-‐adopt-‐crm-‐technology (accessed August 12, 2014).

Baumann, Robert, and Marcel Reber. Rechnungswesen für technische Kaufleute und

HWD. Zurich: Compendido Bildungsmedien, 2011.

BITKOM. Die wichtigsten Hightech-‐Themen 2013. 16. January 2013.

http://www.bitkom.org/de/presse/30739_74757.aspx (Zugriff am 01. July 2014).

—. Die wichtigsten Hightech-‐Themen 2013. January 16, 2013.

http://www.bitkom.org/de/presse/30739_74757.aspx (accessed July 01, 2014).

Bourne, Vanson. "Claranet research programme 2013." The ROI for adopting cloud -‐

Evaluation the business benefits of adoption. November 2012.

Bungee Conect Developer Network. Defining Platform as a Service, or PaaS.

http://bungeeconnect.wordpress.com/2008/02/18/defining-‐platform-‐as-‐a-‐service-‐or-‐paas/ (Zugriff am 28. July 2014).

Burke, Robin. „Hybrid Recommender Systems.“ Herausgeber: Fullerton California State

University. http://josquin.cs.depaul.edu/~rburke/pubs/burke-‐umuai02.pdf (Zugriff am 22. July 2014).

Campos, Christina, Isabel Marti, Reyes Grangel, Alessandro Mascherpa, and Ricardo

Chalmeta. "A Methodological Proposal for the Development of an Interoperability

Framework." CEUR Workshop Proceedings. June 09, 2008. http://ceur-‐ws.org/Vol-‐

340/paper04.pdf (accessed July 05, 2014).

Capgemini. „Studie IT-‐Trends 2014.“ Capgemini. 2014.

http://mc.capgemini.de/magazin/it-‐trends/wp-‐

content/uploads/sites/3/2014/01/Capgemini-‐IT-‐Trends-‐Studie-‐2014.pdf (Zugriff am

17. May 2014).

Catteddu, Danielle, and Giles Hogben. "Cloud Computing Risk Assessment." European

Union Agency for Network and Information Security. November 20, 2009.

140


http://www.enisa.europa.eu/activities/risk-‐management/files/deliverables/cloud-‐

computing-‐risk-‐assessment/ (accessed June 26, 2014).

CCIF. Cloud Computing Interoperability Forum (CCIF).

http://www.cloudbook.net/directories/cloud-‐groups/cloud-‐computing-‐interoperability-‐forum (accessed August 03, 2014).

Chou, Yung. Cloud Computing for IT Pros (2/6): What Is Cloud. December 17, 2010.

http://blogs.technet.com/b/yungchou/archive/2010/12/17/cloud-‐computing-‐

concepts-‐for-‐it-‐pros-‐2-‐3.aspx (accessed July 17, 2014).

Cloud Pier & Cloud4SOA. "Cloud Pier -‐ Facilitating today's PaaS adoption and preparing

for tomorrow's multi-‐cloud demand." Cloud Pier. 2013.

http://opencloudpier.org/sites/default/cloud/files/content-‐files/Cloud%20Pier%20whitepaper.pdf (accessed July 28, 2014).

Cloud Security Alliance. SECURITY GUIDANCE FOR CRITICAL AREAS OF FOCUS IN CLOUD COMPUTING V3.0. Cloud Security Alliance, 2011.

Cloud4SOA. "Cloud4SOA: an open-‐source solution for multi-‐PaaS application manage-‐

ment and portability." Cloudscapeserious. February 04, 2013.

http://media.cloudscapeseries.eu/Repository/images/Posters/Cloud4SOA_poster_v9%20%28final%29.pdf (accessed August 07, 2014).

Cloud4SOA. „Requirement analysis.“ 2012.

Cloudability. Cloudability -‐ Features. https://cloudability.com/features/ (accessed 9. August 2014).

Cohen, Reuven. Examining Cloud Compatibility, Portability and Interoperability. 27. February 2009. http://www.elasticvapor.com/2009/02/examining-‐cloud-‐compatibility.html (accessed 21. July 2014).

College of Engineering and Computer Science at Wright State University. 2014.

http://wiki.knoesis.org/images/thumb/9/96/Chart4.png/380px-‐Chart4.png.

Columbus, Louis. 451 Research: Platform-‐as-‐a-‐Service (PaaS) Fastest Growing Area Of

Cloud Computing. 20. August 2013. http://softwarestrategiesblog.com/2013/08/20/451-‐research-‐platform-‐as-‐a-‐service-‐

paas-‐fastest-‐growing-‐area-‐of-‐cloud-‐computing/ (accessed 20. Juli 2014).

141


—. Gartner Predicts Infrastructure Services Will Accelerate Cloud Computing Growth.

19. February 2013. http://www.forbes.com/sites/louiscolumbus/2013/02/19/gartner-‐

predicts-‐infrastructure-‐services-‐will-‐accelerate-‐cloud-‐computing-‐growth/ (Zugriff am

10. July 2014).

Cooter, Maxwell. Top 10 business reasons to move to the cloud. 21. February 2013.

http://windowsserver2012.itpro.co.uk/business-‐benefits/92/top-‐10-‐business-‐reasons-‐

move-‐cloud (Zugriff am 02. August 2014).

Department of Defense Information Network Global In-‐formation Grid Cloud Compu-‐ting Services Guidance Working Group. „Department of Defense Information Network

(GIG) Cloud Computing Services Interoperability and Portability Reference Architec-‐

ture.“ 05. March 2014. http://collaborate.nist.gov/twiki-‐cloud-‐compu-‐

ting/pub/CloudComputing/CloudInteroperability/NIST_CIPWG_2014_006_DCCSG_CC_IP_Reference_Architecture_v_1_0_03032014.pdf (Zugriff am 25. August 2014).

—. „DoDIN (GIG) Cloud Computing Interoperability and Portability Technical Frame-‐

work V. 1.3.“ 12. December 2013. http://collaborate.nist.gov/twiki-‐cloud-‐

compu-‐ting/pub/CloudComputing/CloudInteroperability/NIST_CIPWG_2014_005_GIG_Cloud_

Interoperability_and_Portability_Technical_Framework_V_1_3.pdf (Zugriff am 25. Au-‐

gust 2014).

DMTF. About DMTF. http://www.dmtf.org/about (accessed July 03, 2014).

Durand, Jaques, Adrian Otto, Gilbert Pilz, und Tom Rutt. „Cloud Application Manage-‐ment for Platforms Version 1.1.“ 12. February 2014. http://docs.oasis-‐open.org/camp/camp-‐spec/v1.1/camp-‐spec-‐v1.1.pdf (Zugriff am 15. June 2014).

DZone Research. DZone’s Definitive Guide to Cloud Providers -‐ Private and Public

Cloud, PaaS, IaaS, BaaS, and More! Cary, NC: DZone, Inc., 2013.

Encyclopædia Britannica Inc. . fourth-‐generation language (4GL).

http://www.britannica.com/EBchecked/topic/215243/fourth-‐generation-‐language-‐4GL (Zugriff am 25. July 2014).

enisa. "Cloud Computing -‐ Benefits, risks and recommendations for information securi-‐

ty." European Union Agency for Network and Information Security. December 2012. https://resilience.enisa.europa.eu/cloud-‐security-‐and-‐resilience/publications/cloud-‐

142


computing-‐benefits-‐risks-‐and-‐recommendations-‐for-‐information-‐security (accessed

June 23, 2014).

Etro, Frederico. "The Economics of Cloud Computing." The IUP Journal of Managerial

Economics, 2011: 1-‐14.

European Commission. „DECISIONS ADOPTED JOINTLY BY THE EUROPEAN PARLIA-‐

MENT AND THE COUNCIL -‐ DECISION No 922/2009/EC OF THE EUROPEAN PARLIA-‐

MENT AND OF THE COUNCIL of 16 September 2009 -‐ on interoperability solutions for

European public administrations.“ Official Journal of the European Union, 16. Septem-‐ber 2009: 4.

European Telecommunications Standards Institute (ETSI). „TR 102 997 V1.1.1 -‐ CLOUD;

Initial analysis of standardization requirements for cloud services.“ 2010. http://www.etsi.org/deliver/etsi_tr/102900_102999/102997/01.01.01_60/tr_102997v

010101p.pdf (accessed 22. July 2014).

Financial Memos. Components of Working Capital and how to manage them. Novem-‐

ber 10, 2013. http://financialmemos.com/components-‐of-‐working-‐capital-‐and-‐how-‐to-‐

manage-‐it/ (accessed August 03, 2014).

Garfinkel, Simson L. Architects of the Information Society -‐ Thirty-‐Five Years of the La-‐boratory for Computer Science at MIT. Edited by Harold Abelson. Cambridge, Massa-‐

chusetts: The MIT Press, 1999.

Gartner. Gartner Hype Cycle. 2013. http://www.gartner.com/technology/research/methodologies/hype-‐cycle.jsp.

Gartner. Gartner's 2013 Hype Cycle for Emerging Technologies Maps Out Evolving Re-‐lationship Between Humans and Machines. 19. August 2013. http://www.google.de/imgres?imgurl=http://na1.www.gartner.com/imagesrv/newsro

om/images/hype-‐cycle-‐

pr.png&imgrefurl=http://www.gartner.com/newsroom/id/2575515&h=425&w=680&t

bnid=lCTLcK2EV9akBM:&zoom=1&tbnh=90&tbnw=144&usg=__6cvfYa45nJjbe20ZvZm

V_HhH_vo=&doci (acceded 13. July 2014).

Gartner . Hype Cycle for Platform as a Service (PaaS). 2013.

http://www.gartner.com/technology/research/methodologies/hype-‐cycle.jsp.

Gartner Inc. Multitenancy. http://www.gartner.com/it-‐glossary/multitenancy/ (Zugriff am 27. July 2014).

143


Gartner . Service Catalog. http://www.gartner.com/it-‐glossary/service-‐catalog/ (Zugriff

am 27. July 2014).

GICTF. Partnership with DMTF. July 09, 2012. http://www.gictf.jp/index_e.html (ac-‐

cessed August 06, 2014).

Gladen, Werner. Performance Measurement -‐ Controlling mit Kennzahlen. 6. Wiesba-‐

den: Springer Gabler Verlag, 2014.

Gleich, Ronald, Uwe Michel, Werner Stegmüller, and Andrea Kämmler-‐Burrak. Moder-‐

ne Kosten-‐ und Ergebnissteuerung. München: Haufe-‐Lexware GmbH & Co. KG, 2010.

Gonidis, Fotis, Iraklis Paraskakis, und Dimitrios Kourtesis. „Addressing the Challenge of

Application Portability in Cloud Platforms.“ 2012.

http://refbase.city.academic.gr/files/gonidis/2012/684_Gonidis2012.pdf (accessed 10. June 2014).

Gonzalves, Ricardo J. Enterprise Interoperability II. London: Springer London, 2007.

Groff, Adam. 5 Ways Cloud Computing is Changing How We Do Business. August 12,

2014. http://www.businessreviewusa.com/technology/4689/5-‐Ways-‐Cloud-‐

Computing-‐is-‐Changing-‐How-‐We-‐Do-‐Business (accessed August 16, 2014).

Heesen, Bernd, and Gruber Wolfgang. Bilanzanalyse und Kennzahlen. Wiesbaden: Springer Gabler, 2014.

Hölscher, Reinhold. Investition, Finanzierung und Steuern. München: Oldenburg Wis-‐

senschaftsverlag GmbH, 2010.

Initiative Cloud Services Made in Germany. Non-‐Profit-‐Organisationen senken Kosten

mit ProfitBricks und SEWOBE. November 26, 2013. http://www.cloud-‐services-‐made-‐in-‐germany.de/non-‐profit-‐organisationen-‐senken-‐kosten-‐mit-‐profitbricks-‐und-‐sewobe (accessed August 05, 2014).

Intel. "Intel Cloud Computing Taxonomy and." Intel. February 2010a.

http://www.intel.com/content/dam/doc/case-‐study/intel-‐it-‐cloud-‐computing-‐

taxonomy-‐ecosystem-‐analysis-‐study.pdf (accessed July 07, 2014).

—. "Intel's Vision of the Ongoing Shift to Cloud Computing." Intel. 2010b. http://www.intel.com/Assets/PDF/whitepaper/wp_cloud_vision_xeon.pdf (accessed

August 11, 2014).

144


ISACA. „Calculating Cloud ROI:.“ ISACA. July 2012.

http://www.isaca.org/Pages/DocumentDownloadRegistration.aspx?title=Calculating%

20Cloud%20ROI:%20From%20the%20Customer%20Perspective&type=&file=http%3a

%2f%2fwww.isaca.org%2fKnowledge-‐Center%2fResearch%2fDocuments%2fCalculating-‐Cloud-‐ROI_whp_Eng_0712.pdf&Re

(Zugriff am 18. June 2014).

—. "Calculating Cloud ROI:." ISACA. July 2012.

http://www.isaca.org/Pages/DocumentDownloadRegistration.aspx?title=Calculating%20Cloud%20ROI:%20From%20the%20Customer%20Perspective&type=&file=http%3a

%2f%2fwww.isaca.org%2fKnowledge-‐

Center%2fResearch%2fDocuments%2fCalculating-‐Cloud-‐ROI_whp_Eng_0712.pdf&Re (accessed June 18, 2014).

Iyer, Sreekanth. Defining Cloud Computing. September 05, 2010. https://www.ibm.com/developerworks/community/blogs/c2028fdc-‐41fe-‐4493-‐8257-‐

33a59069fa04/entry/chapter_1_cloud_computing_10155?lang=en (accessed August

03, 2014).

Jain, Palak. „Cloud Computing and It's Types in Mobile Network.“ International Journal of Science and Research (IJSR), August 2013: 71-‐73.

—. "Cloud Computing and It's Types in Mobile Network." International Journal of Sci-‐

ence and Research (IJSR), August 2013: 71-‐73.

Juniper Networks. Securing Multi-‐Tenancy and Cloud Computing. Juniper Networks,

2012.

Kamateri, Eleni, Nikolaos Loutas, and Dimitris Zeginis. Cloud4SOA: A Semantic-‐Interoperability PaaS Solution for Multi-‐cloud Platform Management and Portability.

Heidelberg: Springer Berlin Heidelberg, 2013.

Kinsella, Joe. Choosing the Right Cost Allocation Reporting Solution. August 19, 2014.

http://www.cloudhealthtech.com/blog/Choosing-‐the-‐Right-‐Cost-‐Allocation-‐Reporting-‐

Solution (accessed August 20, 2014).

Korman, Joshua M. The Business of Plastic Surgery: Navigating a Successful Career.

Singapore: World Scientific Publishing Co. Pte. Ltd., 2010.

—. The Business of Plastic Surgery: Navigating a Successful Career. Singapore: World Scientific Publishing Co. Pte. Ltd., 2010.

145


Kundra, Vivek. "FEDERAL CLOUD COMPUTING STRATEGY." Homeland Security. Febru-‐

ary 08, 2011. https://www.dhs.gov/sites/default/files/publications/digital-‐

strategy/federal-‐cloud-‐computing-‐strategy.pdf (accessed August 01, 2014).

Lee, C. „"A Perspective on Scientific Cloud Computing,".“ Proceedings of the 19th ACM International Symposium on High Performance Distributed Computing (HPDC '10), Chi-‐

cago,. 2010. pp. 451-‐459.

Lewis, Grace A. "The Role of Standards in Cloud-‐ Computing Interoperability." Software

Engineering Institue / Carnegie Mellon University. October 2012. https://resources.sei.cmu.edu/asset_files/TechnicalNote/2012_004_001_28143.pdf

(accessed Juli 22, 2014).

Loutas, Nikos, Eleni Kamateri, Maria Zotou, Dimitris Zeginis, und Konstantinos Taraba-‐nis. „cloud4SOA -‐ D1.1 Requirements Analysis Report -‐ Version 1.1.“ 24. February

2011. http://www.cloud4soa.eu/sites/default/files/Cloud4SOA%20D1.1%20Requirements%2

0Analysis.pdf (accessed 15. 05 2014).

Magalhaes, Ricky M, and Monique L Magalhaes. Standards and Good Cloud Practice.

May 01, 2014. http://www.cloudcomputingadmin.com/articles-‐tutorials/compliance-‐regulations/standards-‐and-‐good-‐cloud-‐practice.html (accessed July 23, 2014).

Mahowald, Robert, Al Hilwa, and Michael Shirer. New IDC Worldwide Public Platform

as a Service Forecast Shows Market Will Grow to Over $14 Billion in 2017. November 07, 2013. http://www.idc.com/getdoc.jsp?containerId=prUS24435913 (accessed June

30, 2014).

Mallya, Subraya. Graduating Cloud to the Enterprise: Platform-‐as-‐a-‐Service. January 25, 2010. http://www.prudentcloud.com/cloud-‐computing-‐technology/graduating-‐

cloud-‐to-‐the-‐enterprise-‐platform-‐as-‐a-‐service-‐25012010/ (accessed July 27, 2014).

Marshall, Gary. Best cloud services compared: Google vs Microsoft vs Amazon vs Apple

vs Dropbox. 12. August 2013. http://www.techradar.com/news/internet/which-‐cloud-‐

services-‐are-‐right-‐for-‐you-‐1055614 (accessed 02. Juli 2014).

McKendrick, Joe. Cloud Computing Market May Become An Oligopoly of High-‐Volume

Vendors. 11. July 2013.

http://www.forbes.com/sites/joemckendrick/2013/07/11/cloud-‐computing-‐market-‐may-‐become-‐an-‐oligopoly-‐of-‐high-‐volume-‐vendors/ (accessed 28. June 2014).

146


McNee, Bill. „Boundary-‐free Enterprise™: The New Master Architecture.“ SIIA (Soft-‐

ware & Information Industry Association). 09-‐10. May 2012.

http://www.siia.net/presentations/software/AATC2012/BoudryFreeEnterprise.pdf

(accessed 10. July 2014).

Mell, Peter, and Timothy Grance. "The NIST Definition of Cloud -‐ Recommendations of

the National Institute of Standards and Technology." NIST. 2011.

http://csrc.nist.gov/publications/nistpubs/800-‐145/SP800-‐145.pdf (accessed May 23,

2014).

Microsoft. "IT Pro Cloud Survey Results." 2011. http://technet.microsoft.com/en-‐

gb/gg710912.

Mitchell, Dave. Defining Platform-‐As-‐A-‐Service,or PaaS. February 18, 2008. http://bungeeconnect.wordpress.com/2008/02/18/defining-‐platform-‐as-‐a-‐service-‐or-‐

paas/ (accessed July 16, 2014).

Murphy, Thomas. "Understanding Current Cloud Market Drivers and Responses." In-‐

formation Processing Management Association. 2014. http://ipma-‐

wa.com/sites/default/files/event/2013/10/SaaS_Gartner.pdf (accessed July 22, 2014).

National Institute of Standards and Technology. „The NIST Defintion of Cloud Compu-‐ting.“ http://faculty.winthrop.edu/domanm/csci411/Handouts/NIST.pdf (accessed 29.

July 2014).

Paoli, Jean. Interoperability Elements of a Cloud Platform Outlined at OSCON. July 22, 2010. http://blogs.msdn.com/b/interoperability/archive/2010/07/22/interoperability-‐

elements-‐of-‐a-‐cloud-‐platform-‐outlined-‐at-‐oscon.aspx (accessed July 22, 2014).

Petcu, Dana, et al. „Experiences in building a mOSAIC of clouds.“ 24. May 2013. http://www.journalofcloudcomputing.com/content/pdf/2192-‐113X-‐2-‐12.pdf (Zugriff

am 11. June 2014).

Platt, Bill. People want PaaS: Nearly 60 percent of companies say they will deploy PaaS

soon. November 29, 2012. http://venturebeat.com/2012/11/29/paas-‐engine-‐yard/

(accessed 06 23, 2014).

Psaty, B, and S Burke. Institute of Medicine recommendations on drug safety. New

England, 2006.

Rak, Massimiliano, Calin Sandru, und Beniamino Di Martino. „Architectural Design of the mOSAIC's API and Platform.“ 29. December 2011. http://developers.mosaic-‐

147


cloud.eu/confluence/download/attachments/2130166/FP7-‐256910-‐D1.1-‐

2.0.pdf?version=1&modificationDate=1325907964000 (accessed 11. June 2014).

Rashidi, Bahman, Mohsen Sharifi, and Jafari Talieh. "A Survey on Interoperability in the

Cloud Computing Environments." Modern Education and Computer Science. July 2013. http://www.mecs-‐press.org/ijmecs/ijmecs-‐v5-‐n6/IJMECS-‐V5-‐N6-‐3.pdf (accessed Mai

2014).

Rogers, Owen. Commoditization brings transformation: cloud economics will drive

change, whoever you are. 08. July 2013. https://451research.com/report-‐short?entityId=77737 (Zugriff am 28. June 2014).

Sambyal, Abhishek Singh, Deepshikha Jamwal, and GS Sambyal. "Cloud Computing: A

growing edge." Proceedings of the International Conference on Upcoming Trends in IT (ICUTIT 2010) Punjab, India. Punjab, 2010.

Satija, Kalpana. Textbook on Economics for Law Students. New Delhi: Universal Law Publishing CO. FVT. LTD., 2009.

Saugatuck Technology. Boundary-‐free Enterprise™: The New Master Architecture. San

Francisco, February 09, 2012.

Schierenbeck, Henner, and Claudia B Wöhle. Grundzüge der Betriebswirtschaftslehre. 18. Munich: Oldenbourg Wissenschaftsverlag, 2012.

Schmidt, Marty. Return on Investment ROI Explained. August 22, 2014.

https://www.business-‐case-‐analysis.com/return-‐on-‐investment.html.

Schmitt, Matthias. "Renditeorientiertes Vertriebscontrolling: Einsatz des Du-‐Pont-‐

Schemas zur modernen Vertriebsteuerung." Haufe. February 2009. https://media.haufe-‐group.com/media/attachmentlibraries/rp/Controlling/Schmitt.pdf.

Schramm, Thomas, Sergio Nogueira, and Derek Jones. Cloud computing and supply

chain: A natural fit for the future. March 14, 2011.

http://www.logisticsmgmt.com/article/cloud_computing_and_supply_chain_a_natura

l_fit_for_the_future/.

Seventh Framework Programme. „A semantically-‐enhanced marketplace of interoper-‐

able Platform-‐as-‐a-‐Service offerings for the deployment and migration of business ap-‐

plications of SMEs.“ 2013.

148


Seventh Framework Programme of the European Community. D1.1 Requirements

Analysis Report. Cloud4SOA, Cloud4SOA, 2011.

Sheth, A, and A, Ranabahu. "Semantic Modeling for Cloud Computing, Part 1." IEEE

Internet Computing, May-‐June 2010: 81-‐83.

Shetty, Sony. Gartner Says Cloud Computing Will Become the Bulk of New IT Spend by

2016. 24. October 2013. http://www.gartner.com/newsroom/id/2613015 (accessed

10. July 2014).

Teckelmann, Ralf, Anthony Sulisto, and Christoph Reich. Cloud Computing -‐ Methodol-‐ogy, Systems and Applications. Edited by Lizhe Wang, Rajic Ranjan, Jinjun Chen and

Boualem Benatallah. Boca Raton: CRC Press, 2012.

The Open Group. The Open Group launches cloud computing guide to help businesses tackle challenge of vendor lock-‐in. June 26, 2013.

http://www.opengroup.org/news/press/open-‐group-‐launches-‐cloud-‐computing-‐guide-‐help-‐businesses-‐tackle-‐challenge-‐vendor-‐lock (accessed June 03, 2014).

TNS Infratest. "Cloud Computing: Usage, Relevance and Satisfaction." Slideshare. April

2012. http://de.slideshare.net/sap/cloud-‐computing-‐usage-‐relevance-‐and-‐satisfaction

(accessed June 11, 2014).

Urquhart, James. Open Cloud Manifesto now signed and delivered. March 29, 2009.

http://www.cnet.com/news/open-‐cloud-‐manifesto-‐now-‐signed-‐and-‐delivered/ (ac-‐

cessed July 14, 2014).

Vagadia, Bharat. Strategic Outsourcing -‐ Management for Professionals. Berlin: Sprin-‐

ger Berlin Heidelberg, 2012.

van der Aalst, Wil M. P. "Eindhoven University of Technology." Congurable Services in the Cloud Supporting Variability While Enabling Cross-‐Organizational Process Mining.

July 29, 2010. http://wwwis.win.tue.nl/~wvdaalst/publications/p607.pdf (accessed

August 04, 2014).

Verginadis, Yiannis, Ioannis Patiniotakis, und Gregoris Mentzas. Broker@Cloud -‐ D20.1

State of the art and research. 1. March 2013. http://www.broker-‐cloud.eu/documents/deliverables/d2-‐1-‐state-‐of-‐the-‐art-‐and-‐research-‐baseline.

Viola, Thiago. Open Cloud Manifesto: Core principles for cloud computing. January 23,

2014. http://thoughtsoncloud.com/2014/01/open-‐cloud-‐manifesto-‐core-‐principles-‐for-‐cloud-‐computing/ (accessed August 01, 2014).

149


Wallraf, Bruno, and Axel Dr. Pols. "Cloud-‐Monitor 2014." KPMG. April 17, 2014.

http://www.kpmg.com/DE/de/Documents/cloudmonitor-‐2014-‐kpmg.pdf (accessed

June 27, 2014).

Wallraf, Bruno, und Axel Dr. Pols. „Cloud-‐Monitor 2014.“ KPMG. 17. April 2014. http://www.kpmg.com/DE/de/Documents/cloudmonitor-‐2014-‐kpmg.pdf (Zugriff am

27. June 2014).

Zeginis, Dimitris, et al. "A USER-‐CENTRIC MULTI-‐PAAS APPLICATION MANAGEMENT

SOLUTION FOR HYBRID MULTI-‐CLOUD SCENARIOS." Scalable Computing: Practices and Experience. March 2013. http://www.scpe.org/index.php/scpe/article/view/825/370

(accessed July 16, 2014).

PaasPort D1 1 v12 · D1.1!–!Requirements!analysis!report!! ... [!AWS!Elastic!Beanstalk! ......

Documents

Transcript of PaasPort D1 1 v12 · D1.1!–!Requirements!analysis!report!! ... [!AWS!Elastic!Beanstalk! ......