If you are in the networking world, chances are you know that Cisco Live is happening this week in Orlando. They were widely expected to announce the official spin-in of Insieme, their enterprise datacenter effort led by the guys who brought us the Nexus and UCS. This morning, Cisco threw us all a bit of a curveball when they teased the spin-in but fell short of actually talking about Insieme products.
— Shamus McGillicuddy (@ShamusTT) June 25, 2013
— ZeeMan (@zkerravala) June 25, 2013
The Cisco presentation coincided with a blog post by Padmasree Warrior (Cisco CTO) where she announced that Cisco was embracing an "application-centric" approach. In the same post, she and Cisco backed away from SDN a bit in favor of loftier goals of networking working in concert with other IT infrastructure silos and ultimately being more tightly connected to the application. Cisco's CEO John Chambers even used the term "application affinity" in his address (you can imagine how we squealed in delight at his adoption of our term affinities!) Indeed, if this talk is any indication, application-driven networking is the new black.
What I am about to write goes against everything they teach you in marketing school. You see, Cisco is certainly Plexxi's biggest competitor. But I think they actually have their central thesis correct. It is about the application.
Of course it does't hurt that Plexxi arrived at this thesis more than two years ago while the world was still debating whether it was software-defined or software-driven networking. Our entire solution offering is predicated on the belief that there is information to be gleaned from the network and information to be shared by the application that can ultimately bring these two worlds together. For the connection between the application and the network to be functional, there needs to be a common data model that describes application workloads.
Where Cisco and Plexxi differ is probably more along the lines of how this is executed and the degree to which programmability is a prerequisite. Cisco has been talking a lot more lately about programmability, touting ONE and onePK as a new collection of APIs and toolkits to facilitate the programming of network functionality directly into a device (or presumably set of devices). This is a page taken from Juniper's playbook several years ago, but with the much larger install base, Cisco should see a more vibrant community emerge than Juniper ever did. Strategically, communities (and application stores) will be more tightly tied to number of installed seats than they are to features and capabilities, which makes this strategy useful to a small number of players.
And while I think programmability offers a lot of power to those who want to program, I do think it raises an interesting question. When we talk about applications and network programmability, do we really want applications programming the network? Anyone on the networking side will surely shudder in fear at the thought of some application wonk specifying how traffic ought to traverse the network. They don't know anything about the network – why would I want them programming it? And then there are the security and stability implications of creating a means for folks outside the networking team to impact networking behavior.
But does that mean we don't want the application guys to interact with the network?
What we really need is a means of expressing application requirements in a language that is not so networking-centric. This is why there has been so much talk about the northbound interface in the SDN world. We need a way of describing what is important about specific conversations in and around the network. But that expression of requirement shouldn't just be a re-imagining of VLANs and ACLs, a re-creation of of policy constructs to be executed even further away from the network.
Instead, the abstraction needs to express application requirements and intent in a language familiar (and relevant) to the application. At first, it might start with bandwidth or latency requirements. An obvious evolution would then include jitter or loss sensitivities. But ultimately we need to get to a place where we can tag applications as HIPPA or PCI compliant. And then the network (or the controller) is responsible for translating this intent into specific device behavior necessary to meet the specification.
One of the subtle points here is that we have a lot of confusion in the industry at large over how to do this. My opinion? We are getting some basic things wrong because we are hung up on words. When we (the industry) talk about applications in a networking context, we usually mean network services (or more precisely, building blocks for network services). Things like firewalls and load balancers are not applications in the broader IT sense. When Plexxi talks about applications, we typically mean actual end-user applications. These are what we need to tie to the network; network services are already inherently tied there. And the abstractions we specify need to keep this in mind.
Now bringing this back to Insieme for my big close. Cisco I think is actually on the right track with their application-centric message. Strategically, this puts them (and us actually) at odds with VMWare, who believes that traffic in the datacenter is random and uniform. There is a subtle but extremely important strategic element that is playing out here. The ultimate question is whether problems will be solved by throwing bandwidth at the problem (VMWare) or intelligence (Cisco). Of course, we all know the real answer to this is going to be a mix of both bandwidth and intelligence. I probably don't need to tell you where Plexxi stands in all of this.