“There is always a well-known solution to every human problem–neat, plausible, and wrong.” H.L. Mencken, Prejudices: Second Series, 1920
I had an interesting conversation today with a cohort of mine regarding network complexity. Specifically, the conversation started out with him mentioning that he thought my network was “bloated with complexity”. He didn’t mean it in a bad way–necessarily–but my first instinct was to take it that way.
Then I started thinking about it. I wondered what, specifically, he might be referring to. Was it the dual-stacked IPv6? The VLANs? The VRFs and multiple redistribution points between protocols? The MP-BGP? Multicast?
It was probably some of these and all of these since he had just been pouring over some network diagrams that I had sent. He did hone in a bit on the IPv6 portion, but more specifically he seemed concerned about the redundancy. Yes, we have multiple routes out of offices, with multiple routers–no single point of failure and all of that. In my mind, however, that is a bonus and evidence of seven years of effort to rebuild this world-wide network into a very, very reliable and robust network.
“We like to keep things simple,” was his response. I pointed out that I could probably rebuild the entire core infrastructure in 12–24 hours, at the command line, from memory, so I didn’t think it was really that complex. He wasn’t necessarily persuaded.
Now don’t get me wrong, the entire conversation was very cordial, and I respect this guy’s bona fides and his judgement. He has a great track record, and a great set of skills in both management and systems administration. But therein lies the rub. His skills mean that what I see as simple solutions to a problem, he sees as a massive level of complexity to be reverse-engineered. Honestly, I’d probably react the same way to some of what he can do on the Active Directory side of the house.
My specialties are data center, bridging/routing, and converged infrastructure, and I’ve been doing that for 19 years professionally, and a hell of a lot longer if you count the years before I figured out someone would pay me for what I know. I briefly wondered if that has put me into an insular world where I can’t see what could be made more simple?
I spent most of the rest of the day thinking about the various parts of my network, and where I had implemented solutions to particular problems. I thought long and hard about what I could do to simplify that particular area of the network and couldn’t come up with anything.
I then turned my attention to whether or not I could add complexity just for the sake of doing it. In most cases the answer was a resounding yes. In fact, I compared what I had done in many places with some of the similar layouts in some of the CCIE labs (admittedly these are at an almost asinine level of complexity, but still…) and found that I had “taken the easy way out” as some of my past teachers were wont to say.
So, then I turned to the more philosophical question of knowledge and the relative nature of it. One of the things that seems to happen to me more often than I’d care to admit is this: I’ll find something in my network that needs fixing, and as I’m looking at the code and the diagrams I’ll wonder what moron did this thing. You’ll probably not be surprised to learn that it was a previous version of me who was the moron.
At the time I was working with what I knew, and I solved the problem using the tools I had, but looking back on it now I realize that I didn’t have all the experience and knowledge I needed to fix the problem correctly. I was approaching the problem based on what I knew, and I probably would have, at the time, viewed my new solution of today as “overly complex and bloated”.
The idea of “keeping it simple” is a good one, and one we should embrace as network engineers and architects as often as we can. If the simplest solution meets all of our requirements without breaking anything else, we should use it. What we should not do, however, is use the concept of keeping it simple to be a catch-all of keeping it so simple that you can hire a CCNA to run a CCIE-level network.
If what you want is a CCNA-level network, and that’s all your business needs, then you’ll be fine. As soon as you start incorporating higher-end systems like top tier ERP systems based on Oracle, redundant SANs in order to provide a certain level of resiliency and performance, 10 and 40-gig Ethernet, blade servers, virtualization, redundant paths and automatic failover, you’ve pretty much let that ship sail, however, and you need to acknowledge that you have a greater need for skilled maintainers of your network than maybe you’d like to believe.
Maybe “keeping it simple” is management code for “we can pay a monkey to maintain this, and maybe make our bonus because we made the IT costs look good this cycle.” In the short term that works. But in the long term there’s a cost to be paid, and if you miscalculate when the note comes due, you’ll likely find yourself in a much worse position when you have to fly a team of high-cost consultants in to clean up the mess.