If you haven’t read Part 1 and Part 2, I recommend them so you know why Spider-Man is driving a Dodge Viper and why Goku keeps showing up uninvited, as well as what Spider-Man does for New York, what he does at home, and why the F.N.S.M. app is basically a Service Catalog with better branding.
Introduction
Last time we talked about Services and Offerings:
- Spider-Man provides Business Services to citizens (Crime Fighting / Civilian Saving)
- And he also has Technology Management Services for keeping his tools running (Suit Upkeep / Webbing Upkeep / Car Maintenance)
- Requests/Incidents get tied back to Offerings, which ties back to Services, which improves reporting, routing, SLAs, and all the things that make grown-ups happy.
Now we’re going to cover something that sounds boring, but is the reason your CMDB stops being a museum and starts being useful... Service Instances.
Mandatory Quick disclaimer (same energy as Parts 1 and 2)
This is a light-hearted take on a topic that is, in reality, quite complex. It’s not a deep-dive or a step-by-step implementation guide. But it might just help spark a few lightbulb moments for customers – or anyone around you who isn’t yet fluent in ServiceNow.
What’s a Service Instance?
A service instance is a set of interconnected applications and hosts that are configured to offer a service to the organization.
I’m going to take a bit of creative liberty and define Spider-Man (Peter Parker) as a Service Instance. He is one of the concrete ways the Services we described before may be offered (crime fighting/criminal beatdown, for example, can also be done by the NYPD), so it fits the description.
I could also make a pun about how he makes use of a web of different kit much like the definition above but I’ll refrain. So let’s get metaphor-ing!
Last time on ELI5 CSDM (queue intro theme)
We had the Business Service:
- Crime Fighting
The Offerings are still:
- Criminal Beatdown
- Criminal Webbing
- Criminal Police Delivery
This means in a normal scenario we have:
- Service: Crime Fighting
- Service Instance: Spider-Man (Peter Parker)
- Status: On duty
Crime doesn’t pay, but neither does crime fighting...
So Spider-Man, or Peter Parker, really, needs a job.
But to pay rent, Peter needs to work, so he decides to also enlist in the Offering of Pizza Delivery from his local pizza joint! And because the pizza is delivered to the public, that makes it a Business Offering.
However, when he’s busy doing that, he’s not available to fight crime so that there must be some backup for that scenario, meaning the Crime Fighting Service is reliant on other Service Instances such as:
- NYPD: not a single Spider-Man, but a collective – so are they something similar to a Service Instance, or something else entirely? (comment underneath if you know what I’m referring to!)
- Miles Morales: he’s another younger Spider-Man, one that’s still in development
- Other super-heroes
Some Service Instances are single, well-defined entities. Others represent a group acting as one operational unit, but more on that next time.
So what does this mean?
The Service did not change.
The Offering did not change.
Only the Service Instance changed if actioned on a crime.
From a citizen’s perspective:
“Crime Fighting still works.”
From an operational perspective:
“The underlying instance changed, but the service is still available.”
Why this matters in CSDM terms
This is exactly why Service Instances exist.
If we only model “Crime Fighting” as a Service, we can’t answer questions like:
- Who is actually delivering this service right now?
- What happens if Spider-Man is unavailable?
- Is there redundancy or failover?
- Are we running in a degraded mode?
With Service Instances, we can.
Many ways to spider a man
Although Miles Morales is a different Spider-Man, he still lives and fights in the New York area. This means that if we regionalise our Service Offerings, relying on a single Spider-Man would leave other cities in trouble:
Service: NY Crime Fighting
Offering: NY Criminal Webbing
Service Instance(s): Peter Parker, Miles Morales
So in comes a character I introduced all the way back in my first ELI5 article about Domain Separation, Pavitr Prabhakar, also known as Spider-Man India, who, as you probably guessed by know, does his Spider-Man thing in India.
As a result, we now have the region of India being supported as well:
Service: India Crime Fighting
Offering: India Criminal Webbing
Service Instance: Pavitr Prabhakar
In practice, you could request Pavitr to help in NY, but that would effectively mean changing which Service Instance supports which Service.
Related Spider-Men? Spider-Mans? Spiders-Man?
Finally, as you saw in the picture above, Spider-Men (we'll go with that one) interact with each other.
In New York specifically, Peter is a mentor to Miles, so Miles actually depends on Peter to train and get better. This means our living Service Instances actually interact with each other and have relationships between them.
Translating this back to ServiceNow
Let’s replace Spider-Man with something more familiar like your Email Service:
- Service: Email
- Offering: Outlook
- Service Instances:
- Outlook – Primary Mail Servers
- Outlook – Secondary / Failover Servers
- Outlook – Temporary Cloud Relay
- Outlook – “Someone applied a workaround” mode
All of these are still Outlook. They’re just different ways it’s being delivered at runtime. When the primary instance is unavailable, the service doesn’t magically disappear - it switches to another instance.
Just like Crime Fighting switches from Spider-Man to NYPD or Miles Morales.
Outlook also doesn't just work on its own, relying on other Service Instances, such as Email Storage, Email Backup, etc. to function properly and deliver all the functionality to its users, much like how Miles relies on Peter to get stronger!
Finally, similarly to Pavitr's version of Spider-Man, let’s regionalise the above:
- Service: Email – APAC
- Offering: Outlook – APAC
- Service Instances:
- Outlook – APAC Primary Mail Servers
- Outlook – APAC Secondary / Failover Servers
- Outlook – APAC Temporary Cloud Relay
- Outlook – APAC “Someone applied a workaround” mode
By having different Service Instances support different regional Services, we’re guaranteeing that latency isn’t an issue or even the servers that host the Service Instance application aren’t overloaded.
This doesn’t mean every Service Instance should be separated by region. Many times, a single instance is the easiest way to ensure processes remain the same, data isn’t replicated or out of sync, complexity is lower, etc. This is very common in ServiceNow itself, where you typically separate by environment such as:
- ServiceNow Production
- ServiceNow UAT
- Service Development
In sum, you can separate your Service Instances in many ways, much like we did with Offerings. However, because they are logical representations of something more tangible, this separation is often easier to understand, as we’ve seen above.
Key ELI5 takeaway
A Service Instance answers one simple question:
Who (or what) is actually delivering this Service right now?
- Sometimes it’s Spider-Man
- Sometimes it’s Miles
- Sometimes it’s NYPD
- Sometimes it’s a mix
- Sometimes it’s “best effort until Spider-Man finishes his shift”
And that’s okay – because the goal is that the Service stays the same, even when the Instance changes.
Conclusion
Service Instances are possibly one of the hardest bits to ELI5, and I could spend hours decomposing how they’re split into the different types available in CSDM v5, but that’s not the spirit of this series (at least not for this part).
Hopefully you can now share the Service Instance joy with your close ones!
Lastly, I have to apologise – I was planning to cover Dynamic CI Groups in this part. But since Service Instances already stretched this article (and Spider-Man still has pizzas to deliver), we’ll save that for next time.
Spoiler: the NYPD will finally get its moment.
