Configuration & Compliance: Part 3 – Why Tapping Ruby Slippers Won’t Make Your Network Compliant

If you’ve been following along, we’ve been taking a journey through our networks with Dorothy. First, we took some time to understand why the network can feel a bit like arriving in Oz for the first time. Then, we tackled what to do when you encounter CLIs and APIs and Clouds (Oh My!) in your network. And now, we’ve reached the final stretch of our journey with Dorothy.

In final scene The Wizard of Oz, Dorothy is able to return to Kansas by tapping her ruby red slippers and wishing, “There’s no place like home.” It’s normal for network engineers to look back fondly at simpler and easier times, but in the world of today’s exploding and dispersed network there’s simply no going back to the way things were. The reality is that the network of today is not just on-premises but it’s also in the cloud and across the Internet, which means applications and users are distributed across the Internet as well. For the network team to maintain the highest level of network security and resiliency, they must be able to ensure compliance across modern API-driven networking.

Compliance = Automation

In traditional CLI-based networking, compliance has always been top of mind, and automating these network elements has not been a focus. However, in the world of API-based cloud services, automation has always been top of mind, and the idea of ensuring post-deployment compliance has not been a focus. In order to ensure compliance across modern API-driven networking, an equal combination of compliance and automation will be required.

While API-driven networking may not have a traditional configuration available to use for compliance checking, the API for that service will provide a method to extract information about the currently running network services, which become the foundational data to determine whether the network service is operating according to your compliance standard. Or to put it another way, instead of looking at a device’s current configuration file to determine if it is compliant, you can query the service through its API interface and it will respond with details of how it’s currently configured, which you can then use to determine if it’s still in compliance. When an API call is made to a network service, you will need to have an understanding of which API call to use, the required input to the API call, and the output format that the API call will return. This is defined by the provider of the service, and a well-defined API will normally include all of that information in a specification file (like OpenAPI or a Postman Collection) and in documentation with examples of how to call the API with the appropriate input and output data.

Why Tapping Ruby Slippers Won’t Make Your Network Compliant

Traditional solutions to ensure compliance across CLI-based networking may not have an easy method of providing compliance across more modern API-based network infrastructure, so a new solution will be necessary. Itential provides a modern solution that includes automation as a core component to coordinate compliance checking and remediation together. By leveraging the Itential Automation Platform, you can quickly reduce the time network devices and services may drift from the standard and guide you down the golden path that leads to a secure and resilient network.

As a last thought, recall that all of Dorothy’s new friends in Oz persevered and at the end of their shared journey they found exactly what they needed. So, don’t lose heart! Using your intellect, a little courage, and working closely with your team, continue onward with your network journey that leads to better lands of Clouds and APIs!

To learn more about Itential’s innovative solution for simplifying compliance across CLI and API based networks and services, watch my latest on-demand webinar here or check out more on Itential’s Configuration Manager.