Overview
In recent years, the approaches to Service Mapping have become more diverse. Traditionally “Top-Down” Service Mapping (which uses patterns) was the approach. This of course is often complex and can be pretty challenging to implement. This led to Customers asking for a quicker time to value, while still giving them the opportunity to have a “Service Aware” CMDB. As a result of this and through new capabilities delivered by the Now Platform, the newer approaches to Service Mapping were introduced - Tag-Based, Machine Learning suggestions, Dynamic Groups, Dynamic Services - and while some of the complexity has been removed from implementing Service Mapping through these methods, it can be still be daunting deciding which approach to apply! That’s where this article comes in.
Considerations
Firstly - this is intended to complement the guidance found in the Product Documentation here - so if you haven’t read that yet, do so and come back… Now you’ve considered that, you can review the decision tree and the detail which follows.
Decision Tree
Here's a basic flow I put together with Miro to visualise how you might like to select your Service Mapping approach. Each area has some more detail highlighted in the sections following.
Container or Virtualisation
If your target service runs on Cloud, or some virtualisation (vCenter) or containerisation (Kubernetes), you won’t be able to leverage top-down mapping. You may be prohibited or it might not be possible at all. Therefore, in all instances you’ll be looking at tag-based mapping. There are plenty of great resources to help you with that, but in short - you’ll:
- start by reviewing (or implementing) the tagging policy,
- Implementing tag categories in which you call out the keys you are looking for
- Add those categories to a Service Family
- Filter the values of the keys (the tag categories) you have added, if appropriate - for Production, certain Application names or so on.
Non-sudo / Administrative bearing Pattern based Discovery
The deciding factor here is basically the access which the Top-Down patterns have - or will not. Top-down patterns frequently use sudo, netstat, grep and the like so clearly, if you’re not allowing that level of access, you need to find an alternative approach to Map. Likewise, if you’re leveraging JEA from Microsoft then the overhead to manage the profile - adding the commands that Top-Down mapping requires - is probably going to outweigh the benefit of having those Services mapped using that approach. If you do decide to go that route, be aware that you’ll need to compare the profile’s commands with the OOB patterns every time there’s a store app release. I wouldn’t recommend it.
Dynamic Services
So - having established that non-administrative or “sudo bearing” approaches to Discovery don’t really support Top-down mapping, it’s good to understand the options. The first is a Dynamic Service. This essentially rebuilds the cmdb_rel_ci relationships defined for the starting CIs into the svc_ci_assoc table and makes that map available for use as a Service. This approach is also great for services where there are non-discoverable components (like mainframes) or the rate of change is really low.
Dynamic CI Groups
If the Service you want to map isn’t made up of connected things - it’s a group of Servers with a single running process, a number of switches or routers that are labelled as used for Production - then you’ll need to map these into a Dynamic CI Group. This gives you the ability to monitor the health of the service and see all its’ member CIs, but not in the hierarchical or tree based view. Your Dynamic CI groups should also be linked to Technical Service Offerings as prescribed by the CSDM, giving you the opportunity to understand who is responsible for the support of the CIs comprising that Service.
Pattern based Discovery with credential access
If the CIs which make up your Service have “typical” credential access via Agentless discovery, then you can consider top-down Service Mapping. However, a couple of important points come up here. First - is it worth it? If there’s a low rate of change, or the service is a Development environment then you might not want to sink the effort of top-down mapping into it. This is often where dynamic Services come in (see the earlier comments on those).
Patterns and Machine Learning
If the Service does warrant the effort - but the ports are non-standard, or there’s a pick and mix of technologies such as mixed middleware layers or database approaches, then you could consider Top-down with Machine Learning as that works to identify where the traffic is and give you those relationships. An excellent way to leverage this (in my experience) is to attempt to map the Service using the top-down approach and use the “connection suggestions” action to review what relationships the ML component has been able to identify.
Top-Down Service Mapping
Finally, then, we get to Top-Down mapping. This is the classic approach, as has been said, and implementing - while challenging - will provide you the most detailed view of the Service. You can expect to see application and middleware components, database connections and so on. My key advice here is that before you start, you should understand the architecture of the Service from the folks that support it.
Conclusion
I hope that this is a useful resource in helping you identify where each Service Mapping approach might be appropriate, and the considerations for each. Please do let me know if you've any suggestions to improve this content, or I've missed something.
