Intel’s “Data-Centric Innovation Day” announcements take specific aim at 5G and NFV, seemingly at a time when operators themselves are doubting whether they really want to deploy their own clouds for hosting features in either area. There is no question that Intel, server vendors, software vendors, and practically everyone else would love to see operators spend on deploying over a hundred thousand data centers. There is increasing question whether operators are willing to do it, and in my last blog I noted two drivers that seem to be influencing operator planning for carrier cloud. One is the lack of understanding of “the cloud” at a technical and cultural level, and the other the issue of “first cost”.
If vendors want carrier cloud to happen, it’s my view that they will need to resolve these issues for their prospective carrier buyers. That’s actually been clear, even to Intel, for quite some time, but what seems to be missing is a strategy to do what they know they need to do. Intel is almost a poster child for this, because they have an unusually complete set of the pieces operators need, and their having missed the boat on execution is particularly unfortunate and perhaps incomprehensible.
Intel and others share a common problem, which is that they want to sell their tools to deploy carrier cloud without selling a business case for carrier cloud. That means that the operators themselves have to first come up with something that actually justifies a carrier cloud build-out and second assemble the pieces from the collection of tools that vendors feel like providing. Given the point that operators don’t understand cloud technology or culture, you can guess how likely that is to succeed.
You need servers and chips and all the things that Intel included in its Innovation Day announcement, but only if you need carrier cloud. Operators believe they will, but clearly don’t have the proof points yet, and part of the reason is that people are selling pieces of the solution. They don’t even realize that there are really six different problems.
If we look at carrier cloud as an opportunity, we see a deployment driven by six distinct market factors, each of which are (today, at least) seen as being independent. In NFV’s vCPE, streaming video and ad personalization, mobile infrastructure and 5G, contextual services, public cloud services to enterprises, and IoT (the six drivers), we have technology initiatives that lack coordination. Even within a given driver, as we can already see with NFV, the lack of a cohesive architecture is making every initiative into an integration project. This is a proof point for the assertion that operators lack cloud technology and culture, and it exacerbates the second issue of first cost.
Suppose we decided to support application development on a broad scale but without any specific operating system or middleware tools. That would mean that each application would end up picking the framework in which it ran, and if we were thinking about operations efficiency and a nice harmonious resource pool, it’s hard to see how we’d get there from that anarchistic starting point. We’ve kind of done that with carrier cloud, starting with NFV. By working hard to preserve the management interfaces to “real” devices through our transformation into the cloud-virtual world, we’ve saved something that wasn’t working particularly by making something vitally important work poorly.
You can see, in a loose and indirect way, how the cloud community has been dealing with this problem. Containers are the natural partner to componentized applications, including hosted service features. Orchestration via Kubernetes has already become the go-to strategy for container orchestration, and foresight on the part of the early architects of Kubernetes created the open interfaces that make Kubernetes suitable to be the core of a growing ecosystem. Something similar is needed with carrier cloud, an ecosystem that would frame how all applications are authored, orchestrated, and managed. Something to standardize the carrier cloud platform so that the things running on it would be more easily integrated and managed. Something above chips and servers and operating systems and even middleware.
I told both Intel and their open-source Wind River group four or five years ago that platform tools were not going to be enough. They needed to pull together what I called “VNFPaaS” for “Virtual Network Function Platform as a Service”, including the management, orchestration, and lifecycle automation pieces. They didn’t, of course, and now they face exactly the same situation they did back then, but with less time to remedy the problems and a sign that the opportunity might be passing away.
The “might be” here relates to the point I made in my earlier blogs on the public cloud and carrier cloud symbiosis. Operators are growing more interested in outsourcing carrier cloud because they can’t build enough of a business case for building it themselves. The question is whether the cloud providers understand what makes carrier cloud different, and so far, I think it’s fair to say they don’t. Can public cloud providers like Amazon frame their own virtual-carrier-cloud vision before vendors like Intel sell a business case and not disconnected tools? That’s the question.
For the cloud providers, the big problem isn’t technical as much as pricing policy. Many carrier cloud applications involve both application-like service-and-management-plane components and components that are part of the service data plane. If cloud providers were to apply traffic charges to the service data plane piece, they’d price themselves out of the market. If they didn’t, they run the risk of increasing their network capacity requirements enormously without adding any revenue to pay for the upgrade.
There could be a technical solution to the pricing problem, though. Almost every service that includes a data-plane carriage requirement could have that requirement satisfied outside the cloud. vCPE isn’t a great cloud application in the first place, but if you wanted to support it you could use uCPE universal premises devices. Mobile evolved packet core (EPC) is currently a tunnel-based application, but the data-plane-tunnel part could be implemented in a white-box SDN device.
A partnership between an agile SDN connection network and a public cloud control and management plane would be a profound shift in thinking, but it would actually be easier in an evolutionary sense. We have network equipment today that lives outside the cloud, in carrier infrastructure. If we could come up with the right management automation abstractions, we could link that external data-plane investment to the cloud, then enhance the linkage with a gradual migration to SDN. SDN, remember, centralizes control plane and distributes the forwarding plane. Doesn’t this sound like our cloud-control-and-SDN-data model?
The tricky truth is that something like this would benefit also Intel in that it would establish a baseline for that VNFPaaS model I mentioned earlier, and at the same time separate the tricky legacy equipment and data plane issues. Why all this “trickiness?” The equipment/data-plane trick is a challenge because of the impact on cloud pricing and network capacity, as I noted above, but why is this a tricky issue because of the benefit to Intel? Because Intel benefits not from the offloading of carrier cloud applications onto the public cloud, but from carriers building the cloud. Thus, the smart position they take to make their own carrier cloud story more appealing may also facilitate having at least the early carrier cloud applications going to the public cloud instead.
At this point, it’s going to take Intel some time to make that carrier cloud business case, if it makes it at all. During that time, it’s likely that the public cloud will steal some of the early demand that might have driven early carrier cloud infrastructure investment. There’s no helping that; Intel and others should have gotten smart sooner. Their best approach now would be to frame the right architecture for both early outsourcing of carrier cloud and for the later clawing back of the opportunity to fuel network operator data center (in particular, edge) buildouts.
“Innovation” implies something radical, and it’s hard to see how a decision to buttress the features of a platform that still can’t make a business case within carrier cloud can qualify. The door is still open for Intel to do more, to build the ecosystem that would create and justify carrier cloud, but time is passing and eventually operators will either offload their cloud mission to public providers, or accept the role of “plumber” in the network of the future.