Cloud Computing Use Cases. August, 2011

(1)

Cloud Computing Use Cases

(2)

Table of Contents

1. Introduction ... 1-1

1.1

Purpose of this Project ... 1-1

1.2

Process and Participants ... 1-1

1.3

Cloud Computing Basics ... 1-2

1.3.1

Definition... 1-2

1.3.2

Deployment Models ... 1-2

1.3.3

Service Models ... 1-2

1.4

Assumptions and Principles ... 1-3

1.4.1

Interoperability ... 1-3

1.4.2

Portability ... 1-3

1.4.3

Security and Privacy ... 1-3

1.4.4

Standards ... 1-3

1.5

Notes on the Use Cases ... 1-4

1.6

Definitions of Actors ... 1-4

2. Use Cases ... 2-5

P01 Move three-tier application from on-premises to cloud ... 2-5

P02 Move three-tier cloud application to another cloud ... 2-7

P03 Move part of on-premises application to cloud to create “hybrid” application ... 2-9

P04 Hybrid application with shared user ID and access services ... 2-11

P05 Move hybrid application to another cloud with common infrastructures ... 2-13

P06 Hybrid cloud application that uses platform services ... 2-15

P07 Port cloud application that uses platform services to another cloud ... 2-17

P08 Create cloud application with components that run on multiple clouds ... 2-19

P09 Cloud application workload requires use of multiple clouds (cloudburst) ... 2-21

P10 Users can “shop around” for cloud services ... 2-23

A. Appendix of Technical Notes ... A-24

A.1

On the Transparency of Standards Implementations ... A-24

A.2

On Portability in the Cloud ... A-24

A.3

On Data Portability in the Cloud ... A-25

A.4

On Switching Costs ... A-26

A5.

Common, Recurring Technologies and Requirements among the Use Cases... A-27

(3)

1.

Introduction

1.1 Purpose of this Project

This white paper describes ten of the most common cloud computing use cases from a practical,

objective point of view based on customer experience.

The purpose is to provide a practical context to help architects, product designers, and policy

makers to understand evolving needs as customers move to cloud computing, and to identify the

technical capabilities and degree of standardization required across cloud environments to meet

those needs.

By “meeting those needs,” we mean not only to meet agreed SLAs, but also to provide the

interoperability

,

portability

, and

security

which the National Institute of Standards and

Technology (NIST) has identified as the “important cloud computing requirements.” These three

requirements are one of the lenses through which we view the use cases, and one of the main

threads in our discussion of them.

1.2 Process and Participants

Microsoft participates in a number of cloud use-case definition, analysis, and discussion efforts,

including the Distributed Management Task Force (DMTF) cloud working group; NIST cloud

roundtables; the ISO JTC-1, subcommittee 38 on cloud computing; and the German Public Sector

engagement with Fraunhofer FOKUS.

For a deeper and broader grounding in customer experience, Microsoft developed these use

cases and reviewed the white paper

with the assistance of the Interoperability Executive

Customer (IEC) Council as a research study in cloud computing. We are

publishing the study to

the standards community at large and NIST in particular to promote further discussion.

Microsoft established the IEC Council in June 2006 as a means of regularly interacting with

customers to solve their technology interoperability challenges. The council includes CIO-level

executives from over 40 governments and corporations representing a cross-section of

industries. Microsoft executives meet twice a year with the Council to discuss interoperability

issues, and throughout the year technical and business working groups spanning the member

organizations drill down on interoperability details.

The Council focuses on seven “work streams”: Office Productivity and Collaboration Tools;

Identity Management; Business Process Modeling and Services Oriented Architecture; Systems

Management; Developer Tools and Runtime; Public Interoperability Policy; and Cloud

Computing. This paper was developed as part of the Cloud Computing work stream with input

and feedback from many IEC Council members.

(4)

1.3 Cloud Computing Basics

1.3.1 Definition

NIST defines cloud computing as “a model for enabling 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.”

1

Computing, at its core, is processing data. The key change in cloud computing is that the location

of where data is processed moves, at least partially, from on-premises datacenters to the cloud.

The cloud centralizes data processing while providing on-demand delivery of data and services to

anywhere, similar to the way electricity is produced and distributed, and with a similar increase

in efficiency and cost-effectiveness. Centralizing computing in the cloud, however, does mean

that data processing is removed from the direct control and visibility of users. That gives rise to

concerns around the issues of interoperability, portability, and security. To help frame these

issues, this document provides diagrams, descriptions and discussions of ten common use cases.

NIST also defines three cloud computing service models and four deployment models.

1.3.2 Deployment Models

The deployment models – private cloud, community cloud, public cloud, and hybrid cloud – are

generally orthogonal to interoperability, portability, and security requirements and standards.

These requirements and the standards that help us meet them apply equally across all cloud

variations; whether an organization is moving an application from one public cloud to another, or

from a private cloud to a hybrid cloud, the operations and requirements are essentially the same.

In fact, it’s important to

ensure

that moving from one cloud variation to another is essentially the

same in order to preserve portability and all its benefits.

1.3.3 Service Models

The service models that NIST defines are important details in these use cases. They are:

•

Software as a Service (SaaS).

The consumer uses the provider’s applications over a network.

•

Plaform as a Service (PaaS).

The consumer deploys customer-created cloud applications onto

the cloud platform.

•

Infrastructure as a Service (IaaS).

The consumer “rents” processing, storage, network

capacity, and other fundamental computing resources provided in the cloud. The consumer

does not manage or control the underlying cloud infrastructure but supplies and controls the

choice of operating systems, application runtime, storage, deployed applications, and

possibly limited control of select networking components (e.g., host firewalls).

This document focuses on use cases for IaaS and PaaS cloud services.

(5)

1.4 Assumptions and Principles

Microsoft and the IEC Council are in accord with the “important cloud computing requirements”

that NIST has identified, and these requirements have served as basic assumptions and guiding

principles in the development of these use cases. These requirements are:

1.4.1 Interoperability

Clouds should work together.

Cloud platforms should enable developer choice in tools,

languages, and runtimes, and should accommodate the naturally occurring range of applications

while accounting for interoperability with the use of well documented protocol specifications, file

formats, and other forms of data exchange.

1.4.2 Portability

Workloads and data need to be able to move around.

Cloud platforms should make it easy and

efficient to securely move customer applications on and off, and data in and out, of their

infrastructure. There should be a secure migration path to cloud computing that preserves

existing investments in technologies which are appropriate to the cloud, and that enables the

co-existence and interoperability of on-premises software and cloud services. In particular,

members of the IEC Council have consistently emphasized data portability as a key requirement

to prevent vendor lock-in and to preserve the agility and flexibility of computing in the cloud.

1.4.3 Security and Privacy

Customer workloads are protected to the extent possible.

One of Microsoft’s core principles is

that customers own their data. This means they must have choice over how cloud service

providers use and disclose their personal information. Of course, the confidentiality, integrity,

and availability of data must be ensured. In addition, customers must be able to truly exercise

choice over how their information is used, and in the cloud they can do so in a meaningful way

only if clearly informed about how their information

is

used.

1.4.4 Standards

Whenever possible, the industry should use existing cloud specifications and standards that

are known to work for critical use cases; that can be easily used by cloud service providers and

consumers; and that are extensible, to provide a basis for innovation.

Leveraging existing and

commonly used standards where possible and developing new standards only when needed is

the most efficient way to accelerate the development of a cloud computing environment that

will meet the needs of the broadest possible range of cloud consumers and providers. This

approach is critical to meeting the three requirements already discussed, i.e., interoperability,

portability, and security.

For more detail on standards and the need for transparency in cloud providers’ implementations

of standards, see A.1, “On Transparency of Standards Implementations.”

(6)

1.5

Notes on the Use Cases

The use cases described in this paper are

platform-centric

for the lifecycle of a cloud application;

in other words, in each case we consider the requirements for building, porting, and maintaining

cloud applications on top of an IaaS or PaaS cloud platform. Future research will be needed in

order to identify and develop

SaaS-centric

cloud computing use cases.

Each use case except the last one includes a diagram to illustrate the action; technical detail in

the right-hand table; and a discussion of some important aspects and implications of the use case

in the left-hand column. In the technical tables, you’ll see capital letters in parentheses – (A), (B),

(C). These letters represent recurring, common elements and correspond with lettered

descriptions of the elements that you’ll find in the final section of this paper, “Common,

Recurring Technologies and Requirements among the Use Cases.”

In general, the use cases are arranged by complexity, beginning with simpler, more basic

deployments and from there increasing in cumulative complexity. This “walk before you run”

order reflects a typical migration pattern for cloud consumers, who naturally start simple and

work up to more challenging use cases as they gain experience and confidence.

Because each use case is built on the preceding use cases, we do not provide redundant

information for each one but rather refer back, in the “Technology elements in common with

other use cases” section of each technical table, to pre-requisites that have already been

discussed.

1.6 Definitions of Actors

This document refers to the following “actors” or players:

•

Cloud service providers:

Public cloud vendors offering cloud services (e.g., Amazon, Google,

Microsoft); hosters offering hosted applications running in cloud environments in any

deployment model; teams supporting cloud platforms for internal or private use; or SaaS

cloud vendors offering finished, hosted software running in their cloud-based data centers.

•

Cloud application developers:

Independent software developers developing or porting

applications for cloud platforms and environments (includes IaaS/PaaS/SaaS clouds).

•

Cloud operators/management:

People in charge of operating, managing, and maintaining

cloud applications.

•

Cloud users/consumers:

Also referred to as “end users.”

•

Cloud identity providers:

Cloud services offering federated identity and access control

services.

•

Cloud procurement officers:

People in charge of cloud services procurement.

•

Cloud broker services:

Cloud services offering placement and consumer/provider

(7)

2.

Use Cases

P01 Move three-tier application from on-premises to cloud

Diagram

Description

Technical Details and Analysis

An organization moves a three-tier application from an on-premises datacenter to a cloud infrastructure provider that will run the application off-premises.

A three-tier application consists of the front-end web server, back-front-end database, and middle-tier business logic that services data requests between the user and the database. Actors involved in this use case include: cloud service providers, software developers, system administrators/operators.

Discussion

This use case is listed first because it represents the most common type of web-based application deployed both in enterprises and mid-sized companies. Thus, the three-tier app is often an entry-level point for larger organizations to learn how to migrate gradually from the traditional client/server, web-based model to cloud computing.

On the other hand, new small and medium-sized businesses (SMBs) may build and run their entire company on a cloud platform

Technology elements in common with other use cases 1.Requires cloud “appliance” packaging file format support:

a.Package multiple VMs, one per application tier, in one or more “appliance” files. (A)

b.Each VM image contains the respective initialization data, application user account data for ID/access, database if applicable. 2.May require upload/import of bulk user data to the cloud over the

network or by sending a disk with agreed-to data packaging. (C) 3.May require access to separate identity/authentication/ authorization

system if using federation.

a.To protect the privacy of cloud users, cloud identity providers should not be able to track and trace user identity and access patterns. The user should not have to provide more information than the minimum necessary to be granted access. (L, M)

4.Requires cloud-based VM management/control for lifetime

management of each application tier running as one or more VMs. (B) 5.Virtual LAN/networking support for managing application’s IP address

space. (J)

Software layers the use case is in (IaaS/VM layer, PaaS layer, etc.) IaaS for machine execution; platform services for data, identity and access are considered available for source and target clouds but not addressed in this case.

Platform, tools and environment needed for execution of use case A hypervisor-based IaaS cloud with support for VMs and appliance file format. VM management tool is needed to monitor the VMs in each cloud.

File formats, wire protocols, in-memory objects, and other artifacts needed for execution

A virtual cloud appliance file format is needed, as well as a VM management protocol with basic CRUD support for VMs.

(8)

rather than building their own datacenters at huge cost. Many new Web 3.0 businesses (such as social gaming companies) would not exist without the cloud.

For a discussion of some of the technical issues involved in portability in the cloud, see A.2, “On Portability in the Cloud.”

Components and services needed for execution

Hypervisor, cloud fabric controller, database, identity/access control service, web server

Input parameters needed for initialization

Web-based, three-tier enterprise application needs to be executing on-premises

Related and pre-requisite use cases None

Existing specifications that are known to work Hypervisor standards for appliance image file format New specifications required

1.VM portability: Create portable appliances from existing on-premises apps and move them to the cloud

2.Bulk import/export of customer data 3.VM management protocol

(9)

P02 Move three-tier cloud application to another cloud

Diagram

Description

An organization moves a three-tier application from one cloud infrastructure provider to another.

Actors involved in this use case include: cloud service providers, software developers, system administrators/operators.

Discussion

This use case is the same as P01 except the application is being moved from one cloud service provider to another, rather than an on-premises datacenter to the cloud. As in P01, the ability to move and then run the app in the cloud as a runtime copy of the original, together with the bulk data, requires APIs, specifications, templates, or standards that enable portability of VMs in and out of the cloud; importing and exporting of data; and VM lifecycle management (or, more precisely in this case, cloud service lifecycle

management).

The Open Cloud Standards Incubator of the DMTF defines the lifecycle of a cloud service to include the following stages:

•

Description of cloud service in a template

•

Deployment of cloud service into a cloud

•

Offering of the service to consumers

Technology elements in common with other use cases

1.Requires VM portability: Create portable appliances from existing VMs in source cloud, then move to 2nd cloud. (A)

2.Connections to inside-firewall systems (e.g., VPNs) or outside systems (e.g., identity federation servers) need to be easily reconfigurable/ reusable.

3.Requires bulk import/export of customer data as in use case P02. (C) 4.Requires VM management. (B)

5.Customer may require “erase” delete of the application on the old cloud.

6.Regardless of the choice of programming language, runtime and tools used to develop the original on-premises application, the cloud service should be available on-premises as a private cloud or offered by a third party as a hosted cloud if the customer chooses not to deploy to the public cloud. (K)

Software layers the use case is in (IaaS/VM layer, PaaS layer, etc.) IaaS for machine execution; platform services for data, identity and access are considered available for source and target clouds but not addressed in this case.

Platform, tools and environment needed for execution of use case Two separate hypervisor-based IaaS clouds with support for VMs and appliance file format. VM management tool is needed to monitor the VMs in each cloud.

A virtual cloud appliance file format is needed, as well as a VM management protocol with basic CRUD support for VMs. Components and services needed for execution

Hypervisor, cloud fabric controller, database, identity/access control service, web server.

Three-tier IaaS cloud application needs to be executing in the original cloud.

(10)

•

Consumer entrance into contracts for the offering

•

Provider operation and management of instances of the service

•

Removal of the service offering1

These stages of the cloud service lifecycle are areas where standardization is evolving. Hence, cloud provider transparency on each

of these areas is key to maintaining the portability that’s (obviously) required to switch from one cloud to another. For a discussion of the technical specifics of moving data in and out of the cloud, see A.3, “On Data Portability in the Cloud.”

For a discussion of inputs and variables that factor into the costs of switching cloud providers or platforms, see A.4, “On Switching Costs.”

1

Distributed Management Task Force, “Interoperable Clouds,” a white paper from the Open Cloud Standards Incubator, November 2009.

Related and pre-requisite use cases P01

Existing specifications that are known to work Hypervisor standards for appliance image file format New specifications required

1.VM portability: Create portable appliances from existing VMs in the source cloud, and move them to the 2nd one. (A)

(11)

P03

Move part of on-premises application to cloud to create “hybrid” application

Diagram

Description

An organization moves one or more parts – or tiers – of an on-premises application to the cloud, in order to separate data storage from processing, for example. This creates a cloud that is a hybrid of both public (off-premises) and private (on-premises) clouds.

Discussion

A hybrid cloud combines the security and customization of traditional IT infrastructure, comprised of dedicated server hardware, with the flex, scale, and cost-effectiveness of public or private cloud infrastructure.

Says Gartner: “Data growth is the biggest data center hardware infrastructure challenge for large enterprises.”1 Because renting cloud storage costs far less than building datacenters, a common hybrid application that’s emerged is cloud data storage combined with on-premises processing. Live application data may be stored in the cloud

1

http://www.computerworld.com/s/article/9194283/Data_growth_remains_IT_s_biggest_challenge_Gartner_says Technology elements in common with other use cases

1.Requires VM management, appliance packaging, bulk import/export, as in the above scenarios. (A, B, C)

2.Also requires runtime web interfaces for the on-premises and cloud components to interact/exchange/sync data with interoperability primitives such as file/object sync/invocation. (D)

3.Will likely require cloud storage for caching intermediate results (simple cloud storage APIs/semantics). (D)

4.Regardless of choice of programming language, runtime and tools used to develop the original on-premises application, the cloud service should be offered by a third party as a hosted cloud if the customer chooses not to deploy to the provider’s public cloud. (K)

Software layers the use case is in (IaaS/VM layer, PaaS layer, etc.) IaaS for machine execution; platform services for data, identity and access are considered available for target clouds.

Platform, tools and environment needed for execution of use case Hypervisor-based IaaS cloud with support for VMs and appliance file format. VM management tool needed. Interoperable web-based communication and messaging layers on-premises and in the cloud. File formats, wire protocols, in-memory objects, and other artifacts needed for execution

A virtual cloud appliance file format is needed, as well as a VM management protocol with basic CRUD support for VMs. Web-based protocols for on-premises and cloud components to interact/exchange/ sync data with interoperability primitives such as file/object

(12)

for cloudburst scenarios, or on-premises data may be replicated to a public storage cloud for archiving and backup, or to implement storage tiering that uses lower-cost tiers for publicly-accessible data.

The additional complexity involved in hybrid vs. pure-play clouds requires that

management across hybrid resources be simplified and optimized. System

configuration, performance management, and capacity management must span the hybrid cloud or service; otherwise, on-premises components may fail to communicate properly with cloud components, or the data access latency may become a problem. Many cloud service providers offer rules-based solutions to simplify hybrid management; this is a start toward standardized management

methodologies that allow customers to deploy and manage their services across a range of evolving hybrid environments.

Hypervisor, cloud fabric controller, database, identity/access control service, web server. Web-based middleware (app server) may be desirable but is not essential.

Web-based, three-tier enterprise application needs to be executing on-premises, with proper componentization.

Existing specifications that are known to work

Hypervisor standards for appliance image file format; runtime web interfaces for on-premises and cloud components to interact/exchange/ sync data with interoperability primitives such as file/object

sync/invocation.

New specifications required

1.VM portability: Create portable appliances from existing on-premises applications and move them to the cloud

2.Bulk import/export of customer data

(13)

P04

Hybrid application with shared user ID and access services

Diagram

Description

This use case is the same as P03 with the added condition that user ID and access are shared between on-premises and cloud components. This requires a common user ID and access control methodology between components based on either on-premises directory access or identity federation. Actors involved in this use case include: cloud service providers, software developers, system administrators/operators, cloud identity providers.

Discussion

Each application or information source has its own access control mechanisms. Federated identity and single sign-on use an

authentication service to vouch that a user with a particular role should be allowed access to a given resource, even if the system controlling that resource has no knowledge of that user. Federated identity enables

information about users in one security domain to be provided to other organizations

1.Hybrid cloud application, deployed partially on-premises and partially on one or more hosted/public cloud(s), uses federated identity and access mechanisms shared among cloud(s) as well as on-premises. a.Support for federated identity and access management is

standards-based and standards-neutral. (Examples: WS-Trust, SAML, OpenID) b.Utilizes federated identity and access management: certificate-based

authorization such as a directory-based cert-authority or Security Token Service (STS)-based authorization.

c.Users can use both enterprise IDs as well as cloud IDs such as those issued by Yahoo, Google or Microsoft LiveID.

d.To protect users’ privacy, cloud identity providers should not be able to track and trace the user’s identity and access patterns. Users should not have to provide more information than the minimum necessary to be granted access. (L, M)

5.This use case applies equally to pure, non-hybrid cloud applications Software layers the use case is in (IaaS/VM layer, PaaS layer, etc.) IaaS for machine execution; platform services for data, identity and access (directory-based or federated) are needed between on-premises and cloud components.

Platform, tools and environment needed for execution of use case Hypervisor-based IaaS cloud with support for VMs and appliance file format. VM management tool needed. Interoperable web-based communication and messaging layers on-premises and in the cloud. Federated or on-premises identity/access platform services required.

(14)

in a federation. This allows for cross-domain single sign-on (SSO) and eliminates the need for content and service providers to maintain user names and passwords. Cloud identity providers (sometimes shortened to “IdPs”) use a standard browser SSO methodology to authenticate cloud users prior to their authorization to access any cloud services. Security Assertion Markup Language (SAML) is the foundation for emerging federated identity-based authentication and

authorization architectures. SAML is an XML-based open standard for exchanging authentication and authorization data between security domains – i.e., between an identity provider and a service provider. SAML exists in different versions, however, which are supported by different cloud providers. This can create problems of integration complexity in hybrid situations. By using multiprotocol federation gateways, cloud identity providers can hide this complexity from cloud consumers. In addition to authentication and authorization, organizations must also

manage the lifecycle of identities themselves, using their Identity and Access Management (IAM) systems and communicating any changes to the cloud identity provider.

A virtual cloud appliance file format is needed, as well as a VM management protocol with basic CRUD support for VMs. Web-based protocols for on-premises and cloud components to interact/ exchange/sync data with interoperability primitives such as file/object sync/invocation (also needed to offer identity and access services). Components and services needed for execution

Three-tier IaaS cloud application needs to be executing in the original cloud, with proper componentization. User ID data may be needed to initialize cloud-based identity service.

Related and pre-requisite use cases P01, P03

Hypervisor standards for appliance image file format; runtime web interfaces for on-premises and cloud components to interact/exchange/ sync data with interoperability primitives such as file/object sync/ invocation. Directory access protocol such as LDAP, or SAML or OpenID. Security Token Service standards.

(15)

P05

Move hybrid application to another cloud with common infrastructures

Diagram

Description

An organization moves the cloud portions of a hybrid application from cloud A to cloud B, both of which support common

infrastructures and VM packages.

Discussion

The complexity ratchets up another level with this use case. Now, in addition to managing applications on-premises, in the cloud, and across hybrid environments, organizations will also face the challenge of managing

relationships and operations across multiple clouds. While such a scenario offers maximum flexibility, it also creates a cloud environment with different management, security, networking, and pricing models, as well as multiple sets of APIs, templates, and supported standards.

An application encapsulated in a VM can move freely (in theory) between systems either dynamically or via offline file transfer.

2.Also requires runtime web interfaces for on-premises and cloud components to interact/exchange/sync data with interoperability primitives such as file/object sync/invocation. (D)

3.Will likely require cloud storage for caching intermediate results (simple cloud storage APIs/semantics). (D)

4.Regardless of the choice of programming language, runtime, and tools used to develop the application, the cloud service should be offered by a third party as a hosted cloud if the customer chooses not to deploy to the provider’s public cloud. (K)

5.Platform neutral data access formats, e.g. OData. (E)

Software layers the use case is in (IaaS/VM layer, PaaS layer, etc.) IaaS for machine execution; platform services for data, identity and access are considered available in the target cloud.

Platform, tools and environment needed for execution of use case Hypervisor-based IaaS cloud with support for VMs and appliance file format. VM management tool needed. Interoperable web-based communication and messaging layers on-premises and in the cloud. File formats, wire protocols, in-memory objects, and other artifacts needed for execution

A virtual cloud appliance file format is needed, as well as a VM management protocol with basic CRUD support for VMs. Web-based protocols for on-premises and cloud components to interact/exchange/ sync data with interoperability primitives such as file/object sync/ invocation.

(16)

But elements such as networking and security may not be identical among all the

environments. This can cause interoperability problems and failure conditions; e.g.,

variations in bandwidth and latency may affect performance. It also shines a spotlight on “right to be forgotten” issues around data deletion from previous clouds.

Cloud companies are working on ways to solve these challenges. Many now offer integrated stacks for IaaS cloud service providers that integrate virtualization, networking, computing, storage, security, and management in a single infrastructure platform. Another method is to use interfaces with common semantics for data, identity, and access control.

Three-tier , IaaS hybrid cloud application needs to be executing in the original cloud, with proper componentization.

Hypervisor standards for appliance image file format; runtime web interfaces for on-premises and cloud components to interact/exchange/ sync data with interoperability primitives such as file/object sync/ invocation.

(17)

P06

Hybrid cloud application that uses platform services

Diagram

Description

This use case is similar to P03 except the cloud application developer in this case chooses to implement cloud components of a hybrid application using platform services available from the cloud platform provider, such as structured or unstructured cloud storage or identity and access control services.

Discussion

What’s additive to the P03 use case here is the use of some platform services (in a hybrid app), or possibly the full PaaS offering (in a pure PaaS app), in addition to IaaS which has been the main cloud layer for the first five use cases we’ve considered.

PaaS providers offer a computing platform and/or solution stack as a service on which to develop applications/services. Organizations no longer have to invest millions in software

_____

1

e.g., as offered by Simple Cloud Storage APIs for PHP

2

e.g., the descriptive capabilities offered by the NIST SCAPs program.

1.User accounts, databases, data stores and bulk data would have to be transferred from equivalent on-premises capabilities. (I)

2.Requires porting code for use of new cloud services. Cost of porting on-premises application is lowered when application logic is written to semantic interfaces that stay valid when the application logic is ported to a new cloud. (H)

a.ID/Access: Runtime web interfaces to deal with federated user identity/access and security (F) would cut porting costs.

b.Data: Common semantics for data structures and interfaces/APIs1. (H)

3.If cloud A or B is IaaS-style, appliance packaging would benefit from identifying the various platforms, runtimes and languages required in widely understood semantics and taxonomies2.

4.Developer choice for tools, languages, and runtimes/ frameworks will offer flexibility, promote competition in richness of capabilities, and reduce porting costs. (G)

5.Regardless of choice of programming language, runtime, and tools used to develop the application, the cloud service should be available on-premises as a private cloud or offered by a third party as a hosted cloud if the customer chooses not to deploy the cloud components to the public cloud. (K)

Software layers the use case is in (IaaS/VM layer, PaaS layer, etc.) PaaS services – e.g., structured/unstructured cloud storage and identity/access interfaces/APIs – are available from cloud vendor. Platform, tools and environment needed for execution of use case PaaS cloud application management tool needed. Interoperable web-based communication and messaging layers on-premises and in the cloud.

(18)

platforms to build apps. Just as traditional operating systems such as Windows and Linux have done in the past for software

developers, PaaS provides a foundation on which to build web-based applications and the operational capability of cloud platform hosting.

Key PaaS capabilities include:

• Services to develop, test, deploy, host, and maintain applications in the same

integrated development environment • Web-based user interface creation tools • Multi-tenant architecture

• Integration with web services and databases

• Utility-grade instrumentation that can give developers clearer visibility into the operations of their services and

applications, and greater insight into the behavior of their users, while offering scale-up and scale-out capability elastically, through large-scale deployment of public clouds.

Given the PaaS value proposition, upon successful completion of the use case, the hybrid app should run as well as or better than the original on-premises app. The ported components in the cloud should perform better than their on-premises version, and should be more featureful and scalable.

Web-based protocols for on-premises and cloud components to interact/exchange/sync data with interoperability primitives such as file/object sync/invocation (e.g., RESTful protocols).

Cloud fabric controller, database, identity/access control service, web server. Web-based middleware (app server) may be desirable but is not essential.

Web-based, three-tier enterprise application needs to be executing on-premises, with proper componentization. Some components should benefit from available cloud platform services when rewritten for the target cloud.

Runtime web interfaces for on-premises and cloud components to interact/exchange/sync data with interoperability primitives such as file/object sync/invocation.

1.Bulk import/export of customer data.

(19)

P07

Port cloud application that uses platform services to another cloud

Diagram

Description

Porting an application that uses services provided by the cloud platform to another cloud platform implies the same requirements as for P06.

Discussion

As in all instances of porting to or from a cloud, a key to a successful outcome is standards-based interoperability. In this case, interoperability across both IaaS and PaaS layers enables organizations to integrate apps rapidly with any platform and with any infrastructure across their environment, on-premises or in the cloud. And that is essential for realizing the full agility, flexibility, and cost-savings benefits of the cloud. Technical interoperability is also essential (although not sufficient by itself) to avoid lock-in to a cloud provider or IT system. It not only helps to enable portability, it also makes it easier by reducing switching costs when

interoperable interfaces are used (often with semantically similar REST-based interfaces).

1.Developer choice for tools, languages, runtimes, storage, database and other infrastructure services should be supported at both IaaS (VM) level as well as PaaS (platform level) to ensure richness of cloud platform offerings and promote innovation. (G)

2.Use of semantic APIs and protocols would allow for the application logic/algorithm to be similar, allowing similar underlying pseudo code. This will help cut porting costs.

3.The application’s use of storage (structured or unstructured) could often be costly to port. However:

a.For non-structured storage (blobs, queues, tables, etc.) using simple, semantically similar cloud storage APIs would cut porting costs since algorithm/pseudo code would be similar.

b.For structured storage, costs of porting code based on SQL data access interfaces are often similar regardless of runtime or language used.

4.Regardless of choices made in 1, the new cloud service should be available on-premises as a private cloud or offered by third-party as hosted cloud if customer opts not to deploy to public cloud. (K) Software layers the use case is in (IaaS/VM layer, PaaS layer, etc.) PaaS services – e.g., structured/unstructured cloud storage and identity/access interfaces/APIs – are available from cloud vendor. Platform, tools and environment needed for execution of use case PaaS cloud application management tool needed. Interoperable Web-based communication and messaging layers on-premises and in the cloud. Support for language, runtime and tools necessary to build cloud

(20)

There are cost savings in that one interop-erable service can be substituted for another to take advantage of lower prices. Another way interoperability cuts switching costs is by ensuring orderly transitions between systems, reducing risk as well as cost.

There are pure-play PaaS providers, and there are providers of other cloud services that are extending into the space, such as Amazon moving up the stack from its IaaS services. Some PaaS providers completely abstract the platform services from the nitty-gritty app details, allowing developers to push apps just as they push on-premises apps into a Git repository (a distributed revision control system), and the platform handles all the rest. These platforms, however, are often focused on one language and impose restrictions on developers.

Other providers support multiple languages and application runtime environments and middleware, and may enable developers to assert control over aspects of their application and to tune a range of parameters.

Web-based protocols for on-premises and cloud components to interact/exchange/sync data with interoperability primitives such as file/object sync/invocation (e.g., RESTful protocols). Use of semantic interfaces and APIs for these primitives would make porting the cloud components to the “burst-into” cloud less costly.

Hybrid cloud application needs to be executing in the source cloud, with proper componentization.

1.Bulk import/export of customer data

2.Semantic cloud application management protocol

3.Non-structured storage (blobs, queues, tables, etc.) – use of simple, semantically similar cloud storage APIs would cut porting costs since underlying algorithm/pseudo code would be similar.

(21)

P08

Create cloud application with components that run on multiple clouds

Diagram

Description

An organization chooses to develop a cloud application with components that run on multiple clouds simultaneously.

Discussion

An example of this use case is a compute cloud node that uses services of a storage cloud service provider at run time to store/access data, and, say, a third-party cloud service provider to obtain weather, market, and news streams or vertical, application-specific data. (By the way, what we just described in that sentence is, essentially, a mashup.)

A mashup is a web page or application that combines data or functionality from two or more external sources to create a new service. It can be as simple as two columns of data side by side, or as extensive as VanGuide, Vancouver, Canada’s web-based and mobile social mapping portal created using the Open Government Data Initiative (OGDI)

framework. OGDI enables developers to take

2.Runtime web interfaces to deal with federated user identity/access and security are required to establish a common trust model across the distributed application. (F)

3.May require message interoperability to synch cross-cloud applications. 4.Data Interoperability primitives such as file/object sync/invocation,

simple cloud storage APIs/semantics, etc. (D)

5.May require structured data services if compute nodes in one cloud need to access such services from another cloud (e.g., a database in a storage cloud.)

6.Use semantic interfaces to develop the application and require Cloud A and B to support them. Cost of porting application from one

language/runtime is lowered when application logic is written to semantic interfaces. (H)

7.User accounts, databases, data stores and bulk data would have to be ported. Existing on-premises portability principles can be applied. (I) 8.Developer choice for tools, languages, frameworks will reduce porting

costs. (G)

9.Regardless of the choices made in 5, the cloud services should be available on-premises as a private cloud or offered by a third party as a hosted cloud if the customer chooses not to deploy some or all of the components to the public cloud. (K)

Software layers the use case is in (IaaS/VM layer, PaaS layer, etc.) PaaS services need to be available from multiple cloud vendors; examples are structured or unstructured cloud storage and identity and access service interfaces/APIs. IaaS environments may also be used depending on the choice of architecture and presence of legacy SOA code.

(22)

data sets and create service and information mashups. VanGuide maps Vancouver’s libraries, schools, bus stops, landmarks, etc., in an interactive app to which citizens can add their own comments, tweets, and links.

Creating new value fast by combining things that already exist is the power of mashups. Today, this is where much of the action is in service innovation. When we discuss the cloud we tend to use definitions such as NIST’s (you’ll find it in the introduction). But the cloud is part of something bigger: a digital environment where the web, virtualization, mobility (in 2010, there were 5.3 billion mobile phone

subscriptions), and liberated data are

converging into powerful new mashups of their own. On one hand, the cloud complexities we’ve discussed are challenging. On the other, the many cloud varieties and options are opportunities for exciting mashups of functionality and content.

Platform, tools and environment needed for execution of use case PaaS cloud application management tool needed. Interoperable Web-based communication and messaging layers on-premises (in case the application includes on-premises components) and in the cloud. Support for language, runtime, and tools necessary to build cloud components. File formats, wire protocols, in-memory objects, and other artifacts needed for execution

Web-based protocols for on-premises and cloud components to interact/exchange/sync data with interoperability primitives such as file/object sync/invocation (e.g., RESTful protocols). Use of semantic interfaces and APIs for these primitives would make the interoperability of the cloud components running across multiple clouds easier and less costly.

Distributed application architecture and blue print. Component design for on-premises (if any) and cloud –based components. Interoperability technologies used between various components executing on-premises and in multiple clouds.

3.Non-structured storage (blobs, queues, tables, etc.) use of simple and semantically similar cloud storage APIs would help reduce the cost of the port since the underlying algorithm/pseudo code would be similar. 4.Protocols for federated identity and access service.

(23)

P09

Cloud application workload requires use of multiple clouds (cloudburst)

Diagram

Description

Sometimes referred to as a cloudburst scenario, the application normally running on-premises or in a private cloud needs to elastically run on other clouds in the cases of short-term, significant increase in user demand load. Cloud tenants can use both their own private clouds as well as hosted/public clouds as the workload may require. VMs and applications can migrate between private cloud and public/hosted clouds and can seamlessly be managed from either side regardless of their location. Actors involved in this use case include: cloud service providers, software developers, system administrators/operators.

Discussion

The ability to massively scale up computing resources at a moment’s notice is one of the main attractions of the cloud.

Traffic spikes happen. They can be planned or unplanned but, in either case, customers usually end up waiting – unhappily. Industries such as pharmaceuticals, medical science, financial services, media, microchip and aerospace design, animation, and oil and gas exploration use grid computing to analyze

Technology elements in common with other use cases 1.Same requirements as in P06.

2.Developer choice for tools, languages, runtimes, storage, database and other infrastructure services should be supported at both IaaS (VM) level as well as PaaS (platform level) to ensure richness of the cloud platform offerings and promote innovation. (G)

3.Use of semantic APIs and protocols would allow for application logic/algorithm to be similar, allowing similar underlying pseudo code. This will help cut porting costs to the burst-into cloud(s), if necessary. 4.The application’s use of storage (structured or unstructured) could

often be costly to port. However:

a)For non-structured storage (blobs, queues, tables…) use of simple and semantically similar cloud storage APIs would reduce porting costs since underlying algorithm/pseudo code would be similar. b)For structured storage, the cost of porting code based on the SQL

data access interfaces is often similar regardless of the runtime or language used.

5.Regardless of choices made in 2, the cloud services should be offered by a third party as a hosted cloud if the customer chooses not to deploy/burst into the public cloud. (K)

Software layers the use case is in (IaaS/VM layer, PaaS layer, etc.) PaaS services – e.g., structured/unstructured cloud storage and identity/access interfaces/APIs – are available from cloud vendor. Platform, tools and environment needed for execution of use case PaaS cloud application management tool needed to manage the cloud burst when it occurs. The application instances running in the “burst-into” destination clouds ideally need to be managed with the same tools and infrastructure that were used to manage the apps running in the cloud(s) during normal operation. Interoperable Web-based communication and messaging layers on-premises and in the cloud. Support for language, runtime and tools necessary to build cloud components.

(24)

massive batches of data in extremely compute-intensive applications. No matter how big and expensive the on-premises datacenter, it may not be enough to handle such peak loads, and so other projects sit idly in queue. The cloud offers the difference between having 100 servers working for 10 hours or 1,000 working for one hour – or, in an extreme cloudburst scenario, 1 million working for 16-2/3 seconds. Unplanned spikes are worse, of course, because you’re blindsided. However, by the time you’ve progressed through the previous use cases to this one (in whatever order suits your

organization’s needs), you should have solved any technical issues in moving apps to and running apps in the cloud. Thus, you’ll have ready at a moment’s notice a rapid onramp to on-demand compute capacity.

Web-based protocols for on-premises and cloud components to interact/exchange/sync data with interoperability primitives such as file/object sync/invocation (e.g., RESTful protocols). Use of semantic interfaces and APIs for these primitives would make porting the cloud components to the “burst-into” cloud less costly.

Cloud application needs to be executing in the source cloud, with proper componentization.

3.Non-structured storage (blobs, queues, tables, etc.) use of simple and semantically similar cloud storage APIs would help reduce the cost of the port since the underlying algorithm/pseudo code would be similar. 5.Protocols for federated identity and access service.

(25)

P10

Users can “shop around” for cloud services

Description

Users and developers shop across hosted or public cloud offerings for best price/ performance ratio, while optimizing against other considerations and Service Level Agreements (SLAs).

Actors involved in this use case include: procurement officers, cloud broker services, cloud service providers, software developers, system administrators/operators.

Discussion

“Shopping around” requires accurate assessments of the costs and risks involved in achieving the desired value. Providers should provide transparent quantification of all costs. Negotiated SLAs for which the cloud service provider is legally accountable can help to mitigate the risk of poorly performing services that lose business. An SLA, which defines the interaction between a cloud service provider and consumer, contains among other things: • A set of services the provider will deliver,

along with a complete, specific definition of each

• The responsibilities of the provider and the consumer

• A set of metrics to determine whether the provider is delivering the service as promised

Organizations need to review the SLA schema to ensure all relevant information is

represented. Ensure that the SLA specification contains all fields and properties needed to accurately and fairly represent all

characteristics of the cloud services being offered. Examine individual SLA data files to ensure proper data-entry and submission by the SLA authors/service providers. Examine the SLA viewing/analyzing tool used by the procurement officers to rule out tool processing error.

Problems in assessing vendors may relate to

the SLA schema not being designed well to match the success criteria. The tools procurement officers use to view/compare/ analyze the SLA instances may fail to properly analyze and compare the respective cloud services offerings, leading to poor decision making on the procurement front. Accurate tools for cloud consumers, and transparency in SLAs, costs, and data management practices for cloud service providers, will provide the needed insight for informed choices.

1.Service Request is made by the customer for an instance of the Service Offering listed in Service Catalog. When a Service Request is

successfully satisfied, a Service Instance is created.

a.A service template specifies the logical hardware, network configuration, and software for a service. A template may be instantiated many times, creating many instances of the service. b.Service Templates range from simple specifications of a single virtual

machine to complex definitions involving many virtual machines, applications, and complex configurations. Typically, templates are instantiated with virtual entities, although physical entities may also be used.

c.Service Instance is created when a Service Template is deployed with given parameters; i.e., a service instance is created after a successful deployment of an instance of the parameterized service template. d.Service Offering is a list of one or more Service Templates. e.Service Catalog is a list of Service Offerings.

2.The SLA includes agreements about services and service availability, performance, and billing. The SLA must be structured such that it can be propagated to all involved cloud service providers. The consumer contracts services from one cloud service provider who could be a broker, federator, or non-broker/non-federator, and that SLA is used as the basis for the broker or federator to programmatically contract for services from other Cloud service providers.

a.In the context of Cloud service providers, including brokers and federators, a negotiated, legally binding contract between cloud service provider and cloud service consumer.

b.The SLA must address issues around software licensing, including details and the cost of the licenses involved.

Software layers the use case is in (IaaS/VM layer, PaaS layer, etc.) Software-as-a-service (to offer SLA pricing and comparison), enabling “cloud shopping”.

Platform, tools and environment needed for execution of use case Typical cloud platform to implement service for SLA management/ brokerage/analysis/comparison.

SLAs need to be expressed in a standardized format (XML/XSD?) to be managed and compared in a uniform manner by all interested parties. Components and services needed for execution

N/A

Data files representing cloud service provider SLAs need to be shared and freely exchanged.

Related and pre-requisite use cases N/A

Existing specifications that are known to work XML/XSD, OData

New specifications required SLA data format

(26)

(27)

A.

Appendix of Technical Notes

A.1 On the Transparency of Standards Implementations

Customers and users need to evaluate the quality of implementation of a given standard or specification. To this end, when a vendor claims conformance to a given standard or specification, they should use a set of best practices. Concepts such as implementers’ notes and objective test cases are important here. In addition, there are often “gray areas,” options or extensions in many standards or technical specifications, so the way that a vendor implements the spec or standard could be different from the way another company implements it. For example, the Enterprise Java technologies supported by IBM products are not necessarily the same as those supported by Oracle’s. One Java implementation might natively support caching, transaction and clustering; another may do it with different object models or APIs, and a third may require customization.

This information – in addition to information on service-level agreements (SLAs), quality of service (QoS), workload portability, automated provisioning, accounting and billing, etc. – should be provided to cloud consumers when evaluating cloud providers. When a provider claims conformance to a given standard or specification, the consumer, in order to ensure that any interoperability issues with the cloud provider’s technologies are understood and managed, should require details and documentation from the cloud provider, including:

•

“Implementation notes” about how the provider has implemented any ambiguous or optional portions of the spec

•

An Errata document describing any bugs or issues with the implementation

•

Published results of interoperability testing against the implementation, especially if the spec comes with a set of conformance tests. Well tested and mature specifications and standards are often tested by various vendors in plugfests and interoperability labs against each other’s implementations.

A.2 On Portability in the Cloud

Even from the first, “entry-level” use case, application and data portability is a key requirement, whether moving to the cloud in the first place or moving from one cloud to another.

Organizations that have virtualized their datacenters have already taken the first step to the cloud. Packaging an operating system, application, and data in a virtual machine (VM) cuts the hardcoded bonds between hardware and software. This makes apps far more portable. And it makes managing them far more efficient by enabling multiple VMs to run on a single server (multi-tenancy) rather than just one application-per-server as had been traditional before virtualization. VMs are designed to be portable, even while in full operation (with live migrations). But the provider’s implementation of all the details of VM packing and management may be different from the consumer’s. As a result:

•

The application appliance may not be accepted by the destination cloud.

•

The application may not start.

•

The application may execute but fail to behave as expected.

•

Performance may be poor.

•

Bulk data may move to the cloud incorrectly.

•

VMs may not respond to the management commands.

Because P01 is an organization’s first use case in cloud computing, the IT staff will encounter for the first time any such portability challenges involved in using Infrastructure as a Service (IaaS) (where the VMs are executed) and Platform as a Service (PaaS) (where data, identity, and access are managed).

(28)

The ideal, of course, is that solving any portability issues that arise when moving the first application to the cloud should solve such portability issues for any cloud service provider one might choose. Standards are a key to achieving that ideal.

Building on existing standards and specifications that are known to work and already in widespread use (and documenting how the standards are implemented) allows developers to continue to use their chosen development languages and tools as they build for cloud environments. This keeps migration costs and risks low by enabling organizations to leverage their IT staff’s current skills, and by providing a secure migration path that preserves existing investments. Examples of languages, tools, and standards that are common in the cloud include programming languages and runtimes such as Java, C#, PHP and Ruby; developer tools such as Visual Studio and Eclipse; Internet protocols for service access such as REST, SOAP, and XML; federated identity standards for service authentication such as SAML and Oauth; web protocols and open specifications for data portability such as OData and TDS; and standards for managing virtualized environments.

Standards continue to rapidly evolve in step with technology. Hence, cloud standards may be at different stages of maturity and levels of acceptance. Open Virtualization Format (OVF), for example, is an open standard for packaging and distributing virtual appliances. Originally offered as a proprietary format to the Distributed Management Task Force (DMTF), OVF was first published in March 2009, then adopted in August 2010 as a national standard by the American National Standards Institute (ANSI). When a provider claims conformance with OVF or any other standard, it should cite the specific version and publish implementation, errata, and testing notes. This will provide the transparency necessary for informed consumer choice, as well as to ensure reasonably seamless technical interoperability between on-premises and cloud virtualized environments.

A.3 On Data Portability in the Cloud

Many people are focused on the need for cloud portability as the means to prevent being locked-in to any particular cloud or provider. “Portability” is generally the ability to move applications and data from one computing

environment to another. But there are significant differences between application and data portability.

With regard to applications, virtualization has greatly improved the portability of server-based workloads. Early on (and still to some extent), some cloud providers used proprietary virtual machine images that are difficult to map to enterprise networks and require transformations in order to port. Now, with the maturing and widespread adoption of the virtualization management standards (which we mentioned earlier), open standards are in place to facilitate VM portability among conformant cloud providers.

Data portability is more complex. It’s also more fundamental to true notion of portability. It puts the ultimate control over data in the hands of the owner of that data, not the web application that uses it or the service provider that hosts the application. For cloud consumers to truly control their own data, they must be able to do so both coming and going – i.e., moving data from Cloud A to Cloud B means not just changing the location of where the data is processed, but also reliably deleting it from the previous cloud provider.

Complexities in data portability stem from the fact that applications process different volumes, kinds, and forms of data, and this data, like motor oil in a car’s engine, may flow throughout the entire system. For example, a financial application might use a petabyte of data, but that data might be securely housed in a single cloud database, making it relatively easy to port. On the other hand, a customer relationship management application running in the cloud might process only a terabyte of data but which is shared among thousands of users; moving the CRM application – and all its distributed data – from one cloud to another would be more challenging. The key to data portability is that the user’s data and metadata (i.e., data about the data) are available in a well-documented and well-tested format available to all for use on other platforms.

It can be claimed that as long as users’ data is not locked in thanks to well-documented and easily accessible interoperable interfaces, the user herself is not locked-in, and that moving to another cloud provider is just a matter of enduring a switching cost. Such cost can be lowered by using best practices such as choosing cloud providers who

(29)

support a wide range of programming languages and application runtimes and middleware, as well as a variety of cloud deployment models independent of other choices the user may have made.

The data porting process is not complete, however, until the data is removed or erased from the old cloud provider. Sometimes called the “right to be forgotten,” the consumer’s ability to delete data is as essential to a user’s control over that data as the ability to retrieve it. This is a hot topic for debate currently as governments such as the European Union consider regulations and the industry works on technical solutions to address this issue in a standardized way.

A.4 On Switching Costs

When changing from one computing system to another, there are always switching costs. The key is to clearly understand the costs in order to make informed choices about change.

When a customer ports an application from one cloud-based platform to another, switching costs will include cost of acquisition, activation, setup, training, configuration, data migration, application migration, operational costs, etc. For standards-based cloud environments and transparent service providers, the costs of moving an application from one cloud to another are actually less than the costs of moving from an on-premises environment to the cloud, as in use case P01.

Note that the applications we’re focused on are mainstream, modern three-tier web applications that are already written to contemporary standards using modern programming languages and runtimes such as Java, Ruby or .NET. When porting legacy applications written two decades ago in FORTRAN or COBOL, there is a high up-front cost to recode to a modern application framework such as Java or .NET. This cost is not imposed by the cloud but rather by the requirement to update the application technology. In other words, this is an absolute, not a relative, cost; whether running on-premises or in the cloud, these legacy apps need to be re-coded in order to fully integrate with modern infrastructures.

In contrast, the mechanical act of taking an existing modern three-tier web application in one language and re-programming it in a different language is fairly minimal, especially with the help of language converters available in the marketplace. In other words, the cost of code migration is a small fraction of the overall cost of acquisition, activation, setup, training, configuration, data migration, application migration, operational costs, etc.

One exception to the above is when an enterprise application uses complex database technologies or advanced enterprise capabilities such as clustering or transactions. In such cases, regardless of the choice of programming language or runtime/frameworks (Java, Ruby or .NET) the application would be using advanced, vendor-spec