Fresh off a week at the C-scape, the Cisco analyst event that takes place alongside their user conference Cisco Live! in Orlando, I thought I would attempt to summarize my takeaways regarding Cisco and SDN. To be honest there was not a lot new, but at the same time I feel I have a better understanding of the pieces of the puzzle while others for me remain a bit disjointed. Cisco ONE is Cisco’s response to SDN and network programmability. This is a uniquely Cisco view of SDN and how it should be approached.

There are three components within the Cisco ONE portfolio: onePK APIs, ONE Controller, and Network Overlays. The onePK is provided by Cisco and designed to interface deeply and directly with Cisco’s networking hardware and operating systems.  The other two components are intended to interface with other third party touch points. The ONE Controller is designed to provide interoperability between Cisco gear and OpenFlow agents. The final piece will provide interoperability between Cisco gear and various gateways, cloudstacks, and hypervisors. Bits and pieces are available now with the remainder scheduled for release over the next 12 months. To date the only platform shipping with support for onePK is the ISR G2. The ONE controller has not been released yet and to the best of my understanding is supposed to be part of the OpenDayLight project. Within the Network Overlay piece, the CSR 1000V, Nexus 1000V are available now along with Service Chaining (vPath) and the OpenStack plugin.

So in a nutshell, Cisco is providing their version of network programmability through a series of APIs, controllers, and plugins. It’s clear that Cisco does not completely buy into the notion of “separating the control and data plane” which to many translates to moving networking functionality onto less expensive commodity hardware platforms. Rather, they are offering up a framework to address the desire for a more programmable networking layer while protecting intelligence within the delivery plane. While this might not represent the SDN vision of some, it does allow shops that have heavily invested in Cisco to leverage that investment and build cloud infrastructures that are more tightly integrated with the networking layer. And while I might normally think this is a great deal of smoke and mirrors, we actually had some compelling conversations with real live Cisco customers playing with these APIs in the field, solving real business problems. Mind you, if you have no interest in DevOps, then you have little business digging into any API-based SDN approach, regardless of who is promoting it. So while this approach is not for everyone and certainly not without a DevOps team on hand, it does and is enabling Cisco customers to take advantage of OpenFlow and reuse existing resources in new ways to solve infrastructure challenges while reducing their OPEX.

Cisco has no intention of ceding its investment in networking equipment.  As a matter of fact, Cisco has every intention of moving the focus away from the topic of network virtualization and has squarely set its sights on datacenter orchestration and control. Cisco will not let VMware dictate how the network will be run and orchestrated. While you might want to dismiss Cisco out of hand, because they “don’t do software,” it is never a good idea to underestimate the power of sheer determination, of which Cisco has no shortage, combined with a dominant market position. We have watched Cisco turn its position from nothing to market leader in the past despite the odds being well stacked against them. While I cringe at their use of taglines like #GameChanger and “Internet of Everything” I don’t doubt their sincerity at giving VMware a good run for their money.

SDN has rapidly become an overhyped term and one that everyone is looking to turn to their particular advantage. In doing so, the term itself becomes meaningless. If you step back and look at the various efforts afoot, the root of the movement is in the fact that the network has become the long pole in the tent. The network lacks the flexibility and ability to rapidly respond to change that the datacenter has enjoyed since it has embraced sever virtualization, and now that the server tier is virtualized and flexible, the network becomes the boat anchor.

There are currently two primary paths to alleviating the network “problem.” One is via overlay networks. The overlay approach is datacenter-driven and still relies on the existing underlying network infrastructure. The problem with overlay networks is that no one has clearly defined how they will avoid creating choke points in the existing network and how these networks will be managed and who is going to troubleshoot them. The second approach uses a combination of controllers and APIs. This is the route Cisco has chosen. The controllers in most cases are acting as middleware and the APIs provide the programmability. This means you need some application coding/development expertise to get it all working together. None of this stuff is out of the box, plug and play ready for the average enterprise. However, for those more progressive IT shops with lots of in house expertise (including a squad of seasoned developers) these API-based approaches open up new ways to leverage existing infrastructure. The rest of the enterprise community will wait until product developers tie together the pieces and leverage the APIs to build/productize/support orchestration middleware that can fully take advantage of these new flexible network architectures.

 

Enhanced by Zemanta