The closing panel of the ONS raised what I think was the most relevant question of all for SDN—how can its value be promoted? It’s a critical question for any technology revolution to answer because without the right answer to it, no revolution will really ever occur. But while the question of value is the right one, the answers can easily head SDN in the wrong direction.
I thought that the most interesting factor in the panel comments was their “we have to make them realize” tone. The real point, perhaps, should have been “we have to give them something to realize.” If you dig into the results of my last three surveys of enterprises, you see some interesting points.
Point one: SDN literacy among enterprises is still a full third below the levels needed to sustain a normal market. This point could justify a level of realization-building of the sort the panel suggests, but according to my surveys the biggest problem with SDN is the fuzziness. One respondent said “It would be easier to say what isn’t SDN than to say what it is.” There are probably four or five purported SDN models out there, and what’s interesting is that most people who are really literate about SDN would recognize that there are perhaps two or three at the most.
Buyers need to be able to understand the features of something, so that they can align those features with benefits to make a business case. What the features of something like SDN would be, if you presume four or five distinct versions of it, would be understandably difficult to establish. Some people call hosted routers “SDN”. Some say that SDN is a software overlay, a new tunnel-based network on top of current networking. Some say it’s OpenFlow and some say it’s APIs. Where does this leave the enterprise buyer trying to dig up a benefit to justify an SDN project?
Point two: The most popular form of “SDN mission” actually being deployed isn’t particularly applicable to the enterprise. At the core of 85% of the SDN projects we had reported in the last three surveys, we found that multi-tenant segmentation was the driving mission. OK, how many multi-tenant enterprises do you know of? Can we reasonably expect enterprises to understand the benefits of SDN in their data centers when what we’re citing as the SDN mission is separating multiple tenants? Does the enterprise host other businesses, or perhaps hackers, and give each their own virtual network?
In theory, enterprises could use virtual networks to separate applications. In theory, you could construct a whole new model of security and access control, a completely fresh vision of application delivery control and acceleration, and even a new model of connectivity using the same SDN technology that can support multi-tenant. We don’t do that. If we had an ONS event to showcase multi-tenancy to enterprises, how many would find it relevant. If we had one to showcase application control through segmentation, how many wouldn’t find it relevant. But the reason we don’t have the event isn’t because of a failure in agenda management, it’s because we don’t have a product.
Point three: The most popular form of SDN doesn’t save any money. If we create virtual networks by doing tunnel-based overlays on top of existing routers and switches, we’ve still got the same hardware and we’ve actually added a layer of stuff to manage. People talk all the time about how SDN is a threat to Cisco, but it’s a threat only if SDN displaces existing switches and routers. Show me a white-box switch vendor who’s setting the world on fire. The fact is that what’s true for NFV according to operators is also likely true for SDN; you can save the same amount of money just by beating up a vendor on price.
The model of “SDN” that would probably impact capital costs most is the hosted-router model that I’d argue isn’t SDN except in the mind of the media (and the vendors who push it). Can you save money hosting router software? The network operators think that there’s only limited benefit there, in no small part because the big issue with cost is complexity and operationalization, which this form of SDN will surely not reduce and might actually increase.
Point four: We have trivialized SDN into being trivial. In an effort to make SDN news, to get URL clicks for publications and PR mentions for vendors, we’ve left every complicated issue out of our processes. We don’t write or talk about them, or even develop them. No application segmentation. No next-gen operations and automation. No new network services—we just use SDN to produce the same Level 2/3 services we had before it ever came along.
If we can totally control network forwarding we can totally re-imagine how a service would work. Where’s the imagination? Wouldn’t a new combined L2/L3 service with secure, controllable, properties make sense? With total control over packet forwarding we could surely build one, but where is it or even discussions about the possibility? Nowhere, because it’s easier to shill nonsense than to do something substantive.
So I have a message for ONS. If you want SDN to be real, make it really useful. I think it can be. I can see a half-dozen truly relevant things that SDN could do. I can see a dozen benefits SDN would be able to harness. I can see future service models possible with SDN and impossible or impractical without it. Why not try to talk about actual utility, gang? Instead of making SDN success look like it’s dependent on making that used-car buyer understand why this car is best for them when it probably isn’t, make it best for them. Or have we laid off all the product types and hired mediameisters?
