I had the opportunity to speak at the ServiceNow Knowledge 22 conference in Sydney.
I spoke on the following topics:
- How discovery & service mapping assisted Lifeblood in the migration of configuration items between data centres;
- Maturing the understanding of our business services and the application services that underpin them;
- Making use of the information within our CMDB to assist in the migration of our application services from physical on-premise data centres into AWS and Azure.
So how did we begin?
In December 2018, we procured ServiceNow to identify where our application data loads were and the dependencies/relationships between the configuration items (CI's) that underpin the application services.
Our journey began with setting up our MID Servers in our two existing data centres, enabling us to start discovering our CIs within the data centres and our other facilities.
The next thing was to set up our foundational data within the platform, including our organisation, departments, locations (facilities), and users. Setting up our locations (facilities) enabled us to relate our discovery schedules to our locations and automatically associate any CI discovered by a discovery schedule to a location.
Now the foundation data had been configured, we needed to understand the IP ranges that belonged to each of our locations. This was key as we would be associating the IP ranges to location specific discovery schedules.
Note: When configuring your discovery schedules, break down your IP ranges into /24 subnets. The reason for this is to reduce any performance issues during discovery.
With the discovery schedules in place, we began discovering our CIs but quickly learned that the standard out of the box (OOTB) patterns would only get us 80-90% there as there were CIs we could not identify. We had to create discovery patterns to assist in discovering the remaining 10-20% of our CIs within our data centres.
Our next step was to begin mapping our application services utilising the top-down approach for this, we utilised a four-phased approach:
- Identify end-user entry points (URLs) and/or application process IDs and listening ports to begin the mapping process.
- Diagnose issues that prevent the service map from being completed, determine if it's a credential issue if the pattern needs to be extended or if a new pattern needs to be developed.
- Where an OOTB pattern doesn't quite meet your needs to map an application, consider extending the pattern to align with your application's implementation.
- For an application or device that was not discoverable using the OOTB patterns, develop your own discovery/service mapping pattern(s).
Three of the biggest problems we faced during the migration of our application services between data centres were:
The next challenge we have begun to face is migrating all of our application services from our on-premise data centres into our tenancies in AWS and Azure, for this to occur we need to identify the current state applications services, the CIs that underpin each application service, service classification, data classification, service owner and if the service is regulated.
To ensure we were able to capture the CIs within both our AWS and Azure tenancies, we stood up additional MID Servers as shown below:
Next, we tagged our CIs with a service tag to assist in determining which server supported which service and to understand the shared infrastructure currently within our environment. An example of the service tag is shown below:
The tags also become extremely useful not just for our Cloud Migration but also to enable our ability to manage vulnerabilities at a service and environment level.
Lastly, we have extended our Services table to assist with capturing critical information against our services including but not limited to Service Governance fields (Restricted Data, Encrypted at Risk, SSO Enabled, Same Sign-on Enabled and User Access Reviews).
Thank you for taking the time and reading how we have utilised ServiceNow's Discovery & Service Mapping to migrate our data centres and how we're planning to use it to move to the cloud over the coming years.
