Eyvonne Sharp wrote a great blog post describing Cisco’s love of complexity and how SD-WAN vendors proved things don’t have to be that complex.
I’m also positive a lot of the complexity we’re facing is the result of customer requests. You know, those people that never bothered to understand how technology really works (because vendors promised them it’s easy), designed their network based on whitepapers (written by those same vendors), faced scaling challenges, and started yelling at the vendor to implement a dozen nerd knobs (while sometimes breaking the standards) to make their network work (stretched clusters anyone?). It’s amazing what a large PO can bring you ;)
The latest installment in that soap opera: OSPF Topology-Transparent Zone (RFC 8099) because it's easier to add another layer of indirection than fixing a broken network design. OTOH, fixing a broken design rarely sells more boxes and software upgrades.
Another source of complexity: clueless CYA customers that have no idea what they need because they never invested into a proper network design. When such customers create an RFP it often requires every technology ever published as an Internet draft “because we might need it in the future”. I’ve personally seen RFPs that were a laundry list of acronyms compiled from 3+ different vendor specs. Needless to say, nobody fulfilled all the requirements
HT to @Anonymous for reminding me of this one– I’ve been away from system integration business for too long.
Of course it’s not just the customers. Have you ever heard the “doing more with less” and “leveraging the existing investment” mantras (aka LISP-in-Campus)?
The real difference between Cisco and SD-WAN vendors is the length of their history. Cisco has been evolving their software for 30+ years (and has to support most of the **** they were forced to implement to get a particular PO indefinitely) while SD-WAN solutions started with a clean slate. Let’s see how complex SD-WAN solutions will get after being faced with incompatible impossible-to-turn-down opportunities for a decade or two.
It’s also easier to start from scratch and implement a clean bare-bones solution (quite often after learning the hard lessons while working for an “overly complex” $vendor) than trying to retrofit a new idea into the old framework (I still remember IBM mainframes having virtual punched cards and 132-column line printer printouts deep in the bowels of their operating systems).
Is it fair to make fun of the complexity-ridden legacy vendors? Well, it definitely makes for fun reading, but maybe we should just respect old age while at the same time telling the dinosaurs it’s time to change by voting with our wallet.
Can you get away from the complexity?
You do know you don’t have to use all the complexity the vendors are throwing at you, right? It’s possible to design simple and robust large-scale networks if you understand how technology works, and select the best tools for each job at hand.
We discussed how to do just that in data centers in the Building Next-Generation Data Center course in autumn 2016 (here are some of the questions we covered) and will do it again in less than a month. All you have to do is to accept the challenge of working really hard for two months and register for the course.