With the recent announcement of Cisco’s Digital Network Architecture (DNA), it has become clear that we are putting tremendous focus on creating an open, extensible and programmable platform in order to enable integrations between Cisco and 3rd party technology. Network-enabled applications, created by developers, will be able to push configuration and pull information from network elements such as Catalyst 3850, from collaboration tools such as Spark and Tropo, from controller/automation platforms such as APIC-EM and from management tools such as Prime Infrastructure. This integration can only be achieved via a) open, well-documented APIs and b) an active developer community such as DevNet which provides developers with the tools, the resources, and the code they need to build innovative, network-enabled solutions. 
I have recently started playing with APIs and wanted to share my personal experiences from this journey. It can be overwhelming in the beginning, since programmability is a new (or forgotten) area for most people with a networking background; with a structured approach towards learning however, it is not as difficult as it seems.
Python and RESTful APIs were two things that I kept hearing and hearing about, so I started with a couple of tutorials that provided theory and hands-on experience. For Python, I found the tutorial at Code Academy to be a fun, interactive way to refresh my programming skills and begin to code. For RESTful APIs, DevNet has a Learning Labs section which includes Coding 101s on REST, Python, JSON, XML, git, etc. Each lab is between 5-35 min and provides a perfect way to combine theory with practice.
The next step was to see APIs in action and what could be more appropriate than playing with APIC-EM, Cisco’s Enterprise SDN controller that is also a component of DNA? Although APIC-EM is free, not everyone has the powerful HW needed to deploy it, neither an actual network for APIC-EM to integrate with. There are simple alternatives however:
Alternative #1 is DevNet always-on APIC-EM lab, which provides the ability to design, develop and test utilizing APIC-EM APIs with a sample simulated sandbox lab topology and a Hello World application. By simply logging into https://sandboxapic.cisco.com:9443/ with the credentials provided here, it is possible to explore the APIC-EM API and actually perform API calls from within the Sandbox, via the “Try it out!” button. Click the image below for an example.
Alternative #2 is DevNet reservation-based APIC-EM HW mini labs, which contain actual network elements (Catalyst switches and ISR routers) and servers (VMs running Ubuntu linux) to create an actual physical topology managed by an APIC-EM instance. Again, it is possible to explore the APIC-EM Swagger API and perform API calls from within the HW Mini Lab.
The cool thing with both lab types is that you can also perform external API requests to the respective APIC-EM controllers. Two options for doing that are:
- The GUI-based approach via Postman, a third-party plugin for the Google Chrome web browser which allows to build API calls and receive the results from within your Chrome browser.
- The CLI, hands-on approach via Python installed on your own laptop (I have found PyCharm to be an excellent IDE, by the way and it’s free!) and using the requests HTTP library for API calls or, even better, to take advantage of a free AWS EC2 account , which enables you to use a Linux VM for free (750 hours/month). The Linux VM can be RHEL, Ubuntu or another Linux flavour, it comes with Python pre-installed and you can connect to it via SSH from your laptop.
I will finish by providing a few additional details on the AWS option since this is an interesting one:
Running a VM with Linux and Python in the AWS Public Cloud allows you to achieve advanced integration between APIC-EM and other API-enabled applications such as Spark or Tropo. For example, Spark does not only receive API calls but can also originate API callbacks to other applications via a mechanism called Webhooks. Think of a simple use case, where a message posted in a Spark room triggers an API call to your Python code running in the AWS Cloud. Your code will parse the message from the Spark room and can react to that message by e.g. initiating a Path Visualization request to the APIC-EM instance in the Always-On DevNet lab. The result of that Path Visualization request can then be received by your Spark code and posted back to the Spark room. At the same time, your code can also initiate an API call to Tropo so that the same result can be sent to a user via an SMS or a voice call. I have created a simple diagram describing these interactions, see below.
If the above gave you a few good pointers on how to begin your programmability journey but you’re the kind of person that prefers a ‘listen, learn and then put in into practice’ approach, don’t get disappointed! The DevNet team, in collaboration with Cisco SDN/programmability experts, organize and run a number of “DevNet Express” events across various countries. These sessions combine a bit of theory (we don’t want to force you into death by powerpoint!) with a lot of hands-on practice and missions to challenge yourself and win prizes. Such events are also a nice way to connect with fellow Network/DevOps/Software engineers with an interest in network programmability.
In perfect timing with this blog, there is an upcoming 2-day DevNet Express session in London, on the 7th and 8th of June, so now is the perfect moment to register, since places are limited!
Authors
