1 Introduction

This document gives an overview of a Private Cloud Reference Model. For the purposes of this document, a Reference Model is defined as the problem definition, requirements, and scope for a specific domain including the identification of all layers (or subdomains) and any interactions or dependencies between the components.

Note:
This document is part of a collection of documents that comprise the Reference Architecture for Private Cloud document set. The Solution for Private Cloud is a community collaboration project. Please feel free to edit this document to improve the quality of this document. If you would like to be recognized for your work on improving this document, please include your name and any contact information you wish to share at the bottom of this page.

An updated version of this article is now available as part of the Cloud Services Foundation Reference Architecture article set.

This Reference Model forms the basis, or cornerstone, for all Reference Architecture in a Private Cloud. It not only defines the domain but also sets taxonomy and drives coherency of approach amongst the many authors who contribute to the Private Cloud Reference Architecture documentation set. Every contributor and reviewer of the Reference Architecture documentation should use the Reference Model to understand the broad landscape of the problem domain before being able to decide if the existing guidance meets their needs or identify what new guidance may be required.

The Reference Model will initially be depicted as a single diagram and the remainder of the document will decompose each layer and describe its components.

This is a general purpose document that provides foundational context and approach for the development of Reference Architecture documentation. Therefore, the first audience for this document are all those people who are involved in the development of any Private Cloud Reference Architecture. All reviewers of the Reference Architecture materials can use this document to determine “fit for purpose” for their materials. The applicability of this guidance is much broader than the development activity as any architect, service manager, or technical decision maker will benefit from an understanding of the problem domain and the approach to producing the Reference Architecture.

2 Reference Model

The Private Cloud Reference Model defines the scope and the problem space for its domain. The model acts as the “guide-rails” to assist architects’ efforts to holistically address the development of a private cloud architecture. Additionally, it provides a common vocabulary and shared understanding across all constituencies.

The Reference Model below depicts a number of layers, which are further decomposed into specific problem spaces or components.


Figure 1: The Private Cloud Reference Model

The Reference Model is split into the following layers:

• The Software, Platform, and Infrastructure Layers represent the technology stack, where each provides services to the layer above.
• The Service Operations and Management Layers represent the process perspective and includes the management tooling required to implement aspects of the process.
• The Service Delivery Layer represents the alignment between business and Information Technology (IT).

It is a deliberate attempt to blend technology and process (for example, Information Technology Infrastructure Library (ITIL)) perspectives because Cloud Computing is as much about the Service Management as it is about the technologies involved in it.

At first it may not seem much different from traditional IT; but remember, this is not a Reference Architecture, it is a Reference Model and is defined as the problem domain. Many of IT’s problems continue to be the same, from both a technology and operational perspective; however, the differences now include some enabling technologies and radical approaches based on the experience and concepts associated with Cloud Computing. From an operational perspective, the desire to adopt good IT Service Management practices has also been around for a long time. But many organizations have not been effective in implementing these best practices and this hinders their success. Cloud Computing is driving a new emphasis on operational rigor, casting a fresh light on best-practices and forcing IT to re-think some of its fundamental concepts.

The layers are further defined as follows:

• Service Delivery Layer: Represents those Service Management activities that require input and interaction with the business and service owner. The components are not only responsible for that interaction, but also the translation of business requirement into technology and operational capabilities. This layer represents the business perspective on the basis of IT.
• Software Layer: Provides the applications and software that support a business activity (for example, CRM). The Software Layer consumes Virtual Machines (VM) services from the Infrastructure Layer and may consume application services from the Platform Layer.
• Platform Layer: Provides a set of platform-level (above operating system level) building blocks which can be consumed by the Software Layer. It consumes hypervisor services from the Infrastructure Layer and is managed by the Management Layer.
• Infrastructure Layer: Provides resilient hypervisor services to the Platform Layer and is managed by the Management Layer. The Infrastructure, Platform, and Software Layers represent the enabling technology perspective within IT.
• Service Operations Layer: Represents Service Management and operational processes carried out by IT operations and support staff.
• Management Layer: Provides management services to the Infrastructure, Platform, and Software Layers. It is comprised of the suite of management tools necessary to support IT Service and Operations Layer and implements the operational processes. The Management Layer provides a baseline set of capabilities to the Infrastructure Layer and an incremental set to the Platform Layer and the Software Layer. The Operations and Management Layers represent the operational perspective within IT.

2.1 Service Delivery Layer

The Service Delivery layer is the interface between business and IT. It serves as the conduit for translating business requirements into IT services and is responsible for managing ongoing delivery of those services. These capabilities are common to all services: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS).


Figure 2: Service Delivery Layer Components

As the primary interface with the business, the Service Delivery Layer is expected to know or obtain answers the following questions:

• What services does the business want?
• What level of service are business decision-makers willing to pay for?
• How can private cloud move IT from being a cost center to becoming a strategic partner to the business?

With these questions in mind, there are two main problems within the Service Layer that IT must address:

• How do we provide a cloud-like platform for business services that meets business objectives?
• How do we adopt an easily understood, usage-based cost model that can be used to influence business decisions?

An organization must adopt the following private cloud principles in order to meet the business objectives of a cloud-like service:

• Perception of Infinite Capacity: From an end user’s perspective, cloud services appear to have no capacity constraints; and there is no limit to the volume of service users can consume.
• Perception of Continuous Availability: An end user should never observe any interruption in cloud services, even if failures occur within the cloud environment.
• Resiliency over Redundancy Mindset: Provider focus is on maintaining service availability through resiliency instead of redundancy.
• Service Provider's Approach in Delivering Infrastructure: IT organizations should adopt a service provider model based on infrastructure service definitions with clear capabilities from provider and consumer perspectives.
• Drive Predictability: Remove as much variation from the environment as possible to increase predictability.
• Minimize Human Involvement: A highly automated environment is required to achieve resiliency.
• Optimization of Resource Usage: From the provider’s perspective, resources should be optimized to maximize utilization and minimize waste, driving efficiency and reducing cost.
• Encourage Desired Consumer Behavior: Use cost, quality, and agility to influence consumer behavior in ways congruent with principles.

The components of the Service Delivery Layer are:

• Financial Management: Financial Management incorporates the functions and processes used to meet a service provider’s budgeting, accounting, metering, and charging requirements. The primary concerns around Financial Management in a private cloud are providing cost transparency to the business and structuring a usage-based cost model for the consumer. Achieving these goals is a basic precursor to achieving the principle of encouraging desired consumer behavior.
• Demand Management: Demand Management involves understanding and influencing customer demands for services, plus the provision of capacity to meet these demands. The principles of perceived infinite capacity and continuous availability are fundamental to stimulating customer demand for cloud-based services. A resilient, predictable environment and predictable capacity management are necessary to adhere to these principles. Cost, quality, and agility factors influence consumer demand for these services.
• Business Relationship Management: Business Relationship Management is the strategic interface between the business and IT. If an IT department is to adhere to the principle that it must act as a service provider, mature Business Relationship Management is critical. The business should define the functionality of required services and partner with IT on solution procurement. The business will also need to work closely with IT to define future capacity requirements to continue adhering to the principle of perceived infinite capacity.
• Service Catalog: The output of Demand and Business Relationship Management will be a list of services or service classes offered and documented in the service catalog. This catalog describes each service class, eligibility requirements for each service class, service-level attributes, targets included with each service class (such as availability targets), and cost models for each service class. The catalog must be managed over time to reflect changing business needs and objectives.
• Service Life Cycle Management: Service Life Cycle Management takes an end-to-end management view of a service. A typical journey starts with identification of a business need, through Business Relationship Management, to the time when that service becomes available. Service strategy drives service design. After launch, the service is transitioned to operations and refined through continual service improvement. Taking a service provider’s approach is key to successful Service Life Cycle Management.
• Service-Level Management: Service-Level Management is the process of negotiating Service-Level Agreements (SLAs) and making sure the agreements are met. SLAs define target levels for cost, quality, and agility by service class as well as the metrics for measuring actual performance. Managing SLAs is necessary for achieving the perception of infinite capacity and continuous availability. This, too, requires a service provider’s approach by IT.
• Continuity and Availability Management: Availability Management defines processes necessary to achieve the perception of continuous availability. Continuity Management defines how risk will be managed in a disaster scenario to make sure minimum service-levels are maintained. The principles of resiliency and automation are fundamental here.
• Capacity Management: Capacity Management defines the processes necessary to achieve the perception of infinite capacity. Capacity must be managed to meet existing and future peak demand while controlling under-utilization. Business Relationship and Demand Management are key inputs into effective Capacity Management and require a service provider’s approach. Predictability and optimization of resource usage are primary principles in achieving Capacity Management objectives.
• Information Security Management: Information Security Management strives to make sure that all requirements are met for confidentiality, integrity, and availability of the organization’s assets, information, data, and services. An organization’s particular information security policies will drive the architecture, design, and operations of a private cloud. Resource segmentation and multi-tenancy requirements are important factors to consider during this process.

2.2 Software Layer

The Software Layer provides the business applications with solution-specific runtime components necessary to deliver a business service. It will consume hypervisor services from the Infrastructure Layer and may consume application services from the Platform Layer. The Software Layer provides interfaces to end-users.

2.3 Platform Layer

The Platform Layer provides application services to the Software Layer and consumes hypervisor services from the Infrastructure Layer. Platform Layer interfaces will vary; some examples of Platform Layer interface include Hypertext Transfer Protocol (HTTP) and Representational State Transfer (REST).

2.4 Infrastructure Layer

The Infrastructure Layer provides hypervisor services (VM resources) to the Platform and Software Layers. It defines the capabilities necessary for these VMs to execute; it includes hypervisor, physical servers, network devices, storage systems, and facilities (which include space, power, cooling, and physical interconnects).


Figure 3: Infrastructure Layer Components

Infrastructure Layer components include:

• Network: Network services provide addressing and packet delivery for the provider’s physical infrastructure and the consumer’s VMs. Network capability includes physical and virtual network switches, routers, firewalls, and Virtual Local Area Network (VLAN).
• Compute: Compute services supply the physical resources such as CPU, Random Access Memory (RAM), NIC, Video, and Storage used by the provider to deliver VMs to consumers. It contains the physical server hardware and parent OS.
• Storage: Storage provides physical storage devices to the provider, which exposes these services to consumers as virtual disks. Storage should be connected to a network for VM portability.
• Hypervisor: The hypervisor provides VM services by partitioning and presenting compute, network, and storage services.
• Facilities: Facilities represent the physical building, racks, power, cooling, and physical interconnects.

2.5 Service Operations Layer

The Service Operations Layer defines the operational processes and procedures necessary to deliver IT as a Service. This layer uses IT Service Management concepts that can be found in prevailing best practice such as ITIL or Microsoft Operations Framework (MOF).

The main focus of the Service Operations Layer is to execute the business requirements defined at the Service Delivery layer. Cloud-like service attributes cannot be achieved through technology alone; mature IT service management is also required.

The Service Operations capabilities are common to all three services; IaaS, PaaS, and SaaS.


Figure 4: Service Operations Layer Components

The components of the Service Operations Layer include:

• Change Management: Change Management is responsible for controlling the life cycle of all changes. Its primary objective is to implement beneficial changes with minimum disruption to the perception of continuous availability. Change Management determines the cost and risk of making changes and balances them against the benefits to the business or service. Driving predictability and minimizing human involvement are the core principles behind a mature Change Management process.
• Service Asset and Configuration Management: Service Asset and Configuration Management maintains information on the assets, components, and infrastructure needed to provide a service. Accurate configuration data for each component, and its relationship to other components, must be captured and maintained. This data should include historical and expected future states in addition to the current state, and be easily available to those who need it. Mature Service Asset and Configuration Management processes are necessary for achieving predictability.
• Release and Deployment Management: Release and Deployment Management is responsible for seeing that changes to a service are built, tested, and deployed with minimal disruption to the service or production environment. Change Management provides the approval mechanism (determining what will be changed and why), but Release and Deployment Management is the mechanism for determining how changes are implemented. Driving predictability and minimizing human involvement in the release and deployment process are key to achieving cost, quality, and agility goals.
• Knowledge Management: Knowledge Management is responsible for gathering, analyzing, storing, and sharing information within an organization. Mature Knowledge Management processes are necessary to achieve a service provider’s approach and a key element of IT service management.
• Incident and Problem Management: The goal of Incident and Problem Management is to resolve disruptive, or potentially disruptive, events with maximum speed and minimum disruption. Problem Management also identifies root causes of past incidents and seeks to identify and prevent (or minimize the impact of) future ones. In a private cloud, the resiliency of the infrastructure helps make sure that faults, when they occur, have minimal impact on service availability. Resilient design promotes rapid restoration of service continuity. Driving predictability and minimizing human involvement are necessary to achieve this resiliency.
• Request Fulfillment: The goal of Request Fulfillment is to manage user requests for services. As IT adopts a service provider’s approach, it should define available services in a service catalog based on business functionality. The catalog should encourage desired user behavior by exposing cost, quality, and agility factors to the user. Self-service portals, when appropriate, can assist the drive towards minimal human involvement.
• Access Management: The goal of Access Management is to deny access to unauthorized users while making sure that authorized users have access to needed services. Access Management implements security policies defined by Information Security Management at the Service Delivery Layer. Maintaining smooth access for authorized users is critical to achieving the perception of continuous availability. Adopting a service provider’s approach to Access Management will also make sure that resource segmentation and multi-tenancy are addressed.
• Systems Administration: The goal of System Administration is to perform the daily, weekly, monthly, and as-needed tasks required for system health. A mature approach to Systems Administration is required for achieving a service provider’s approach and for driving predictability. The vast majority of Systems Administration tasks should be automated.

2.6 Management Layer

The Management Layer defines the capabilities required to execute and implement the Operation and Service Layer processes and procedures to support IaaS, PaaS, and SaaS. These capabilities are incremental moving up through the Infrastructure, Platform and Software Layers.


Figure 5: Management Layer Components Related to Infrastructure

The components of the Management Layer related to the Infrastructure Layer are:

• Service Reporting: Service Reporting is the mechanism for producing and delivering performance reports on Service Levels. The system requirements for the service reporting toolset should be driven by the service-level requirements defined by Service-Level Management in the IT Service Layer.
• Service Management System: A Service Management System is a set of tools designed to facilitate Service Management processes. Ideally, these tools should be able to integrate data and information from the entire set of tools found in the Management Layer. It should also be capable of processing and present the data as needed. At a minimum, the Service Management System should be linked to the Configuration Management System (CMS), commonly known as the Configuration Management Database (CMDB), and should log and track incidents, problems, and changes. It is also preferred that the Service Management System be integrated with the Service Health Modeling system so that incident tickets can be auto-generated.
• Service Health Monitoring: The Service Health Monitoring system makes sure that services meet all service-level targets. This system should be aware of each component required to provide a service – and its relationship and dependencies on other components. The Service Health Monitoring system should identify when a service is approaching a performance threshold or component failure and either resolve the issue itself or alert Operations.
• Configuration Management System: A Configuration Management System (CMS) is the definitive hub for collecting, storing, managing, updating, and presenting data about all Configuration Items (CIs) and their relationships. A CMS is composed of a number of Configuration Management Databases (CMDBs), each of which manages a subset of configuration data. A CMS should ideally integrate and correlate the information from the CMDBs for processing, analysis, and presentation. The CMS should also have configuration monitoring capability to identify, report, and repair when configurations fall out of the desired state.
• Fabric Management: Fabric Management is the toolset responsible for managing workloads of virtual hosts, virtual networks, and storage. Fabric Management provides the orchestration necessary to manage the life cycle of a consumer’s workload (one or more VMs that collectively deliver a service; Microsoft Office SharePoint Portal being one example).
• Deployment and Provisioning Management: Deployment and Provisioning Management is the toolset used to carry out the processes defined by Release and Deployment Management in the Operations Layer. Deployment results in creation or installation of a computer unit or service component in generic, unequipped fashion; provisioning is the process of applying service-specific and instance-specific attributes to the deployed resource.
• Data Protection: Data Protection provides the capability to backup and restore data, hosts, and infrastructure and service components. Data protection policies should be defined in the IT Service Layer by Service-Level Management and Information Security Management.
• Network Management: Network Management manages the underlying network fabric, including VLANs, switch ports, load balancers, and firewall rules. Network Management also includes a set of network services that support IaaS; for example, Dynamic Host Configuration Protocol (DHCP), Domain Name System (DNS), and Pre-Boot Execution Environment (PXE).
• Security Management: Security Management defines and reports on the security policies (for example, password complexity levels) that apply to the infrastructure. It provides security services such as a directory, authentication, and authorization.

As this content series continues each element of the Reference Model will be expanded to expose the details of each layer resulting in a complete Reference Architecture for Private Cloud. Note that that Security (which includes identity and access management) is not represented in the Reference Model. This was not by omission but rather recognition that the security domain is a cross-cutting concern that influences every aspect of the architecture. Rather than show a security block with arrows throughout the diagram we just recognize the cross cutting nature of security on the architecture and will address it in the Cloud Security Architecture document set and as each layer is expanded.  For additional cloud and datacenter architectural and solution guidance, please visit the Microsoft Cloud and Data Center Solutions Hub.

RESOURCES:

ACKNOWLEDGEMENTS LIST:
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 

TRANSLATIONS:
Modelo de referencia de nube privada (es-ES)