Big Switch has announced its defection from Open Daylight, and the move has been greeted with all the usual “I-told-you-so’s”. According to the majority who’ve commented so far, this is because Cisco contributed its open-source controller as a deliberate move to crush the business model of Big Switch. Well, I don’t know about that.
First, anyone who thought (or still thinks) that they can be successful based solely on an OpenFlow Controller is delusional. There’s a ton of stuff out there that’s open-source and free already (Big Switch has a free version). The problem with OpenFlow is and has always been those pesky northbound APIs, the stuff that links OpenFlow with all the network and service intelligence that nobody wanted to bother sticking in…including Big Switch. They needed, from the first, to focus on what they’re focusing on now—northbound applications. They didn’t, and if they thought that joining Open Daylight to contribute their free controller so people would be up-sold to the commercial version instead, they were unrealistic.
But this doesn’t mean that Cisco isn’t playing its own opportunistic game. Did somebody out there actually think that Open Daylight was a happy band of market/tech socialists contributing all of their abilities to match all the market’s needs? Everyone in the process is out for something, which has been true of every one of these groups in the past and will be true of all the future ones too.
In any case, Cisco isn’t gunning for Big Switch (why bother?) they’re gunning for VMware. Everyone in the vendor space knows darn straight well that virtualization, the cloud, and SDN are going to combine to fuel NFV and a displacement of network devices by hosted software. VMware is in a darn good position to be a major player in that space, though I think their smarts with NFV and even the broader missions of SDN have yet to be demonstrated. In the enterprise, where Cisco can’t afford to take chances, VMware hurts and an industry group like Open Daylight erodes its advantage by standardizing and open-sourcing some of the key components.
And it’s not junky code. I took a look at the Open Daylight controller code, with the help of a friend who’s one of the hundred-odd engineers working on it. It’s nice, modular, and not particularly Cisco-centric. Yes, you can add a ONEpk plugin pretty easily but that would be true of any plugin. Why gripe about modularity and expandability?
I still have major reservations about Open Daylight, and to be sure Cisco’s willingness to back it creates one of them. But as I said before about the venture, whatever else it is, it’s an SDN activity that’s actually developing an implementation. It could just do something useful, even northbound, at a time when standards activities are contemplating the whichness of why, their navels, or both.
Meanwhile, I had a chance to get a look at Brocade’s SDN strategy, and I was surprised by how good it was and how well they articulated it at a technical level. Their Vyatta buy is paying off by providing them a flexible virtual router that’s just been picked by Rackspace for virtual hosting support, and they’re also represented in my survey of strategic vendors for network operators for the first time since the survey started. No, they’re not threatening any of the leaders, but they will surely make the playoffs even if they don’t gain further as the responses come back.
The problem Brocade has is the same that many have, but with a complication. Market positioning and website articulation are awful, press attention is non-existent, and they don’t kiss analyst rings so they don’t get any love there either. And since Brocade is very much a channel-sales company, outreach is the only way to get a strategy change going. If they can fix that problem they have a chance of riding SDN and NFV to some decent carrier attention and especially to seize some control of the nacent enterprise SDN opportunity.
With Brocade as with so many SDN advocates, though, it’s going to be NFV that differentiates them or tosses their last chance in the trash. Brocade hasn’t articulated its NFV position but they are engaged in the activity and they’ve been quietly doing stuff that has gotten them carrier attention; it’s NFV in fact that carriers cite as their primary reason for being more interested in Brocade as a strategic partner.
SDN is going to be a big part of NFV implementation; in fact it’s likely that NFV will drive SDN consumption more than multi-tenancy in the cloud would do. Every NFV service will likely have to keep its virtual functions partitioned, and if the service is instantiated per user as business services likely would be, then there will be many partitions. Furthermore, interior traffic in virtual services of any sort are IMHO exempt from neutrality rules, which would allow operators even in the US to prioritize their intra-NFV traffic. Net-net, this could be a very significant time for SDN, and NFV, and even Open Daylight. And, yes, for Brocade.