All of the networking vendors want to be included in the software defined networking club. Anything they can do to point out, “We have an SDN strategy! No really, we do,” they’re doing. We that evaluate, recommend, and ultimately purchase networking equipment need to be careful to figure out what a vendor is actually delivering when they claim SDN capability. What a vendor wielding “SDN” on a slide deck wants you to think is that they are delivering some brand new, powerful, flexible, or simpler way to make the packets move around your network. A few solutions actually deliver applications along these lines. Think Embrane (not precisely in the packet pushing business, but I like the way they abstract resources). Think Plexxi’s notion of Affinity Groups.
But most vendors are not delivering integrated SDN solutions, not so far. In fact, if the most notable SDN success story is Google…well, they built it on their own, and still used a lot of legacy protocols to do it. Hmm.
One form of SDN marketing hyperbole is equating an application programming interface with SDN. “We have an API; therefore you’ll have an SDN if you deploy our gear.” Sorry, but an API does not a software defined network make. An API from a networking vendor is merely a tool (albeit a powerful one) that offers you a documented and hopefully predictable way to make something special happen with the packets that scurry around your data center. Assuming the API allows manipulation of forwarding tables, all you’ve really bought is a potentially software defined network. You still need to fulfill your wild-eyed SDN dreams with your own programming skills. “You want an SDN? Fine,” some vendors are saying. “Write the code yourself, and good luck with that.”
So…an API, to me, is decidedly not equal to delivering an SDN. Software *definable* network? Okay, I will go that far with you, dear vendor. You could even say “SDN Ready.” But software *defined*? Well, it just isn’t, is it? Not merely because you’ve got an API available. Am I splitting hairs? I don’t think so. I want a simpler network that integrates with my other IT assets. I don’t want to figure out for myself how that’s going to happen. I still want the network-in-a-box. I still want centralized, orchestrated network provisioning, application-oriented service monitoring, and the ability to write custom forwarding policies based on criteria I define. But mostly, I want that simplification. I want to move away from what I recently heard described by Russ White as “the pile of protocols.” As of yet, I don’t see the vendor offerings heading in this direction. APIs are indeed powerful tools, but they probably make my network more complicated if I have to deal with them myself on a large-scale. Not less. Are APIs necessary? Absolutely – I’ve argued in their favor. I like the API idea. I think APIs are the layer needed to truly abstract the network while allowing existing product lines to continue. But I don’t want to become a programmer to make my own software defined network, anymore than I want to have to create my own word processor to write this post. I want vendors to give me a complete set of applications before they claim they’re selling me an SDN.
Mass market adoption of SDN is far off in the distant future. I think I can still see it on the horizon…maybe. Hard to tell. I think the focus is getting blurrier than it was six months ago.
- Little guys don’t know why they need SDN. And mostly don’t care. “Does it do 10G? Okay, good, because we have a lot of that 10G stuff showing up on the dock.”
- Big guys possibly need it, but for reasons that vary as widely as the environments they represent.
- Standards bodies are scrambling to determine where to put the SDN stake in the ground, while vendors are doing their earnest best to manipulate that process to their advantage.
- OpenFlow is limited in scope, is not an open standard, and is seeing slow vendor uptake as the versioning progresses.
- The message of just what SDN is is becoming diffuse and indistinct. SDN has about as much meaning as “cloud”. Can pros that run cloud networks define “cloud”? Sure they can. But to the marketing organizations of the IT industry, cloud as a term has been beaten into meaningless twaddle attached to everything in the IT space. SDN is rapidly heading in that same direction, especially from vendors who want you to keep buying the same stuff you’ve been buying for years. SDN is a marketing sticker you slap on the front of the same old switch…”NOW WITH SDN FOR MORE FORWARDING GOODNESS IN EVERY LOOKUP!”
Now is a good time to be skeptical. To be cynical. To ask a lot of questions…that is, if SDN actually matters to you in the purchasing process. I have a concern that if SDN continues down the road it’s been on lately, maybe no one’s going to care all that much.
And that would be a shame. We’re right on the edge of something great.