When you take over a network as a technical lead, you often run into design elements that make you do a spit-take. They did WHAT? Really? Were they…stupid? Clueless? Stupid AND clueless?
Maybe they were, but I argue that you should give those humans that came before you a break. You weren’t there. You don’t know what constraints they were operating under. Since you don’t know those things, it’s hard to pass fair judgement. Unfair judgement? Oh, yeah. All day long, and you can even feel righteous while doing so. Super smug.
Now, don’t get me wrong. Maybe they left closet switches as spanning-tree root. Maybe there are lots of access lists permitting all the things. Maybe they stuck you with a VLAN 1 distributed campus-wide. Maybe you’ve got a bunch of switches named “Switch”. Maybe you inherited firewall policies that are not policies so much as evidence for the prosecution. Not that I’m speaking from experience. ????
In other words, perhaps you’ve been handed a design that isn’t a design. It was a network cobbled together by someone who really didn’t know what they were doing. That the network functions at all is a happy accident.
I’m not talking about that sort of network. I’m talking about the sort of network where design is evident, but you’d have never built it that way.
Technology Changes
Think about the emerging technology of today that you’re keen on, but makes you feel a little uncomfortable. Maybe that’s automating network state changes via a pipeline. Would you implement that scary-to-you thing in production? Probably not. At best you’d try it in a low-impact corner of the network, see how it went, and learn the hard lessons we all learn when getting a handle on new tech.
Now imagine yourself in the shoes of the designer that’s got you all upset because of what they didn’t implement. It could be that the technology in question wasn’t ready for production yet. It’s frustrating when you have to do a major architecture change that could have been avoided IF SOMEONE HAD JUST A LITTLE FORESIGHT. But if the nerds in charge weren’t ready back in the day, they likely went with something tried and true that would get the job done.
Networking is always about business enablement. Stability and resiliency are key features of that mission. New networking tech is usually complex, and complexity makes a network fragile.
Constraints Change
What’s your budget for your current project? When I said budget, did you think I meant money? How do you know I didn’t mean power? Or weight? Or rack units? Or labor? Or time?
Any project is bounded by budgetary constraints, and constraints change. A company that was conserving cash because of a slowdown in their industry 5 years ago might be ready to invest heavily in network infrastructure today. A data center that was tight on space a while ago might have several rows available because of a cloud migration today. An IT group that was severely undermanned in the past might be rightsized today.
Network designs are compromises. There is rarely enough money, time, capacity, or humans to deploy the design that would be ideal for the business problems at hand. If you can do better today, that’s outstanding, but don’t assume that your predecessor operated under the same constraints you are.
People Change
You’re a new technical lead on a large enterprise network spanning the better part of two continents. The business is going through a reorganization, and you see BGP EVPN as a solution that would assist the reorg. Do you implement it? Maybe you do, and maybe you don’t.
Part of your thought process to help you decide will be the supportability of the solution. Does the ops team know BGP EVPN? What’s their current workload? Do they have the cycles to support it? How would you train them? Are you able to write the procedures or create the tools that would help them diagnose EVPN issues?
Perhaps human infrastructure of the past just couldn’t support a new technology, for whatever reasons. Maybe today they can.
Network designs should be as simple as possible, but no simpler. Is the new technology in question adding complexity? Probably. Will it solve a business problem? Presumably, or you wouldn’t be considering it. Can people support it? That’s a complicated question. Is there a simpler way to solve the business problem that is more easily supported? Maybe that’s the right answer. Or…maybe it isn’t. And that’s my point.
The Self-Righteous Dump
It’s easy to take a steaming dump on the humans that came before you. I’ve done it myself. It’s a little ego boost that makes you feel smarter than people who aren’t around to defend themselves. You get a 2x ego power boost multiplier if you’re not only smug, but also insecure.
But remember–you weren’t there. You don’t know what was going on at the time. There are many reasons why, at the time, the design put into production was the right one. Just because that design isn’t the right one today doesn’t invalidate the problems it solved yesterday.
