The Ever-Increasing Complexity
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 know Cisco (and every other vendor) loves making ever-more-complex solutions that lock you into their morass for the rest of your life (long-distance vMotion anyone?).
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 ;)
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
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.
I ranted about the never-ending complexity in the Business Aspects of Networking Technologies webinar, and we large-scale data center network designs in the Building Next-Generation Data Center course.
I work for a $vendor. I wish I could share the last 5 RFPs that actually crossed my desk. As long as our customers ask for lock, stock & barrel (i.e. contains every possible feature that they might use somewhere down the line), which is complaint with every standard out there, while leaving all the integration risk with the vendor, all these complex solutions are here to stay.
Customers need to:
1) focus: choose what is important and what not
2) take responsibility: make your own architectural and design decisions