Cisco ONE: Proof that Cisco doesn't get SDN's

Cisco is trying to turn momentum to open the field of networking into its own private initiative and keep the networking industry locked into it’s mainframe-like state.

With the rising popularity of OpenFlow and the Open Networking Foundation, there was a lot of anticipation for Cisco's SDN announcement this week at Cisco live. We know Cisco gets disruptive technologies, and given their early, and aggressive entrance into VoIP and Computing, they should be leading the charge into SDN, right? Wrong. Instead, Cisco is trying to turn momentum to open the field of networking into its own private initiative and keep the networking industry locked into its mainframe-like state. 

Just two months ago at the Open Networking Summit, Google SVP Urs Hoelzle told the world how the search giant had moved its largest network, which happens to be one of the largest networks in the world, to a new network built on OpenFlow. He noted the numerous benefits that Google has already seen, that the migration had been faster and smoother than anticipated due to the new types of advanced tools that were not possible on traditional networks, and what Google had accomplished thus far was just the tip of the iceberg of what they planned to deliver with OpenFlow. Perhaps most importantly, though, Google described how they had to build their OpenFlow network by themselves. They didn't want to build this on their own but, according to Hoelzle, Google tried working with leading networking vendors for a solution, and they were refused. The leading vendors would not join with Google in building what they knew they wanted, what the cloud computing pioneer knew was the right network for the Cloud era.This really comes as no surprise to the SDN community. The entire basis of the SDN movement has been that computing's shift away from closed mainframes to a open computing model has been tremendously positive for the industry and its consumers; however, the networking industry has never made this shift. Cloud computing pioneer James Hamilton nailed this point in his article "Networking: The Last Bastion of Mainframe Computing." This article is excellent and should be required reading for anyone interested in SDN. Take a quick glance at Dr. Nick McKeown's site and you will see that all early presentations on OpenFlow and SDN have this theme. Also, look through the presentations at the Open Networking Summit's and you will also see this common theme pop up frequently. Here is a clip from James Hamilton's article:

So when I saw Cisco's David Ward opine about the complexities of SDN and present a push towards increasing development on an increasingly programmable IOS (the same strategy they have had since 2005), it looked like a repeat of history. Google proves to the skeptics that OpenFlow does in fact work and openly asks the industry to commit to the vision of the Open Networking Foundation, and Cisco once again responds with more of the same.

"The networking equipment world looks just like mainframe computing ecosystem did 40 years ago. A small number of players produce vertically integrated solutions where the ASICs, the hardware design, the hardware manufacture, and the entire software stack are single sourced and vertically integrated. Just as you couldn’t run IBM MVS on a Burrows computer, you can’t run Cisco IOS on Juniper equipment."

So I am sure I will get a lot of flack for this article, but please, someone tell me how Cisco's ONE strategy changes the mainframe-like status of the networking industry at all. How does it change the above picture? And don't tell me that the support for OpenFlow addresses this, because not only was OpenFlow not really encouraged, the decentralized application development was the clearly focus. The decentralized paradigm is fundamentally different, and will not result in a Northbound API that would result from a Centralized Architecture. By clearly encouraging significant net-new development on decentralized architectures, they haven't even begun focusing on developing the significant next-generation network architectures that rely on a centralized control plane. So while they are right about a focus on building a NorthBound API, they are building the entirely wrong Northboud API. InformationWeek Director Art Witmann nailed this point in his article "Cisco Describes SDN Strategy, Sets Industry Back 10 Years". And how about UCS? Cisco jumped ahead of other vendors into private clouds by producing a very small, tightly restricted system that did not support many of the critical features that would eventually be required if companies were to move at a very large scale to UCS. Limited scale, reliance on expensive third-party software, a single network fabric, forced use of FcoE, crippling bandwidth limitations, no real solution for hybrid and community clouds ... all of these things kept other seasoned server vendors from releasing this solution. It simply wasnt mature enough for many critical needs that a holistic approach would require. But Cisco knows that disruption is not about a technology being able to do each and every thing, when disruptive technologies are new, they dont replace every legacy technology on the first day, but where they fit they offer compelling business benefits and a compelling roadmap. Disruptions like SDN deliver a promising new platform that creates a paradigm where new things are possible. While Cisco points out that OpenFlow is still young and needs to mature, they push the entire paradigm to the back seat rather than focusing heavily on developing the new technology as they did for VoIP and UCS. Why? There is a very simple answer, in VoIP and Computing, Cisco was not the incumbent, it was a new entrant into the market. This is disruptive technology strategy 101, folks. Take a quick glance into Clayton Christenson's landmark book, "The Innovator's Solution" and you will find the answer ... all of the research on disruptive technologies has shown that when  there is a disruption in technology, the statistical odds for success favor the new entrant over the incumbent, as shown in this graphic from Dr. Christensen's site:

Consider Cisco's move into VoIP and remember what it was like: every seasoned PBX engineer had numerous, legitimate complaints about the prospects of VoIP. In its early days, the technology had a LOT of challenges. And there was no doubt it was inferior in very significant ways, the largest of which was the mission-critical reliability of the five 9's requirement, or the e911 challenges it has taken years to solve. Despite the numerous challenges, Cisco charged ahead into VoIP promising that the challenges would in time be solved and VoIP would yield significant improvements over the legacy paradigm. This is a stark difference with how Cisco is treating SDN.

This simple principle shows exactly why Cisco charges like a bull in a china shop when someone else is the incumbent, but when Cisco is the incumbent, they take a slow, sheepish path and pretend to be the only ones with a mature rational approach.

Cisco figured out that while disruptive innovations are sometimes truly novel, oftentimes they simply skip a few steps of linear, incremental innovations. Take for example portable music players and consider the portable CD player vs. an iPod. Most companies are too risk averse to release something that doesnt already have an established market, and if Apple hadnt disrupted with the iPod, there probably would have been a more linear approach. Imagine if Sony released a Walkman that had local storage and could save directly from your CD's. Had this happened, it would have still eventually resulted in the iPod-type format, but in a linear, non-disruptive model that would have favored the incumbent. Likewise, we can see that networking missed a step when the rest of distributed computing moved towards SOA/Web Services frameworks with intelligent API's ... that was the time the networking industry should have moved towards decentralized architecture with programmability and advanced API's. Cisco tried this with SONA, but their proprietary and tightly controlled network-centric approach couldnt attract major application developers. Today, technology has matured to the next major paradigm where centralized control planes can provide the insight, control and responsiveness required for robust application interaction. And major application developers are rallying around this paradigm demonstrating that we can now build towards a standard where cloud developers can out-of-the box deliver applications that can send their requests directly to the network.  But this would be a "disruptive" approach that presents too much risk for Cisco. Instead, they have realized if they can wave a shiny coin and get the industry focused on the programmable paradigm, while still saying they are providing a path to the next generation of centralized applications 'eventually, once the technology is mature,' they think they can turn OpenFlow's disruptive potential into a series of incremental innovations spanning a much larger period of time, preserving Cisco's incumbent advantage and giving them another 10 years of spoon-feeding forklift upgrades and selling legacy technology at exorbitant margins, a repeat of the past decade which has proven great for Cisco and not so great for the industry, innovation or consumers. This reminds me of one of the least pleasant periods of time I spent reselling Cisco gear, after Aruba and Trapeze delivered Thin Access Points and Cisco still only had Fat Access Points. I had the ever-so-fun job of trying to unload the Cisco Fat AP's. It was embarrassing trying to present Fat AP's to customers that had already seen the elegant Aruba and Trapeze solutions. I remember waiting and hoping for the first generation of Wireless Lan Solution Engine (WLSE) to be released, an app that was supposed to deliver thin-AP like management and functionality to Fat-AP's. Man, was that a boat anchor. It was one of the worst applications I have ever used, all because it was reliant on completely decentralized intelligence. Just like Cisco's decentralized approach with ONE, the app had to go out and consistently poll hundreds of fat AP's before it could provide a response. It took pressure from competition to force Cisco into rushing their Thin AP support, and it was when they finally moved to Thin AP's that they were able to put out a semi-decent solution. Had it not been for competetive pressure, my bet is that it would have taken Cisco a LOT longer to deliver because they only deliver new solutions once they have milked their legacy investments for all that they possibly can. This is a repeat of that same exact story. Just like the fat-AP based WLSE, today's decentralized Cisco ONE strategy will yield new applications. While they may be an improvement over their current gear, they will barely hold a candle to the applications that are possible with a centralized architecture. Don't believe me? Look at the apps that Cisco has released. Then go over to the OpenFlow website and see what grad students who don't have a fraction of the resources are putting together. And miraculously you will see that with OpenFlow, routers can actually route. By that I mean despite the price premium and the years of maturity, routers still cant route based on any meaningful information that has anything to do with traffic conditions or application considerations. And then see that when you centralize the control plane, this functionality becomes a simple, basic thing. And that is just the tip of the iceberg, while Cisco is focusing on automating router configurations, the top computer scientists in the field will be building the next generation of the internet on a fundamentally new networking paradigm that has so much business benefit that the cloud providers and telcos are diving head-first into OpenFlow as though it were the gold rush.

I think a lot of people hoped that, amidst all of Cisco's apologies to the community about all their recent mishaps, they would actually change. But please go back and look at all of their apologies. Their apologies were not to their engineering customers whose potential they have damaged by milking their legacy approach, and they were not to the industry that has been hurt by monopolistic practices; they were not to the ecosystem that could have emerged in an open paradigm as it has with open computing. Their apologies were to its shareholders, for not fleecing and milking the industry as well as they could have. Their only apology was when their stock market results were below par, and their newfound optimism is found in their new fleecing model for the industry. If you hate what I am saying here before you leave posts bashing me, do one thing, go read James Hamilton's article and tell me how it is not true. Tell me that we wouldnt all benefit from that paradigm. 

SDN is about fundamentally new ways of networking. What Cisco announced essentially promotes automating and enhancing the same old way of networking, complete with the same old proprietary death grip that prevented real advancement in the past. My advice, don't buy into it. SDN could deliver more compelling business benefits for networking than we have seen from any network technology in the past 20 years. I can think of at least one other vendor whose strategy is to move towards centralized SDN every bit as aggressively as Cisco did with VoIP or UCS, but also with a more mature, open approach focused on advancing the entire industry. What I hope? Just like Aruba and Trapeze did with thin access-point architectures, I hope that other vendors will emerge with similar strategies and forces Cisco into following along. And if you look at most of the advancements in networking where Cisco has been the incumbent and almost never "best of breed," following others in networking seems to be Cisco's strategy, not innovation or the risk that comes with it.

Please note, I am a Dell Employee, and this post reflects my own opinion and not necessarily that of Dell. This post is not reviewed or approved in any way by my employer, and my posts are my own words and my own thoughts.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2012 IDG Communications, Inc.

IT Salary Survey: The results are in