There’s some interesting news on the SDN/OpenFlow front, both from the side of the provider (Verizon in this case) and the vendor (Cisco). Some is from CTIA and some from Interop, which means that just perhaps something useful may come out of Interop after all!
Verizon’s Elby talked about the role that OpenFlow might play in the cloud. “The cloud is essentially a hosting platform for the SDN,” said Elby in a Light Reading article that quoted his CTIA talk. What strikes me about Elby’s comments is that he’s asking for the same mission “above” OpenFlow that I’ve blogged about before. DevOps in general, and perhaps Donabe in particular, seems to me to be aimed at the spot that Elby wants filled. By creating an abstract view of connectivity, addressing, and resources, you can put an app in the cloud anywhere and have it self-integrate. Elby is right in saying that this capability doesn’t exist, but I think that DevOps is the place that’s currently building it.
What’s interesting here is that it’s clear that Verizon has been thinking a lot about OpenFlow and the cloud, which demonstrates that the interest from Google in OpenFlow as a cloud-backbone isn’t the only example of cloud linkage to OpenFlow that’s out there. I expect that the spring survey will show that the cloud/OpenFlow connection has been made by pretty much all of the Tier One operators, and further that most of them have the same vision regarding the need to create some higher-level function to provide the knowledge of cloud connectivity that OpenFlow would demand.
We’ve seen some recent positioning about OpenFlow and the cloud, but given both Google’s presentation and Verizon’s, it’s hard to understand why vendors haven’t jumped on the OpenFlow cloud angle sooner. The Google project has been going on for over a year according to my sources. The longest-running Tier One project in the area is nearly two years old. Google clearly did their thing without vendor support, so imagine what might happen if there was real support and not just “softwashing” of switches and routers with SDN claims.
Some of that support may be coming from Cisco, who happens to be heading the Donabe project. In an Interop pitch also reported in Light Reading, Cisco CTO Warrior talked about what it’s calling the Cisco Open Programmable Environment, which is a layer above the SDN/OpenFlow process and which extends upward into software, and according to Warrior’s presentation, to orchestration. If all of this is real, it could be a real coup for Cisco. According to the talk, Cisco’s framework will be “open”, which I take to mean it involves enough open-source that it will have to be offered with open interfaces and possibly even open-source code. It will likely then have developer programs associated with it, programs that could be relied upon to build not only software to drive basic applications automating connection management, but complicated ones that involve cloud provisioning and service-layer component orchestration. In short, Cisco might be building a bridge that links all of the critical stuff of the age, and building it across both the enterprise and service provider spaces.
One benefit this has for Cisco (and let’s face it, there has to be a benefit because this isn’t charity, it’s a competitive industry) is that this higher layer will be able to manage virtualization not only for OpenFlow/SDN networks but also for tunnels based on IP technology, including MPLS. I think it’s also likely Cisco plans to use the same layer to manage optical paths, which would mean Cisco could become the first vendor to fully integrate its stack of protocols and services vertically with applications.
One interesting question is whether this sort of thing, which has as I said a clear developer connection, will make Cisco much more attractive to developers than its competitors. Developers want two things from a vendor partner, exposure and facilitation for their value-add. A well-designed framework with the kind of features that Warrior alluded to in her talk would certainly provide an easier jumping-off point for development than one that requires that developers work with the primitive device-level APIs. And of course nobody doubts that Cisco can provide exposure.