How To Create Related List In Servicenow

You are not a cool developer if your code is not running behind a couple of levels of virtualization by now. The ability to run consistent environments for test to prod, automatically managed, scalable and controlled by code. Then the power for developers to push code through that platform from start to finish in a reliable way without significantly breaking it. Isn't that dreamy?

Yet beyond all levels of abstraction is a serious gap between the old and the new. For many large companies, DevOps is treated as an isolated pocket and enterprises are still relying on traditional technologies such as Hybrid-IT, VM's, CMDB's and infrastructure running aside their microservices. The question then arises, how do we combine these worlds into the ServiceNow data model?

That's what this article is about – and I can give you an answer already now; with some creativity.

Customizing the CMDB for microservices & API's

The first thing we need to figure out is how we are going to represent our microservices in the CMDB. In order to do that we must understand in which context they will be used and by whom. Who will visit ServiceNow to view them and why? For example:

Are we only going to report incidents on the microservices and nothing else?
Are we going to raise changes towards them?
Will they tie into a bigger picture of infrastructure and other dependencies?
Or will we actually use ServiceNow as the place to de facto document our microservices, their purpose, endpoints and all that comes with it? In other words, will ServiceNow be the central location to do so?

Depending on the answers to these questions we can quickly determine that no out-of-the-box class for microservices exists for this purpose. One could, of course, make the argument that a microservice is merely a fancy name for a small application, and whilst this is true – the CI class "application service" is in my opinion still not a good candidate. Soon you will see why.

Format for documenting microservices in the CMDB

How do we actually define a microservice or API? Most of the time, a microservice contains a few basic definitions. Although you might find different answers to this question, it exists some pre-defined, widely used standards out there which we can rely on, such as the industry-standard OpenAPI from Swagger . According to a 2019 State of API survey, it was found that nearly 70% of respondents are currently using the Swagger/OpenAPI standards for defining their APIs.

Reading the standard we can see there's a lot of potential attributes – so let's keep it basic to start with. It can always be expanded on depending on your needs.

Basic fields- and references

Name - name of the (micro)service
Description - A short description of the application.
termsOfService - A URL to the Terms of Service for the API.
Contact – reference field to company/sys_user
License - The license information for the exposed API.
Version – The version of the API
Servers – A related list of Server Objects, which provide connectivity information to a target server.
Paths - A related list of the available paths and operations for the API. It can also be referred to as endpoints.
qualityAttributes - the service's quality attributes, also known as non-functional attributes. For example SLA's or commitments.
Run time information - instance/connections count (hook into the config/registry server)

The picture that starts to form is a custom CI class which contains the above attributes and information. Let's name the CI class "microservice" and agree that the "application service" class is not cut for the job.

No alt text provided for this image

Updating microservices in the CMDB – the lifecycle

What happens if you have hundreds if not thousands of microservices? Surely we can't maintain and update the CMDB manually or expect developers to login to ServiceNow and update the microservice information every time something changes. I rather burn in a pit of fire.

In order for this to function, it must be easy to register services dynamically using many convenient methods. For example from a CI/CD pipeline, inside a docker image, chef, ansible or wherever it makes sense. But how? This is where it gets fun.

A microservice to document microservices

One smart way to achieve this is to create our own "microservice" API who's only role and purpose is to document microservices in our CMDB. And what is not a better candidate than to use ServiceNow scripted REST API to do so? From the scripted rest API, we can create our own API directly in ServiceNow that can be called from various sources (and by various developers).

As such developers can easily replicate microservice information and attributes to ServiceNow CMDB with some JSON magic and simple REST calls. So every time something get's deleted, created or modified it would also be thrown over the fence to our API to register it. May it be a version change, endpoint or instance/connection count.

No alt text provided for this image

Where to go from here

Using the OpenAPI as a standard for defining our microservices is a great first step. Creating related list of paths, servers, and many more objects or fields based on this standard is more than doable. The leap to start drawing out relationships between the microservices is not far from there. As we have them in the CMDB we can leverage the relationship table and leverage our REST API to create- and maintain parents/children.

With discovery on top that natively can discover docker, kubernetes and more you would get a pretty complete picture. It might seem like a lot of work but the truth is that it's very hard to "discover" microservices in a consistent manner as it's an abstraction which we all define differently, just like a technical application. But with the above methodology, you can hopefully get some inspiration on how to approach this topic.

Final thoughts

One could question the value of CMDB in the year 2020 in the world of microservices. My personal take on the CMDB is that it doesn't make sense to use if you are a software company that run the majority of your application stacks as microservices, 100% in the cloud and not caring about infrastructure. Yet for the vast majority of big enterprises who are trying to mix their traditional IT with DevOps, doing some small customizations to the ServiceNow CMDB might generate very valuable results and ensure buy-in from DevOps- and operations team alike. It's dynamic enough to support it.

What is your opinion? Please comment below as I'd love to learn more from others out there.