We’re at the end of the 2010s. It’s almost time to start making posts about 2020 and somehow working vision or eyesight into the theme so you can look just like everyone else. But I want to look back for a moment on how much things have changed for networking in the last ten years.
It’s true that networking wasn’t too exciting for most of the 2000s. Things got faster and more complicated. Nothing really got better except the bottom lines of people pushing bigger hardware. And that’s honestly how we liked it. Because the idea that we were all special people that needed to be at the top of our game to get things done resonated with us. We weren’t just mechanics. We were the automobile designers of the future!
But if there’s something that the mobile revolution of the late 2000s taught us, it was that operators don’t need to be programmers to enjoy using technology. Likewise, enterprise users don’t need to be CCIEs or VCDXs to make things work. That’s the real secret behind all the of the advances in networking technology in the 2010s. We’re not making networking harder any more. We’re not adding complexity for the sake of making our lives more important.
The rapid pace of change that we’ve had over the last ten years is the driver for so many technologies that are changing the role of networking engineers. Automation, orchestration, and software-driven networking aren’t just fads. They’re necessities. That’s because of the focus on new features, not in spite of them. I can remember administering CallManager years ago and not realizing what half of the checkboxes on a line appearance did. That’s not helping things.
There are those that would say that what we’re doing is just hiding the complexity behind another layer of abstraction, which is a favorite saying of Russ White. I’d argue that we’re not hiding the complexity as much as we’re putting it back where it belongs – out of sight. We don’t need the added complexity for most operations. This flies in the face of what we want networking engineers to know. If you want to be part of the club you have to know every LSA type and how they interact and what happens during an OSPF DR election. That’s the barrier for entry, right?
Except not everyone needs to know that stuff. They need to know what it looks like when routing is down. More likely, they just need to recognize more basic stuff like DNS being down or something being wrong in the service provider. The odds are way better that something else is causing the problem somewhere outside of your control. And that means your skills are good for very little once you’ve figured out that the problem is somewhere you can’t help.
Hiding complexity behind summary screens or simple policy decisions isn’t bad. In fact, it tends to keep people from diving down rabbit holes when fixing the problems. How many times have we tried to figure out some complicated timer issue when it was really a client with a tenuous connection or a DNS issue? We want the problems to be complicated so we can flex our knowledge to others when in fact we should be applying Occam’s Razor much earlier in the process. Instead of trying to find the most complicated solution to the problem so we can justify our learning, we should instead try to make it as simple as possible to conserve that energy for a time when it’s really needed.
We need to leverage the tools that have been developed to make our lives easier in the 2020s instead of railing against them because they’re upsetting our view of how things should be. Maybe networking in 2010 needed complexity and syntax and command lines. But networking in 2022 might need automated scripts and telemetry to figure things out faster since there are ten times the moving parts. It’s like memorizing phone numbers. It works well when you only need to know seven or eight with a few digits. But when you need to know several hundred each with ten or more digits it’s impossible. Yet I still hear people complain about contact lists or phone books because “they used to be good at memorizing numbers”. Instead of us focusing on what we used to be good at, let’s try to keep with the times and be good at what we need to be good at now and in the future.
Pingback: Obfuscating Complexity Considered Harmful – rule 11 reader
Pingback: Obfuscating Complexity Considered Harmful - GistTree
Pingback: Science Technology Obfuscating Complexity Considered Harmful »
Pingback: Obfuscating Complexity Considered Harmful - Morning News