Cisco Blogs
Share

Why is Cisco Teaching Me Python? 

- March 8, 2018 - 20 Comments

At a recent network programmability workshop one of the attendees asked, “Why is Cisco teaching me Python?

I was leading a workshop for a group of senior network engineers at a large financial company that was organized and sponsored by a member of their cloud leadership team.  This made the workshop and audience a bit different than most of the DevNet Express, Cisco Live, and DevNet Zone events I had been supporting for the last year.

Hank Preston presenting about programmable networks at Cisco Live in Melbourne, Australia

Hank Preston presenting about programmable networks at Cisco Live in Melbourne, Australia

It was different because at the Cisco events the audience “self-selected” to attend the workshop or presentation.  The audience in those events was already convinced of the importance of learning topics related to programmable networks – like Python, JSON, REST APIs, etc.  However, in the case of the financial company sponsored event, the audience was in attendance because their management TOLD them to attend.  Or at least that was the case for several of the audience members.  To be fair, at least half this audience was excited to be there and had already been experimenting with many of the topics.  Nonetheless, it struck me that this was an entirely fair question

As you might expect, a question like that generated quite a bit of discussion on the topic.  We may have fallen a bit off schedule, however I think the time was well spent.

Well… Why Is Cisco Teaching You Python You Ask?

So what is the answer you wonder… well simply put (and this is exactly how I answered it in the workshop), Cisco is teaching you Python for the same reason Cisco taught you subnetting, the OSI model, and fundamentals of spanning-tree and routing.  Because understanding Python is critical to your success as a network engineer, and Cisco wants to help network engineers be successful.  

Now, not everyone in the audience bought the answer immediately.  “Why is it critical?” was asked several times.  “I didn’t become an network engineer to become a programmer” may have been said a few times as well.

The argument was made that even though network automation was clearly the direction of the industry (no real disagreement on that front) there were many many tools available for them to use to automate the network without writing any code.  And if the time came when they DID need to code something directly, their organization had software developers that could do that work for them.  Those points are definitely true, and for some engineers that maybe an approach that works for them and their company.

However, I feel I’m a much better engineer because I learned the details behind subnetting rather than rely on “The Subnet Calculator” online to explain the difference between Layer 2 and 3 communications. I understood WHY I configured portfast and BPDU guard.  In the same way, I believe the best network engineers in the future will be able to:

  • build their own Python scripts (or curate and modify scripts they find)
  • query the APIs for their network devices, controllers, and management systems
  • contribute to key Open Source projects that are becoming the foundation of network automation

For those reasons I’ll continue to lead programmability workshops with customers, make network programming basics videos, as well as build and deliver all the amazing NetDevOps content on DevNet, at Cisco Live, and at other events around the world.

What do you think?

Are you on “Team Python” as you look to build your own career?  Or do you think all this focus on programmability skills is a flash in the pan?  Tell me in the comments or on Twitter/LinkedIn.  Let’s keep the discussion going.

Tags:

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.

20 Comments

  1. It is true that network engineer should know programming with their core expertise. There is always a gab between developers and business groups, an engineer can play a vital role if he or she understand the programming at least minimum level to understand business requirement and translate for developers.

  2. Agreed

    As a business analyst, I didn't think that I'd need to ever use programming skills, but as I collaborate more with software engineers, I notice that having a basic understanding of the program has helped my understanding of the struggles and challenges they face. This general understanding is helpful to our teams, and to ourselves in helping our careers grow. Similar to what you said above Hank, I also understood the "WHY". While I'm far from being proficient at Python, I've taken an intro course to Python so that I can get better.

    I totally agree, and I consider myself to be on the "conservative" side. To someone like me, the paradigm can be something like this: To be a Network Engineer you learned how to do "conf t; interface x/x; ip address x.x.x.x". With python (or whatever language) you can actually do the exact same things, it is just that the sintax changes and that you can re-use your configs on hundreds/thousands of devices in one go. You will still be a network enginner, that uses a different CLI. You learned IOS without any problem, now you just have to learn a "different IOS". Seeing it like this I have to say that that the "change" becomes easier to accept.

  3. Hi Hank, I am currently just a CCNA holder, how do I proceed to becoming a devnet engineer ?

    Amazing post Hank !!! There is a lot to do and a lot going on ... good documentations are in the pipeline, communities formed in the past are getting stronger and at this fast pace I'm pretty sure that programming is "a plus" for today but it will become a must-have tool in the very near future.

    i have written several python3 based packages. the first python program i wrote was based on a need to turn interactive ssh sessions into non-interactive sessions. the program uses a package called pexpect. the main purpose behind the program was to solve a problem of bulk device changes using multiprocessing (the python program first started its life as a TCL/Expect script). i was able to make configuration changes to 346 wan routers in minutes. then i got to thinking. i wrote a python package. I named the package ciscopy; thus extending the first python program. the package contains modules for networking objects (router, switch, switch stack, reachability, ip addresses, etc.), snmp objects, configuration objects, interface objects, etc. this package is now indispensable for me. in fact, i just keep developing it as needed. the use case for it. automate the production of a CMDB file of CIs that may then be used to populate a CMDB so that the network devices may then be added into a network management system. as a network engineer i cannot be without python now, and wonder how had i got through in the past without python. the latest package/program i wrote was to solve a problem with backing up Cisco CMX and then used cron to schedule the program. the program has off-box transfer of backup file using scp, backup file transfer validation, and email notifications if something went wrong along the way included. wrote the program once, tested, and deployed to the Cisco CMX fleet of servers. networking and python; way to go...

      That's awesome John! Very cool. Is "ciscopy" something you post and share with others, or your personal secret weapon?

    Python is a handy application to have in my tool belt. I would like to see better documentation of the modules that Cisco imports into the python environments embedded in their equipment. I'm using Nexus 5K gear running version 5 NX-OS software, but the website referenced in the "help()" documentation, http://docs.python.org/library/cisco, doesn't exist. Difficult to use the module and it's various classes w/out a roadmap.

    Great article. Shows what direction the network community is moving, and moving fast. Not claiming we have put CLI to bed in the next 2-3 years, but it will happen :D

      Thanks Henrik! I'm not sure the CLI will ever go completely away. That would indicate that direct network engineer interaction with devices is no longer needed, and I doubt we'll ever go quite that far. There will still be a need for troubleshooting, exploring status, verification, etc... all of that is much easier to do via CLI than having to craft an API call each time..

    In the beginning I hoped all the controllers and tools would give me all the solutions I want without programming. But I figured out at least in the moment there is a lot you can't get without at least manipulating some python scripts. In the moment one of my topics is to convince my colleagues that at least they should be able to understand the python scripts and use them instead of the cli and the copy & paste approach they are used to for such a long time.

      Christoph.. I think a lot of us had big expectations for some of the new SDN tools and features that they would fit all our needs and use cases, and have come to a similar conclusion as yourself. I'm not sure we'll ever get to the point where the majority of engineers and their problems can fit neatly into packaged solutions from Open Source of vendors.. I expect it will always be a bit of both...

  4. I have been scripting for years. Typically a few lines of code for filtering log files or automatically generating config files. I'm happy to learn Python or Perl because, despite the learning curve it does pay you back. HOWEVER Networks are progressively more sophisticated, evolving from relatively small flat topologies the average enterprise could now run converged services in parallel with interior and exterior protocols facing multiple service / cloud providers. Getting skilled engineering help is tough at the moment and the complexity of current solutions risks configuration error through misunderstanding or genuine mistake. Adding code on top of this complexity, to me, seems like a significant mistake. Tunability of traffic flows across the control plane using mature APIs obviously adds value. But done badly this is likely to increase instability, not reduce it.

      Alexis, Just like anything new, scripting with Python and using new APIs for automation will require engineers to learn and master the skills before deploying widely across their network. Anything "done badly" will cause problems as I'm sure can all relate to and share anecdotes of network changes gone wrong. But the fact is that the ability for network engineers to keep up with the rate of change, scale of networks, and processing of requirements is already over extended, and without automation and programmability we will continue to see cases of human error induced outages and errors. We must all learn the skills needed so engineers can once again focus on design and engineering solutions, then leveraging these new tools (one of which is Python) to first test and then deploy widely at scale. Done correctly, this will have massive positive impact to stability. Thanks! Hank

    Python is without any question a must have tool. Agree 100%.

  5. I am new to the networking field. But I strongly believe that Programming is the new way to go. I was able to exercise more control over the virtually simulated GNS3 network than I ever did in the CLI. Simply, I vote for Team Python.

    Great Article. I am a big believer that all traditional network, voice, security engineers should know some programming. Yes, there will be tools to make this easier for those that are not developers, myself included, but understanding how devices communicate with each other and controllers via APIs is very important. There will be a big opportunity for those who can understand programming and can also apply it to traditional networking practices for the purposes of automation, alerting, and self-healing. Those that plan to cling to their CLI and not ascend to the way of IT will soon find themselves obsolete.

      Couldn't agree more Jonathon!

    Good work with that article. A really nice and fresh theme. :)