Leveraging APIs to Enable End-to-End Network Automation

Blog #2 in a Series on APIs from the ONUG O&A Working Group

Part One of this blog series on APIs for network automation set the foundation for the importance of using APIs (application programming interfaces) for network and end-to-end process automation. Here in Part Two, we are going to look at more of the implementation details and points to consider when first looking to leverage API calls for automation.

The digital transformation movement is pushing enterprise IT to deliver agility, scalability and security for the business. Automation has become a critical enabler to deliver repeatable and reliable services.  Automation can also embed governance, compliance, and corporate processes to ensure proper change policies are implemented. Building automated processes can also help to provide important business metrics about how many services are being implemented and how quickly and reliably. These metrics are important to show return on investment (ROI) and make decisions going forward.

While the DevOps organizations have led the way in using automation to drive CI/CD pipelines to speed application development and delivery, NetOps has fallen behind largely due to the complexity of the underlying network. As described in the O&A Taxonomy document, the network layer (and related domains) are not yet fully programmatic and can require a vendor-specific command-line interface (CLI) to configure individual network devices. Management layer components like ITSM, CMDB, IPAM, SNMP Monitoring, Log servers and more typically provide a programmatic interface. Open source and commercial products providing orchestration and automation are typically able to interface with the network layer and onboard API calls to interface with management plane components to provide end-to-end process automation. As covered in the O&A Session at ONUG Spring 2021, part of the O&A Maturity model Level 3 is to incorporate API calls as part of implementing process automation.

When looking to onboard API calls, there are seven key steps to perform:

  1. Define the use-case(s) and exactly what you want to automate – The first step is exercising the process manually and understanding exactly what steps you need to perform to then automate the process. This often involves using the systems Graphical User Interface (GUI), which generally is some type of web-based portal. These interfaces are often using the same API calls behind the scenes even though a user may be using the GUI. If the Web GUI is using the API calls, then it helps to bring up the developer tools of the Web Browser to see what calls are used for what parts of the Web GUI that are of interest.
  2. Review the vendor API documentation – Vendors will provide API documentation to provide an understanding of the API to use in a program. The quality of the API documentation varies from vendor to vendor.  Most modern APIs are “REST-based” (a.k.a. RESTful) which means it conforms to a standard for the information exchange over the http(s) protocol.  While we can’t cover all the details in this blog, using REST, a request is made from a client to the URI (Uniform Resource Identifier) of a server (API endpoint) that responds with a payload formatted in HTML, XML, JSON or some other format.  The most common operations (HTTP methods) are:
  • GET – read the resource or a collection of the resource
  • POST – create a resource
  • DELETE – remove existing resource
  • PUT – update an existing resource

along with other less common operations. The vendor documentation will provide examples of each supported call and often software development kits (SDKs) or at least code examples. There is a different SDK per programming language supported by the vendor.  The platform you are using for orchestration determines the programming language used which determines the SDK from the vendor to use, which is often JavaScript, Python, or another standard language. Note, that while REST is currently popular, there are other APIs using other protocols such as SOAP and proprietary methods. Also, there are other API technologies to consider like GraphQL, gRPC, Webhooks, and more that are out of scope for this blog.

  1. Identify the exact API calls to use to accomplish the use-case(s) – After reviewing the vendor documentation you should be able to identify the API calls required to accomplish the use-case. Keep in mind there are often pre-required steps in the process, for example, you may have to perform several GET commands to read in variables from the system, to then use POST commands to execute an action or a change. The required sequence of commands can be worked out in step 5 when testing the programmatic interaction. Vendors may provide more than one way to accomplish a task via different API calls, so step 2 is very important to understand all the options the vendor offers and any provided examples.
  2. Understand the authentication/authorization mechanisms – When enabling programmatic interactions, it is critical to enforce and manage security and compliance policies associated with application services and integration. Vendors will support one or more of the following options:
  • HTTP protocol authentication mechanisms – These leverage basic username/password with each call.
  • API Key – The service creates a unique key for your account, and you pass it alongside every request. The key can be requested or provided by an administrator of the system.
  • OAuth 2 – allows requesting for the authentication token from the authentication server (bearer token) with several default grant types specified in the OAuth 2 specification. You must provide at least the client id parameter you receive from the client registration process. Then depending on the selected grant type, you may need to add other values in the request.
  1. Test the API programmatic interaction – API toolsets are available such as Postman or Advanced REST Client (ARC) to test and exercise each call to understand the details of the input/output parameters and format. These products provide the ability to define the HTTP operation along with the URL and required header parameters along with authentication to define and test any REST API calls. They also provide code snippets in various languages to integrate directly into your implementation. Another option is to use a simple curl command-line tool to define and test any REST API calls. Most orchestration frameworks also provide the ability to onboard and test the REST calls directly in the product.
  2. Integrate the API calls – This step will be specific to your infrastructure, which can be home-grown python scripts or a commercially available O&A platform. This is where your use-case will come to life as an end-to-end automated process. Note that some vendor platforms provide Swagger/OpenAPI Specification(OAS) or RAML programmatic documentation which can help to speed the onboarding process of the API calls.
  3. Test, test, test, then deploy – In the final step, ensure your environment supports the ability to fully test the end-to-end process so that each step can be verified. Once tested, ensure you have a process to deliver to production for operational use.

While this blog serves to introduce the major steps in onboarding and integrating API calls for end-to-end automation, it is only the beginning. There are many architectural decisions to be made when designing automation. Many use-cases will get complex, requiring dozens of API calls, and many sub-calls for systems to interact and perform steps to collect information, make changes, update status and more.  In Part Three of the blog, we will examine some specific use-cases and the API integrations performed to accomplish the automation.

 

Author's Bio

Michael Haugh, Gluware; Dave Hegenbarth, Pliant; Rich Martin, Itential

guest