Defining Network Programmability

Network programmability is such a generic term, like SDN and the whole Software Defined X paradigm, that it means different things to different people. Not so long ago network programmability was synonymous with Openflow but as time passed and pragmatism kicked in, the industry settled around a common view. Driven by real benefits like time and cost savings, reduction of human error, customization and innovation, network programmability is currently understood as a set of tools and best practices to deploy, manage and troubleshoot network devices.

Designing the flexible network 

The times when we could configure and manage one device at a time are going away. In a dynamic DevOps world when entire testing and development environments are built and destroyed within minutes, we expect the network to keep up and be just as flexible. This means that we have to look at the way we’ve done networking so far from a different angle. When a new VLAN needs to be added to our infrastructure, or a new application requires a set of QoS parameters to be applied end to end in the environment, we need to be capable of performing these changes safely and within minutes.

Networking vendors have seen this challenge and are at different phases of adopting and implementing solutions for it. The common solution across the industry seems to be revolving around providing application programming interfaces (APIs), sample code, and reliable software development kits (SDKs). Besides the good old Command Line Interface (CLI) that has faithfully served us for so many years, vendors are now exposing APIs with their products. Repetitive tasks in an environment that provides programming interfaces leads organically to network programmability and automation.

Pushing the boundaries of automation

Network programmability and automation is not new. Engineers have tried to simplify their work since the first ARPANET in the late 60s. From screen scraping, to bash and Expect scripts, the pain has been real. What is new is that we have reached a point in which the scale of our networks, the agile nature and dynamic requirements of our network infrastructure cannot be realistically configured and managed one device at a time. It is now time to start interacting with the APIs, use them to automate most of the mundane and repetitive tasks that used to take so much time to get done, and manage as many network devices as possible with a few scripts. As an industry we learn from our mistakes and always try to improve and push the boundaries.

 

Your time is now 

So, what does all of this mean for us who have been in the industry for a while, or for new students looking to improve their knowledge and trying to get a job in networking? Is this the end of world as we know it? Hardly. Networking has been constantly changing and evolving, much like programming. Although you still see requirements for Fortran or Cobol developers, mostly for maintaining very old legacy applications (I am sure somewhere out there there’s still a network running on 10Base5), the vast majority of the world has long changed and evolved, in most cases for the better. If you follow the Cisco certification program and the NetAcad community, you can see the same change patterns. All the certification tracks have been in a constant evolution process based on new technologies, new requirements from the job market and feedback received from the students. This time is no different. The difference is that now the network has become even more critical, and the requirement for highly skilled network engineers will only increase. The network has become a business differentiator and the more agile and dynamic your infrastructure is, the quicker you can develop and bring those applications into production.

Training and retraining 

Networking students: I recommend that you keep an open mind!  Know that you will have to constantly learn and be interested in new technologies. If you enjoy this and are passionate about it, you are in for an amazing journey.

Networking veterans (me included): I tell you, this is no different that what you’ve done so far. Remember when you had to learn about ATM and Frame Relay, and then MPLS, L3VPNs, LISP and OTV? We all have to learn now about data formats, APIs, mostly REST hopefully, parsing and manipulating data programmatically in a way that makes your life easier.

Based on the maturity of the language, the amount of libraries and support, as well as ease to learn, the general consensus is that Python is the best fit at the moment to tackle the challenge of network programmability. As network, DevOps or systems engineers we need to be able to talk to developers in their own language and be able to understand their problems.

Following the server virtualization and hypervisor revolution at the end of the 90s and more recently the move to the cloud and the whole DevOps style of management, it is now time for the network to become more agile and accommodating to the requirements of the applications. There’s no better place currently for massive innovation than the network. The network sees and hears everything that moves through it! From more intelligent WAN routing with solutions like Cisco iWAN, to embedded security in which the network acts as a dynamic sensor and policy enforcer, to traffic anomalies detection and instant analytics, with products such as Cisco Tetration, there’s more and more intelligence being moved to the network layer.

I would like to invite you to join me on this trip as we start exploring network programmability in more depth. All questions, beginner and advanced, are appreciated. Add them below, or find me on Twitter @aidevnet.

And remember… the only constant is change.