The grumpy whining about young engineers continues with Part 2 of my commentary on the skills of the fresh-faced in our industry. For context, please make sure you’ve read the original post and Part 1 of this response.
The second reason I raised the topic of skills for younger engineers?
2. Because Abstraction
See how I used the current fad of saying “Because <noun>”? I’m trying to bridge the generation gap, so stick with me for a moment. Let’s assume that this Software Defined Networking (SDN) thing goes full steam ahead, and we end up running automated networks using Python, APIs, controllers, and Single Panes of Glass. What happens when something doesn’t work through the clicky GUI? Is the software going to be smart enough to diagnose and self-repair a problem? Maybe sometimes, but when it’s not, what do we do?
Interestingly, Steven Iveson stole some of my “thought thunder” with his comment on my original post, although it echoes a theme raised on my previous post about the future of networking jobs in an SDN world. It seems that we’re may have a potential problem in the future, which is that the engineers in Tier 1 will be trained to handle the automation and control systems that are managing the network. Tier 3 (the “old guys” mentioned by Steven) are there for when things go wrong, but what’s left for a nominal Tier 2? And how do engineers make the jump from Tier 1 to Tier 3 successfully? I proposed that perhaps we end up in a situation where – since we’ll undoubtedly have a mixture of SDN and non-SDN or partial-SDN networks – Tier 1 may start in a pure SDN environment but would have to step out into a more legacy environment in order to earn their spurs on non-SDN network which would then allow them to learn the skills that would allow them to become that sour old guy in the corner who goes on about how kids today don’t know they’re born and anyway things were cheaper back in my day.
“You mentioned abstraction,” you say. Yes, I did. To clarify, what I’m talking about here applies to a couple of areas. Firstly, that through the push towards fabrics and the software defined data center, we are hiding the underlying network from view. For example, we are abstracting a complex interconnection of switches and links as a “fabric”. We might not know exactly how the fabric works, or perhaps even how it makes its decisions. Does it matter if you know how ISIS works in order to understand TRILL or SPB? The whole concept is that you don’t need to know about it; it’s plug and play networking. And how are you going to manage it? Not node by node for sure; you’re going to manage it like a black box: data goes in, data comes out and what happens in the middle doesn’t matter (so long as it works).
The second area of abstraction – if abstraction is the right word – is that thing that happens to all technologies as they mature. Newcomers to IP don’t worry about how IP works; they just assume it does. And perhaps that’s why they don’t understand ARP; they’ve never encountered a situation where IP just didn’t work! Similarly, I don’t understand the voltages used in Ethernet, because it just works. I’ve abstracted all of that complicated detail to the level of a line on a diagram connecting two devices; I just see the bandwidth it provides and I don’t worry about the underlying technology, and just hope it works when I plug it in.
What about network design? At Networking Field Day 7 I saw two companies – Dell and Juniper – showing us an automated network design solution of sorts. Juniper’s tool was a command line effort, and heaven help me I found myself saying “they need to put a GUI on that”. Don’t tell anybody, please! Dell’s offering, in contrast, was impressively GUified; tell it how many servers, at what speed they will connect, and the tool pretty much spits out a bill of materials, a full cable matrix and the base configurations to put on all the devices so that the network will come up as designed. When the manufacturer goes to that length to present an architecture to you, do you need to even think any more? We’ve abstracted design! I remember reading about the idea of the robotically managed data center last year if not before, and my gut reaction was “how ridiculous”. On the other hand, you do begin to wonder if you can get to the point of going to a data center provider and saying “I need 1000 servers”, and it gets provisioned and built physically at the click of a button. Ok maybe that’s a bit far-fetched, but just this week AT&T discussed their ambitious vision of their own software defined network, where “Customers will be able to self-provision networking services on the fly, as needed, just as they now do with compute services and storage from cloud providers.” Maybe the robots won’t play a part, but seriously, how cool is that?
Getting Back to the Point (Young Engineers)
Abstraction. Maybe it’s a necessary evil in order to spend less time on the parts of the network that are highly reliable and probably never need your skills, and more time on the more complex higher layer protocols running over the top. Truly the commoditization of the network, and something that the lovely folks at Microsoft and VMWare would like us to continue thinking (dumb network, smart overlays).
On the other hand, SDN ain’t here yet. The products are out there but very few data centers are built using them, and the software to make networks pointy clicky isn’t mature enough yet to hand over the data center to Tier 1. Until we get there, do we still have a need for a good understanding of what’s underneath the hood, so to speak?
More to come.