The climate of networks is changing. We're all accustomed to network hardware and software dinosaurs. The old systems don't include features or performance that are needed in modern network designs. This often results in the old hardware being relegated to parts of the network where the new functionality is not needed. Even there, though, it eventually goes extinct, as network upgrades replace the old equipment that the vendors either don't support or charge exorbitant maintenance fees to support.
Ok, we know about the hardware and software, but what about "peopleware"? For more than twenty years, we have taught tens of thousands of network engineers how to design, configure, operate, and diagnose networks -- one box at a time. We've also known for some time now (at least ten years) that this model doesn't scale well as networks grow in size, complexity, and dynamics. The box-at-a-time model is being replaced with software-defined networks (SDNs), a key component of which is network automation via application programming interfaces (APIs).
Network automation can be applied to nearly any network equipment. The NETCONF and YANG initiatives provide data models and the communication protocol for working with a wide range of network devices. These initiatives are conceptually not that different than the SNMP and the corresponding MIBs.
I've had several individuals tell me something equivalent to the above quote. They just want to continue to do things the way they were taught. These people are network dinosaurs.
Every time I've heard someone talk about not learning anything new, I've been shocked. If I were a corporate manager and someone told me that, I'd be helping them achieve that retirement as soon as possible, because that individual isn't good for the enterprise. Enterprises remain competitive by being innovative, and when the individuals within the organization don't want to innovate, it hurts everyone in the enterprise.
Not adapting to change is also not good for the individual. Learning new things is a good exercise for our brain and keeps it flexible. Besides, it can be fun, if approached with a positive viewpoint.
Learning new network technology isn't foreign to any of us. We've all had to learn new concepts, design methods, implementation details, and troubleshooting techniques for things like IP subnetting (understanding subnetting was one of the major employment advantages for network engineers for many years), VLANs, MPLS, virtual device contexts, LACP, MLAG, IPv6, multicast, (and the list goes on)...
What can we do to adapt? Read and learn. Read about SDN, APIs, and what others are doing with them to make their networks more flexible and reliable. We don't all have to be early adopters, but we should strive to be early mainstream implementers, if we're to provide real value to our employers.
Learn some scripting language fundamentals. I'm not talking about learning to be a software developer; I'm talking about learning enough that you can understand the language of software development so that you can talk with developers. Know what JSON is, its structure, and how to read it. In a Software Gone Wild podcast at ipspace.net, Ivan Pepelnjak and Nick Buraglio say that it is best to pair a network engineer with a software developer when developing network automation software (specifically, look for the discussion starting at 24:15). Even better, be the person who bridges the chasm between networking and software.
You don't have to be able to write the software yourself, although obtaining some basic programming experience will be valuable. You need to learn the basic structures in most of the languages that are used for network automation. In Python, one of the more popular network automation languages, it is useful to understand the basic syntax, lists, dictionaries (hash tables), and control flow mechanisms. (There are many free online courses on Python.) It would be useful to gain an understanding of modular software development and when recursion is useful as well as when it is a problem. Also learn about some of the automation systems, such as Ansible, Chef, or Puppet.
Ivan Pepelnjak is doing a six-week online course at ipspace.net titled Building Network Automation Solutions that promises to be a great opportunity to learn how to apply Ansible to network automation. It isn't free, though so if you're on a budget or can't work with his course schedule, there are plenty of free Ansible tutorials online. You may have to look through a few lists to find the ones that apply to network device automation, but they're out there.
Work with some software developers to learn how to estimate the size and duration of software projects. Look for places to recommend where diagnostic functions should be incorporated so that the software and the network it controls is easy to monitor and manage. In the podcast I mentioned above, Buraglio talks about wanting a CLI that someone had developed for doing low-level diagnostics. Software developers may not know what diagnostic information is valuable, and that's where our operational expertise comes into play.
We'll see certifications embrace network automation, just like they have included other new technologies as they have been developed. SDN and network automation is simply another cycle in the progression of network evolution. Yes, it is something else to learn, but that's not a bad thing. It makes individuals who stay up with current technology and hold advanced certifications more valuable to their employers. I welcome the change to networking and look forward to the day when we configure the network by describing the desired result instead of configuring individual boxes.
