Cloud Provider Evaluation

US Government Cloud Computing Technology Roadmap Volume I: High-Priority Requirements to Further USG Agency Cloud Computing Adoption comprises public domain material from the National Institute of Standards and Technology, U.S. Department of Commerce. UMGC has

modified this work.

US Government Cloud Computing Technology Roadmap, Volume II, Release 2.0

5

2 NIST Cloud Computing Definition and Reference Architecture

Cloud computing is an emerging computing model which has evolved as a result of the maturity of

underlying prerequisite technologies. There are differences in perspective as to when a set of

underlying technologies becomes a “cloud” model. In order to categorize cloud computing services,

and to expect some level of consistent characteristics to be associated with the services, cloud

adopters need a consistent frame of

reference. The NIST Cloud Computing

Reference Architecture and Taxonomy

document defines a standard reference

architecture and taxonomy that provide the

USG agencies with a common and

consistent frame of reference for comparing

cloud services from different service

providers when selecting and deploying

cloud services to support their mission

requirements. At a certain level of

abstraction, a cloud adopter does not need to

repeatedly interpret the technical

representation of cloud services available

from different vendors. Rather the use of a

common reference architecture by the cloud

service providers can be an efficient tool

that ensures consistent categorization of the

services offered.

2.1 Revisiting the Definition

This document uses the NIST SP 800-145,

The NIST Cloud Computing Definition, to

explain characteristics of cloud computing.

For the convenience of the reader, the

following is excerpted from NIST SP 800-

145:

Cloud computing is 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.

This definition lists five essential

characteristics that are common among all

cloud computing services:

Highlights: The NIST cloud computing

definition identifies three distinct service models,

i.e., Software as a Service, Platform as a Service,

and Infrastructure as a Service.

In late 2010, the NIST Cloud Computing

Reference Architecture project team surveyed

and completed an analysis of existing cloud

computing reference models, and developed a

vendor-neutral reference architecture which

extends the NIST cloud computing definition.

This effort leveraged a collaborative process

through the NIST Cloud Computing Reference

Architecture and Taxonomy working group.

Through a discussion and validation process, the

NIST cloud computing reference architecture

project team and working group analyzed the

intricacies of different types of cloud services and

confirmed the need for “Clear and Consistently

Categorized Cloud Services” - NIST USG Cloud

Computing Technology Roadmap Volume I,

Requirement 4.

The NIST cloud computing definition and

reference architecture provides a technical basis

for discussing “Frameworks to support federated

community clouds” - Volume I, Requirement 5.

The companion NIST cloud computing taxonomy

effort has also identified the need for: “Technical

specification for high quality service level

agreements – Volume I, Requirement 3, and

Define and implemented cloud service metrics –

Volume I, Requirement 10.”

See NIST Special Publication 800-145, A NIST

Definition of Cloud Computing, and NIST

Special Publication 500-292, NIST Cloud

Computing Reference Architecture.

US Government Cloud Computing Technology Roadmap, Volume II, Release 2.0

6

On-demand self-service: A consumer can unilaterally provision computing capabilities, such as

server time and network storage, as needed automatically without requiring human interaction with

each service’s provider.

• Broad network access: Capabilities are available over the network and accessed through

standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g.,

mobile phones, laptops, and personal digital assistants [PDAs]).

• Resource pooling: The provider’s computing resources are pooled to serve multiple consumers

using a multi-tenant model, with different physical and virtual resources dynamically assigned

and reassigned according to consumer demand. There is a sense of location independence in that

the subscriber generally has no control or knowledge over the exact location of the provided

resources but may be able to specify location at a higher level of abstraction (e.g., country, state,

or data center). Examples of resources include storage, processing, memory, network

bandwidth, and virtual machines.

• Rapid elasticity: Capabilities can be rapidly and elastically provisioned, in some cases

automatically, to quickly scale out and rapidly released to quickly scale in. To the consumer, the

capabilities available for provisioning often appear to be unlimited and can be purchased in any

quantity at any time.

• Measured Service: Cloud systems automatically control and optimize resource use by

leveraging a metering capability at some level of abstraction appropriate to the type of service

(e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be

monitored, controlled, and reported, providing transparency for both the provider and consumer

of the utilized service.

Service Models

Cloud Software as a Service (SaaS): The capability provided to the consumer to use the provider’s

applications running on a cloud infrastructure. The applications are accessible from various client

devices through a thin client interface such as a Web browser (e.g., Web-based email). The

consumer does not manage or control the underlying cloud infrastructure including network,

servers, operating systems, storage, or even individual application capabilities, with the possible

exception of limited user-specific application configuration settings.

Cloud Platform as a Service (PaaS): The capability provided to the consumer is to deploy onto the

cloud infrastructure consumer-created or acquired applications created using programming

languages and tools supported by the provider. The consumer does not manage or control the

underlying cloud infrastructure including network, servers, operating systems, or storage, but has

control over the deployed applications and possibly application hosting environment configurations.

Cloud Infrastructure as a Service (IaaS): The capability provided to the consumer is to provision

processing, storage, networks, and other fundamental computing resources where the consumer is

able to deploy and run arbitrary software, which can include operating systems and applications.

The consumer does not manage or control the underlying cloud infrastructure but has control over

the operating systems, storage, deployed applications, and possibly limited control of select

networking components (e.g., host firewalls).

US Government Cloud Computing Technology Roadmap, Volume II, Release 2.0

7

Deployment Models

Based on how exclusive the cloud infrastructure is operated and made available to a consumer,

cloud services can also be categorized by a series of deployment models:

Private cloud: The cloud infrastructure is operated solely for an organization. It may be managed by

the organization or a third party and may exist on premise or off premise.

Community cloud: The cloud infrastructure is shared by several organizations and supports a

specific community that has shared concerns (e.g., mission, security requirements, policy,

and compliance considerations). It may be managed by the organizations or a third party and

may exist on premise or off premise.

Public cloud: The cloud infrastructure is made available to the general public or a large industry

group and is owned by an organization selling cloud services.

Hybrid cloud: The cloud infrastructure is a composition of two or more clouds (private, community,

or public) that remain unique entities but are bound together by standardized or proprietary

technology that enables data and application portability (e.g., cloud bursting for load

balancing between clouds).

2.2 NIST Cloud Computing Reference Architecture

The NIST cloud computing reference architecture is a logical extension to the NIST cloud

computing definition. This extension provides a common frame of reference to help USG and other

cloud computing stakeholders to:

• Gain a further understanding of the technical and operational intricacies of cloud computing;

• Communicate cloud consumers requirements precisely;

• Categorize and compare cloud services objectively; and

• Analyze security, interoperability, and portability requirements systematically in order to better

inform solution implementations.

The reference architecture describes a conceptual model comprising abstract architectural elements

and their relations or interactions, such as

• Cloud computing actors and how they interact with each other in their activities;

• System components and how these components are orchestrated to deliver the computing

services;

• Management functionalities that are required to support the life cycle of operations; and

• Other cross-cutting aspects such as security and privacy associated with these elements.

The reference architecture is a high-level, abstract model not tied to any specific cloud technology

or vendor product, that focuses on the requirements of “what” cloud services provide and not on

“how to” design and implement these services.

US Government Cloud Computing Technology Roadmap, Volume II, Release 2.0

8

The reference architecture also provides a companion cloud computing taxonomy detailing the

definitions and relationships of a control vocabulary.

A cloud solution provider may use this reference architecture to guide the development of real

architectures from different viewpoints (such as application architecture, middleware architecture,

data architecture, and network architecture), given constraints imposed by the organization’s

operational and technical environments. The reference architecture has a direct benefit for the cloud

consumer as well. By mapping the various cloud solution products to the architectural components

defined in the reference architecture, a cloud consumer can understand and compare cloud service

offerings and make informed decisions. For other stakeholders, such as academia and Standards

Development Organizations (SDOs), the reference architecture can help frame issues and provide a

common baseline for research.

As described above, the NIST Cloud Computing Reference Architecture Project Team surveyed and

completed an initial analysis of existing cloud computing reference architectures and reference

models. On this basis, the project team developed a straw man model of architectural concepts. This

effort leveraged a collaborative process from the NIST Cloud Computing Reference Architecture

and Taxonomy Working Group, active between November 2010 and April 2011. This process

involved broad participation from the industry, academic, SDOs, and private and public sector

cloud adopters. The project team iteratively revised the reference model by incorporating comments

and feedback received from the working group. This section summarizes version 1.0 of the

reference architecture and taxonomy and highlights the changes brought upon during the final

editing process for this document.

2.2.1 Conceptual Model

Figure 1 presents the NIST cloud computing reference architecture, which identifies the major

actors, their activities, and their functions in cloud computing. The diagram depicts a generic high-

level architecture and is intended to facilitate the understanding of the requirements, uses,

characteristics, and standards of cloud computing.

The reference architecture displayed in Figure 1 is an updated version based on additional public

comments received in the revision process for this document. Through the RA/TAX Public

Working Group process, this new model has been verified and approved by its members. The

principal difference between the original reference architecture (found in NIST 500-292) and the

one in this document is the change in the position of the “Security” and “Privacy” components.

Security and Privacy were originally identified as cross-cutting concerns and items that are shared

responsibilities for each cloud computing actor, therefore the placement of Security and Privacy as a

backplane to the cloud computing reference architecture is an appropriate change to the model.

US Government Cloud Computing Technology Roadmap, Volume II, Release 2.0

9

Figure 1: The Conceptual Reference Model

2.2.2 Cloud Computing Actors

As shown in Figure 1, the NIST cloud computing reference architecture defines five major actors:

cloud consumer, cloud provider, cloud carrier, cloud auditor, and cloud broker. Each actor is an

entity (a person or an organization) that participates in a transaction or process or performs tasks in

cloud computing.

2.2.2.1 Cloud Consumer

The cloud-consumer is the principal stakeholder for the cloud computing service. A cloud-consumer

represents a person or organization that maintains a business relationship with, and uses the service

from a cloud-provider. A cloud-consumer browses the service catalog from a cloud-provider,

requests the appropriate service, sets up service contracts with the cloud-provider, and uses the

service. The cloud-consumer may be billed for the service provisioned, and needs to arrange

payments accordingly. Cloud-consumers need SLAs to specify the technical performance

requirements fulfilled by a cloud-provider. SLAs can cover terms regarding the quality of service,

security, and remedies for performance failures.

SaaS applications are made accessible via a network to the SaaS consumers. The consumers of SaaS

can be organizations that provide their members with access to software applications, end users who

directly use software applications, or software application administrators who configure

applications for end users. SaaS consumers can be billed based on the number of end users, the time

of use, the network bandwidth consumed, the amount of data stored, or the duration of stored data.

US Government Cloud Computing Technology Roadmap, Volume II, Release 2.0

10

PaaS consumers employ the tools and execution resources provided by cloud providers to develop,

test, deploy, and manage the operation of PaaS applications hosted in a cloud environment. PaaS

consumers can be application developers who design and implement application software,

application testers who run and test applications in a cloud-based environment, application

deployers who publish applications into the cloud, and application administrators who configure,

monitor, and manage applications deployed in a cloud. PaaS consumers can be billed according to

the number of PaaS users, the processing, storage, and network resources consumed by the PaaS

application, and the duration of the platform usage.

IaaS clouds provide cloud consumers with virtual computers, network-accessible storage, network

infrastructure components, and other fundamental computing resources, on which IaaS consumers

can deploy and run arbitrary software. IaaS can be used by system developers, system

administrators, and IT managers who are interested in creating, installing, monitoring, and

managing services and applications deployed in an IaaS cloud. IaaS consumers can be billed

according to the amount or duration of the resources consumed, such as CPU hours used by virtual

computers, volume and duration of data stored, network bandwidth consumed, or the number of IP

addresses used for certain intervals.

2.2.2.2 Cloud Provider

A cloud provider is the entity (a person or an organization) responsible for making a service

available to interested parties. A cloud provider acquires and manages the computing infrastructure

required for providing the services, runs the cloud software that provides the services, and makes

the arrangements to deliver the cloud services to cloud consumers through network access.

For SaaS, the cloud provider deploys, configures, maintains, and updates the operation of the

software applications on a cloud infrastructure. The SaaS cloud provider is mostly responsible for

managing the applications, security, and the cloud infrastructure, while the SaaS cloud consumer

has limited administrative control of the applications.

For PaaS, the cloud provider manages the computing infrastructure for the platform and runs the

cloud software that provides the components of the platform, such as runtime software execution

stack, databases, and other middleware components. The PaaS cloud provider typically also

supports the development, deployment, and management process of the PaaS cloud consumer by

providing tools such as integrated development environments (IDEs), development versions of

cloud software, software development kits (SDKs), and deployment and management tools. The

PaaS cloud consumer has control over the applications and possibly over some of the hosting

environment settings, but has no or limited access to the infrastructure underlying the platform such

as network, servers, operating systems (OSs), or storage.

For IaaS, the cloud provider acquires the physical computing resources underlying the service,

including the servers, networks, storage, and hosting infrastructure. The cloud provider runs the

cloud software necessary to render the necessary computing resources to the IaaS cloud consumer

through a set of service interfaces and computing resource abstractions, such as virtual machines

and virtual network interfaces. In return, the IaaS cloud consumer uses these computing resources,

such as a virtual computer, for fundamental computing needs. Compared to SaaS and PaaS

consumers, an IaaS consumer has access to more fundamental forms of computing resources and

thus has control over more software components in an application stack, including the OS. The IaaS

US Government Cloud Computing Technology Roadmap, Volume II, Release 2.0

11

cloud provider, on the other hand, has control over the physical hardware and cloud software that

make the provisioning of these infrastructure services possible, for example, the physical servers,

network equipment, storage devices, host OS, and hypervisor software for virtualization.

A cloud provider’s activities span five major areas including service deployment, service

orchestration, cloud service management, security, and privacy.

2.2.2.3 Cloud Auditor

A cloud auditor is a party that can perform an independent examination of cloud service controls

with the intent to express an opinion thereon. Audits are performed to verify conformance to

standards through a review of objective evidence. A cloud auditor can evaluate the services

provided by a cloud provider such as security controls, privacy, and performance. There are many

reasons an organization (government or not) may have aspects of privacy evaluated by an auditor.

Auditing is especially important for federal agencies. The Federal Cloud Computing Strategy

document published in February 2011 pointed out that “agencies should include a contractual clause

enabling third parties to assess security controls of cloud providers.” Security controls are the

management, operational, and technical safeguards or countermeasures employed within an

organizational information system to protect the confidentiality, integrity, and availability of the

system and its information. For security auditing, a cloud auditor can make an assessment of the

security controls in the information system to determine the extent to which the controls are

implemented correctly, operating as intended, and producing the desired outcome with respect to

the security requirements for the system. The security auditing should also assess the compliance

with the specified regulation and with the security policy. For example, an auditor can be tasked

with ensuring that the correct policies are applied to data retention according to relevant rules for

the jurisdiction. The auditor may ensure that fixed content has not been modified and that the legal

and business data archival requirements have been satisfied.

A privacy audit can help federal agencies comply with applicable privacy laws and regulations

governing an individual’s privacy, and to ensure confidentiality, integrity, and availability of an

individual’s personal information at every stage of development and operation.

2.2.2.4 Cloud Broker

As cloud computing evolves, the integration of cloud services can be too complex for cloud

consumers to manage. A cloud consumer may request cloud services from a cloud broker, instead of

contacting a cloud provider directly. A cloud broker is an entity that manages the use, performance,

and delivery of cloud services and negotiates relationships between cloud providers and cloud

consumers.

In general, a cloud broker can provide services in three categories:

• Service Intermediation: A cloud broker enhances a given service by improving some specific

capability and providing value-added services to cloud consumers. The improvement can be

managing access to cloud services, identity management, performance reporting, enhanced

security, etc.

US Government Cloud Computing Technology Roadmap, Volume II, Release 2.0

12

• Service Aggregation: A cloud broker combines and integrates multiple services into one or more

new services. The broker provides data integration and ensures the secure data movement

between the cloud consumer and multiple cloud providers.

• Service Arbitrage: Service arbitrage is similar to service aggregation except that the services

being aggregated are not fixed. Service arbitrage means a broker has the flexibility to choose

services from multiple agencies. The cloud broker, for example, can use a credit-scoring service

to measure and select an agency with the best score.

A Cloud Broker may provide services in two separate domains:

• Business and relationship support services (business intermediation).

• Technical support service (aggregation, arbitrage and technical intermediation), with a key focus

on handling interoperability issues among multiple providers.

Cloud Brokers may behave as Business brokers in some cases, Technical brokers in others or may

take on both roles.

A Business Cloud Broker is an entity that offers Cloud Consumers business and relationship

services to evaluate and select Cloud Providers based upon the consumer’s requirements. Business

brokerage does not offer technical broker-related capabilities to interact with Cloud Consumer data

in Cloud Provider environments. Business brokerage can be combined with or operate

independently of technical Brokerage services. They do not have any contact with the consumer’s

data migrated to the cloud, consumer operational processes in the cloud or consumer-based cloud

artifacts such as images, volumes or firewalls.

A Technical Cloud Broker is an entity that offers Cloud Consumers the capability to consistently

interact with the consumer’s operational processes, cloud artifacts and/or data residing in Cloud

Providers environments by aggregating services from multiple providers and adding a layer of

technical functionality that addresses consistent interface and interoperability issues. Technical

Brokerage does not offer business broker-related capabilities to evaluate and select Cloud Providers.

Technical brokerage can be combined with or operate independently of business brokerage services.

This individual will interact with the consumer’s operational processes, cloud artifacts and/or

consumer data by aggregating services from multiple providers and adding a layer of technical

functionality by addressing single-point-of-entry and interoperability issues.

A Technical Cloud Broker has two defining qualities which distinguish it from a Cloud Provider:

1. The Cloud Broker provides a single point of entry for managing multiple cloud services. The

key defining features that distinguish a Cloud Broker from a Cloud Service Provider are the

ability to provide a single consistent interface to multiple differing providers, whether the

interface is for business or technical purposes and to provide the Cloud Consumer with

complete transparency into the identity of the supporting Cloud Service Providers.

2. The Cloud Broker provides transparency to the Cloud Consumer on the identity of the Cloud

Providers in the background. A Cloud Broker will always allow the cloud Consumer a particular

level of transparency into the identity of the target Cloud Providers. An entity that provides

additional layers of functionality to only one Cloud Provider or does not allow transparency into

their underlying Cloud Providers will be considered an Intermediary Cloud Provider.

US Government Cloud Computing Technology Roadmap, Volume II, Release 2.0

13

In both cases, the Cloud Brokers provide a single interface across multiple cloud service provider

targets, for business or technical services respectively. Combinations of technical and business

brokerage can be carried out by the same entity. Cloud Providers who operate in a Cloud Broker

role can provide brokerage services as well.

There are two classes of Cloud Providers - primary and intermediary. A Primary Cloud Provider is

an entity that provides the cloud consumer with a full stack of cloud services without relying on

other entities to provision particular functional service layers, whereas an Intermediary Cloud

Provider is a cloud provider that relies on one or more other cloud service providers to deliver

services to the cloud consumer, but does not provide the consumer with visibility into the

underlying cloud provider services in use. They may also provide additional layers of functionality

to only one Cloud Provider.

Basic Broker Model

Figure 2 shows a basic example of cloud brokerage. Depending upon the broker services rendered,

the brokerage can be business oriented, technically oriented or a combination of the two. Cross-

provider business services might include service catalogue lookups, subscription handling, customer

relation management, etc. and cross-provider technical services might include orchestration, load

management and cloud-bursting, integrated identity and authorization management, security

Brokerage and integrated security management, metrics retrieval, unified billing, cost and usage

reporting, etc.

Note that two key

characteristics of brokerage

are fulfilled:

• The Cloud Consumer

uses a single broker

interface to engage with

multiple providers.

• The Cloud Consumer

retains visibility into the

cloud service providers

they use through the

broker, either through the

broker, directly or both.

Figure 2: Cloud Broker Interactions

US Government Cloud Computing Technology Roadmap, Volume II, Release 2.0

14

Intermediary Cloud Provider Example

Figure 3 below shows a simple example of an intermediary cloud provider interaction with a cloud

consumer. Both the broker and the intermediary provider have the capability to interact with

multiple cloud providers. However, the intermediary cloud provider presents only its service

interface to the cloud consumer and does not offer visibility into or control over any additional

cloud or non-cloud providers used in the creation of the service behind the scenes. Instead, the

intermediary cloud uses the additional providers as invisible components of its own service, which

is presented to the customer as an integrated offering.

2.2.2.5 Cloud Carrier

A cloud carrier acts as an intermediary that provides connectivity and transport of cloud services

between cloud consumers and cloud providers. Cloud carriers provide access to consumers through

network, telecommunication, and other access devices. For example, cloud consumers can obtain

cloud services through network access devices, such as desktop computers, laptops, mobile phones,

and other mobile Internet devices (MIDs). The distribution of cloud services is normally provided

by network and telecommunication carriers or a transport agent, where a transport agent refers to a

business organization that provides physical transport of storage media, such as high-capacity hard

drives.

Figure 3: Intermediary Cloud Provider Brokerage Example

2.2.2.6 Scope of Control between Provider and Consumer

The cloud provider and cloud consumer share the control of resources in a cloud system. As

illustrated in Figure 3, different service models affect an organization’s control over the

US Government Cloud Computing Technology Roadmap, Volume II, Release 2.0

15

computational resources and thus what can be done in a cloud system. The figure shows these

differences using a classic software stack notation comprised of the application, middleware, and

OS layers. This analysis of delineation of controls over the application stack increases

understanding of the responsibilities of parties involved in managing the cloud application.

• The application layer includes software applications targeted at end users or programs. The

applications are used by SaaS consumers, or installed/managed/maintained by PaaS consumers,

IaaS consumers, and SaaS providers.

• The middleware layer provides software building blocks (e.g., libraries, database, and Java

virtual machine) for developing application software in the cloud. The middleware is used by

PaaS consumers, installed/managed/maintained by IaaS consumers or PaaS providers, and

hidden from SaaS consumers.

• The OS layer includes operating system and drivers, and is hidden from SaaS and PaaS

consumers. An IaaS cloud allows one or multiple guest OSs to run virtualized on a single

physical host. Generally, consumers have broad freedom to choose which OS is to be hosted

among all the OSs that could be supported by the cloud provider. The IaaS consumers should

assume full responsibility for the guest OS(s), while the IaaS provider controls the host OS.

Figure 4: Scope of Controls between Provider and Consumer

2.2.3 Architecture Components

This section describes the architectural elements with which cloud actors interact, including an

abstraction of the system components that orchestrate together to deliver the service capabilities, the

different deployment models of these infrastructure components, and the management activities

cloud providers engage in with cloud consumers.

US Government Cloud Computing Technology Roadmap, Volume II, Release 2.0

16

2.2.3.1 Service Orchestration

Service Orchestration refers to the composition of system components to support the cloud provider

activities in arrangement, coordination, and management of

computing resources in order to provide cloud services to

cloud consumers. Figure 5 shows a generic stack diagram of

this composition that underlies the provisioning of cloud

services.

A three-layered model is used in this representation to depict

the grouping of the three types of system components that

cloud providers need to compose to deliver their services.

In the model shown in Figure 5, the top is the service layer,

where cloud providers define interfaces for cloud consumers

to access the computing services. Access interfaces of each

of the three service models are provided in this layer. It is

possible, though not necessary, that SaaS applications can

be built on top of PaaS components, and PaaS components

can be built on top of IaaS components. The optional

dependency relationships among SaaS, PaaS, and IaaS

components are represented graphically as components

stacking on each other; while the angling of the components

represents that each of the service component can stand by

itself. For example, a SaaS application can be implemented

and hosted on virtual machines from an IaaS cloud, or it can

be implemented directly on top of cloud resources without

using IaaS virtual machines.

The middle layer in the model is the resource abstraction

and control layer. This layer contains the system

components that cloud providers use to provide and manage access to the physical computing

resources through software abstraction. Examples of resource abstraction components include

software elements such as hypervisors, virtual machines, virtual data storage, and other computing

resource abstractions. The resource abstraction needs to ensure efficient, secure, and reliable usage

of the underlying physical resources. While virtual machine technology is commonly used at this

layer, other means of providing the necessary software abstractions are also possible. The control

aspect of this layer refers to the software components that are responsible for resource allocation,

access control, and usage monitoring. This is the software framework that ties together the

numerous underlying physical resources and their software abstractions to enable resource pooling,

dynamic allocation, and measured service. Various open source and proprietary cloud software are

examples of this type of middleware.

The lowest layer in the stack is the physical resource layer, which includes all the physical

computing resources. This layer includes hardware resources, such as computers (CPU and

memory), networks (routers, firewalls, switches, network links, and interfaces), storage components

(hard disks), and other physical computing infrastructure elements. It also includes facility

Figure 5: Cloud Provider –

Service Orchestration

US Government Cloud Computing Technology Roadmap, Volume II, Release 2.0

17

resources, such as heating, ventilation and air conditioning (HVAC), power, communications, and

other aspects of the physical plant.

Following system architecture conventions, the horizontal positioning, i.e., the layering, in a model

represents dependency relationships – the upper layer components are dependent on adjacent lower

layer to function. The resource abstraction and control layer exposes virtual cloud resources on top

of the physical resource layer and supports the service layer where cloud services interfaces are

exposed to cloud consumers. Cloud consumers do not have direct access to the physical resources.

2.2.3.2 Cloud Service Management

Cloud Service Management includes all of the service-related functions that are necessary for the

management and operation of those services required by or proposed to cloud consumers. Cloud

service management can be described from the perspective of business support, provisioning and

configuration, and from the perspective of portability and interoperability requirements.

2.3 NIST Cloud Computing Taxonomy

The NIST Cloud Computing taxonomy was developed in conjunction with the reference

architecture and describes key cloud computing concepts, the relationships between these concepts,

and their given context. The taxonomy organizes the key concepts into four levels:

• Level 1: Role, which indicates a set of obligations and behaviors as conceptualized by the

associated actors in the context of cloud computing.

• Level 2: Activity, which entails the general behaviors or tasks associated to a specific role.

• Level 3: Component, which refers to the specific processes, actions, or tasks that must be

performed to meet the objective of a specific activity.

• Level 4: Sub-component, which presents a modular part of a component.

The taxonomy can be used as a source for developing a controlled vocabulary of cloud computing

terms that will provide an increased clarification and standardization of the cloud computing

terminology. Details about this taxonomy and the related vocabulary can be found on the NIST

cloud computing reference architecture and taxonomy collaboration site: http://collaborate.nist.gov/twiki-

cloud-computing/bin/view/CloudComputing/ReferenceArchitectureTaxonomy.