Complexity Is Relative

Read­ing Time: 4 min­utes

“There is always a well-known solu­tion to every human problem–neat, plau­si­ble, and wrong.”  H.L. Menck­en, Prej­u­dices: Sec­ond Series, 1920

I had an inter­est­ing con­ver­sa­tion today with a cohort of mine regard­ing net­work com­plex­i­ty. Specif­i­cal­ly, the con­ver­sa­tion start­ed out with him men­tion­ing that he thought my net­work was “bloat­ed with com­plex­i­ty”. He did­n’t mean it in a bad way–necessarily–but my first instinct was to take it that way.

Then I start­ed think­ing about it. I won­dered what, specif­i­cal­ly, he might be refer­ring to. Was it the dual-stacked IPv6? The VLANs? The VRFs and mul­ti­ple redis­tri­b­u­tion points between pro­to­cols? The MP-BGP? Mul­ti­cast?

It was prob­a­bly some of these and all of these since he had just been pour­ing over some net­work dia­grams that I had sent. He did hone in a bit on the IPv6 por­tion, but more specif­i­cal­ly he seemed con­cerned about the redun­dan­cy. Yes, we have mul­ti­ple routes out of offices, with mul­ti­ple routers–no sin­gle point of fail­ure and all of that. In my mind, how­ev­er, that is a bonus and evi­dence of sev­en years of effort to rebuild this world-wide net­work into a very, very reli­able and robust net­work.

“We like to keep things sim­ple,” was his response. I point­ed out that I could prob­a­bly rebuild the entire core infra­struc­ture in 12–24 hours, at the com­mand line, from mem­o­ry, so I did­n’t think it was real­ly that com­plex. He was­n’t nec­es­sar­i­ly per­suad­ed.

Now don’t get me wrong, the entire con­ver­sa­tion was very cor­dial, and I respect this guy’s bona fides and his judge­ment. He has a great track record, and a great set of skills in both man­age­ment and sys­tems admin­is­tra­tion. But there­in lies the rub. His skills mean that what I see as sim­ple solu­tions to a prob­lem, he sees as a mas­sive lev­el of com­plex­i­ty to be reverse-engi­neered. Hon­est­ly, I’d prob­a­bly react the same way to some of what he can do on the Active Direc­to­ry side of the house.

My spe­cial­ties are data cen­ter, bridging/routing, and con­verged infra­struc­ture, and I’ve been doing that for 19 years pro­fes­sion­al­ly, and a hell of a lot longer if you count the years before I fig­ured out some­one would pay me for what I know. I briefly won­dered if that has put me into an insu­lar world where I can’t see what could be made more sim­ple?

I spent most of the rest of the day think­ing about the var­i­ous parts of my net­work, and where I had imple­ment­ed solu­tions to par­tic­u­lar prob­lems. I thought long and hard about what I could do to sim­pli­fy that par­tic­u­lar area of the net­work and could­n’t come up with any­thing.

I then turned my atten­tion to whether or not I could add com­plex­i­ty just for the sake of doing it. In most cas­es the answer was a resound­ing yes. In fact, I com­pared what I had done in many places with some of the sim­i­lar lay­outs in some of the CCIE labs (admit­ted­ly these are at an almost asi­nine lev­el of com­plex­i­ty, but still…) and found that I had “tak­en the easy way out” as some of my past teach­ers were wont to say.

So, then I turned to the more philo­soph­i­cal ques­tion of knowl­edge and the rel­a­tive nature of it. One of the things that seems to hap­pen to me more often than I’d care to admit is this: I’ll find some­thing in my net­work that needs fix­ing, and as I’m look­ing at the code and the dia­grams I’ll won­der what moron did this thing. You’ll prob­a­bly not be sur­prised to learn that it was a pre­vi­ous ver­sion of me who was the moron.

At the time I was work­ing with what I knew, and I solved the prob­lem using the tools I had, but look­ing back on it now I real­ize that I did­n’t have all the expe­ri­ence and knowl­edge I need­ed to fix the prob­lem cor­rect­ly. I was approach­ing the prob­lem based on what I knew, and I prob­a­bly would have, at the time, viewed my new solu­tion of today as “over­ly com­plex and bloat­ed”.

The idea of “keep­ing it sim­ple” is a good one, and one we should embrace as net­work engi­neers and archi­tects as often as we can. If the sim­plest solu­tion meets all of our require­ments with­out break­ing any­thing else, we should use it. What we should not do, how­ev­er, is use the con­cept of keep­ing it sim­ple to be a catch-all of keep­ing it so sim­ple that you can hire a CCNA to run a CCIE-lev­el net­work.

If what you want is a CCNA-lev­el net­work, and that’s all your busi­ness needs, then you’ll be fine. As soon as you start incor­po­rat­ing high­er-end sys­tems like top tier ERP sys­tems based on Ora­cle, redun­dant SANs in order to pro­vide a cer­tain lev­el of resilien­cy and per­for­mance, 10 and 40-gig Eth­er­net, blade servers, vir­tu­al­iza­tion, redun­dant paths and auto­mat­ic failover, you’ve pret­ty much let that ship sail, how­ev­er, and you need to acknowl­edge that you have a greater need for skilled main­tain­ers of your net­work than maybe you’d like to believe.

Maybe “keep­ing it sim­ple” is man­age­ment code for “we can pay a mon­key to main­tain 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 mis­cal­cu­late when the note comes due, you’ll like­ly find your­self in a much worse posi­tion when you have to fly a team of high-cost con­sul­tants in to clean up the mess.