A popular song of my youth was “How Deep is the Ocean, How High is the Sky?” We may be adding another semantically related question to that list, which is “How High is the Top?” Top-down planning for technology change has always been a favorite notion of mine, and we’re now starting to wonder as an industry just how high that top might be.
This isn’t a topic of idle interest. There’s a fundamental question here, one argued for decades in the tech world. Do new products and services create new social/behavioral patterns and shape demand, or does demand shape the new products and services? If the former is true, then you can start with demand goals and work products/services to align. If the latter is true, then you’ll have to actually analyze demand shifts in order to form product/service policies.
What’s true in networking? From a networking perspective, you can argue either way. The Internet, surely the most revolutionary development of our time, was technology/service-driven. There was no demand for the Internet, even after the Web came along. The service was a fulfillment of an operator goal, which was advancing the consumer from limited-value voice services to something else. Smartphones were a savvy assessment of the way mobile demand would evolve.
How should we assess the “top” of the technologies that we’re looking to as drivers or the future of networking? Overall, I’d say that we’ve stumbled on a course that doesn’t accept either of these two models. Instead, we’re assuming a third—the future is a lower-cost version of the past.
You could argue that this model overlaps both the others. The presumption of SDN and NFV and even the cloud is that they could lower service costs, perhaps dramatically. If that savings were applied to improving return on infrastructure, it could facilitate a build-out of new infrastructure that could then support new models of consumption. If it were applied to lowering prices, it could stimulate new applications directly. Two tops in one.
I think that a cost-reduction transformation overlaps the other approaches to setting the top in impact terms, but it also sets a different top of its own. Here the key is to start by identifying the costs you’re targeting, which should be large in comparison to the investment/impact of your solution. I blogged this week (and earlier too) arguing that opex reduction through software modeling, orchestration, and automation was the logical place to start. One reason is that it could address the immediate problem of infrastructure profit compression, obviously essential if you want to spend more on a service-level transformation.
Getting to that service-level transformation is the next logical step. Operators have also always promoted “service agility” as a goal, which is a nice way of saying that you’d make more money by being able to accelerate the full-service lifecycle—from market plans to deployment of customers. It’s at that point that we have to jump off the cost-reducing top, and land somewhere on one of the other revenue-augmenting paths.
The big problem with new revenue from new services is squaring the new-service notion with the buyers’ own priorities, which (no surprise) are also largely cost-targeted. When I last surveyed enterprises on this point less than a year ago there was no statistically significant interest in any new telecom service that didn’t lower costs. That would mean that all the hype about dialing up bandwidth increases or selling virtual CPE is just that—hype. It also means that future revenue gains will have to come from selling not different forms of the same stuff, but different stuff.
What do buyers want in the way of new services? They respond with a laundry list of stuff that all boils down to two points of focus. Some want new over-the-top services, meaning services modeled on what OTTs would deliver today. Others say that if you want to augment today’s telecom/connection services, do so by composing application features into them instead of network features. In either case, it would be fair to say that they want delivered experiences, not delivered bits.
The compelling thing about this point is that such services would look more like cloud computing than like NFV or SDN. Google, who has been very open about its own network evolution and structure, clearly sees the goal of the network as “feature delivery” and sees the network as a cloud. To me, that raises a very critical point about our pathway to transformation.
There is nothing we can do to add “telecom or VPN service features” to connectivity that will move the ball for network operators overall. Repeat, nothing. There are a lot of things that could add revenue above those basic service features, but they’d look like application elements or OTT services hosted using the cloud. Thus, we should be talking about transformation’s “service agility” dimension only in cloud computing terms. Carrier cloud is the goal, the top. Everything else is either a step toward it or a detour into financial waste.
I said before that you could achieve opex savings galore without changing out a dollar’s worth of infrastructure. You simply model services formally with something like TOSCA, and use the models to integrate operations and management tasks and automate their completion. Think of this as a kind of hybrid of the cloud notion of DevOps and what we could call “ServOps”.
This doesn’t mean we don’t do SDN or NFV. Google, who’s my poster-child for the right approach to “next-gen” services, uses SDN extensively. What it does mean is that both SDN and NFV have to be focused very specifically on creating value for the carrier cloud. We’ve not done enough to either technology to optimize that mission, and in the case of NFV we’ve done a lot that has no relevance to it.
That raises the inevitable “What now, then?” question. Carrier cloud cannot emerge from SDN-driven modernization of facilities, nor can it emerge from NFV’s prevailing model of virtual CPE. We’re not going to churn out current wireless infrastructure; too much displaced cost. That means that it’s probably going to stand or fall based on 5G deployment, and that in turn means we’re not going to get anywhere until slightly beyond 2020.
The timeline gets us back to one of the earlier points; we need to introduce effective and pervasive software automation of the service lifecycle, and do it quickly to sustain operator investment in infrastructure. We also need to stop thinking about SDN and NFV in terms of what they do for services, and focus entirely on what they do for the carrier cloud. That’s not going to be hard for SDN, but for NFV we have a challenge (of ETSI’s own making). We should forget most of what’s been done and focus on the question of how useful carrier-cloud services would modify prevailing cloud tools, tools like OpenStack. That’s right; all of our NFV activity should be looked on as exploiting, modifying, and supporting traditional cloud deployment. Why? Because nothing else will help.
Ironically, this could help vendors. There’s far less pressure to revolutionize connection infrastructure under this model, and far more pressure to revolutionize operations and to prepare a model of cloud computing that’s more agile, better connected, more distributed. Think Google’s model. Which, of course, is what we should have been doing all along.