Cloud Provisioning used to be done through deployment definitions (aka blueprints) which an infrastructure designer had to physically craft in a design canvas.
I say this used to be done as the approach has changed over the years, to do this through code. When written as code (JSON, YAML or even high-level procedural scripts), infrastructure definitions are easier to transport across multiple environments, easy to version and test. There are open or well-accepted, well-known standards in the cloud-native world such as cloud formation templates (CFT) for AWS, and Azure resource management (ARM) templates and again there's multi-cloud, horizontal technologies like Hashicorp's Terraform - with commercial (TF Enterprise - TFE) and open-source versions (TF Opensource - TFO). Many app dev teams nowadays use cloud templates such as these in their application builds.
Here's a schematic indicating ServiceNow's cloud provisioning and cloud operations flows along wth technologies supported.
How exactly does this work - you might have read earlier blog/articles on this topic, that show how we are able to understand variables in the IaC template and translate these into equivalent form variables in catalog item while linking this to CMDB resources. Of course, using a catalog item brings all the ServiceNow richness of control and governance into the picture - this is what I call our infrastructure deployment and management, with guardrails. The app dev teams will order the stack from ServiceNow through API instead of going to the cloud directly thereby ensuring consistency and conformance to the organizational norms.
Here's the big news -
Dear ServiceNow Cloud Management customers, I am happy to announce the latest version of the Terraform Connector for CPG loaded with some amazing features -
-
Support for AWS cloud with Terraform OSS and Enterprise
-
Support for VMware cloud with Terraform Enterprise (OSS supported from before)
-
GitLabs source code repository with TFE (GitHub supported from before)
-
Sharing workspaces across deployments - this way, you can reduce their workspace licensing costs with Terraform Enterprise
-
IaC Discovery schedule - for detecting changes to IaC sources, and creating 'change' tasks
And very importantly -
-
Change Governance for IaC (Terraform) templates
This one is a key improvement so as a ServiceNow catalog item designer you are able to handle changes done by app dev in their IaC, and effect these in the ServiceNow cloud catalog items.
Let's understand change governance some more...
Assume that the app dev team initially starts their development assuming the infrastructure needed is a 2-node cluster in the cloud. This would be defined in IaC and used as a catalog item in the ServiceNow provisioning context. Now the app dev team is told that they need to work with an elastic cluster, can't always assume 2-node cluster is sufficient - so, an IaC specification change is done, to use elastic clusters, along with needed app side design changes to make it handle higher loads. However, how can this and more changes like this be effected easily into the ServiceNow provisioning workflows? This is where our change detection comes into the picture, CPG picks up changes done in the source code by connecting with the version control system, and assigns 'change tasks' for approval. Once it is reviewed to ensure the change is valid and compliant to enterprise policies (e.g. cost, OS image, hardware type, tags etc), the catalog item can be updated to automatically reflect the change in IaC, in 1 step. We provide a workflow in the newly introduced Admin Portal view - IaC -> Change Task UI for this. Complex changes would require a new catalog item to be created with the old catalog item automatically getting disabled, this is also taken care of.
Change Task - sample (closed task)
The narrative on how we handle change - best explained through a flowchart
The guiding principles are -
- As app code changes software-defined infrastructure will change in nature and context
- Changes must be updated in catalog items ordered through ServiceNow
- Changes can be small or large and handling will vary in such cases
Sure, in order to ensure that there's no unexpected outage and non-availability of catalog items in production, keep the production-grade catalog item sacrosanct, and only update the non-production catalog items during a sprint cycle. the production-grade catalog item will be updated at the end of a sprint or during a release management phase. this is depicted through this schematic below. this is akin to most DevOps teams' app dev phases and so it does not cause any additional work for these teams.
The outcomes
With this approach to change governance, you can use ServiceNow cloud provisioning and governance to achieve the following results.
- Automation - Scheduled artefact discovery, prevent failures due to ungoverned change
- Governance - Get changes approved through CAB, interact via change task
- Higher cloud agility - Keep offerings up-to-date with the app builds non-intrusively
Our doc page is here.
Please try out the new app version from our store, and please share your feedback.
Ram Devanathan
ITOM product Management
