Services are the most visible part of your cloud, representing the value IT adds to the business. Your compute, network, and storage resources work together to support the services end users request through the BMC My Cloud Services Console.
The following sections provide overview information about BMC Cloud Lifecycle Management services:
Introduction to services
Services describe the functionality that an organization provides. Web hosting, email service, and enterprise resource planning are all examples of services. An IT organization provides services in the form of service offerings. For example, for a Web hosting service, a cloud administrator might create three service offerings (Small, Medium, and Large) each with different prices for deployment and maintenance. A cloud administrator creates requestable offerings for each of the service offerings he or she wants to make available in the Service Catalog. Lastly, a cloud administrator can also create options, each with multiple choices, that the end user can request to supplement a requestable offering. Each choice has an associated price.
Example service offering, requestable offering, and options
For example, from the BMC My Cloud Services Console, an end user might request the Large LAMP Stack service offering, and add options for Monitoring and Backup. The price to deliver that service is $100, and the monthly price to maintain the service is $16.
The arrangement of your services and the infrastructure services that support them is your service model. It organizes the behaviors and functional relationships of your supporting resources, and manages the delivery of the resulting services. To support a service model that complies with IT Infrastructure Library (ITIL) v3, services include several components that combine the utility (what a service does) and warranty (how the service is delivered).
Within BMC Cloud Lifecycle Management, services are presented to end users and cloud administrators from different perspectives. End users view services as the offerings they can request through the BMC My Cloud Services Console. End users see the price of the service, as well as any options they can select for that service. Cloud administrators can view services as end users do, but cloud administrators also view services structurally as the service blueprints that define the software packages and resources used to deliver a service.
Every service has an associated price that specifies the financial amount the user is charged for that service. Each service also has an associated cost that specifies the financial amount the IT organization absorbs for delivering or maintaining the service. Price is visible to all users, while cost is visible only to cloud administrators. BMC Cloud Lifecycle Management can track the charges for allocated services, but does not manage the billing process for those services.
Service offerings overview
Service offerings define what service an organization provides and how it is provided. Services can have one or more service offerings. Each service offering defines a level of service for a price: it combines the service (utility), a service level target (warranty), and add-on options.
For example, the Calbro IT organization offers a service for email hosting. In support of that service, Calbro offers different service offerings, or levels, for an email support service based on response times. Each service offering costs a different amount based on the service level targets.
Service level target type
Service level target description
Email Support Gold
5 minutes, 80% of time
USD $12 per year per instance
Email Support Silver
15 minutes, 80% of time
USD $8 per year per instance
You can also define the cost to your business of delivering the service, though only the price to users is visible in the BMC My Services Cloud Console. Price can be based on currency type, the type of charge (such as per instance or per CPU second), and frequency (such as per week or per hour).
You can define service offerings based on how you want to manage your services. For example, if managing your services by location is important to your business, you might create the service offerings for Email-US, Email-Europe, and Email-Asia. If managing services by organizations and their resource demands, you might have service offerings for Finance-Small, Finance-Medium, Finance-Large, Support-Medium, and Support-Large to customize for the different storage requirements for each organization.
In the Service Catalog, you can further define a service offering:
- Associate a service offering with a technical service.
- Add options to the service offering for end users to select.
- Link requestable offerings to the service.
- Set service level targets for the service.
All technical and business services must have at least one service offering.
Service offerings are mapped to a service blueprint and one of that blueprint's service definitions.
Requestable offerings overview
A requestable offering is an aspect of a service offering that end users can request. Like a service offering, a requestable offering defines what service an organization provides and how it is provided. Requestable offerings provide options for how IT implements the service offering. Service offerings do not require a requestable offering but can have one or more. Each requestable offering defines a level of service for a price: it combines the service (utility), a service level target (warranty), and add-on options.
For example, the Calbro IT organization creates the following requestable offerings for its email service:
- Create a new account.
- Reset an account password.
- Increase the inbox size limit.
- Backup and restore email.
The Calbro Finance group has the silver email service offering. An end user cannot see or choose a service offering, such as gold or silver, but he can select from the requestable offerings. He already has an account, but because he deals with budget requests from several other groups, he needs a higher quota on his inbox size.
To deploy a requestable service in a cloud environment, the Service Catalog enables you to map service blueprints to the service offerings. The service offerings defined in the Service Catalog would utilize different underlying service blueprints.
BMC Cloud Lifecycle Management includes the following types of requestable offerings:
- Request definition — Describes the details of the service offering, including the name, description, and one-time delivery price (which is different from the service offering price that describes the ongoing maintenance price). The cloud administrator can define only one request definition for a particular service offering, and a request definition must be created for the service offering to be available in the BMC My Services Cloud Console. Request definitions can be added to packages.
- Post-deploy action — Represents an action an end user can take on a service instance after it has been provisioned. For example, after a LAMP stack has been provisioned, the user might request a different amount of memory or CPU. Post-deploy actions are not required, and the cloud administrator can create any number of post-deploy actions per service offering. Certain restrictions apply to post-deploy actions depending on your operating system.
Combining request definitions and post-deploy actions in a service offering allows the cloud administrator to provide a flexible service that meets end users' needs.
Inside the Service Catalog, the primary purpose of configuring Option Choices is that the cloud administrator allows end users to modify the services they are requesting to meet their specifications. For example, you decide to set up three variations of the Apache server service offering with 0GB, 2GB or 4GB of additional disk space. By using Option Choices, you only need to specify one Service Offering and one Blueprint Deployment model (DM). You then configure three option choices — 0GB, 2GB, and 4GB.
You can also open the Option Choices editor from inside a service offering by clicking the Options tab.
As a result, when end users request a service for a new Apache server, their options are not constrained by the underlying service blueprint. Instead, they can modify the request to specify a Web NIC or additional disk capacity.
If you do not use Option Choices, you need to specify three Service Offerings and three Blueprint DMs — one each for each GB disk space. If you include a 1 CPU, 2 CPU, or 4 CPU configuration, the number of configurations then increases to nine. The immediate benefit for the cloud administrator is that Option Choices reduce the proliferation of service offerings and service blueprints that you need to configure in typical cloud environments.
In the Service Catalog, you can create options for service offerings (request definitions), requestable offerings (post-deploy actions), or any request. An option has one or more choices, each of which has cost and price information. These options and their choices are used when end users make a request in a request console, such as Service Request Management. They are managed separately from offerings because they do not rely on a specific offering. You can reuse options across offerings. You can use any number of options in an offering.
You can also group options into categories visible to end users. For example, a Hardware category might include options for CPU and memory.
Finally, you can set an icon to display the option when a user requests it in the Service Catalog request portal (under Service Instances).
You can use the Blueprint Configuration Editor of the Service Catalog to map options to service blueprints, enabling users to override the original value defined in the service definition. For example, when mapped to the related deployment mode, a memory option choice of 4GB can enable the user to request more memory than originally defined for that definition.
Fulfillment options include:
- A change to a service blueprint's definition, such as adding software packages, and tagging service definitions to assist with policy-based placement.
- A change to a service blueprint's service definition, such as a resource-set change for memory or CPU, and tagging definitions to assist with policy-based placement.
Entitlement packages overview
An entitlement package is a group of requestable offerings that can be mapped to tenants. This makes it easier for service providers to partition and manage services created specifically for various tenants. Cloud administrators can define a simple model for entitlement packages, in which all offerings are mapped to a single entitlement package that is available to all tenants. In a more detailed model, the cloud administrator might associate certain offerings to one tenant, and other offerings to all tenants, with a separate entitlement package for each group of offerings.
Service Catalog overview
ITIL V3 has raised the importance of service lifecycle management and the need to align IT with business goals. Creating a service catalog has two main challenges. First, customers and partners need to know clearly what services IT offers and what it does not. One reason is that services are fragmented, and service information is managed in different places or silos. Process and end user information is managed in one place, service level management is managed elsewhere, and another application manages costs.
Second, service models tend to focus on the infrastructure and on the technical services and associated CIs in an environment. The focus is on the supporting services and details and not on the business services. For example, when a particular server fails, an IT staff member might not know the business service that is affected, such as the ability to book orders. In this situation, the service model and the service catalog present only a partial view of the services.
As a result of these challenges, an IT user cannot view the whole service. Rather than design a service catalog starting with the CIs, ITIL V3 requires starting with the business service. The Service Catalog allows you to overcome fragmentation and to provide a more complete view of services:
- Focus on services to generate better business results.
- Create a catalog of services in which you manage cost, quality, and value.
- Use a common language for IT and businesses to communicate clearly what IT does and does not do.
Service blueprints overview
The following sections provides an overview of service blueprints.
What are service blueprints?
When contractors build houses, they use blueprints designed by an architect to guide them. The blueprints typically contain a variety of specifications: one house might have three bedrooms and two baths, while another house might have only one bedroom and one bathroom, and so on.
In the same way, service blueprints enable you to design, manage, and build the underlying components, operations, and server groups that define services users can request. When creating a service blueprint, you define the service and how it is deployed. You define the topology (number of tiers), configuration, operating systems, and software packages that need to be provisioned to "stand up" an application or server. You also specify one or more ways in which the blueprint could be instantiated when it is provisioned.
For example, in a blueprint for a pet store application you might want three versions—Small, Medium, and Large—mapped to a single service offering in the Service Catalog. The Small version for the pet store application might use a single server group that consists of one virtual machine (VM) to support all three tiers: web, business logic, and database. In contrast, the Large version might distribute the application component to three different server groups, each corresponding to a different application tier. (For example, the web server and application server might be on VMs while the database server is on a physical Solaris computer.) You can define several scenarios for that service with a single service blueprint.
You can add and configure the following components in a service blueprint:
- Applications, such as software packages
- PaaS resources
- Load balancers
- IP endpoints and virtual LANs
- Other service blueprints
Each service blueprint has properties that enable you to define the following aspects of that service blueprint:
- Tags that serve as metadata to associate the service blueprint with components and server groups, and to control how resources are used during service provisioning. For more information, see Managing blueprint tags.
- Parameters that pass data to the software, scripts, and BMC Atrium Orchestrator workflows included in the service blueprints. For example, you might require an end user to enter a Webmaster email address when requesting a Web server service. For more information, see Configuring service blueprint parameters.
A service blueprint definition is a cloud construct that describes how resources (such as VMs or physical systems) are assigned to instantiate a service. A service blueprint can include one or more definitions. Use definitions to specify different options for application deployments. For example, a service blueprint definition for a service in a development environment might not include certain security software and may use a PostgreSQL database on a single server, while a definition for that service in production would include the security software and an Oracle Enterprise database, spread across multiple servers.
Each definition uses one or more server groups, each of which represents one or more physical servers or virtual machines. A small definition might use only one server group to support all the components, but a large definition might use one server group per component. A server group must have one or more components that define a list of requirements on the IT infrastructure. The following figure illustrates a definition in which a web server and application server are deployed to a VM, but the database server is deployed to an actual physical system.
You can define the following aspects of a definition, as described in Creating, copying, or editing a service blueprint.
- Properties, such as its name, tags, and description.
- Parameters that pass data to the software, scripts, and BMC Atrium Orchestrator workflows included in the service blueprints. For more information, see Configuring service blueprint parameters.
- Operations that start or stop software defined in the service blueprint.
- Postdeployment actions, such as the installation of software.
- The sequence in which components in the configuration are deployed.
Blueprint Library and versioning
When you define a new service blueprint, you do so locally. When you are satisfied with your service blueprint, you check it in to the Blueprint Library, a centralized collection of service blueprints, where it can be viewed and checked out by other cloud administrators. When you check out a service blueprint from the Blueprint Library, BMC Cloud Lifecycle Management creates a copy of that blueprint available to you for editing. While you have a service blueprint checked out, other administrators can view the most recently checked-in version in the Blueprint Library, but cannot edit, retire, or delete that blueprint as long as you have it checked out. When you check in a service blueprint, a new version of that blueprint is created in the Blueprint Library. When you create a service, you determine the version of a particular service blueprint you want to use for that service. For more information about creating services, see Creating cloud services.
Reusable service blueprints
BMC Cloud Lifecycle Management supports the ability to reuse service blueprints within other service blueprints, enabling you to reuse a common structure across several blueprints. For example, if you frequently define a Web server and database pair in your service blueprints, you can create a service blueprint for that pair, and then reuse that pair as an object in other service blueprints.
You can even reuse a service blueprint that reuses another object (or multiple objects). For example, a service blueprint might reuse a service component and a compute resource. If you reuse that service blueprint as an object in another service blueprint, the service component and compute resource are included as part of that object.
When you reuse an object from the Blueprint Library, it is outlined with a dashed line to indicate that it cannot be edited from the service blueprint in which it is reused. You can choose which checked-in version of that service blueprint to reuse. Optionally, you can choose to always use the latest version. If you choose the latest version, your service blueprint is updated whenever a new version of the reused service blueprint is checked in.
In addition to full service blueprints, you can save the following as reusable objects:
- Applications—These appear in the Application Blueprints section of the Blueprint Library.
- Servers—These appear in the Server/PaaS Blueprints section of the Blueprint Library. When a compute resource is reused, BMC Cloud Lifecycle Management provides an editable server group around that compute resource.
- PaaS resources—These appear in the Server/PaaS Resources section of the Blueprint Library.
Within a definition of a service blueprint, you define how components communicate with other components by specifying the source and destination components in a connection. For example, you can create a connection between a Tomcat server and an Oracle database. Connections are drawn as lines in the Service Blueprint Designer, with an arrow indicating the direction of the connection. Connections are unidirectional from source to destination. The following figure shows that:
- For Connection 1, Component 1 is the source and Component 2 is the destination.
- For Connection 2, Component 2 is the source and Component 3 is the destination.
Source-Destination connection examples
The first connection you make from a server must be a network placement between the compute resource and a network, defining the first NIC in use for that compute resource. After the first NIC is defined, any future connection lines from that compute resource can be another network placement (defining another NIC) or a network path.
When you add a load balancer pool (LBP) to a service blueprint, you determine whether the LBP will be associated with a server group in that blueprint. If so, that LBP is created when the server group is deployed and is typically used to load balance the servers in that group. If the LBP is not associated with a server group in the blueprint, then BMC Cloud Lifecycle Management will not create the LBP when the service is deployed. Instead, BMC Cloud Lifecycle Management will search for an existing LBP with the name specified in the blueprint, and will create entries in that LBP based on the entries in the blueprint. When creating network connections that involve LBPs, you can create a network path or a network entry between a compute resource and a LBP associated with the same server group. If the LBP is associated with a different server group than the compute resource, you can create only a network path. If the LBP is not associated with a server group at all, you can create only a network entry to the compute resource.
You can also create connections between applications. For example, if you have a two servers, one with an Apache Web server application and another with a Tomcat application, you can draw a connection between those applications and specify the port numbers to use on each end of the connection. If you want to create a network path based on that connection, you can create that network path directly from the application path in the Service Designer. If you choose not to clone the application connection to a network path, the application connection serves only documentation purposes to allow those viewing the blueprint to see that a connection between the applications is needed.
For more information about defining connections, see Creating, copying, or editing a service blueprint.
As part of a service blueprint you can specify the sequence in which applications and other service blueprint components are deployed when a service is requested. Network connections are automatically created immediately before any software is installed. If you do not specify a deployment sequence, service blueprint elements are assigned the following default deployment sequence:
- Server groups (in parallel)
- Network paths
If you include a blueprint in another blueprint, the sequence specified in the reusing blueprint shows the included blueprint as a single unit. However, the deployment process respects the deployment sequence of the included blueprint when the service is provisioned.
As part of a service blueprint you can specify BMC Atrium Orchestrator workflow to be run after a service has been provisioned. For example, you can run a workflow to create directories on a disk. You can add postdeployment actions to the following pieces of a service blueprint:
- Service blueprint properties, applicable to all definitions of the service blueprint
- Service blueprint definitions
- Server groups
- PaaS resources
When you define a postdeployment action, you must include any parameters that the action requires. Use the delineated AO Workflow path <Module>:<Name> (for example, MyProvisioningActions:UpdateDNS). You must ensure that the AO Workflow you define in a service blueprint is actually available in BMC Atrium Orchestrator. For more information about BMC Atrium Orchestrator workflow, see the BMC Atrium Orchestrator online technical documentation. For information about context items and parameters, see the BMC Atrium Orchestrator online documentation on context items and System parameters.
Additionally, you can specify NSH scripts to be run as postdeployment actions for servers. For more information, see Parameterizing NSH scripts.
Where to go from here
Related BMC Communities blog entry
The following link provides supplemental information available from a blog entry in BMC Cloud Lifecycle Management Communities:
This blog entry discusses how to configure entitlement for a Tenant’s users, whether they belong to the same department/Organization or different, so that they can see different Service Request Definitions/Rquestable Offerings assigned to them.