180
Cloud Computing Concepts, Technology and Architecture TUDOR MARIUS COSMIN

Cloud Computing_2015_03_05

Embed Size (px)

Citation preview

Cloud Computing Concepts, Technology and Architecture

TUDOR MARIUS COSMIN

Instructor Contact Information

Instructor Background Information

Role@Star Storage :

Chief Delivery Officer for Infrastructure Solutions & Cloud Business Unit

Role@MCloud 1

Leaded the delivery team from Star Storage

Background

IT and Business Management

Business Process Management

Project Management

IT Security

Accredited Tier Specialist for Data Centers Operations (Uptime Institute)

Cloud Computing Certified Professional

Ground Rules

There are not any!…as long as you keep your mobiles on mute and laptop/tablet closed

Ask questions, comment and challenge at anytime!

I don’t have all the answers, however might be able to get it later.

Understand the time limitation -Rome was not built in a day

Instructor Contact Information

[email protected]

@tudor_cosmin

www.star-storage.ro

www.star-vault.ro

Timetable

Session 1 - 05 March:

Session 1 - 10 : 00 AM – 11:20 AM

Coffee break – 11:20 AM – 11:40 AM

Session 2 – 11:40 AM – 13:00 PM

Session 1 Overview

A Brief History of Cloud Computing

Fundamental Terminology and Concepts

Characteristics of a cloud

Roles and Boundaries

Cloud Delivery Models

Cloud Deployment Models

Benefits of Cloud Computing

Challenges of Cloud Computing

Business Cost Metrics

Service Level Agreements (SLAs)

The world has chaged !

What is the

“CLOUD”

“When asked what “the cloud” is, a

majority respond it’s either an actual

cloud, the sky, or something related to

wheather”

Citrix Cloud Survey Guide

Cloud Computing Defined

“Cloud computing is a specialized form of

distributed computing that introduces

utilization models for remotely provisioning

scalable and measured IT resources.”

Cloud Defined

“A cloud is a distinct and remote IT

environment designed for the purpose of

remotely provisioning scalable and

measured IT resources.”

A Brief History of

Cloud Computing

Overview

The idea of computing in a “CLOUD” traces back to the origins of utility

computing – a concept published in 1961 by scientist John McCarty:

“If computers of the kind I have advocated become the computers of the future,

then computing may someday be organized as a public utility just as the

telephone system is a public utility. … The computer utility could become the basis

of a new and important industry.”

In 1969, Leonard Kleinrock, a chief scientist of the Advanced Research

Projects Agency Network or ARPANET, stated:

“As of now, computer networks are still in their infancy, but as they grow up and

become sophisticated, we will probably see the spread of ‘computer utilities’ …”.

Overview

Mid-1990s, various forms of Internet-based computer utilities:

Search Engines: Yahoo!, Google

E-mail Services: Hotmail, Gmail

Social Media: My Space, Facebook, YouTube, Twitter, Linkedin

Term “Network Cloud” or “Cloud” was introduced in early 1990s in networking industry

In 2002, Amazon.com launched the Amazon Web Services (AWS) platform, a suite of enterprise-oriented services that provide remotely provisioned storage, computing resources, and business functionality

In 2006 the term “cloud computing” emerged in the commercial arena.

Amazon launched its Elastic Compute Cloud (EC2) services that enabled organizations to “lease” computing capacity and processing power to run their enterprise applications

Google Apps also began providing browser-based enterprise applications in the same year, and three years later, the Google App Engine became another historic milestone.

Overview

Cloud computing emerged from a combination of business drivers and technology innovations.

Business drivers:

Capacity Planning

Cost reduction and Operating Overhead

Organizational Agility

Technology Innovations:

Grid Computing Technology

Clustering Technology

Virtualization Technology

Business Drivers: Capacity Planning

Capacity planning is an unavoidable responsibility for most IT enterprises, requiring that future demands on IT infrastructure be planned for and accommodated.

Capacity planning can be very challenging because it can require estimating usage load fluctuations.

There is a constant need to balance peak usage requirements without unnecessarily over-spending on IT infrastructure.

To accommodate maximum usage loads may require too high of an investment. To moderate the investment may result in lost transactions and other usage limitations due to lower usage thresholds.

Business Drivers: Capacity Planning

Different capacity planning strategies exist :

Lead Strategy – adding capacity to an IT resource in anticipation of demand

Lag Strategy – adding capacity when the IT resource reaches his full capacity

Match Strategy – adding IT resource capacity in small increments, as demand

increases

Business Drivers: Cost Reduction

and Operating Overhead

Two costs need to be accounted for:

the cost of acquiring new infrastructure

The cost of its going ownership (TCO)

Common forms of infrastructure-related operating overhead include the following:

technical personnel required to keep the environment operational

upgrades and patches that introduce additional testing and deployment cycles

utility bills and capital expense investments for power and cooling

security and access control measures that need to be maintained and enforced to protect infrastructure resources

administrative and accounts staff that may be required to keep track of licenses and support arrangements

Business Drivers: Organization Agility

Organizational agility represents the responsiveness of an organization in

the face of business chance.

“… so even elephants can walk on a tightrope”

Technology Innovations:

Grid Computing Grid computing emerged in the 90’s to introduce the

concept of “computing as a networked utility”.

A computing grid provides a platform in which computing resources are organized into one or more logical pools.

With a grid you could plug into a pool of shared computing power the same way you would plug an appliance into a shared power grid

This concept led to the notion of “pay-as-you-go” computing and further formed the basis of “elasticity” –both of witch established fundamental characteristics of a cloud

Technology Innovations:

Web/Clustering Architectures

Because Web Applications were commonly made available to a wide

public, they often became demand-driven and tended to be “spiky” in

their usage loads.

The back-end technology architectures that evolved in support of Web-

based applications therefore introduced the need for:

Load balancing

Server farms

Clustered servers

Clustered databases

Technology Innovations:

Virtualization Technology

Virtualization is an established technology that has enabled

hardware owners to repeatedly leverage physical servers for

wide, concurrent usage.

Virtualization further helped realize the notion of “server

elasticity” by allowing one physical server to host a variable

number of “virtual” servers.

Virtualization is a key technology in modern cloud computing.

Fundamental Terminology

and Concepts

Overview

Before we can discuss the details of cloud computing, we need to first

establish some fundamentals terms and concepts :

IT Resource

Virtualization

Scaling

Cloud

On-Premise

Service

Cloud Service

Service Agent

IT Resource

An IT resource is a physical or virtual IT-related artifact (software or

hardware).

The following are common types of IT resources:

• physical server

• software program

• storage device

• virtual server

• service

• network device

Virtualization

Virtualization allows physical IT resources to provide multiple virtual images of themselves so that their underlying processing capabilities can be shared individually by multiple consumers.

The owner of the physical IT resource maintains centralized administrative control and intentionally hides implementation details fro consumers of the virtual IT resources.

This abstraction of the physical IT resource allows consumers to use the provided virtual IT resources without any required knowledge of how the underlying physical IT resource exists or operates.

As consumer usage demands fluctuate, the owner of the physical IT resource can scale it accordingly.

Virtualization For example, a physical computer will often contain a single installation

of an operating system that can be used by a single consumer.

Through virtualization, the same computer can provide multiple images of the same operating system installation that can be independently used by multiple consumers.

The owner of the physical computer can retain administrative control of the computer hardware and the base operation system environment.

Consumers of the virtual operating system images can independently configure and control their respective virtual environments, but are not given access to (nor require access to) the underlying physical environment.

Virtualization Virtualization is an established area of technology that

emerged long before cloud computing.

Within cloud environments, virtualization technology is primarily utilized to replicate multiple virtual images of the same physical server for remote access by consumers.

A virtual server is a form of virtualization software that emulates a physical computer (a physical server).

Each physical server can host multiple virtual servers.

To a cloud consumer, a virtual server appears as an independent physical server.

Scaling

Scaling, from an IT resource perspective, represents the ability of the IT

resource to gracefully handle increased or decreased usage demands.

The following are scaling –related terms used in these courses:

• horizontal scaling

scale out

scale in

• vertical scaling

scale up

scale down

Scaling (Horizontal)

Horizontal scaling refers to the allocation or releasing of resources of

the same type. The horizontal allocation of resources is referred to as

scaling out and the horizontal releasing of resources is referred to as

scaling in.

Horizontal scaling is a common form of scaling within cloud

environments.

Scaling (Vertical)

Vertical scaling occurs when an existing resource is

replaced by another.

The replacing of an IT resource with another that has

a higher capacity is referred to as scaling up and the

replacing an IT resource with another that has a lower

capacity is referred to as scaling down.

Vertical scaling is less common in cloud environments

due to the downtime required while the replacement

is taking place.

Scaling

A comparison of horizontal and vertical scaling :

Cloud

A cloud is a distinct and remote IT environment designed for

the purpose of remotely provisioning scalable and measured

IT resources.

IT resources are provided by a cloud for consumers to access remotely, from outside the cloud perimeter.

Consumers may or may not know the exact physical location of the IT

resources provided by a cloud.

Although a cloud will commonly be based on Web protocols and

technologies, it is not necessary for a cloud to be Web-based. A cloud

can exist with the use of any remote access protocols that allow for access to its IT resources.

Cloud Not every IT resource that resides inside a cloud needs to be made

directly available to consumers.

A cloud-based IT resource can be remotely accessed or it can support

the remote access of other cloud-based IT resources.

When an IT resource is made available to external consumers, it is

accessible as a cloud service (as explained in the upcoming Cloud

Service section).

Cloud Example A cloud hosting eight IT resources: three virtual servers, two cloud

services, and three cloud storage devices.

On-Premise The term on-premise (or “on-premises”) is used to qualify an IT resource

that is not remotely accessible via a cloud, but instead resides within an

internal IT enterprise environment.

It is important to note that very often cloud-based IT resources are

invoked by or communicate with on-premise IT resources.

For example, an IT resource may be moved from an on-premise

environment to a cloud, or vice versa.

On-Premise to Cloud

Service

From an implementation perspective, a service is a software

program that can be remotely invoked via a published technical

interface (or API) referred to as a service contract.

When a software program invokes and interacts with a service, it is

labeled as a service consumer.

Services acting as service consumers can invoke other services.

When two or more services participate to complete a given task,

the services from a service composition.

A service can reside on-premise or in a cloud. In the latter case, it is

further qualified as a cloud service (as explained in the following Cloud Service section).

Cloud Service The term “service” within the context of cloud computing is very broad.

From a cloud computing perspective, any remotely accessible IT resourceis classified as a service.

A cloud service can therefore be considered an IT resource made remotely accessible via a cloud.

Note that even though a cloud service exists as an IT resource, it may further provide access to other cloud-based IT resources.

Note that a cloud service can exist as a software program that acts as an endpoint or access point to a larger application, platform or environment.

From a consumer perspective, the larger application, platform or environment itself (and in its entirety) may be considered the “service”.

Cloud Service A cloud service can exist as:

• A traditional service (such as a Web service or a REST service) accessed via a published contract and messaging.

• A software program remotely accessed via other means (such as communicating with a software program on a server using a proprietary protocol)

Service Agent A service agent is an event-driven program capable of transparently

intercepting and processing messages sent to or from services.

Depending on the development platform you are working with, service

agents may be called “filters”, “listeners”, “interceptors”, “handlers”, etc.

Most modern runtime environments (and operating systems) provide a

set of system service agents, but service agents can also be custom-

developed.

Service agents do not have a technical interface (or service contract)

and are therefore not explicitly invoked.

Service Agent

Service agents are depicted using the rectangular block symbol.

Common functions performed by service agents include routing,

logging, validation, and security related processing.

Service agents are important to cloud computing, especially for

providing runtime monitoring and load balancing functions.

Characteristics of a Cloud

Overview Let’s revisit the definition of cloud computing:

Cloud computing is a specialized form of distributed computing that introduces utilization models for remotely provisioning scalable and measured IT resources.

Let’s revisit the definition of a cloud:

A cloud is a distinct and remote IT environment designed for the purpose of remotely provisioning scalable and measured IT resources.

In order to remotely provision scalable and measured IT resources in an effective manner, an IT environment requires a specific set of characteristics.

These characteristics need to exist to a meaningful extent for the IT environment to be considered an effective cloud.

Cloud Characteristics This section is dedicated to individually describing the following six cloud

characteristics :

• On-Demand Usage

• Ubiquitous Access

• Multitenancy

• Elasticity

• Measured Usage

• Resiliency

On-Demand Usage

A cloud consumer can unilaterally access cloud-based IT resources

giving the cloud consumer the freedom to self-provision these IT

resources.

Once configured, usage of the self-provisioned IT resources can be

automated, requiring no further human involvement by the cloud

consumer or cloud provider.

This results in an on-demand usage environment.

Ubiquitous Access

Ubiquitous access represents the

ability for a cloud service to be widely

accessible. Establishing ubiquitous

access for a cloud service can require

support for a range of transport

protocols, interfaces and security

technologies.

To enable this level of access generally

requires that the cloud service be tailored to the particular needs of

different cloud service consumers.

Multitenancy (and Resource

Pooling)

Multitenancy is a characteristic of a software program that enables an instance of the program to serve different consumers (tenants), each of which is isolated from the other.

A cloud provider pools its IT resources to serve multiple cloud service consumers by using the multitenancy model.

Cloud-based multitenancy models frequently rely on the use of virtualization technologies.

Through the use of multitenancy technology, IT resources can be dynamically assigned and reassigned, according to cloud service consumer demands.

The figure on the left is an example of single tenancy in that each

cloud service consumer is provided a separate underlying IT

resource instance (in this case, a storage device).

The figure on the right illustrates multitenancy, whereby a single

instance of an IT resource is provided to both cloud service

consumers, each likely unaware that the IT resource is being shared.

Elasticity

Elasticity is the automated ability of a cloud to gracefully and

transparently scale IT resources, as required in response to runtime

conditions or as predetermined by the cloud consumer or cloud

provider.

Elasticity is often considered a core justification for the adoption of

cloud computing, primarily due to the fact that it is closely associated

with the Reduced Investment and Proportional Costs benefit.

Cloud providers with the vast resources can offer the greates range of

elasticity.

Elasticity

A sample

workflow

depicting

elastic

resource

allocation.

Measured Usage

Measured usage represents the ability of a cloud platform to keep

track of the usage of its IT resources by cloud consumers.

Based on what is measured, the cloud consumer is charged only for

the IT resources actually used and/ or for the timeframe where access

to the IT resources was required.

Measured usage is not limited to tracking statistics for billing purposes. It

also encompasses the general monitoring of IT resources and related usage reporting (to both cloud provider and cloud consumers).

Measured Usage A typical application

of measured usage

within a cloud is the

monitoring and

collection of runtime

data by the cloud

provider to be used

for cloud consumer

billing purposes, as

demonstrated here.

Resiliency Resilient computing is a form of failover that distributes redundant

implementations of IT resources across physical locations.

IT resources can be pre-configured so that if one becomes deficient,

processing is automatically handed over to another redundant IT

resource.

Within cloud computing, resiliency can refer to redundant IT resources

within the same cloud (but in different physical locations) or across multiple clouds.

Cloud consumers can increase the reliability and availability of cloud-based IT resources.

Resiliency For example, Cloud A provides Cloud

Service A as part of a failover system that encompasses a redundant implementation of Cloud Service A on Cloud B. If Cloud Service A on Cloud A fails, then Cloud Service A on Cloud B is automatically provisioned transparently to Cloud Service Consumer A.

Each cloud has a specific level of reliability and availability that it guarantees for Cloud Service A. By spanning the failover system across both clouds, the overall reliability and availability will be higher than the maximum reliability and availability of either cloud.

Roles and Boundaries

Overview

Roles:

• Service Consumer

• Cloud Service Consumer

• Cloud Provider

• Cloud Consumer

• Cloud Resource Administrator

• Cloud Service Owner

Boundaries:

• Organizational Boundary

• Trust Boundary

Service Consumer As described earlier in the Fundamental Terms & Concepts section,

when a software program accesses a service it is labeled as a service consumer.

A service consume is therefore a temporary runtime role assumed by a software program.

A service itself may assume the role of a service consumer when it invokes and interacts with another service (as part of a service composition).

To distinguish between service consumers that access on-premise and cloud-based services, those that access cloud services are further qualified as cloud service consumers (as explained next).

Cloud Service Consumer

The cloud service consumer is a temporary runtime role assumed by

a software program when it accessed a cloud service.

The following are common types of cloud service consumers:

• software programs and services capable of remotely accessing cloud

services with published service contracts (such as Web services)

• workstations, laptops and mobile devices running software capable of

remotely accessing other IT resources positioned as cloud services (such

as virtual servers)

Cloud Service Consumer

The cloud service consumer role is assumed when:

Cloud Provider

A cloud provider is the organization that owns (provides) a cloud.

One cloud provider may own multiple clouds.

When relevant, diagrams in these courses indicate the cloud providers of depicted clouds.

When a cloud is not further labeled with a cloud provider, it is still implied that the cloud has a cloud provider.

Cloud Consumer

A cloud consumer is an organization or a human that uses a cloud

service consumer to access a cloud service.

The diagrams in these courses do not often explicitly label symbols

as “cloud consumers”.

Instead, it is generally implied that organizations or humans shown

remotely accessing cloud-based IT resources are considered cloud consumers.

Cloud Consumer

In this example, Organization A is

the cloud consumer

In this example, the illustrated

human is the cloud consumer

Cloud Service Owner

A cloud service owner is the person or organization that legally owns

a cloud service.

The cloud service owner can be either the cloud consumer or the

cloud provider of the cloud within which the cloud service resides.

For example, if Cloud X hosts Cloud Service A then either the cloud

consumer of Cloud X or the cloud provider of Cloud X can be the

Cloud Service Owner of Cloud Service A. (See the upcoming

diagrams).

Cloud Service Owner

A cloud consumer can be a cloud service owner when it has

deployed its own service in a cloud.

A common example of this is when the cloud consumer uses a PaaS

offering to develop and deploy its own cloud service (as explained

in the upcoming Cloud Delivery models section).

Cloud Service Owner

A cloud provider can be a cloud service owner when it deploys its

own service in a cloud (typically for use by other cloud consumer)

A common example of this is when the cloud providers make

services commercially available as SaaS offerings (as explained in

the upcoming Cloud Delivery models section).

Cloud Resource Administrator

A cloud resource administrator is the person or organization responsible for administering a cloud-based IT resource (including cloud services).

The cloud resource administrator can be (or belong to) the cloud consumer or cloud provider of the cloud within which the cloud service resides.

Alternatively, it can be (or belong to) a third-party organization contracted to administer the cloud-based IT resource.

For example, a cloud service owner could contract a cloud resource administrator to administer a cloud service.

Cloud Resource Administrator

A cloud resource administrator can be with a cloud consumer

organization and can administer remotely accessible IT resources that

belong to the cloud consumer.

Cloud Resource Administrator

A cloud resource administrator can be with a cloud provider

organization for which it can administer IT resources (internally and

externally available) belonging to the cloud provider.

Cloud Resource Administrator

The reason we don’t call the cloud resource administrator a cloud

service administrator, is because this person or organization may be

responsible for administering cloud-based IT resources that don’t

exist as cloud services.

For example, if the cloud resource administrator belongs to (or is contracted by) the cloud provider, IT resources not made remotely

accessible may be administered by this role (and these types of IT

resources are not classified as cloud services).

In this scenario, the cloud provider’s cloud resource administrator

accesses an internal IT resource (the physical server) that hosts

externally accessible IT resources (the virtual server and the cloud

service) available to the cloud consumer.

Cloud Resource Administrator

Note that the cloud resource administrator is a role assumed

by a human (or a group of humans). It is not a role assumed by a software program.

In diagrams, when we show the workstation symbol

remotely accessing an IT resource (such as the virtual server

in the diagram to the right), we refer to this as the “cloud

resource administrator”.

However, it is implied that the workstation being used by the

human to perform the administration task is using a software

program that technically is acting as a cloud service consumer.

Roles Summary

Runtime roles assumed by software programs:

• service consumer (when a software program accesses an on-premise

service)

• cloud service consumer (when a software program accesses a cloud service)

Roles assumed by people/ organizations:

• cloud consumer (when a person/ organization uses IT resources provided by

a cloud)

• cloud provider (the person / organization that owns/ provides a cloud)

• cloud resource administrator (the person/ organization responsible for

administering a cloud-based IT resource)

Organizational Boundary and Trust

Boundary An organizational boundary represents the physical perimeter that

surrounds a set of IT resources owned by a specific organization.

This means that an organizational boundary does not represent the boundary of an actual organization (only a set of organizational IT assets represented by IT resources).

Organizational boundaries are generally used to indicate regions or environments that are under the control of the organization.

Incorporating cloud computing into an IT enterprise can require that IT resources be placed outside of an organizational boundary.

This can result in a loss of control of an organization’s IT resources.

Organizational Boundary and Trust

Boundary

An organization acting as a

cloud consumer has its own

organizational boundary.

A cloud provided by a cloud

provider will have its own

organizational boundary.

Organizational Boundary and Trust

Boundary

A trust boundary establishes a logical perimeter wherein IT

resources are trusted from a security perspective.

The IT enterprise within an organization can establish an

internal trust boundary that encompasses its own IT

resources.

Organizational Boundary and Trust

Boundary Cloud-based IT resources that are used by a cloud consumer reside

outside of the cloud consumer’s organizational boundary.

To use the IT resources, the cloud consumer will generally need to trust them.

As a result, the cloud consumer’s

trust boundary is expanded beyond

its organizational boundary to

encompass the cloud.

Cloud Delivery Models

Overview

A cloud delivery model represents a specific combination of IT resources offered by a cloud provider.

Depending on the types of IT resources required by a cloud consumer, three common delivery models are used:

• Infrastructure-as-a-Service (IaaS)

• Platform-as-a-Service (PaaS)

• Software-as-a-Service (SaaS)

Variations of these delivery models can also exist. Note that a cloud delivery model is also referred to as a cloud service delivery model because each model is classified as a different type of cloud service offering.

Infrastructure-as-a-Service (IaaS)

The IaaS delivery model provides a self-contained IT environment

comprised of infrastructure-centric IT resources.

This environment can include hardware, network, connectivity,

operating systems, and other “raw” IT resources.

In contrast to traditional hosting or outsourcing IT environments, with

IaaS, IT resources are typically virtualized and packaged into

bundles that simplify up-front runtime scaling and customization of

the infrastructure.

Infrastructure-as-a-Service (IaaS)

Cloud consumers are provided with a range of contractual guarantees

by the cloud provider, pertaining to characteristics such as capacity,

performance, availability, etc.

Infrastructure-as-a-Service (IaaS)

The IT resources provided by IaaS are generally raw and not

preconfigured, placing the operational responsibility upon the cloud consumer.

The IaaS delivery model is therefore used by cloud consumers that

require a high level of control over the cloud-based environment they

intend to create.

Sometimes cloud providers will contract IaaS offerings from other cloud

providers in order to scale their own cloud environments.

The types and brands of the IT resources provided by IaaS products

offered by different cloud providers can vary.

Platform-as-a-Service (PaaS)

The PaaS delivery model provides a pre-defined cloud environment with already deployed and configured IT resources suitable for the

development and deployment of applications.

Three common reasons cloud consumers use PaaS:

1. The cloud consumer wants to extend on-premise environments into the

cloud for scalability and economic purposes.

2. The cloud consumer uses the ready-made environment to entirely

substitute an on-premise environment.

3. The cloud consumer wants to become a cloud provider and deploys its

own cloud services that are made available to other external cloud

consumers.

The PaaS delivery model relies on (and is primarily defined by) the

usage of a ready-made environment that establishes a set of pre-

packaged products and tools used to support the entire delivery

lifecycle of custom applications.

The cloud service consumer is given access to a ready-made environment on

a virtual server (also with contractual

guarantees) but will typically not be given

knowledge of any further implementation details.

Software-as-a-Service (SaaS)

The SaaS delivery model generally represents a product that exists

as a shared cloud service offered by a cloud provider to cloud consumers.

The cloud consumer leases the cloud service from the cloud

provider, who is responsible fro maintaining the cloud service’s

underlying IT resources.

SaaS offerings are typically provided so that cloud consumers can

gain access to the cloud service with minimal up-front effort.

Software-as-a-Service (SaaS)

The cloud service consumer is given access the cloud service

contract, but not to any underlying IT resources or implementation

details.

Software-as-a-Service (SaaS)

Unlike with IaaS and PaaS models, the SaaS delivery model does not

provide cloud consumers with administrative control over the cloud

service or its IT resources.

Cloud consumers are granted usage control over the cloud service

– administrative control is retained by the cloud provider.

Software-as-a-Service (SaaS) from

a customer perspective

Administrative Control

The three delivery models differ with respect to the functionality and the

level of administrative control provided to cloud consumers.

Activities Control

Typical activities carried out by cloud consumers and cloud providers in

relation to the cloud delivery models

Administrative Control - IaaS

With the IaaS delivery model:

• The cloud provider will typically have full administrative control over the

physical hardware, physical network, storage devices, and virtualization

platforms.

• The cloud consumer will typically have full or partial administrative

control over virtual servers, databases, cloud service implementations,

and security settings.

Administrative Control - PaaS

With the PaaS delivery model:

• The cloud provider will typically have full administrative control over all

items listed under the IaaS model, plus virtual servers and databases.

• The cloud consumer’s administrative control is limited to the ready-

made environment(instead of accessing server settings directly,

administrative configuration are made via custom front-end provided

by the ready-made environment).

Administrative Control - SaaS

With the SaaS delivery model:

• The cloud provider will typically have full administrative control over all

items listed under the IaaS model, plus virtual servers and databases

and often the service implementation itself.

• The cloud consumer’s administrative control is limited to service

implementation which can be configured via a custom front-end.

Combining Cloud Delivery Models

As pointed out with each of the three preceding scenarios, there are common steps to realizing each of the three cloud delivery

models.

This highlights a natural layered relationship between the three

delivery models providing cloud providers with the option of

establishing one cloud delivery model by leveraging IT resources

from another.

The following pages explore common combinations of cloud

delivery models.

IaaS +PaaS

To set up a PaaS environment a cloud provider can leverage

physical and/ or virtual servers

provided by an existing IaaS

environment.

The PaaS ready-made

environments are built upon virtual servers and physical

servers provided by a separate

IaaS environment.

IaaS +PaaS

The decision by a cloud provider to lease IT resources from another cloud provider can be economical or it may be influenced by cloud consumer requirements. For example, a cloud consumer may have a legal requirements for data to be physically stored in a specific region (for which the cloud provider needs to contract a different cloud provider).

IaaS + PaaS +SaaS

All three cloud delivery models can be combined to establish layers of IT resources that build upon each other.

Using the ready-made environment provided by PaaS, a cloud

consumer organization can develop and deploy its own SaaS cloud

service that it can then make available as a commercial product.

The SaaS product is developed using a

PaaS ready-made environment and

implemented upon virtual severs and physical servers provided by a

separate IaaS environment.

Cloud

Deployment Models

Overview

A cloud deployment model represents a specific type of cloud

environment, primarily distinguished by ownership and size.

There are four common deployment models:

• Public Cloud

• Community Cloud

• Private Cloud

• Hybrid Cloud

(Variations of these deployment models can also exist)

Public Cloud

A public cloud is a publically accessible cloud environment owned by

a third-party cloud provider.

The IT resources (usually offered via the previously described delivery

models) on public clouds are generally offered to cloud consumers at

a cost.

The cloud provider is responsible for the creation and on-going

maintenance of the public cloud and its IT resources.

Many notable IT vendors provide public clouds.

Many notable IT vendors provide public clouds.

Community Cloud

A community cloud is similar to a public cloud except that its access is

limited to a specific community of cloud consumers.

The community cloud may be jointly owned by the community

member or it may be owned by a third-partu cloud provider that

provisions a public cloud with limited access.

The member cloud consumers of the community typically share the responsibility for defining and evolving the community cloud.

However, membership in the community does not necessarily guarantee access or control to the cloud’s IT resources.

An example of a “community of organizations accessing IT

resources from a community cloud.

Private Cloud

A private cloud is owned by a single organization.

Private clouds enable an organization to use cloud computing

technology as a means of centralizing access to IT resources by different

parts of the organization.

The use of a private cloud can change how organizational and trust

boundaries are defined and applied.

The actual administration of a private cloud environment may be

carried out by internal or outsourced staff.

Private Cloud External private clouds can effectively extend on-premise

infrastructure to IT resources that are physically isolated in the private

cloud environment through the use of a virtual primate network

(VPN).

Private Cloud

With a private cloud, the same organization is technically both the cloud consumer and cloud provider.

In order to differentiate these roles:

• a separate organizational department typically assumes the

responsibility for provisioning the cloud (and therefore assumes the

cloud provider role)

• departments requiring access to the private cloud assume the cloud

consumer role

Hybrid Cloud

A hybrid cloud is a cloud environment of two or more different cloud deployment models.

For example, a cloud consumer may choose to deploy cloud services processing sensitive data to a private cloud and non-sensitive cloud services to a public cloud.

The result of this combination is a hybrid deployment model.

Hybrid deployment models can be complex and challenging to create and maintain.

An organization using a hybrid cloud

model, which utilizes both a private

cloud and a public cloud.

Benefits of

Cloud Computing

Benefits of Cloud Computing

The following represent the primary benefits of cloud

computing:

• Reduced Investment and Proportional Costs

• Increased Scalability

• Increased Availability and Reliability

Reduced Investment and

Proportional Costs

By using virtualization, a cloud provider can offer the same IT resource to

multiple cloud consumers.

Cloud consumers that use cloud-based IT resources can generally lease

them with a pay-for-use model.

With this model, cloud consumers pay a usage fee for only the amount

of the IT resource actually used, resulting in directly proportional costs.

This gives an organization access to IT resources without having to

purchase its own, resulting in reduced investment requirements.

Reduced Investment and

Proportional Costs By lowering required investments and incurring costs that are

proportional to their needs, cloud consumers can scale their IT

enterprise effectively and pro-actively.

As an example, this chart compares the

costs of on-premise IT resources with the

costs of cloud-based IT resources over a

three-year period.

Increased Scalability

IT resources can be flexibly acquired from a cloud provider, almost

instantaneously and at a wide variety of usage levels.

By scaling with cloud-based IT resources, cloud consumers can

leverage this flexibility to increase their responsiveness to foreseen

changes and unforeseen changes.

This holds true for when a cloud consumer needs to scale IT

resources, based on current requirements.

Increased Scalability

The depicted example illustrates the variation of demand for an application server during a period of 24 hours, measured in concurrent

users.

Assuming one server from a given cloud provider is

able to handle 2,000 concurrent user, the cloud

consumer can adjust the usage as necessary (in this

case between 1 and 5 servers) and pay only for the

hours of server usage.

Increased Availability and

Reliability An IT resource with increased availability is available for longer periods of

time (for example, 22 hours out of a 24 hour day).

An IT resource with increased reliability is able to better avoid and recover from exception conditions.

Cloud providers generally offer resilient IT resources for which they are able to guarantee high levels of availability.

Cloud environments can be based on a modular architecture that provides extensive failover support to further increase reliability.

Note that availability and reliability are explained in detail in the Service Level Agreements section.

Increased Availability and

Reliability

In the upcoming example, a cloud transparently provides increased

availability and reliability.

During the two illustrated message exchanges, the cloud service

consumer is unaware it is interacting with different implementations

of Cloud Service A located in different geographical regions.

There are many different types of cloud-based technology architectures that can be created to support this benefit, including

the option for one cloud to leverage IT resources in another cloud.

The details for each step are

provided on the next page.

Increased Availability and

Reliability

1. The cloud service consumer invokes capability1 of Service A. Service A is a cloud-based service that is physically implemented on a server residing in a specific geographic region (Region 1).

2. Cloud Service A replies with the expected response message.

3. The next time the cloud service consumer attempts to invoke the same capability of the same service, the cloud determines that the previous implementation (the one residing in Region 1) is currently unavailable. The request message is therefore automatically routed to a different implementation of Cloud Service A, which resides in a different geographic region (Region 2).

4. Cloud Service A replies with the expected response message.

Challenges of Cloud

Computing

Challenges of Cloud Computing

The following are common cloud computing adoption challenges:

• Increased Security Vulnerabilities

• Reduced Operational Governance Control

• Limited Portability Between Cloud Providers

• Multi-Regional Compliance and Legal Issues

Note that all of these challenges pertain primarily to cloud consumers

that use IT resources located in public clouds (as explained in the Cloud Deployment Models section).

Increased Security Vulnerabilities

The remote usage of IT resources requires an expansion of trust

boundaries by the cloud consumer to include an external cloud.

Unless the cloud consumer and cloud provider support the same or compatible security technologies, it can be difficult to establish a

security architecture that spans the trust boundary without

introducing vulnerabilities.

Furthermore, because cloud-based IT resources can be shared,

there can be overlapping trust boundaries from different cloud

consumers (as illustrated on the following page).

Increased Security Vulnerabilities

In the example on the following page, two organizations accessing

the same cloud service are required to extend their respective trust

boundaries to the cloud, resulting in overlapping trust boundaries. It

can be difficult for a cloud provider to offer security technologies

that accommodate the security requirements of both cloud service

consumers.

Furthermore, the fact that trust boundaries overlap can lead to

opportunities for an attacker to attack IT resources shared by

multiple cloud consumers.

Reduced Operational

Governance Control

When forming dependencies on externally cloud-hosted IT

resources, cloud consumers are almost always given a lower level of governance control when compared to on-premise IT resources.

This reduced level of control can introduce risks pertaining to how a

cloud is operated by the cloud provider, as well as external

connections between the cloud consumer and the cloud.

Cloud consumers are often required to rely on Service Level

Agreements (SLAs) and other warranties made by the cloud

provider.

Reduced Operational

Governance Control

This challenge can relate to the organization providing a cloud or the external connections required to communicate with the cloud.

For example:

• An unreliable cloud provider may not maintain guarantees it makes in

the SLAs published for its cloud services. This can jeopardize the quality

of cloud consumer solutions that rely on these cloud services.

• The geographic distance between the cloud consumer and cloud

provider can require additional network hops that introduce fluctuating

latency and potential bandwidth constraints. This can also jeopardize

the quality of cloud consumer solutions that rely on cloud services.

Reduced Operational

Governance Control

Legal contracts, combined with SLAs, technology inspections, and monitoring can mitigate these risks.

However, with public clouds, there is always a risk that the cloud provider will be acquired or may go out of business, potentially resulting in an inability to fulfill legal obligations.

This, combined with the Limited Portability challenge (explained shortly), can have significantly restrictive impacts on the cloud consumer.

Note that SLAs are explained in detail in the Service Level Agreements section.

Example of an Unreliable Cloud Provider

Because a cloud provider has more governance control than the cloud consumer, it may be able to make changes to IT resources without the cloud consumer's permission.

The diagrams on the right depict an example whereby an irresponsible cloud provider performs a non-backwards-compatible upgrade of the messaging technology.

The details for each step are listed on the next page.

Reduced Operational

Governance Control1. The cloud service consumer accesses cloud services (not shown)

hosted on a virtual server. Both the cloud service consumer and the cloud services are designed to support the exchange of messages based on the SOAP 1.1 industry standard.

2. Without informing the cloud consumer, the cloud provider upgrades the virtual machine so that it can now only support messages based on the SOAP 1.2 industry standard. (The tact that this upgrade is non-backwards compatible to SOAP 1.1 may be accidental.)

3. The cloud service consumer is no longer able to access cloud services on the virtual server using SOAP 1.1 compliant messages.

Note that different cloud delivery models will offer different levels of operational and governance control. This example is specific to the SaaSdelivery model, as explained in the Cloud Delivery Models section.

Reduced Operational

Governance Control

Example of an Unreliable Network

The following diagram explains that

despite the cloud consumer and cloud

provider each having reliable networks,

the network connection between their

respective environments can still

jeopardize communication.

Reduced Operational

Governance ControlExample of an Unreliable Network (continued)

A cloud consumer has a local area network with a robust bandwidth of 1 Gbps.

The cloud provider also has a robust local area network with a bandwidth of 1 Gbps.

The network connecting the cloud consumer and cloud provider has a bandwidth of 100mbps.

The connection from the cloud consumer to the cloud provider over the Internet is also subjected to variable speeds and network hops that further limit throughput.

The total throughput for communications between cloud consumer and cloud provider is limited to a bandwidth of 100mbps, plus additional fluctuations.

Limited Portability Between

Cloud Providers

Due to a lack of established industry standards within the cloud computing industry, individual public clouds are proprietary to various extents.

For cloud consumers that have custom-built solutions with dependencies on these proprietary environments, it can be challenging to move from one cloud provider to another.

This challenge can be mitigated if cloud consumers can build solutions based on industry standards and if cloud providers support these industry standards.

Note that this challenge is especially relevant for PaaS and laaS delivery models.

As an example, a

cloud consumer

may be unable to

migrate an

application from Cloud A to Cloud B

because the cloud

provider of Cloud B

does not support the

same security

technologies as

Cloud A.

Multi-Regional Compliance

and Legal issues

Cloud consumers will often not have information regarding the physical

location of the IT resources provided by third party cloud providers.

Depending on the nature of the cloud consumer’s business, there may be

industry or government regulations and policies that impose specific legal

requirements.

For example, the Payment Card Industry Data Security Standard (PCI DSS)

requires that cardholder data be stored in separated network segments.

Cloud consumers unaware of the location of data or IT resources hosted by

cloud providers may not be able to comply with such regulations and

policies.

Multi-Regional Compliance

and Legal issues

Another regional legal issue that can pose problems is the disclosure of cloud hosted data.

A cloud consumer may be unaware that a cloud provider is physically locating the cloud consumer's storage device in a country where the risk of data being disclosed is higher than in other countries.

For example, data stored in the United States by a EU- based cloud consumer can be easier accessed than data stored in EU countries due to the enactment of the USA PATRIOT act.

Reputable cloud providers can generally provide guarantees that these types of compliance and legal concerns are addressed.

Business Cost Metrics

Overview

Metrics are measured statistics collected for analysis purposes.

This section focuses on the following core metrics used to evaluate the estimated costs and business value of leasing cloud-based IT resources when compared to the purchase of on-premise IT resources.

• Up-front Costs

• On-going Costs

The following additional cost metrics are also described:

• Cost of Capital

• Sunk Costs

• Integration Costs

• Locked-in Costs

Up-front Costs

Up-front costs represent the initial investment required by the organization to fund the IT resources it requires.

Up-front costs for the purchase and deployment of on-premise IT resources tend to be high.

Examples of up-front costs for on-premise environments can include hardware, software and the labor required for deployment.

Up-front costs for the leasing of cloud-based IT resources tend to be low.

Examples of up-front costs for cloud-based environments can include the labor costs required to assess and set up a cloud environment.

On going- Costs On-going costs represent the expenses required by the organization to run

and maintain IT resources it uses.

On-going costs for the operation of on-premise IT resources can vary.

Examples of on-going costs for on-premise environments can include

licensing fees, electricity, insurance, and labor.

On-going costs for the operation of cloud-based IT resources can also vary,

but often exceed the on-going costs of on-premise IT resources (especially

over a longer period of time).

Examples of on-going costs for cloud-based environments include virtual

hardware leasing fees, bandwidth usage fees, licensing fees and labor.

Up-front Costs and On-going Costs

The following is an example metrics analysis:

Let’s assume an organization requires three new physical servers.

The purchase price of one server is $7,000 and the monthly lease cost of

the same server from a cloud provider is $1,000.

The organization chooses to calculate the up-front and on-going costs

for the usage of the servers over a period of three years.

The table on the next page provides a sample comparison of up-front

and on-going costs for on-premise and cloud-based environments.

Up-front Costs and On-going Costs

Over a period of three years, the on-premise environment would cost the organization $163,100 based on the following calculation:

$33,500 up-front cost +

($3,600 on-going costs x 36 months)

Over a period of three years, the cloud-based environment would cost the organization $158,500 based on the following calculation:

$100 up-front cost +

($4,400 on-going costs x 36 months)

Up-front Costs and On-going Costs

The preceding analysis assumes the three servers will be fully used over the three-year period.

However, in most cases, the usage requirements of an organization will fluctuate.

This is where the elasticity characteristic of cloud environments can have a significant impact on on-going usage costs.

Let’s assume that, over the three-year period, the organization will actually require a maximum of 3 servers, a minimum of 1 server and 2 servers on average.

The table on the next page shows the adjusted costs.

Up-front Costs and On-going Costs

The on-premise costs remain unchanged.

The cloud-based up-front cost has been increased to reflect the

additional labor required to set-up the scalability parameters for the

use of one to three servers.

The cloud-based on-going cost has been decreased to represent

the fact that, on average, less IT resources will be used.

The result is a decrease of the cloud-based costs to a total of $124,900 over the three year period.

Additional Metrics

The preceding analysis provides a basic insight into the primary cost

metrics for evaluating the usage cloud-based IT resources.

However, this type of analysis can be more complex, as there are

additional metrics that can be taken into account, depending on a

given organization's unique requirements and circumstances.

The next pages describe the following additional types of metrics:

• Cost of Capital

• Sunk Costs

• Integration Costs

• Locked-in Costs

Cost of Capital

The cost of capital is a value that represents the cost incurred by

raising required funds.

For example, it will generally be more expensive to raise an initial

investment of $150,000 than it will be to raise this amount over a

period of three years.

The relevancy of this cost depends on how the organization goes

about raising the funds it requires.

If the cost of capital for an initial investment is high, then it further

helps justify the leasing of cloud-based IT resources.

Sunk Costs An organization will often have existing IT resources that are already

paid for and operational.

The prior investment that has been made in these on-premise IT

resources is referred to as sunk costs.

When comparing cloud-based IT resources to on-premise IT resources with sunk costs, the up-front costs for on-premise IT

resources is significantly lower.

It can therefore be more difficult to justify the leasing of cloud-

based IT resources as an alternative.

Integration Costs Integration testing is a form of testing required to measure the effort

required to make IT resources compatible and interoperable within a

new environment, such as a new cloud platform.

Depending on the cloud deployment model and cloud delivery model

being considered by an organization, there may be the need to further

allocate funds to carry out integration testing and additional labor

related to enable interoperability between cloud service consumers

and cloud services.

These expenses are referred to as integration costs.

High integration costs imposed by cloud providers can make the option of leasing cloud-based IT resources less appealing.

Locked-in Costs

As explained earlier in the Challenges of Cloud Computing section 24, cloud environments can impose portability limitations.

When performing a metrics analysis over a longer period of time, it may

be necessary to take into consideration the possibility of having to

move from one cloud provider to another.

Due to the fact that cloud service consumers can become dependent

on proprietary characteristics of a cloud environment, there are locked-

in costs (primarily related to labor) associated with this type of move.

Locked-in costs can further decrease the long-term business value of

leasing cloud-based IT resources.

Service Level

Agreements (SLAs)

Service Level Agreements

A Service Level Agreement (SLA) is a document that describes quality-of-service features, behaviors, and limitations of a service.

An SLA can be considered a human-readable part of a service

contract that extends the technical service contract.

Because cloud environments intentionally hide back-end

implementation details about cloud services, the guarantees

expressed in SLAs become very important to cloud consumers.

Service Level Agreements

A typical SLA document for a cloud service will cover three specific

quality-of-service characteristics:

• availability

• reliability

• performance

The following sections describe each of these characteristics separately.

Service Level Agreement:

Availability

The availability of an IT resource is the probability that it will be

accessible.

The probability value is generally expressed with a percentage

representing the amount of time that the IT resource is accessible

during a given period.

The percentage is calculated as follows:

1. Divide the amount of hours the IT resource was unavailable (within a

measured period) by the total amount of hours within the measured

period.

2. Multiply the value by 100.

3. Deduct the value from 100.

Service Level Agreements:

Availability

For example, let's take a Web service that was unavailable for 18

hours over the course of a year (24 x 365 = 8,760 hours):

• 18 hours / 8,760 hours = 0.002

• 0.002 x 100 = 0.2

• 100-0.2 = 99.8

The availability rating of the Web service for the measured period is

99.8%.

Service Level Agreements:

Availability

The availability value guaranteed in the SLA is based on assumptions regarding future downtimes.

Future downtimes are estimated by assigning the event that causes a downtime a probability for its occurrence and the time it would take to bring up the IT resource again.

The percentage is calculated as follows:

1. Multiply the probability of downtime by the actual estimated downtime.

2. Divide the value by a measured period of time.

3. Multiply the value by 100.

4. Deduct the value from a 100.

Service Level Agreements:

Availability

For example, a Web service may rely on a network that has a 20%

probability of crashing over the course of a year, plus it is further estimated that it would take 12 hours to recover:

0.2 x 12 hours = 2.4

2.4 / 8,670 = 0.00028

0.00028x100 = 0.028

100 - 0.028 = 99.97 (rounded to two decimals)

The availability rating of the network for the measured period is

99.97%.

Service Level Agreements:

Reliability

Reliability represents the probability that an IT resource performs its

intended functions without failure under pre-defined conditions.

A common formula tor calculating the reliability rating of an IT

resource, is to take the number of successful executions of its

function(s) and divide that value by the number of attempts made to

execute those function(s).

Multiple the result by 100 to determine the reliability percentage.

Service Level Agreements:

Reliability

For example, let's take a Web service that received 3,000 invocation

attempts over a given period, but only executed 2,892 of those attempts successfully:

• 2,892 /3,000 = 0.964

• 0.964 x100 = 96.4

The reliability rating of the Web service during the measured period is

96.4%.

Reliability is closely related to availability because, in order to be

reliable, the IT resource needs to be available.

Service Level Agreements:

Performance

The maximum performance of an IT resource represents the capacity

up to which the IT resource is able to perform its functions.

The determination of this capacity (the performance rating) of a given

IT resource depends on its type and purpose.

For example, a Web service's performance rating could be specified in

calls per seconds and the response time for each call.

A development environment, on the other hand, may measure

capacity in the maximum number of concurrent users that can be supported.

Service Level Management

Agreements Types

There are three types of SLM agremeents:

Service Level Agreement (SLA)

Operational Level Agreement (OLA)

Underpinning Contracts (UC)

Service Level Management

Agreements Types

OLA : An Agreement between an IT Service Provider and another part

of the same Organization. An OLA supports the IT Service Provider's delivery of IT Services to Customers. The OLA defines the goods or

Services to be provided and the responsibilities of both parties.

For example there could be an OLA between the:

IT Service Provider and a procurement department to obtain hardware in

agreed times

Service Desk and a Support Group to provide Incident Resolution in agreed

times.

Service Level Management

Agreements Types

UC : A Contract between an IT Service Provider and a Third Party. The

Third Party provides goods or Services that support delivery of an IT Service to a Customer.

The Underpinning Contract defines targets and responsibilities tat are

required to meet agreed Service Level Targets in an SLA.

Sample Service Level Agreement

Sample Service Level Agreement

Sample Service Level Agreement

Sample Service Level Agreement

Sample Service Level Agreement

Sample Service Level Agreement

Sample Service Level Agreement

Sample Service Level Agreement

Sample Service Level Agreement

THE WORLD HAS CHANGED!

“In 1999: 38M people had

broadband internet

Today: 1.3B people have it on their

mobile phones”

Ctrlaltdeletebook.com

The world is changing has changed

MOBILITY:

1,3 billion world’s mobile worker population will be reached by 2015

SOCIAL:

65% of companies are deploying at least one social software tool

CLOUD:

70% of business are either using or investigating cloud computing solutions

ANALYTICS:

Big Data market is growing 40% every year to reach $17 billion by 2015

IDC Prediction

3rd Platform will dominate growth

3rd Platform will cannibalize 2nd Platform

Value migrating within 3rd Platform

The CLOUD takes shapes

The key objectives behind your approach to cloud adoption?

“Business executives are starting to appreciate the potential transformative value of cloud”