New Ways of Thinking

Rule 11 definitely applies to most new technology that’s being hyped (and overhyped) in the networking world. But while some things stay the same, others actually do change. From one of my readers—

Much of the current “trends” in networking are largely just new marketing-speak on old concepts, but some (I’ll propose) are actually new, or require new ways of thinking—which is which, or for a simpler version: how (really) should I change my thinking to reflect the new-networking-order?

This question rebounds through the networking industry today—how, really, do I need to change my thinking to cope with the new networking order? There are, on the face of it, three options available. Let me begin with a story from a prior career to set the stage.

A long time ago, in a galaxy far away, I worked on airfield electronics and communication systems. Things like RADAR systems, wind speed measurement systems, TACANs, VORs, crypto hardware, MUX’s, inverse MUX’s, and even telephone switches. There was a point when I saw something interesting happening where I lived and spent my time. The TACAN and VOR, for instance, were replaced by new gear. Instead of half splitting, measuring things, and replacing individual components, the new gear required me to sit at a terminal and select from a menu system. The menu system drove diagnostics which, in turn, told me which part to replace. I could walk over to the supply point, grab the right part, replace the part, and then do a turn-around, sending the part to the depot for repair.

I thought, at first, this transferred all the work to the depot folks. “I’d really rather be in the depot,” I thought, “taking in all these broken parts and doing the hard troubleshooting and repair.” Then I visited one—it wasn’t quite what I thought it would be. In reality, there was a test bench with a small computer (for the time, at least), and a set of test harnesses. The depot person would grab a part out of the box, plug it into the test harness, and select some menu items that would tell them what part needed to be replaced. They would pull the larger unit apart, replace the part, tossing the old one in the garbage, repackage the now repaired unit, and prepare it for shipment back to some other Air Force base.

As it turned out, all the actual work of troubleshooting and repair had been moved to the designers, leaving essentially nothing but manual labor for the actual tech on site and for the person in the depot. Over my time in airfield electronics, I saw this same pattern repeat—the TACAN, VOR, storm detection RADAR, wind speed, runway visual range, etc.—one by one they fell to the automation monster, as it were.

This is the lesson I originally tried to apply to the networking field and devops, when I first encountered them. The problem is the lesson is only partially true. There are some places where the automation monster is, in fact, taking over. Hyperconvergence seems to be one such place. If it’s true that 80% or more of the enterprise data centers can be replaced with a few racks of hyperconverged equipment, then 80% of the network engineers out there focusing on enterprise scale data center design are destined for some bad news of one sort or another.

There are others, though, where this paradigm just doesn’t fit. So, to wit, what is a network engineer to do? What skills do I need to learn, and how do I cope? There is a part of the story above I didn’t tell you. There were a certain number of engineers who, on seeing the changes taking place, stopped focusing on troubleshooting the parts, and started focusing on troubleshooting the whole. Instead of trying to figure out which part of a landing system was broken, they learned how the landing system worked so they could figure out why it wasn’t working right even when the manual didn’t tell them the right answer. In the real world, there are always things the designer doesn’t think about. The engineer who asks “why” can always solve the problem, even if they don’t know the details of which resister is soldered in where.

With all this mind, let’s return to the three options—

First, you can keep learning things the way we’ve always learned them. You could learn each new product as it comes out, figuring out the configuration interface the vendor gives you, learning the operation of each protocol, etc. This is useful, of course, because vendors always seem to be coming out with new products, and standards bodies always seem to be coming out with new protocols. These bits of information are really needed in day to day life right now, hype or not. In other words, you can move into the depot in my example.

Second, you could opt out, in a sense, and move into managing relationships from the strength of technical knowledge, rather than managing technology directly. You could move all your company’s work to “the cloud,” for instance, and let someone else take care of racking and stacking, while you take care of measuring performance and managing contracts.

Third, you could opt up, in a sense, and move into asking “why,” rather than “what.” In this case, you learn why things work they way they do, so you can learn to see the patterns across multiple technologies, and hence learn how to be a designer. It doesn’t matter if you’re a designer working for a cloud company, or a designer working for an enterprise, or a designer working for a vendor; no matter how automated the world gets, there will still be a need for designers (“meaning makers,” to put it in philosophical terms).

There is one point to make in terms of the options here versus the options I had in electronics when this transition took place: there is a point, in the real world, where there are enough airfields. There’s a time when we’re saturated with advanced airfield landing systems. I don’t know that we’re anywhere near that point for networks. Maybe, some day, we will be, but I don’t think we’re near there yet.

Reflecting on these choices, I don’t think one is “right,” and another “wrong.” It all depends on your bent of mind, what you enjoy, where you are in life, and what’s important to you. Some people just like to dig around in the CLI and API. Others just like to manage contracts and measure performance. Others like to think through how things work and why they work that way.

The skills you’re actually going to need to survive are going to depend on which of these options you choose. This blog, ‘net Work, is all about the third option (if you’ve not figured that out before now, now you know). My direction has been to learn how things work and why, rather than focusing on keeping up with the command line. I won’t say another option is wrong, but if you want to understand the path I’ve taken, then you should stick around and read my posts. I’m still learning how to explain, and I’m still actually learning how to blend knowing the what, the how, and the why in the right measures.

In a future post, I’ll try to give a more definitive answer to the original question, perhaps; this will have to do for now.