The purpose of the service portfolio is to accept or reject service proposals and maintain the overall catalog of services whether rejected, under development, deployed, or retired. A primary responsibility of Service Portfolio Management is to verify that the services accepted for development and deployment align with the strategic and business requirements of the organization and its customers. This includes continuous review to allow adjustment of services due to new requirements and retirement of existing services due to lack of demand or replacement with a newer service.

The purpose of a service catalog is to maintain the active set of services. Active services are those under development or currently offered to customers for use in the vCloud environment. In this context, the service catalog is part of the overall service portfolio (as opposed to the consumer service catalog from which customers deploy service offerings). The tool that supports the service portfolio and contains the service catalog provides a mechanism for automatically populating the consumer self-service catalog from the service offerings defined in the service catalog as part of the service offering release process. Regular reviews of the service catalog should be performed and adjustments made in line with feature changes in future releases of vCloud Director, vSphere, or other supporting products.

The service catalog for the vCloud supported by vCloud Director offers service components to the end customer. At a minimum, the service catalog must define the following:

In addition to these core vCloud components, an organization can establish a standard set of offerings within the vCloud service catalog to provide customers with vApps (standardized groupings of preconfigured virtual machines) and media (installable software packages).

After being accepted into the service portfolio, the service and constituent service offerings should be defined with at least the following components:

Including pricing and chargeback, compliance, security, and operational requirements in the service definition is critical, as these are core considerations during the service design and development process.

Service types include business user services and technology services.

For optimal vCloud business user services, all types of technology services must be seamlessly integrated, usually with a workflow engine named the orchestration layer. Invoking a business user service can automatically trigger one or more technology services. The rules governing these workflows need to be preconfigured and preapproved for control. They are also needed to provide an agreed-to level of service to the business user. This agreed-to level of service is known as a Service Level Agreement (SLA).

To improve the vCloud service catalog process and help realize vCloud benefits, as many service offerings as possible should be made available to users through automated provisioning.

In the virtualization world, the initial process for procurement of virtual machines generally follows the model that is applied to physical infrastructure. Although effective, this is not the most efficient mechanism for providing services, and vCloud benefits cannot be fully realized unless the process is changed. A logical representation of the evolution of the vCloud service catalog from this current state to the desired end state is illustrated in the following figure.

 

In the service catalog current state, when a new service is requested, a service request is submitted to select and provision an offering from the service catalog. In addition to the utility (vApp or organization virtual datacenter) to be provided to the customer, the request includes the required service level provided by the virtual datacenter in which the vApp is to be provisioned, and any built-in availability features within the vApp itself. After the service is ordered, the end customer must wait for staff to fulfill the service request for the virtual machines to provide the service to be provisioned.

To satisfy the self-service, on-demand attribute of vCloud computing, the customer should be able to connect to a portal, select the required service offering, and have it automatically provisioned. This removes the need for manual selection from the service catalog, and also removes delay in the provisioning processes. This process is shown as the vCloud service catalog target state in Figure 11.

vCloud Director provides the ability to manage these requests from the service catalog. For vApps, an organization administrator can determine who within the organization has rights to request and provision vApps and thus provide end-to-end self-service. With vCloud Director, the user can select and provision the vApp and also specify in which organization’s virtual datacenter it is to be deployed. Because organization virtual datacenters are associated with provider virtual datacenters, the user is, in effect, selecting the required level of service.

Standardization of service offerings is essential to achieving a scalable, cost efficient vCloud environment. Typically, compute resource-based service offerings (CPU, memory, and storage) provide a baseline for vCloud consumption and should be standardized as much as possible, regardless of whether they apply to organization virtual datacenters or vApps (and their associated virtual machines).

Compute resources for organization virtual datacenters available in the service catalog should be standardized into various sizes. The required compute resource configurations vary depending on the selected vCloud Director allocation model (Allocation Pool, Pay As You Go, or Reservation Pool), because attributes such as CPU speed and CPU or memory guarantee vary. Combining these two components means that the service catalog can offer differently sized organization virtual datacenters for each type of allocation model.

Similarly, to create a vApp catalog item (public or organization), there should be as much standardization as possible. From a compute resource point of view, standard sized virtual machines should be created to use in a pick list of machines for vApp creation. These standardized virtual machines can vary in resource size for CPU, memory and storage; for example, Standard, Standard Plus, Advanced, Premium, and Premium Plus. Because a vApp is comprised of one or more individual virtual machines, the appropriately sized virtual machines can be selected from the pick list during the vApp catalog creation process.

In addition to the basic compute offerings of the virtual machines within the vApps, it is necessary to develop the service catalog to include vApp software configurations. These can be basic groupings of compute resources and can be expanded over time to offer more advanced services. Sample vApp offerings are shown in the following table.

To provide an appropriate level of service depending on the vCloud customers’ requirements, services should be further differentiated by their corresponding service levels. Service levels can be defined with availability and recoverability attributes such as Recovery Time Objective (RTO), Recovery Point Objective (RPO), and incident response times. The attributes can be applied to the different components within the service catalog.

It is possible to design for different service levels for the virtual machines contained in a vApp. For example, a vApp could contain multiple web servers to provide resilience in the event of server failure, and thus a lower RTO for the service.

Virtual datacenters provide abstracted physical and virtual resources. Different service levels can be defined by using (or not using) the underlying hardware technology (such as server capabilities, storage array technologies, storage protocols, and replication) and virtualization technology (HA, DRS, VMware vSphere vMotion®, and others).

Combined, vApps and the capabilities of the virtual datacenters on which they can be deployed offer the ability to create a powerful and extensive vCloud service catalog.