If you’ve tracked both SDN and NFV carefully, as I have, you’ve probably noticed that the value propositions for both have shifted or evolved over time. Service revenue increases are great, but you have to be able to justify them with some hard opportunity numbers. Where are the brass rings with new SDN and NFV services?
One important point to make is that “new services” have to be broken down into the connection services and cloud services that I’ve talked about in prior blogs. The reason this is important is that network operators have a natural place in the connection services market, with infrastructure, skills, brand, and so forth. They’re trying to wrestle a place in the cloud or hosted feature space, but they are not there yet. That’s why operators tend to think of “new” services in terms of legacy stuff that’s tweaked somehow to be presented differently.
We’ve heard about turbo buttons and bandwidth on demand for decades now, and it’s totally true that you could do them with SDN and NFV. You could also have done them without either technology, and still could. The concept of elastic bandwidth has been difficult to promote in the real world, both because buyers don’t see a big value and sellers see a big risk.
Most companies size their VPNs and VLANs and physical-layer trunks based on their typical traffic needs and over-engineer a bit to accommodate peaks. I surveyed users about this practice for years and they were comfortable with the approach. Yes, about two-thirds of buyers said they thought that having some elasticity to better accommodate bursty traffic would be nice, but what was interesting is that they had essentially zero willingness to pay for it. In fact, nearly all the users who wanted elastic bandwidth wanted to reduce current spending by downsizing capacity on the average and boosting it only during peaks. That’s why operators finally realized this was a less-than-zero-sum game for them.
One solution to this problem being proposed today is what might be called “extranets”, meaning network relationships among companies instead of within them. Traffic levels here are more variable and few companies say they support extranet applications with fixed network services. But few companies say they have significant extranet traffic, and most companies who do “extranetting” today say that secure Internet VPNs are the best solution.
OK, what this tells me is that there is little credibility that extensions to connection services based on SDN or NFV could really add much in the way of revenue. You might be able to frame offerings differently if you had already completed an SDN/NFV infrastructure transition, but the benefits would fall short of justifying the change.
Revenue from connection-related features (the vCPE model) is also difficult to justify on a large scale (though I think a business case for vCPE can be made in other ways). The problem is that credible revenue opportunities from vCPE are really limited to current Carrier-Ethernet sites or prospective sites, meaning satellite sites of multi-site businesses. These sites can’t be sold one-off, you have to sell the HQ locations. There, the most credible connection-related VNF-hostable features—security—have long been considered and addressed via CPE. Yes, SMBs don’t fit this model and may be extremely interested in managed services, but with some notable vertical-market exception it has proved difficult to sell to these communities because the average revenue per user is small compared to the cost of sales/marketing.
Before we throw in the towel on new service revenues as an NFV justification, though, we need to examine what could change all this. Not in a heartbeat to be sure, and not without some extensive marketing by vendors, but change it for sure. The best general name we could give the path to new service success is the as-a-service-extension model.
We have static networking today because we visualize the network as being separate from the application, which means it serves the aggregate of applications. This tends to level capacity and connectivity needs and also limits the extent to which a given application can have network services tuned to its needs. We build application-independent, permissive-connectivity, networks then pay incrementally to build application awareness and access control.
The cloud teaches us (or should be teaching us) a lesson here, which is that network services can be specific to an application. If you look at the virtual networking model of giants like Amazon and Google, it’s based on virtual-networking techniques that could easily create a whole vertical stack of virtual networks for a company, linked to workers and partners at any point where you find a suitable human (or machine).
The easiest way to promote this model is with as-a-service in-cloud applications, and so SaaS trends would be a way to make this all happen. In fact, every major network vendor who has an SDN strategy—Alcatel-Lucent, Cisco, Juniper—has the ability to do this now. Since selling traditional boxes and security/application-awareness add-ons is a great business, though, we don’t hear much about this approach.
You could also support this from the inside, from the application side. A virtual router product that can be hosted on a generic server or edge device could build this kind of model without the support of the big vendors. Brocade could do this, for example, and you could create an open-source project to enhance any open switch/router to support virtual networking in this form. Once you have it, you could start dialing down private virtual networks in today’s site-networking form.
Well, maybe. One big barrier to this is regulatory uncertainties with respect to net neutrality interpretations. If we tried to build something like this today, from the application out to the user, we’d almost surely have to adopt an Internet overlay connection model, and that would be easier if we could have SLAs on services. SLAs are at least a close neighbor to fast lanes, and most operators are reluctant to jump into this space lest the services they create end up violating regulatory and public policy goals.
IoT might be another answer to the problem. There is no rational model of IoT other than a big-data-and-analytics model that lives in the cloud, sucks in sensor data from any convenient source over any worthwhile connection technology, and then makes everything available under a policy-metered query umbrella. An operator or even a big vendor could establish a model like this, and since the networking in the model is largely inside the IoT cloud or represents a simple access extension, you could do whatever you wanted with SLAs and network architecture without impacting the current services or running afoul of regulators.
Cloud services are another dodge. Inside a SaaS or perhaps even PaaS envelope, you could create pathways that were similar to those within a mobile network or CDN, both exempt from neutrality regulations. Now all sorts of intra-cloud high-value services could be presented and procured.
The point here is that it’s probable that new service revenues won’t present a widespread benefit for either SDN or NFV justification unless you can do something to increase their scope of impact, which my two examples would do. The question would then be whether that broader scope was seen by both operators and vendors as too much change, too much risk.
We can justify SDN and NFV for some operators with new service revenues today, but only on a limited scale. For the big justification, for the benefits that can build out enough infrastructure to make it easy to add on services and features as the market demands, we’ll need something else. Opex is all that’s left, so we’re back to the same point—you’ll need exceptional opex automation to make either SDN or NFV work.