Resource blocks in Cloud Provisioning and Governance

Release version: Xanadu

Updated August 1, 2024

6 minutes to read

Summarize

Summarized using AI

Summary of Resource blocks in Cloud Provisioning and Governance

Resource blocks serve as middleware components connecting catalog items, Cloud API (CAPI), and the CMDB within ServiceNow Cloud Provisioning and Governance. They are fundamental building blocks used to create blueprints, which become catalog items (stacks) available for provisioning through the Cloud Catalog. Each resource block corresponds to a CI type in the CMDB and manages operations such as Provision and Deprovision by interacting with CAPI and processing cloud provider responses to update the CMDB accordingly.

Show full answer Show less

Resource Block Connectivity and Interfaces

Resource blocks connect vertically and horizontally within blueprints using defined interfaces and bindings:

Guest interface: Connects to the resource above and provides operation signatures for actions users can perform.
Host interface: Connects to the resource below, also containing operation signatures.
Bindings: Link adjacent resources, configured unidirectionally on specific resource blocks.

Vertical connections (containment) require matching host and guest interfaces, while horizontal connections (attached-to) bind resources residing on the same parent resource block.

Guest Interfaces and Operations

Guest interfaces provide default operation signatures enabling users to manage resources. Common operations include Provision, Deprovision, Start, Stop, Cleanup, ModifySchedule, and ModifyLease. These enable users to create, manage, and remove cloud resources through the provisioning process.

Resource Block Components and Operations

Each resource block consists of:

Layers: Logical stack layers to which resource blocks belong, selectable during configuration.
Operations: Defined for each guest interface, consisting of steps that call specific CAPI interfaces and methods.
Input parameters: Values provided by users or processes (e.g., datacenter location) that are passed to CAPI methods.
Steps: Detailed actions within an operation that execute CAPI calls; multiple steps can be chained with output attributes passing data between them.
Response processors: Scripts that handle cloud provider responses and update the CMDB accordingly, such as creating or updating CIs.

Provisioning Workflow

When a user requests a stack from the Cloud Catalog, the system triggers the Provision operation across all resource blocks in the blueprint. Each step in the operation calls CAPI to interact with the cloud provider's API, which provisions the resource. Responses are parsed and used to update the CMDB, ensuring the infrastructure is accurately reflected in ServiceNow. The provisioned stack then becomes manageable via the cloud user portal.

Managing and Extending Resource Blocks

Resource blocks are managed via the Resource Blocks page under the Cloud Admin portal. Customers can:

Create custom resource blocks if existing ones do not meet provisioning requirements.
Configure input parameters, operations, steps, and output attributes to tailor resource blocks.
Add resource scripts to perform actions during deployment or update the CMDB post-deployment.
Extend guest interfaces by adding override operations or creating new interfaces with custom operations.
Configure response processors to handle cloud responses for accurate CMDB synchronization.
Integrate Terraform orchestration interfaces to enable operations via Terraform templates after activating the Terraform store app.

Examples and Use Cases

Resource blocks can be created for specific cloud platforms, such as Microsoft Azure, based on CMDB CI types. They are designed to model complex cloud resources and their relationships (e.g., virtual servers attached to storage within a datacenter) to enable robust, reusable cloud catalog items.

Resource blocks act as a type of middleware component between catalog items, the Cloud API (CAPI), and the CMDB.

The following graphic illustrates how resource blocks fit between other components in the system:

Resource blocks in the cloud provisioning and governance environment

Blueprints: Each resource block becomes a building block within a blueprint. The blueprint eventually becomes a catalog item (also called a stack) that a user provisions from the Cloud Catalog.
Cloud API (CAPI): Each resource block defines allowable operations, such as Provision and Deprovision. These operations call various components within CAPI to carry out the operation that is received from the stack.
The CMDB: Each resource block is based on a CI type from the CMDB. Resource blocks also have a response processor that handles responses from the cloud provider to take some type of action in the CMDB, such as creating or updating a CI.

How resource blocks are connected

Resource blocks are connected to each other in blueprints. For example, in this blueprint, a virtual server resource block is connected to storage. The virtual server and the storage are both connected to an AWS datacenter resource block.

For these connections to be successful, each resource block needs to specify a type of interface. This graphic illustrates these interfaces:

Resource block interfaces — Figure 2. Types of interfaces for resource blocks

The guest interface connects to the resource that is above it. The guest interface contains the operations (also called operation signatures), which allows users to take action on their resource.
The host interface connects to the resource below the resource block in the blueprint. The host interface also contains operation signatures.
The bindings connect adjacent resources.

Resource blocks can have as many guest interfaces, host interfaces, and bindings as necessary. Connections can be made in different directions:

Vertical connections require the top resource block to have the same host interface as the bottom resource block guest interface.
Note:
In blueprints, this vertical connection is called a containment connection.
Horizontal connections bind one resource to another, but both resources have to reside on top of the same resource block.
Note:
In blueprints, this horizontal connection is called an attached-to connection.

The same example blueprint with a virtual server with attached storage on an AWS datacenter, the resource blocks are configured as this graphic illustrates:

Figure 3. Interfaces for resource blocks


Resource block	Interfaces and bindings
Virtual server	Host interface: Compute Binding: to Storage Volume
AWS Datacenter	Guest interface: Compute Guest interface: Storage Server interface
Storage	Host interface: Storage Server interface The binding between the virtual server and the storage is unidirectional. You configure the binding on the virtual storage resource block only by specifying the storage resource block. You do not need to configure another binding on the storage resource block.

Guest interfaces and operations

Each guest interface provides a default set of operations (also called operation signatures) that allow the user to choose what they want to do with a virtual resource. The most common operation is Provision, which means that a virtual resource is created. Many guest interfaces and corresponding operations are provided by default with the Cloud Provisioning and Governance application. You can use these default guest interfaces for many of your resource blocks.

If you do need to create a new guest interface, these operations are provided by default:

Start
Stop
Provision
Deprovision
Cleanup
ModifySchedule
ModifyLease

Resource block component details

Each resource block contains these components:

Layers

The logical layer in the stack that this resource block belongs to. By default, Cloud Provisioning and Governance provides the layers. When you configure resource blocks, you can choose the one that relates to you.

Operations for each guest interface

As mentioned, each guest interface provides operations. For example, the most common operations for a virtual server are Provision, Deprovision, Start, Stop.

Input parameters for each operation

The input parameters hold values that the cloud provider uses, via CAPI, when operations are run. These parameters hold the information that the user selects while performing an operation, such as provisioning, on a stack.

For example, a user typically must specify the location, which is a datacenter, that a stack belongs in. The value that the user selects in the Location field is held in the Location parameter. The system takes this parameter, which is available by default for the virtual server resource block, and passes it to the CreateNode CAPI interface operation. The CreateNode interface operation tells the cloud provider to create (or provision) the actual virtual server.

Steps for each operation

Each operation requires a step to do the actual work. Each step calls a specific interface and method in CAPI, and passes along the input parameters required by that method. For example, the Provision operation on a virtual server provides one step to first connect and create a virtual machine, and another step to create the node in the cloud provider. Each step provides different input parameters. To connect and create a virtual machine, the cloud account, among many other parameters, is required. To create the node, the cloud account is not required.

You can add as many steps as needed for each operation. You can also use output attributes to pass values in attributes from one step to another step, or from steps in one operation to steps in a subsequent operation. For example, the Provision operation for a virtual server can provide an output attribute for the network interface ID and another for the node ID. When the cloud provider sends the response, the actual ID of the network and node are parsed out of the response and saved in the output attributes. Subsequent steps can then use the IDs to perform actions.

Response processors

Response processors tell the system what to do in the CMDB. When the cloud provider sends a response after an operation is run, the processor handles the response.

Note:

These processors are scripts that are system includes. They are not MID Server script includes like the CAPI scripts that you can create to integrate with the cloud provider.

How resource block components work together — Figure 4. How components work together

Users can see catalog items, also called stacks, in the Cloud Catalog. A catalog item is based on a blueprint, which in turn is composed of resource blocks that are connected together.

The user kicks off the process by requesting a stack. The request is the Provision operation in the system.
The system runs the steps in order for the Provision operation for the resource blocks that comprise the stack.
Each step calls CAPI to determine which method to run, while also passing in values for necessary parameters.
CAPI interfaces with the API of the cloud provider to provision the actual resource.

Response process from the cloud provider — Figure 5. Process flow when a resource is created in the cloud provider

The cloud provider provisions the resource and responds with JSON.
The system parses the response inside the resource script in the resource block.
The system updates the CMDB. When provisioning a new resource, the system creates a CI in the correct table.
The new stack appears in the cloud user portal for the user to manage.

The Resource Blocks page

Manage resource blocks in the Resource Blocks page. Open the Cloud Admin portal, and then navigate to Design > Resource Blocks.

Resource block page and descriptions of the items in the page — Figure 6. Resource Blocks page components