I contributed 2 pieces to a Network World “digital spotlight” on software defined networking (SDN). SDN’s all the rage with marketing teams & the industry media. I’ve been contracted to write or contribute to a total of 3 large SDN pieces, including this one, over the next few months. And of course at Interop, you couldn’t walk for 5 seconds into the exhibitor hall without tripping over an SDN poster at someone’s booth. Pretty interesting for a technology that few are buying yet.
I believe the industry is doing a good job of getting the terminology of SDN out there, but is not doing so well when it comes to communicating the *why* of SDN, at least not to the enterprise folks I identify with. I, personally, am still seeing a comprehension gap with enterprise networking folks, who aren’t grokking the benefits SDN would bring them, and are therefore merely curious about the technology as opposed to engaged in it. I think it’s going to be that way for a while, for one simple reason: enterprise people need working apps more than toolkits. So far, most (not all, but most) of the working SDN apps have been aimed at IaaS and cloud provider folks, at least from what I’ve seen. Think NEC ProgrammableFlow, Anuta and Nuage. Less prevalent have been apps like Plexxi’s affinity networking or HP’s Sentinel security app that provides a service enterprise folks can get a hold of and identify an immediate benefit from.
A lot of the rest of the SDN tech have been toolkits. Hey, become a programmer and do whatever you want with the network, aka here’s enough rope to hang yourself. Think Cisco onePK and a zillion other APIs. Necessary and useful, these APIs, but I’m not sure the enterprise folks are going to grab them and do all that much. Enterprises will need to shop at the SDN app store. I don’t think they want to write the apps.
That said, I think the market is slowly changing & maturing. One of the most encouraging things I see in SDN are the partnerships formed between controller providers (Big Switch, for example) and network device providers (F5, for example). No matter your use-case for a given network device, if you can automate the provisioning of that device in a vendor agnostic way (big idea there, the vendor agnosticism) via a middleware SDN controller driven by a business policy, then you can build and operate an entire network infrastructure on that foundation.
Going this direction is a sea change, though. SDN is a whole new way of going about networking, which spark a lot of questions for a millions-strong global IT practitioner community that’s been used to building their enterprise networks in a particular way for the last 20 years or so.
- Okay, so this controller is automating provisioning & building forwarding paths for me. But what about reporting & monitoring?
- This controller abstracted all the hardware I was used to logging into, so how do I troubleshoot problems?
- So, do I still need spanning tree, OSPF, MPLS and all of that?
- What’s to prevent my junior engineer from doing something stupid? Or my senior one, for that matter?
- Isn’t the controller a SPOF and/or target for a DoS attack?
- Doesn’t the promise of vendor agnosticism imply SDN standards are in place? Because I know there aren’t any, and so SDN looks like vendor lock-in to me right now.
- Do I have to become a programmer or master a scripting language?
- What does SDN give me that I didn’t already have before?
Answering these questions, all of which certainly have answers from what I’ve seen, are key ideas for the SDN marketers to go after. Yes, SDN solves certain operational problems, and problem/solution is a classic marketing strategy. But the network nerds need assurances that buying into this SDN solution to problems they can mostly cope with isn’t going to cause them yet other problems. Crafting a truthful message addressing the natural questions will help eminently practical enterprise customers – in aggregate the largest networking marketplace – get over their SDN anxiety and start seriously evaluating how their next generation network is going to function.