Modern Network Compliance Means Going Beyond CLIs & Adopting APIs

It’s important for network practitioners to start adopting APIs in the same way that they have adopted CLIs. I’m sure you’re wondering why. This is the very topic that was discussed in recent webinar, “Modern Network Compliance: Go Beyond CLIs, Adopt APIs.”

APIs, like CLIs, are a way of configuring a network device or service and understanding how a network element is configured. APIs may seem scary at first, but they’re not as foreign as you may think as every practitioner already has API-based network solutions now. Most practitioners already have something with an available API already installed and operating in their network. Think about it – is there any solution that you have that uses a controller or web dashboard to configure network devices or services? Enterprise SD-WAN and Wireless solutions typically fit this description, and if you do a quick google search for that solution’s APIs, you’ll probably find a complete API listing for it.

So, let’s take some time to dig into why network practitioners must understand APIs in order to have a fully compliant network.

Why APIs Aren’t as Foreign as they Seem

When using CLIs, it’s always important to read the documentation to understand what commands are available to use and what data is required to pass along to the command. As a simple example, to create a typical static route in a Cisco IOS device using CLI, I would need to know the command “ip route” and the data it requires to build the route “<network> <netmask> <next hop>.”

Putting it all together, I have what I need to create a route on the router:
“ip route 192.168.100.0 255.255.255.0 10.0.0.2”

Reading the documentation further would also help me understand other options and features available for the “ip route” command, like specifying interfaces for the next hop, or defining a different metric for the route. The world of APIs is really no different. API documentation is published by the product vendor and will define the methods that are available to users to interact with the network solution, how to properly access the API methods, and how to format the data that is passed to each method.

One reason it’s crucial to start adopting APIs is because the cloud is API-driven. So let’s take a look at a specific example, a VPC in Amazon Web Services, a foundational network element. A VPC is its own cloud networking construct, but it’s a bit like a switch, a router, and a firewall in terms of function and configuration. Normally, most users would create a VPC using the web-based management console, but because we’re here to learn about APIs, let’s take a look at the documentation.

Start by browsing through the available API actions, or methods, that AWS publishes here.

These are all of the functions that the API provides for interacting with AWS’ EC2 services, and this includes a lot of network related actions. Since we are looking for how to create a VPC, you can scroll down to the link for “CreateVpc” and click on it to open the documentation for this API call.

If you take a close look at the documentation for “CreateVpc,” you’ll notice that it defines a set of Request Parameters, which is the data needed to pass to the API call. It also defines a set of Response Elements, which is the data sent in response to this request. It also includes examples, which may arguably be the most valuable information here, especially when considering how often practitioners scour the Internet for example CLI configurations. The example shows how to execute the CreateVpc API call via an https request, and how to format and pass along the data required for the CreateVpc call.

Lastly, pay close attention to the Response to a successful CreateVpc API call. This response defines exactly how this new VPC is configured. While it’s formatted programmatically in XML, it’s straightforward to understand the logic of how everything is defined, and as a network practitioner I hope this helps to highlight just how similar in function APIs are to CLIs, despite them feeling like a very foreign thing.

APIs Enable Modern Network Compliance

Since the network now comprises of API-driven devices and services that don’t conform to CLI, adopting APIs is the only way to deliver compliance across your entire network. By only focusing on CLI-based devices and ignoring APIs, only part of your network will ever be in compliance. Since most traditional NCCM solutions don’t speak API, I’m sure you’re still wondering how to start adopting APIs.

It’s true that APIs are meant to be used in programs and make it easy to automate network functions, but that doesn’t mean you must learn to write code to take advantage of APIs. By leveraging Itential Configuration Manager, you can integrate with any network or cloud infrastructure that uses APIs and build Golden Configuration templates that define how these services must be configured in order to be compliant. This application works with you CLI-based network devices as well, so you can ensure compliance across your entire network, whether it’s on-prem or in multiple cloud platforms.

When you’re ready to automate, Itential Automation Studio allows network practitioners to easily build automations on a low-code canvas where API actions like “CreateVpc” are simply a task you can drag-and-drop into a workflow. You can build these automations to work with multiple network solutions and your IT ecosystem of IPAM, ITSM, and messaging systems with Itential’s unique ability to quickly build integrations based on API specifications.

To learn more about Itential’s approach to modern network configuration and compliance check here or take a deeper dive into these three things that matter most in our recent on-demand webinar, “Modern Network Compliance: Go Beyond CLIs, Adopt API.” See the full modern network compliance webinar series here.