I’ve been on a couple trips recently that featured, at some point or the other, the classical multi-armed signpost telling me how far I was from New York, Beijing, Rio, or whatever. And, while there’s never been a road junction at one of these signs that could take me to all the destinations, you can surely get there from here. That the converse is true isn’t necessarily obvious, but you can get to any given place from a lot of starting points. That’s one reason our current network-evolutionary trends are sometimes confusing. What we need to do is travel the road less taken, I think.
What operators want in networking is what every business wants, higher revenues and profits. The challenges they’ve faced in that regard is that communications services aren’t infinitely expanding or consumable. People have historically spend a fairly constant piece of their disposable income on communications, and businesses have done likewise. That means that average revenue per user (ARPU) tends to flatten over time, making the industry dependent on subscriber growth for revenue gains.
On the profit side, the challenge we’ve faced for literally decades is that service prices have been in decline but costs have not declined along the same curve. Stu Elby and other operator executives have been showing the charts that illustrate the future cost/price collision, the point where infrastructure isn’t profitable.
So what operators want is to find other stuff to sell, and other ways of producing that stuff that offers lower cost points. Simple, right?
SDN and NFV are technology-shift solutions that are arguably aimed primarily at the cost side but that could also offer new service benefits. There are some indications that you can raise network utilization with SDN or improve the economics of high-touch features with NFV, but the biggest benefit of both would be to shed proprietary fetters and empower commodity devices. This notion got, and still gets, a lot of media attention even though operators themselves are saying that they could likely get the same cost reductions by “beating up Huawei on price”.
Another strategy that has a lot of merit from the operator perspective is a shift away from multi-layered hierarchical networks to something very simple. An extreme example is an optical network with a ring of electrical on-ramps around the edge. You take advantage of the declining price of an optical bit to create a network that doesn’t “aggregate traffic” to save money because aggregation likely costs more in device and operations costs than it saves. This is of particular interest to operators in the metro networks, and I’ve been blogging all this year that metro is where the profitable traffic is (and will be) found. This approach is sometimes called “flattening” the network because it tends to eliminate some OSI layers, but the real goal is simplification, not flattening layers. Less to manage means less management cost.
It’s this point that creates the traffic jam on our road to a profitable destination. SDN and NFV both have a tendency to increase the number of elements in a network. Pre- and post-SDN, do you have fewer boxes or just different ones? The latter, I think. In the case of NFV, do I end up taking a fifty-dollar box and converting it into a couple of hosted functions that require deployment of cloud stacks, hypervisors, servers, data-path acceleration, vSwitches, and so forth? If so, how much is it going to cost to operationalize all of this new stuff?
What SDN and NFV should have taught us is that we’re at a fork in our converging set of roads—a place where we have to decide whether we’re going to remake operationalization while we remake networking, or try to do network management and service management largely as we’ve done in the past. The path of change is often called simply service automation, but that covers a lot of diverse ground. How do you automate a service? You make the service lifecycle processes event-driven and capable of acting based on complex policies rather than based on human judgment. You reduce or eliminate autonomous behaviors that are non-deterministic, like the way router networks adapt to failures. And you do this not only for the new SDN-ish or NFV-ish elements of networks but for the legacy stuff. That’s not going away completely, no matter what some may think, and particularly not in the near term.
But that’s only one of my forks; what’s the other? It’s aggressive device commoditization. You can’t build unprofitable networks, so you’ll skin the needed margins from something. If it’s not opex it’s capex. You start by favoring price-leader vendors (does Huawei come to mind here?) and you then drive down cost further by offloading features and further dumbing down the devices (SDN and NFV). This path flattens metro networks, emphasizes capacity generation over capacity management, and generally picks the pockets of the network vendors.
But this is the path vendors are taking. I’ve been involved in five projects aimed at service automation in the last eight years, and none of them have received any helpful vendor support. Vendors have blown kisses at operationalization by using acronyms like “TCO” that cover vague assertions that their gear is somewhat lower-cost to operate. The problem is that “operations’ means everything from creating a service from piece-parts in a lab, through rolling it out and selling it, to managing its availability and performance during its billable life. The network vendors have declared most of this out of bounds for them, so they’ve not fixed operationalization and given operators no choice but to seek cheaper devices as their path to their profit goals. The OSS/BSS vendors have declared all the low-level network stuff out-of-scope too, and nothing is bringing the two groups together in a useful way. Why, otherwise, would it take two to eight weeks to sell a VPN service?
We have the solution to network profit and vendor profit staring us in the face, and it’s the same solution for both. We need to rethink the notion of “services” and the notion of “infrastructure” to match a cloud model. That has to include on the creation of an agile platform for hosting features and a cost-effective platform for pushing bits around, but it has to focus on an architecture that can optimize everything in the virtual-resource and virtual-service worlds at the same time for diverse sets of missions and trade-offs. Who makes this? Nobody, today. Somebody, soon, I think, and that’s the company I’m going to watch.