When I reference ServiceNow in discussions with DevOps and platform engineers they often look at me and quickly roll their eyes – with that bored look on their faces saying “next…”
Why is that?
- ServiceNow is known as a ticketing system and as a way to automate business processes of enterprise organizations.
- Most enterprise development teams don’t even have access to ServiceNow and therefore even if they are using it in the organization developers don’t consider it as a solution for automating DevOps processes.
At Cloudify, our DevOps automation platform primarily targets DevOps engineers, who were also locked in this mindset. Over the past year and a half, we started a deeper integration between Cloudify and ServiceNow, originally as a way to address a specific customer environment.
As we got a deeper knowledge of the platform we discovered its power and more importantly learned how to better unleash this power to DevOps and platform engineering teams.
In this post, I’ll share the lessons from that experience.
ServiceNow: Noteworthy features for DevOps teams
Before diving into a specific use case I want to start by highlighting a specific set of features that we found to be highly beneficial for addressing common DevOps challenges.
- Self Service Catalog
DevOps teams can define templates for development, testing, quality assurance, and production environments, and publish them to the service catalog. From the catalog, developers can self-request the deployment of new environments. These new environments are deployed automatically, without relying on DevOps engineers to take manual action or run scripts.
- Approval Process
Any existing ServiceNow approval process can be applied to the process of requesting a new cloud environment, making it simple for authorized users to approve or reject new cloud environment requests.
ServiceNow ITOM Cloud Configuration Governance (CCG) makes it possible to continuously scan public cloud resources to ensure they remain in compliance with regulatory, security, and corporate policies. However, when policy violations are identified, ITOM CCG users must still execute remediation workflows manually or via scripts.
Using Cloudify with ServiceNow ITOM CCG makes it possible for CCG users to select from a list of available, predefined remediation processes to remediate any issues. Cloudify automatically executes these remediation processes, bringing cloud resources back into compliance quickly and easily. Cloudify can also trigger CCG scans as part of any provisioning or Day-2 workflow, to ensure any cloud resource provisioned or modified by Cloudify is in compliance with CCG policies.
- Low Code, Flow Designer, Integration, Notification, and other business services
ServiceNow Flow Designer provides ServiceNow users with a low code/ no code experience for defining business workflows that can be used consistently across various services in ServiceNow.
Cloudify takes advantage of Flow Designer to build the workflows that manage the interaction between Cloudify and various ServiceNow services. The flows and subflows defined for Cloudify in Flow Designer can be reused across many workflows. Inputs to the flows can be variablized so run time properties can be passed as inputs when the flow or subflow is initiated.
- Custom API access – Allowing inbound calls from the developer’s pipeline into ServiceNow workflows
Cloudify’s fully documented REST API interface makes it easy to integrate Cloudify requests from a variety of developer-facing services, making it simple to trigger Cloudify workflows from CI\CD pipelines, which in turn trigger ServiceNow workflows, such as approval requests and cloud governance policy scans, as part of these pipelines. The result is a closed-loop cloud provisioning and governance experience that works with the tools and interfaces developers are already using in their day-to-day tasks.
- Self-service development environments.- providing a development sandbox to test and validate code
Cloudify’s integration with ServiceNow ITSM Service Catalog makes it possible for developers to self-manage their own sandbox and development environments without relying on the availability of DevOps Engineers or cloud platform subject matter experts to do the work. Developers can request the creation of a new sandbox or development environment from the Service Catalog. The cloud resources provisioned by the request are predefined by the DevOps and cloud platform engineers who know what should be provisioned and how.
Cloudify automates the process of provisioning the new cloud environment for the developer in a matter of minutes. Once deployed, developers can also execute Day 2 operations against their existing sandbox and development environments from the Service Catalog, again, without worrying about the availability of DevOps or cloud platform engineers.
If the developer needs to increase or decrease the compute power of their VM, add a message queue to an existing deployment, change the type of database used by their application, or any other desired change to the environment, it is possible to do this without active runtime effort from engineers. The engineering teams continue to maintain control over what gets deployed in the cloud and how it gets deployed.
ServiceNow is a huge platform with many more features but the list above should be sufficient to get you started and gain some real benefits from the platform.
Extending the DevOps infrastructure to non-developers
What I stated as the weakness of the platform in the eyes of DevOps engineers (i.e that it is not designed for DevOps engineers) can become an advantage once we address the integration to the DevOps toolchain per the section above.
In this context, I’m referring to the fact that the DevOps environments are usually targeting engineers that use Git and CI/CD pipelines as their main interface.
However other stakeholders, such as managers who need to be part of an approval or governance process, as well as other users, such as sales or marketing teams, may need access to the same products used by the DevOps team but would need a simple interface as they often don’t have access to CI/CD nor feel comfortable running infrastructure as code.
ServiceNow fills in the gap perfectly through the Self-Service Catalog as well as the ability to customize those environments through the ServiceNow no-code/ low-code Flow Designer interface.
Cloudify as the bridge between DevOps and ServiceNow users
Cloudify fits a middle layer that connects the DevOps pipeline and the ServiceNow self-service portal.
That means that all the remote execution needed to provision and update infrastructure resources goes through Cloudify regardless if the request is coming from a CI/CD pipeline or from a Rest API call from ServiceNow.
This means that the state of the workflow also remains consistent between those interfaces and therefore, would allow it to handle interoperability between those two sources.
Below are specific use case descriptions that illustrate how this integration works.
Use Case 1: Using ServiceNow implicitly as part of the DevOps pipeline
In this use case, a developer triggers a provisioning request through a CI/CD pipeline.
That request will then be routed to ServiceNow for approval and once approved it will be routed back to Cloudify to continue that workflow exactly from the point it left.
This method of integration is also referred to as inbound workflow. In this case, ServiceNow appears as yet another chain in the pipeline. The developer doesn’t need to get any access to it and all the integration is done through API and is handled implicitly by Cloudify.
Use Case 2: Using ServiceNow as the front-end interface to trigger the DevOps toolchain
In this use case, we are using ServiceNow as the front-end interface.
A ServiceNow user uses the ServiceNow catalog to trigger a provisioning request through Cloudify. Once triggered the provisioning workflow will be exactly the same as the one triggered through the pipeline and therefore the state of that request will be consistent between the two systems. This is key to closing the loop between the initial provisioning request and the approval process.
Use Case 3: Post-deployment remediation
Once a provisioning request has been completed Cloudify will use the inbound interface to call back to ServiceNow ITOM Cloud Configuration Governance (CCG) to trigger a governance policy scan or a discovery process.
In the event a newly provisioned resource is out of compliance with cloud governance policies, the cloud governance policy scan initiated in ITOM CCG by a call from Cloudify will identify the non-compliant resource and create an audit issue for the resource. Cloud governance managers from an organization’s Cloud Center of Excellence (CCoE) can easily identify the non-compliant resource and select a remediation workflow to bring the resource back into compliance. ITOM CCG triggers Cloudify to execute the remediation workflow automatically. Once completed, Cloudify closes the loop by notifying ITOM CCG that the audit issue has been remediated.
What’s coming up next?
- Major enhancements to ServiceNow UI/UX experience
- Adding token-authentication that was introduced in 6.4
- Making the catalog item creation (customization easier)
- Adding support for new inputs types (deployment creation, manage environment, update environment)
- Adding inbound rest integration inside the application
- Adding 2 Admin Tasks Catalog Items (resume/ cancel executions)
- Some enhancements to data consistency due to updates to flow designer behavior change
- Adding the discovery REST APIs -to trigger pointed discovery for specific resource with custom types
The reason why ServiceNow hasn’t been considered as part of the DevOps toolchain is in many cases a result of the legacy organization structure and lack of knowledge of the platform and its capabilities.
There are a lot of benefits that come with integrating the DevOps pipeline with the ServiceNow platform as I outlined above.
Cloudify fills in a big void in that regard, by providing a shared provisioning and state management platform that is key to bringing those two worlds together.