We did not attend Interop this week. We had an unavoidable scheduling conflict and obligations elsewhere that may or may not involve a 6-year old’s musical performance. Otherwise, we would have been there, it was a very interesting show this year.
The networking space has gotten interesting again after many years of not being so. The reason for this can be explained in one acronym – SDN or software-defined networking. If you look at the flood of press releases and product introductions in the week ahead of Interop, it is clear that this topic is on everyone’s minds.
We are not going to dive into the technical details of SDN today. That would require a lot more words than we have time or space for. Instead, we are just going to examine some of the language around this latest hot topic, because there is an interesting lesson there.
The Origins of “SDN”
You may have noticed we have not defined SDN yet. It turns out that there is no simple definition, the definition itself has become part of the debate.
While SDN as a concept has been kicking around for five years or so, it started getting a lot of interest and momentum about two years ago. At that time, Nicira ‘de-cloaked’ and announced its products, explained its architecture and named customers. This mattered because Nicira’s founders had done much of the original academic work on the central pillars of SDN. While Nicira ended up going down a different path, that initial work led to a protocol called Open Flow and a supporting organization, the Open Network Foundation (ONF).
A second major development was that Google announced that it was actually using Open Flow in its own data centers. Until this point, no one was sure if Open Flow actually worked, and certainly no one was clear that it could operate at Googlescale. Suddenly, the ideas behind SDN seemed not only tangible but a new force in their own right. Set aside for the moment that Google was only using Open Flow for a very specific use case at the frontier of their data centers.
Software Dines Out
In networking circles, all of this was interesting stuff. Even before Nicira was eventually acquired by VMware for a cool $1.2 billion, the Valley’s PR machine was in full effect as many venture-backed companies used the news to build their own mindshare. All of this would have been noteworthy in its own right. But around the same time, something else important happened. Valley luminary, Netscape founder and partner at Andreesen Horrowitz, Marc Andreesen published an editorial in the Wall Street Journal. The title of this piece was “Software will Eat the World” and that pretty much sums up its content. Andreesen held that all the complex problems in technology (and the world) would be solved by software in the future, and that hardware was essentially a commodity. The value in technology, he argued, would shift irrevocably to software. The implication was that hardware would just run on lowest-cost parts. Set aside for the moment that Andreesen Horrowitz was an investor in Nicira.
In some circles, this piece lit the world on fire. For the increasingly software-oriented Valley, this ideal sounded like the clarion call of revolution. Time to storm the barricades. For the hardware makers of the world this provoked an awkward silence. Many chose to ignore it. Building hardware is not easy. Plastic, metal and silicon can still do things that software cannot, was the response of some. Others tried to go out of their way to demonstrate their software credentials or acquire their way into a transformation. Set aside for the moment that Marc Andreesen was on the board of HP when they acquired Autonomy.
Wherever you stand on the soft vs. hard spectrum, there is some logic to Software Eating the World. It certainly crystalized the debate for many. Hardware develops as a step function. You build a box, it does certain things. If you want it do something new, you have to build a new box. That product cycle from one box to another takes years, and each time the box has to be triple checked, because if something does not work, it is very hard to fix. This is even more true if you are building your own chips. By contrast, if you write software, especially software that runs on the web, you can release it quickly, then add features and fix bugs as needed. Yes, we are simplifying things greatly, but it is important to understand that we are really talking about two very different ways of thinking. Two distinct philosophies of engineering.
All of this brings us to software-defined networking. In light of the events above, it is easy to see how the tech community could get excited about SDN. Networking is complicated stuff, and in many ways it seems to have fallen behind the rest of the tech industry. The idea that as software ate the world, we could suddenly solve our very complicated networking problems with software held immense appeal. And this led to a tidal wave of momentum and, dare we say it, hype. SDN achieved nearly mythical proportions. It would soon solve all our problems, and then pick up our dry-cleaning on the way home.
Cisco’s Aikido moves
For the companies who make networking equipment, however, all this SDN talk was much more problematic. This is where we introduce another major player in the story – Cisco. Cisco builds networking equipment, a lot of it. By some estimates they have 60% or 70% of the switch and router market, maybe more depending on what you count. If software eats networking, and we start running commodity switches, well, this would be a big problem for Cisco.
Say what you will about Cisco’s products, it is hard to question their strength of their sales and marketing team. Since SDN burst on the scene, it has been educational to watch Cisco’s response. First, they got out of the way. For a period they were very quiet about SDN. There was the occasional mention, but for the most part they avoided picking fights and let some of SDN’s momentum ebb. In the meantime, they were getting organized behind the scenes.
Then, about a year ago, they responded. Looking back, the marketer in us is a bit in awe of how they handled the situation. They effectively turned SDN’s momentum on itself, like an Aikido Ninja. Right around last year’s ONF Conference they rolled out a series of new products. These had been previewed, and hnits had been dropped in the press. Basic PR footwork, well executed. Their offering was called Cisco ONE, that ‘O’ stands for open, so you probably can see where this is going. This new suite was packed with features. The Cisco marketing team poured out copious details about all of it. It was a lot to digest, and frankly we are still working out the details. Again, we will not get into the technical details here. Suffice it to say, Cisco now had a lot to say, and they used every opportunity to deliver that message.
Importantly, they picked apart ‘SDN’. They pointed out, rightly, that the core protocol, Open Flow, only did a few things, and maybe did not do them in the right way. They pointed out that Open Flow only talked ‘down’ to the network, from a central controller to the various switches in the network. Cisco asked the obvious question, how do those nodes communicate back to the controller. This opened up a debate within the ONF about creating “North-bound” protocols, a debate that has bogged down and continues. Cisco also offered an API or programming interface. “See, we have software configuration in our products too.” The list goes on, but Cisco atomized the SDN conversation into a whole series of discrete conversations. SDN was no longer a thing, it was just a term used to cover a whole bunch of other things.
Crucially, Cisco, with the support of others, called into question the very definition of “SDN”. If you wanted to talk to your Cisco sales rep about SDN, you had to be very precise because you would be meet with a wall of information and detail about a whole host of topics.
As a result, today when people in networking talk about SDN today, they tend to focus on one very specific aspect of SDN – the separation of the control plane and the data pane. This is the function that Open Flow provides, and as it turns out there are other ways to accomplish this.
In the end, this was Cisco’s genius. They completely changed the conversation, Mad Men 101. The conversation around SDN has changed markedly. This is not entirely due to Cisco. It was clear even a year ago, that SDN was too large and too vague. But there is much less of the feeling that Cisco is facing some existential threat. Set aside the fact, the Cisco ONE is not all that revolutionary, and that there are still some big gaps in Cisco’s product strategy.
If you really push people at Cisco about how they respond to the desire for change among big networking customers, they usually move beyond ONE pretty quickly. Instead, if you talk to a fan of Cisco, the conversation is almost certain to eventually turn to Insieme. This is the latest Cisco “spin-in”. A private company backed by Cisco and probably some venture money, packed with former Cisco employees. The Cisco bulls will tell you Insieme is the real Cisco response to SDN. It is hard to argue with this fact since Insieme is in stealth mode, albeit a stealth mode that gets written up in the New York Times. From what we can tell Insieme is probably a year away from unveiling its product. We are equal parts skeptical and intrigued. Insieme has some very smart people working there, and probably has something very interesting in store.
One thing to note about Insieme. On the Jobs page of their very barebones website, about half the openings are for software engineers. The limited details in these make for interesting reading. But most notable is the opening for a GUI Framework Developer, someone who builds graphical user interfaces. This is noteworthy because in our conversations with networking professionals they will almost always mention a key frustration with Cisco products, the fact that so much of the work on them requires typing onto a command line interface. While the rest of the world has come a long ways since the days of DOS, Cisco products still need to be programmed and managed one line at a time.
And this brings us full circle back to the origins of SDN. However you define it, and however much the enthusiasts went overboard, the whole idea caught on because networking equipment customers are frustrated. They are frustrated by having to use archaic command lines, and the complexity of managing traditional switching products. They are frustrated by being sold equipment packed with features they do not need or want. And they are frustrated by Cisco’s healthy margins. That is why Google went down the Open Flow path to begin with, and that is why they design their own switches and have them built by contract manufacturers in Taiwan running Google-designed protocols. There is real demand for an alternative, and that is why Google and many other large web players are pushing for alternatives. And while it is true that Google’s needs are very different from most networking equipment buyers, it is also clear that others are frustrated with the status quo.
The debate over “SDN” has changed, but the debate is not over.