One of the big buzzwords you hear surrounding tech startups is pivot, which is what happens when a company is moving in one direction and makes a strategic decision to go in another direction. For example, the company we now know as Twitter was once known as Odeo, which was going to offer a way for people to subscribe to podcasts. However, with iTunes becoming a dominate force in podcast subscriptions, the decision was made to pivot to a micro-blogging platform.
Sometimes, we need to make a pivot in our own careers based on what we anticipate happening to the industry. For example, many local bookstores have disappeared because of Amazon.com. Blockbuster went bankrupt in their video rental business with the advent of NetFlix and streaming video services.
“The electric light did not come from the continuous improvement of candles.” –Oren Harari
Let’s now consider the networking industry. Personally, I’ve been working with Cisco routers since 1989 (beginning with the Cisco AGS+), and for nearly 28 years I’ve been typing configuration instructions at the command line interface (CLI). After so much time, quite honestly, I don’t really want to change the way I configure networks! But… I know deep down, that the time has come to pivot.
The pivot I’m speaking of is changing from traditional CLI configuration, where I configure individual Cisco devices one at a time, to using Software Defined Networking (SDN). With SDN, an application can send a set of configuration parameters to a network controller, which can then send out appropriate commands to multiple network devices.
Such an approach makes configuration of large networks more scalable, faster, and less error-prone. However, the way in which we issue configuration instructions will be very different. We might use applications someone else wrote, or we might write our own using a programming language like Python.
A heated point of debate surrounding this topic is the ongoing value of traditional routing and switching certifications (including the CCIE R/S certification). My personal conviction is that there will continue to be tremendous value in having these certifications and the requisite knowledge accompanying them. Specifically, I believe to an effective network engineer who uses SDN technologies, you must first understand the inner workings of the network. Sure, SDN can make quick work of pushing out a quality of service (QoS) policy to hundreds of routers, but you should understand exactly what that policy does. Is your committed burst value too high in your policing configuration? How are you marking your different traffic classes? What thresholds should be set for Weighted Random Early Detection (WRED)?
The point is, we should continue to learn how to do things from the CLI, while understanding what each command does. We just need to add a new tool to our arsenal. That tool is SDN, which can help us do our job in a more powerful way.
The way I’m starting my pivot is by going through the following books, and I thought you might get value from them too: