Avoid Getting Lost in Your Forest of Services With Itential’s Stateful Orchestration

Whether you are a service provider or an enterprise, you have a stack of infrastructure technologies that provides services to your end users.

In some cases, your end users are consuming network services directly, like with direct internet access. In other cases, your end users may be line of business owners who need to deploy applications quickly.

In order for a service to operate, it requires each part of the infrastructure stack to be updated in such a way to work together to successfully enable each component of the overarching service. If we just look at network and security infrastructure, they are probably divided into multiple domains run by different teams who are focused and specialized on that particular technology. These teams typically operate in silos using their own tools with little knowledge of how their resources are interrelated with their peers in other domains.

Time for a fairy tale…

Once upon a time, working at different service providers, I remember part of our team’s process was that when we provisioned a new Internet customer, we would assign the next available port to a customer and populate the port description with details on that customer.

This was not ideal, because there was a limited amount of space and an increasing number of useful details we needed to cram in there. Things like turn up date, customer name, account number, service details, order number were all details that we tried to document, but frequently we ran out of space, resulting in a strange set of shorthand and abbreviations that became harder to understand.

Services changed over time, and when they did, we needed to update that port description with the most relevant information. Eventually, the system broke down for many reasons — too many details to track, too many changes to update, too much additional work for the team, and sometimes we accidentally deleted it and didn’t realize it.

The moral of the story…

But WHY did we do all of this? Because we recognized that we needed breadcrumbs for every service, and these little hints would save us time in the future whenever one of these services needed to be revisited in some way — changes over time, troubleshooting, and eventually turning it off. These breadcrumbs allowed us to react more quickly to the change events by giving us the data we needed to take action. Without these details, we would often spend minutes to hours manually looking up related details from one system or network device to another until we had a complete picture of the service that we were working on or troubleshooting. This system started off great, but quickly broke down because we didn’t have the right tools. And like the story of Hansel and Gretel, when the breadcrumbs disappeared, we ended up getting lost in the forest of services and had to manually find our way out every single time.

That was a long, long time ago in a faraway kingdom. In today’s world, services ride on top of a much more complex set of network domains and interact with more systems, resulting in a much bigger and broader set of data that needs to be tracked. A basic service or application may require technical resources from cloud, data center, and security domains, and each domain has a set of specific details relevant to the service. We’re talking about ports, interfaces, virtual interfaces, VLANs, IP addresses, routes, policies, firewall rules and more.

What about non-technical details for a service that ought to be tracked? Things that are equally important and unique that come from different systems in your environment like billing, inventory, and ordering? From these systems come details like customer Name, account numbers, order id, CPE details, addresses and more. So, it only stands to reason that network teams spend even more time looking these details up when they need to operate on a service than we used to. Therefore, a better solution would have a significant impact, saving them more time and helping them operate more efficiently.

Okay, we want a better solution. How?

When you need to create a new service, all this data comes from different sources, and orchestrating this process and remembering the important details saves time.

When you need to change an existing service, looking up data (even a portion of it) takes time, and recalling it and orchestrating the changes saves time. Since changes happen frequently over the lifetime of the service, lots of time is saved.

When you need to decommission/turn down a service, looking all of this data up from different sources takes lots of time, and is necessary to release these resources so they can be used by new services. This saves lots of time, and provides better utilization of network resources (see this article on ghost config to read about another story’s villain).

Lifecycle Manager (LCM) is an application in the Itential platform that builds upon our approach to automation and orchestration and can help your team overcome these challenges. Itential’s approach is to enable integration with everything — from cloud, modern and traditional networking, virtual or physical firewall, and every system in your environment, so that you can orchestrate processes that automate network changes.

In order to successfully track today’s service data, you need to be able to interact with everything that holds those details.

Next, Itential uses JSON schemas to normalize and represent data from these different integrations, which also gives teams the ability to define the information they want to track in a flexible format and is how we represent this data in LCM.

Finally, LCM leverages orchestration workflows, built by your teams in a low-code canvas, to automate service deployment, updates, and decommissioning and stores that data locally, so it’s always available when your team needs it to automate across different service stages.

Does this all end happily ever after? Well, I’ve spent enough time in networking to know there’s always something around the corner, but with Itential’s ability to enable stateful orchestration through LCM, you will certainly escape this particular witch and never need to rely on scattering breadcrumbs ever again.

For more on stateful orchestration and LCM, watch this demo.