Mapping services and assets in a hybrid world

The new perimeter of service mapping

What are the discovery conditions necessary for a service mapping technology to be able to know in detail the relationships between assets and services in a hybrid IT environment.

Knowledge of the relationships between the various components of the CMDB is a basic requirement for ensuring the performance and availability of IT services.

In fact, in order to be able to respond quickly to changes - planned and unforeseen - occurring within the IT infrastructure (incidents and problems, but also impact analyses for the deployment of new services), it is necessary to have a full understanding of the dependencies of infrastructures, applications and services in order to trace the inheritance of critical issues at several levels.

Making a comparison with genetics, the concept is the same as the inheritance models of family trees: there are recessive traits that do not emerge but the principle of vertical transmission still applies. Maybe an IT component in a hierarchical line does not show obvious problems, but it is still involved in the transmission of criticality. And without dependency mapping, this will never be discovered.

A Service Mapping technology bases its work of automatically creating maps of relationships and dependencies on the discovery data collected within the CMDB. Therefore, the first step to ensure successful mapping is to verify the perimeter of the data collected.

The useful perimeter for Service Mapping

To discover the dependencies of assets and services, it is necessary to have full knowledge of the physical and virtual configurations of:

• Data center (server, hypervisors, storage, database, applicazioni)
• Edge (desktop, stampanti, VOIP, IoT, mobile)
• Network (switches, routers, firewall, load balancer, wireless)
• Cloud (server virtuali, storage, database, applicazioni, security groups)

In a hybrid world, servers and applications can be running on any environment and consequently we need probes and sensors that detect data centres, their hardware specifications, OS and connected components (hypervisors, network switches, firewalls and storage) regardless of their location, whether physical or virtual.

Furthermore, client devices may connect to servers located at the extremes (or “edge”) of decentralised networks, so in order to discover in detail the services that are being accessed , we also need to be fully aware of the relationships with these peripheral devices (desktops, printers, VoIP phones or mobile devices).

A service mapping solution, in order to successfully map all dependencies, should therefore be based on comprehensive discovery data for data centre, edge and cloud.

In my experience at enterprise companies, however, I have encountered such scenarios:

• Manual CMDB imports and updates that do not ensure timely completeness of information (errors, duplications, new configurations not reported, etc.)
• use of discovery tools that are insufficiently evolved or not optimised for data centres (e.g. Lansweeper, OCS Inventory, GLPI) that offer an insufficient level of inventory detail to identify the relationships between the systems detected
• costly integrations between multiple systems to discover cloud resources as well: knowledge of the relationships between virtual objects may require the cost of maintaining a SQL database

In these situations, the resulting mapping of dependencies may not be able to cover the entire IT perimeter, or be able to do so at great expense.

One of the technological requirements to evaluate when choosing a Service Mapping technology is to verify that it is designed for a hybrid IT environment and consequently has discovery probes that can be extended to any type of IT resource.

Other technological requirements in support of perimeter definition

When we talk about defining the useful perimeter for Service Mapping, there are other aspects to consider in the technology besides making sure that it ensures complete coverage of IT resources.

Another important aspect to consider is the ease and speed of deploying discovery probes: there is no point in having a very complete inventory detail if it takes days to get it or you have to struggle downloading, configuring and updating data collection agents.

Discovery should therefore also be possible with agentless probes (e.g. WMI, SSH, SNMP) that operate by “pinging” subnets and are able to quickly retrieve a list of IP addresses with all their configuration details. Where this is not possible (e.g. for cloud resources), direct API integration should be exploited.

Another issue that should not be overlooked, again in the area of discovery useful for service mapping, is security: since the use of probes and APIs requires credentials to be entered for the types of systems to be scanned, preference should be given to technologies that offer sufficient security guarantees. For example, it would be preferable for the discovery application to be installed on an on-prem server where data can be easily encrypted.

Cloud discovery in Ivanti Neurons for service mapping

Our service mapping partner Ivanti's technology is designed to work in a hybrid IT environment.

It leverages a discovery data collector that can be installed on a company's physical or cloud server: in addition to agentless probes that scan 20.000 IP in the order of hours, not days, it offers API integrations for cloud services.