Jumping into the DevNet waters! Part 1

First I am not a programmer, didn’t take computer science in college, I’m just not a “software/programmer” guy. I started in Electrical Engineering doing high power RF and Microwave at the RHIC particle Accelerator and my passion is and always will be hardware.

bnl

I did a career change in the early 90’s going into IT doing the MCSE path then CCNA-CCIE path. None of this required a lick of programing skills. I did take Pascal and Fortran in the early ’80s in College but programming was not for me and ive had a very sucessful career for the last 25 years without programing.

Over the years as we see SDN and in general software-defined anything become commonplace in IT we see that new skill sets are needed in understanding how API calls and programming is used to interact with these platforms. The industry for networking, storage compute and virtualization is moving to a controller-based approach for managing multiple IT assets using API driven controllers. I can remember being at the CiscoLive 2014 NetVet event and John Chambers telling a room full of CCIE’s to get ready as someday you will no longer configure a network device using the command line of each device. That became a reality with ACI as you must configure everything from the APIC controller. Also now that most companies are migrating some or in cases a lot of workloads to the public cloud we find that there are significant advantages to understand how API’s work and how to automation function with tools like Ansible and Terraform.

I’ve worked with ACI for many years and could do some basic programming with Postman and some very basic stuff controlling MP-BGP EVPN fabrics with Ansible, but never could get very deep. And while I am a top expert in data-center switching, MPLS, routing, compute, and virtualization I found myself very lacking in DevNet. Taking the next step in keeping up with the industry and being able to deeply learn API calls and how to interact with platforms with automation tools is starting to become a necessary skill especially in my new role in R&D work with Cisco and other OEM’s. As the years have gone by, I’ve watched a lot of coworkers take to programming and automation very easily, however, most of them took computer science then went directly into IT so they had the necessary programming background to easily transition from a network engineer to a network engineer using DevNet to automate.

I felt more and more like the dog in Chevy Chase’s Vacation and had to figure out a way to keep up as I was being dragged along and not keeping up. “Poor little guy probably kept up with yah for a mile or so”

One of my biggest challenges was how to get started with Python and setting up my Windows laptop for being able to program. I think the Windows platform was one of the biggest hindrances as I would try and do installs of these software packages, they would fail I would get frustrated. Add that to just tons of work and traveling and it wasn’t super relevant in a pre-sales role, I could never get started and just kept getting dragged along like the Griswalds pooch.

One of the things the WWT Automation practice came up with was some program-ability labs and the concept of a “CONE”. Now when I think of CONE I think of Cone-head or something like this (let us see if anyone knows where my hats from)

That’s not exactly how WWT defines a CONE but rather a “CONE” is a Crusty Old Network Engineer. What we are seeing in our customer base as well as in our engineers is the lack of DevNet skills to get today’s network engineers up to speed using automation tools.

Two of my co-workers Joel King and Jeff Andiorio https://www.wwt.com/article/turning-cones-into-unicorns https://blogs.cisco.com/developer/get-certified wrote great posts on why “CONE’s” need to learn automation skills and become “Unicorns”. An experienced CCIE that can do automation is very rare in the industry and as the industry turns to more and more programmable infrastructures a CCIE with Devnet Certs becomes a very valuable asset to the company. Also as the command-line configuration of individual devices is removed (like in ACI), any network engineer will need to know how to interact via API calls and will need to know how to do this. One of the things I was also lacking was a structured way of doing that and we shall get into that in part 2.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.