Why Should Networking Engineers Learn Python?

I’ve been a network engineer for more than 20 years and CCIE for 18 years, with a passion for network management. The last couple of years, the network management world has changed. Years ago service providers would validate a new service (router, OS version, and configuration) for a couple of months before installing it in production. These days, the time requirements for enabling new services have been reduced dramatically. That led to the development of APIs to monitor and configure the network elements directly … and the full SDN story.

Btw, the term SDN is overused these days. I like the pragmatic SDN definition given by Dave Ward: SDN functionally enables the network to be accessed by operators programmatically, allowing for automated management and orchestration techniques; application of configuration policy across multiple routers, switches, and servers, and the decoupling of the application that performs these operations from the network device’s operating system.

The only constant in this networking industry is « change », so how to adapt to this trend? In other words, how to stay relevant in a couple of years? Interestingly, more and more network engineer job descriptions require some sort of scripting skills these days.

Reflecting on this, I decided to learn scripting. Sure, I’ve been using shell scripts, but I needed a way to automate network management tasks, and not only server tasks. Asking my friends in the industry, both from Cisco and outside Cisco, which programming language to learn, the answer has been consistent: Python.

Python is a modern programming language, with enough simplicity and yet powerful enough to be used as a convenient tool for daily parsing tasks, performance management, and configuration. Most SDKs are provided in Python and there is a vast amount of available libraries.

The famous « Hello world! » was very intuitive and was done in no time (I promise). The interpretive nature of Python is very convenient, and added to the fun of learning Python. I attended a 3 days internal course, which provided me the basics. The course « An Introduction to Interactive Programming in Python » from coursera.org was a nice addition. Weekly videos, quizzes, and mini-projects helped me master Python (for some definition of « master »). A few professionals teaching something interesting, a community around the world wanted to learn, ready to share what its knowledge, I enjoyed that. However, don’t take this effort to lightly though, it needs some serious commitment: between 8 to 10 hours per week, for 9 weeks. In the end, the final project looked like this youtube video (you’ll have to pay for the sound, or maybe I was just lazy, sorry). That impressed my kids: « Yes, dad can develop games 🙂 ». All mini-projects consisted of on game developments: guess a number, blackjack, etc. And I proudly share my results: that one will impress my mother 🙂

While attending the course, I participated to a 24 hours Hackathon, developing a feature I’ve been requesting to my product management and engineering team for some time. This « feature » was developed on top of our Cisco routers, which supports Python. What a refreshing feeling: if I can’t have « my » feature fast enough, I’ll just script it! Back to reality: Is this feature ready to ship? Not really, it would require more testing, performance analysis, code review, and a way to support it in the future … but this is beside the point in this situation: 3 people, 24 hours, and some passion/stubbornness is all it takes to demonstrate a prove of concept. This is the beauty of scripting!

The future.

Will all network engineers have to become programmers in the future? Not really! Will I become a full-time programmer? Probably not! Even if there is an industry trend towards SDN, cloud, virtualization, everything-as-a-service, etc. does not imply that network engineers will disappear. When a (young) application designer will complain that his call to the API « get-me-a-new-service-over-the-network(bandwidth = infinite, packetloss = 0, one-way-delay = 0, jitter = 0, cost = 0) » doesn’t work as expected, we will still need a network engineer to troubleshoot! More seriously, the best (and most efficient) network engineers in the future will be the ones who will be able to script their automated network-related tasks, create their own services directly in the network, and modify their scripts on the fly … without forgetting to share some of this with the open source community, as a way to give back to a community who cared to share its knowledge.

Very good background info: the packet pushers show 176 Intro to Python & Automation for Network Engineers

Regards, Benoît