In preparation for the Open Networking Summit (ONS) in a few weeks, ESG networking guru Bob Laliberte and I have been talking to networking vendors, end users, VCs, even actual OpenFlow shops. Here's what I'm thinking at this point.
1. SDN is inevitable. I don't think you'd get much on an argument here. In fact, I'd go as far as to say that this is not new news. Arista articulated an SDN vision to me 2 or 3 years ago at Interop only we didn't call it SDN then. Same thing with Juniper when QFabricwas called "project Stratus" and I had to go to Juniper customers to get details because Juniper wouldn't sing. And whatever Cisco Jawbreaker/Insieme is, I guarantee it is Cisco's SDN spin. Think of SDN as a dividing line between business/application/cloud orchestration on one side and network technology gorp on the other.
2. OpenFlow is raw but real. Think rev 1.0 here with new products, immature standards, limited functionality, etc. That said, those organizations working with OpenFlow are doing really cool things. Yes, it takes custom coding, but you can roll your own load balancers, traffic engineering, overlay management networks (a la Gigamon), routers, etc. No wonder why carriers and cloud providers with lots of programmers and custom infrastructure needs are all over this. I'm also bullish on OpenFlow maturity through the academic and open source communities.
3. Enterprises are still in the dark. Networking professionals at enterprise organizations have been barraged by new standards and innovations for the past few years. Things like FCoE, TRILL, DCB, SPB, VEPA, VXLAN, yada, yada, yada. Now the industry is throwing SDN and OpenFlow at them and they just aren't paying attention. Unlike carriers and Universities, most enterprises don't want to custom build a "poor man's" F5 BigIP, they want to buy good commercial products that work better than what they have. Arista did exactly this in the HPC market. Brocade, IBM, and HP will work this same game plan in the enterprise.
SDN will succeed on the back of existing networking vendors one way or another. OpenFlow on the other hand, can only succeed if the standard evolves, developers produce high-quality software to add functionality to OF controllers, and vendors embrace but don't extend OpenFlow standards. This chapter is yet to be written.