Change Management — From a Business Request to Fulfillment ServiceNow & Cloudify

Introduction

Change management is a process that changes an existing environment after it is created. It is also called a “Day 2” update scenario. Typically, it starts from a business user submitting a change request ticket in ServiceNow to apply to an existing environment. The process starts by picking an item from a catalog, changing the right parameters and applying the change, as will be described later. For common changes, a good catalog management allows adding a “change request” including its parameters as a new catalog item that can be reused.

What is an environment or more precisely, what is EaaS? EaaS — Environment as a Service — is a templated set of resources grouped into an environment. Environments can be created, used and deleted.

Environments are flexible and can contain any combination of resources. Resources are created when the environment is created, and deleted when the environment is deleted.

For example, an environment can include a Kubernetes cluster plus a Node.js and a Postgres DB running on top. Another example is a 5G edge site, a gNodeB instance that runs a Kubernetes cluster and a DU (distributed unit) RAN (radio access network) service on top.

Cloudify manages the environment life cycle (LCM) and it includes the life cycle operations defined for the environment like init, configure, start, stop, update and delete life cycle operations. Each operation manipulates the resources associated with the environment.

Environments can be modified after they are created which is referred to as a “Day 2 update scenario”. For example, you can add additional resources like an AWS SNS (simple notification service) to an existing environment. Another example is changing the parameters of an existing environment like scaling a Kubernetes environment by increasing its node’s pools.

In this blog we will describe how we can apply a change management update scenario into an existing environment. In my previous blog I described how we can instantiate 5G environments from core to edge, covering both open5GS core and gNodeB edges.

The example environment that is changed is a 5G core environment, composed from a Kubernetes cluster running 5G core services on top. We are going to modify the 5G slice parameters, as shown in the figure above, item #3 flow — “Day 2 slice update + approval”.

Cloudify & ServiceNow Platform

The trigger starts when a business owner opens a change management ticket in the ServiceNow platform. When approved, it’s executed by Cloudify to fulfill the request.

On the left side of the figure below, we see the ServiceNow catalog with Cloudify’s environment and the available operations like; create, update and delete an environment. On the right side we see three environments, already created and placed with their locations on the map, (the green bubbles). The three mapped environments are a 5G core, and two gNodeB edge sites, each including a Kubernetes cluster and 5G services running on top.

Triggering Environment Update from a ServiceNow Platform

The change management update scenario begins by choosing “Update Environment” from the ServiceNow catalog. Then you pick the environment to which you would like to apply the change. It presents you with the current environment’s parameters which can be changed. In the figure below we choose to update the 5G core slice parameters and we submit the update, then a ServiceNow ticket is created.

The Approval process

Such a change is a major change which impacts the whole system and requires a manager’s approval. This is a workflow handled by ServiceNow as described in the figure below.

The Actual Execution

After the change is approved, the actual execution starts. Cloudify is integrated with ServiceNow platform and is being called as part of the workflow to apply the change. Cloudify keeps the environment details as a DAG (directed acyclic graph) in memory. This is an execution model based on TOSCA — Topology and Orchestration for Cloud Applications.

The two figures below show the call to Cloudify upon service approval and starting the update workflow process in Cloudify. In the second figure you can see that the update workflow started on the 5G core environment.

Cloudify in turn communicates with the AWS cloud to update the environment. In this case, Cloudify interfaces with the AWS CodeBuild to set up the required resources. This is shown in the figure below.

We can track the workflow execution in Cloudify. Now the environment is updated and the right resources are created. The updated workflow is complete.

You can also see that the CodeBuild finished successfully in AWS

To close the loop, ServiceNow platform is notified for the successful update of the environment and the ticket is closed, as seen in the figure below.

Summary

This blog demonstrates a change management update workflow for EaaS (environment as a service) that is:

• Initiated by a business owner from the ServiceNow Platform
• An environment represents the resources in it. In our example it is a 5G core environment running a Kubernetes cluster and Open 5GS services and pods on top.
• The environment update is part of an environment LCM, life cycle management: init, configure, start, update, stop and delete operations.
• We followed closely the end-to-end process, from initiation by a business request in the ServiceNow platform, approval, execution and fulfillment by Cloudify.
• The change management could be applied to any EaaS (environment as as Service) whether it is a development environment or a production environment.