Service blueprints overview

This topic provides an overview of service blueprints. The following topics discuss two key elements 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
Servers
PaaS resources
Networks
Load balancers
IP endpoints and virtual LANs
Other service blueprints

Service properties

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.

Definitions

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.

Deployment definition

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.

Connections

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.

Deployment sequence

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
Applications

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.

Postdeployment actions

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
Servers
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.