One of the imponderables about the future of networking is how it’s going to be paid for. Nobody is going to invest in a network without ample return, which in financial terms means an ROI that’s at least equal to the investor’s current internal rate of return. There’s a lot of pressure to “boost benefits” on a project, but that’s hard when you aren’t really sure how those benefits are derived in the first place.
If you look at the “cost” of a network today, you find that on the average about half of that cost represents capital spending and half represents operations expenses (capex and opex). This ratio varies depending on geography because areas with higher labor costs or difficulties retaining skilled personnel will tip more into the opex direction, of course. The point is that if you look at network cost alone, you have a rough capex/opex balance.
When something like SDN comes along, there’s a group that will tout the “savings”, but the fact is that on a large scale we have little data on which to base any presumption of savings. Buyers in our fall survey (both businesses and service providers) told us that they were not aware of any mature SDN solution by a 3:1 margin. Among enterprises, only about 18% could draw an SDN configuration with the elements labeled and half of those could put the names of products/vendors in the boxes. Slightly less than 8% had done any capital comparison of costs, and of that group less than half reported any actual savings could accrue. I think it’s pretty clear at this point that capital cost benefits for SDN are still speculative.
Where SDN has shown benefits is in cloud data center networking, or actually any application where a large number of servers and a lot of WAN connectivity have to mesh. Much of the capex savings here comes from better utilization and resiliency. Enterprises think that they would see similar savings at the WAN level where they actually build their own WAN connections, but the trend in the enterprise is toward consumption of architected VPN services for the WAN, so SDN doesn’t impact their plans directly.
IMHO, you’ll rarely create an SDN justification based on capital cost, whether you’re a carrier or an enterprise. That makes opex reduction the cost-savings-benefit target, and unfortunately SDN opex is totally mythical according to buyers. The percentage of enterprises who could delineate where SDN could save operations costs is down in the statistical noise level, and for the service providers it’s only about 21% who recognize categories. Only 7% of operators thought they could realize the savings, and that low level of realization is due to the fact that they can’t readily assimilate SDN operations into network operations on a larger scale.
This is the very problem that plagues NFV, but with NFV the operators have a better handle on the market dynamic. A large majority of operators believe that traditional network equipment from the major vendors (excluding Huawei) is over-priced, and that their best strategy for reducing capex is simply to put price pressure on vendors. In part, this is because the NFV value proposition works best for middle-box elements and not the devices that actually handle the bit-pushing. However, operators think that as price pressure on connection/transport equipment increases, vendors will jack up the prices and margins on their middlebox products. That’s a concern for operators because the operators see higher-layer services (often created by appliances or middle-box gadgets) as their own profit salvation down the line. NFV is as much a preemptive strike as a current remedy, capex-wise.
But operators know that you have to look hard at opex even for things that are supposed to be justified by capex. They also know, better than enterprises, that network operations is complicated by the existence of multiple models of management, multiple technology choices per model, and a generally service-specific capital program that often creates a lot more disorder in the management layer to save a few bucks on capital costs.
One operator I talked with recently summed it up nicely, I think. “We have traditionally designed networks to be cheap to buy, and now we have to learn to design them to be cheap to run.” The notion that TCO is moving toward opex dominance is recognized by buyers and sellers, everyone tells me, but the sellers still think that’s an excuse to spend more on gear even when compensatory savings in operations costs can’t be proven. And operators tell me that they think every single vendor TCO story is crap…no exceptions. Frankly, they’re right.
What SDN and NFV need, both in my view and in the view of the “literati” who really get this stuff in the buyer space, is a real architecture that covers the entire network geography and that extends upward through all the service elements—including hosts and caches and software features—to the management layer. Everyone agrees that management automation is the only path to optimum opex, but you can’t automate a process you can’t describe at the software level, and we still don’t have a description of what an SDN or NFV service looks like, or how to specify the functional and performance objectives of the pieces.
There’s some hope here, I think. Network operators who know the network is their stock in trade and not just a pencil that gets pushed around in the course of their real business, are now looking for answers and not platitudes. In the NFV activity I can see real maturity of thought on the management side, and the TMF is collecting all the NFV-related activities into a set of sessions in their Team Action Week to focus better on how evolved network models interact with management concepts. Hope is good, but it’s also still true that a responsible business case for either SDN or NFV would be difficult to make today without some extensive pilot testing, and that may mean that little happens with live deployment of either until 2015.