This document is part of a collection of documents that comprise the
Reference Architecture for Private Cloud
document set. The Reference Architecture for Private Cloud documentation is a community collaboration project. Please feel free to edit this document to improve its quality. If you would like to be recognized for your work on improving this article,
please include your name and any contact information you wish to share at the bottom of this page.
Two dimensions are used to classify the various deployment models for cloud computing:
Our reference architecture will be based upon the NIST definition as we define the core principals, concepts, and patterns used throughout the reference architecture and subsequent implementation guidance in this content series. The reference architecture
will consist of a reference frame that outlines the overall cloud computing stack based on the NIST definition and defines the core principals, concepts, and patterns of a good reference architecture. This is then followed by service delivery guidance to guide
the business on solution based delivery of an on-premises private cloud infrastructure.
The reference architecture presented contain practices that are independent of any specific platform provider and generally should be present on any IaaS platform or service engagement available from or through a provider of cloud based computing capability.
Where applicable, we will link with solution implementation guidance that is based on the use of Microsoft Server products to illustrate the capability discussed in the reference architecture.
The cloud provides options for approach, sourcing, and control. It delivers a well-defined set of services, which are perceived by the customers to have infinite capacity, continuous availability, increased agility, and improved
cost efficiency. To achieve these attributes in their customers’ minds, IT must shift its traditional server-centric approach to a
service-centric approach. This implies that IT must go from deploying applications in silos with minimal leverage across environments to delivering applications on pre-determined standardized platforms with mutually agreed upon service levels. A
hybrid strategy that uses several cloud options at the same time will become the norm as organizations choose a mix of various cloud models to meet their specific needs.
Cloud options typically are categorized by the following service and sourcing models:
Software as a Service (SaaS) delivers business processes and applications, such as CRM, collaboration, and email, as standardized capabilities for a usage-based cost at an agreed, business-relevant service level. SaaS provides significant efficiencies in
cost and delivery in exchange for minimal customization and represents a shift of operational risks from the consumer to the provider. All infrastructure and IT operational functions are abstracted away from the consumer.
Platform as a Service (PaaS) delivers application execution services, such as application runtime, storage, and integration for applications written for a pre-specified development framework. PaaS provides an efficient and agile approach to operate scale-out
applications in a predictable and cost-effective manner. Service levels and operational risks are shared because the consumer must take responsibility for the stability, architectural compliance, and overall operations of the application while the provider
delivers the platform capability (including the infrastructure and operational functions) at a predictable service level and cost.
Infrastructure as a Service (IaaS) abstracts hardware (server, storage, and network infrastructure) into a pool of computing, storage, and connectivity capabilities that are delivered as services for a usage-based (metered) cost. Its goal is to provide a
flexible, standard, and virtualized operating environment that can become a foundation for PaaS and SaaS.
IaaS is usually seen to provide a standardized virtual server. The consumer takes responsibility for configuration and operations of the guest Operating System (OS), software, and Database (DB). Compute capabilities (such as performance, bandwidth, and storage
access) are also standardized.
Service levels cover the performance and availability of the virtualized infrastructure. The consumer takes on the operational risk that exists above the infrastructure.
Service Provided by Cloud
Service Level Coverage
Deployment models (shared or dedicated and internally or externally hosted) are defined by the ownership and control of architectural design and the degree of available customization. The different deployment models can be evaluated against the three standards
- cost, control, and scalability.
The Public Cloud is a pool of computing services delivered over the Internet. It is offered by a vendor, who typically uses a “pay as you go” or "metered service" model. Public Cloud Computing has the following potential advantages: you only pay for resources
you consume; you gain agility through quick deployment; there is rapid capacity scaling; and all services are delivered with consistent availability, resiliency, security, and manageability. Public Cloud options include:
The private cloud is a pool of computing resources delivered as a standardized set of services that are specified, architected, and controlled by a particular enterprise.
The path to a private cloud is often driven by the need to maintain control of the service delivery environment because of application maturity, performance requirements, industry or government regulatory controls, or business differentiation reasons. For example,
banks and governments have data security issues that may preclude the use of currently available public cloud services. Private cloud options include:
The array of services delivered by the combination of service and sourcing models can be dizzying. CIOs will need to evaluate their business requirements and the experience of the provider to select the appropriate Cloud models.
In the content above, we describe several characteristics, service models, and deployment models that are aligned to the NIST definition of cloud computing. Now we couple this with infrastructure layer components that are briefly described in the Blueprint
for Private Cloud Infrastructure as a Service and expand the Infrastructure Layer in the Private Cloud Reference Model.
This expanded reference model illustrated in the figure below is the basis of the Private Cloud Infrastructure as a Service architecture design contained in this series.
Throughout the Infrastructure as a Service series, the focus will be on the Infrastructure Layer of the Reference Model, however as you see in the illustration, the Infrastructure layer has a light coupling with the Management layer and the Platform layer.
Further, the Infrastructure and Management layers are influenced by the Operations layer. Certain key areas of the Management layer such as Fabric Management are covered in detail in this Infrastructure as a Service series while remaining areas of the Management,
Operations, and Service Delivery layers are covered in later or future content in the Private Cloud Reference Architecture.
We can now state that Private Cloud Infrastructure as IaaS is an advanced state of IT maturity that has a high degree of automation, integrated-service management, and efficient resource utilization. Virtualization can be a key enabler of IaaS, but in most
models, including the NIST cloud definition, virtualization is a common, not an essential, attribute. An infrastructure that is 100 percent virtualized may have no process automation; it might not provide management and monitoring of applications that are
running inside virtual machines (VMs) or IT services that are provided by a collection of VMs. In addition to virtualization, several other infrastructure-architecture layers are required to achieve the essential cloud attributes.
A rich automation capability is required in this environment. Automation must be enabled across all hardware components—including server, storage, and networking devices—as well as all software layers, such as operating systems, services, and applications.
The Windows Management Framework—which comprises Windows Management Instrumentation (WMI), Web Services-Management (WS-Management), and Windows PowerShell—is an example of a rich automation capability that was initially scoped to Microsoft products, but that
is now being leveraged by a wide variety of hardware and software partners.
A management layer that leverages automation and functions across physical, virtual, and application resources is another required layer for higher IT maturity. The management system must be able to deploy capacity, monitor health state, and automatically respond
to issues or faults at any layer of the architecture.
Orchestration that manages all of the automation and management components must be implemented as the interface between the IT organization and the infrastructure. Orchestration provides the bridge between IT business logic, such as "deploy a new web-server
VM when capacity reaches 85 percent," and the dozens of steps in an automated workflow that are required to actually implement such a change.
The IaaS solution’s primary purpose is to host other higher layers such as the PaaS and SaaS.
The final layer is the Service Delivery layer that provides interfaces for both service providers and service consumers.
The integration of virtualization, automation, management, and orchestration layers provides the foundation for achieving the highest levels of IT maturity.
Several key concerns must be established that are cross cutting in the overall design of a Private Cloud Infrastructure as a Service design. These concerns are grounded in the Private Cloud Reference Architecture and expanded here in the context of providing
Infrastructure as a Service.
The physical datacenter is the enterprise facility where the organization's cloud capability is deployed. When providing cloud services, we generally think of services that exist, but we don't give much thought to where they exist. However, we must consider
location when dealing with a physical datacenter. Some corporate datacenters may exist in one or more corporate locations. For large organization, there may be dedicated facilities just for housing their datacenter(s). Increasingly these considerations include
locations where the climate enables the use of outside air to provide environmental climate control within the datacenter, which reduces energy consumption. A location may also be selected because it provides access to low cost energy for the datacenter.
The location of a datacenter plays an active role in the design of Private Cloud Fault Domains and options available to the IT consumer when selecting capabilities to purchase and deploy through Private Cloud Self Service.
The Private Cloud Reference Architecture defines the private cloud pattern of a Scale Unit. However, there is no specific predefined set or selection of values that comprise a scale unit. The determination is part of the private cloud design and planning
process. A Scale Unit is a pool of compute, storage, and network resources that can be deployed as a single unit or in bundles that allow both extensibility and reuse or reallocation without physical reconfiguration. Examples of these resources are:
When selecting elements of a scale unit, the architect should consider future availability as changes in hardware architectures will influence Management Fabric implementations over time. A scale unit should be sized to accommodate future growth over a period
that is meaningful to the business. Some businesses will plan on a quarterly basis while others may forecast by fiscal year or more.
A resource pool is comprised of server, network, and storage scale units that share a common hardware and configuration baseline but does not share a single point of failure with any other resource pool other than the facility itself. Note that a resource
pool could be subdivided further into Fault Domains. See
Private Cloud Reference Architecture Principles, Patterns, and Concepts.
The Physical Fault Domains pattern is defined in the Private Cloud Reference Architecture. In an Infrastructure as a Service design, a fault domain is a set of physical infrastructure with a common configuration within a resource pool that does not share
a single point of failure with any other fault domain.
An upgrade domain is infrastructure within a resource pool that can be maintained, taken offline, or upgraded without downtime to the workloads running in the resource pool.
Private Cloud Infrastructure as a Service is an evolution in the industry and IT. It forms the foundation of cloud computing for all cloud enabled workloads. Designing for Infrastructure as a Service raises the IT Capability and Maturity level to realize
cloud capabilities in the allowing the business to focus on objectives, respond with agility and realize economies of scale.
If you edit this page and would like acknowledgement of your participation in the v1 version of this document set, please include your name below:
[Enter your name here and include any contact information you would like to share]
Return to Reference Architecture for Private Cloud
Very interesting. Good job.
Very informative article, well done!