If you want to make money selling carrier cloud infrastructure, you’re running out of time. There are three Light Reading stories to buttress this view. First, Verizon and AT&T are both working through plans to build private wireless networks for enterprises. Second, IBM has joined other public cloud providers in going after network operator carrier cloud opportunities, and finally, Microsoft and Verizon are partnering for mobile edge computing services (MEC).
All of this is incredibly important, not only to cloud providers and network operators, but also to the vendors who had hoped to reap a piece of the one hundred thousand incremental data centers that carrier cloud could generate by 2030. These signs, combined with others that I’ve covered in prior blogs, suggest that network operators are changing their thinking, moving to a “cloud-as-a-service” rather than building their own clouds. Why? Because nobody has shown them how, or why, they could do that.
All cloud applications pose two questions to buyers. The first is the nature of the application itself, its functionality and the properties of its implementation that relate to its usability, scalability, and performance. The second is the resources required to run the application, meaning the hardware, operating system, middleware, management and orchestration tools, etc. If you want to do something “in the cloud” you need to answer these two questions with respect to your candidate approaches.
Problem number one for operators is that they often know little or nothing about the application side of their cloud plans. Sure, they’ve heard that their stuff should be “virtualized” and “disaggregated” and “cloud-native”, but what the heck does all that mean? What applications are out there that have these properties? The operators may understand things like “SDN” or “NFV”, but they don’t understand how to convert these things, which are really deployment and management architectures and not applications, to the applications themselves. Without actual applications in mind, it’s hard for them to answer the second question, which is what is needed to run those applications.
I think a big part of the operators’ recent infatuation with public cloud providers as a source of 5G hosting can be traced to this. Many of these providers are offering not just a platform but a telco cloud application (5G), and so they’re a one-stop shop. There’s no concern about the functionality or the compatibility of the application to the platform—it’s all integrated, from a single source, and one big enough to sue if they misrepresent things.
For the classic potential beneficiaries of carrier cloud, or the hypothetical beneficiaries thereof, these problems are big stuff. If operators can’t build carrier cloud applications and infrastructure, the platform vendors lose revenues on a hundred thousand data centers. Even chip vendors cringe at the thought of that kind of loss.
This is the context of the Samsung/VMware announcement, following a similar one with Samsung and Red Hat, is highly significant. Absent applications, platforms for 5G are an intellectual exercise, which means that the platform vendors are in the drivers’ seat. That may also explain Ericsson’s somewhat-late-and-somewhat-uneasy commitment to Open RAN with its “Cloud RAN” platform. The lack of applications for carrier cloud puts mobile network vendors in an awkward position. On the one hand, they stand to gain from selling their original proprietary solutions. That’s particularly true with the pressure on operators to keep price-leader Huawei out of the market. On the other hand, of operators want an open-model mobile network, the proprietary vendors are setting up non-network competitors to provide it, raising more competition at likely lower prices yet.
Platform vendors would, of course, rather see a bunch of application providers vying for their platform business, and operators pushing for the whole package, than a small number of application vendors all dealing on the same platforms. That’s particularly true when 5G is the only target at this point, and it’s hardly the only driver of carrier cloud. In fact, 5G is likely to reach its peak influence on carrier cloud decisions by the end of 2021, and (even then) account for about a fifth of the opportunity. But 5G is important because it’s the “two-punch” of a “one-two-punch” driver set, the first of which has already failed to produce.
My original carrier cloud market model suggested that to get full data center realization from the opportunity, operators would need to prime the pump, first with NFV and then with 5G. NFV hasn’t delivered any significant number of data centers, so 5G is the only “familiar” application operators could aim at with carrier cloud deployments. All the rest of the carrier cloud drivers are things like advertising, streaming video services, and personalization/contextualization, things that the operators aren’t nearly as comfortable with. If 5G doesn’t deliver some data center deployments, then these hazy and somewhat frightening drivers are going to have to pull the cart all by themselves. That would make carrier cloud far less likely.
It would also mean that the network operators would be totally dependent on a combination of cost-reducing measures and the revenue for NaaS-type services to erase their profit-per-bit problem. Neither of these approaches is ideal. Cost reduction obviously vanishes to a point; you can only reduce cost so much. NaaS-type revenues have a significant upside, but they also have a lower ROI than retail services would have. Augmented reality and “contextual services” that build on what a user might want to know about their surroundings, based on where they happened to be, have a retail opportunity and also a NaaS opportunity. Operators might find the latter more comfortable, but the former would be more profitable.
Would the profit difference between NaaS and retail OTT-type services be enough to make the difference between profitable operators and operators scraping by? It’s impossible to answer that with any confidence at this point because we don’t know how much of the retail service could be subducted into NaaS features. We also don’t know the cost of deploying NaaS, in no small part because there are multiple ways of approaching it.
NaaS is really built around what some (including the ONF) have called “programmable networks”. If a network’s service features can be composed, then services can be based on this composition process rather than extracted from a common set of device behaviors, as they are now. To make NaaS truly valuable, though, there has to be a way of absorbing new features into the network, features that today lie outside traditional connectivity features but which are mandatory for the network connectivity process to work. Things like DNS/DHCP, CDN redirection, and the control-to-user-plane interfaces of 4G and 5G fit into this.
So could the AR and contextual services I mentioned above. As I’ve said in past blogs, it’s totally unrealistic to assume that somebody is going to deploy a bunch of IoT sensors that could be exploited by anyone. They would want to deploy services based on their own IoT sensors, and thus earn a respectable return on investment. To do that, there would have to be a way of building those services, and the thing you built them on would have to be deployed. That’s why the early applications like NFV or 5G are important to carrier cloud; they put the infrastructure into place to host additional “service middleware” features.
NaaS is important in part because it frames a plausible if not compelling revenue model that’s based on direct evolution from operator connection services of the past and present. The other reason it’s important is because “network” in any form is, to the network consumer, whatever isn’t on my desk, in my hand, or on my wall in my TV mount. Whatever services we get remotely can be considered network services, and so the operator could offer them without a culture-wrenching shift.
It’s also a way to transform to a wholesale model, if that’s the goal. Operators’ resistance to higher-level services seems to be related as much to discomfort with the retail sales-marketing model for those services as to the creation of the services themselves. NaaS could provide operators with the appropriate experience.
If, that is, vendors provide them with the tools and guidance. Operators in general seem to believe that they’re bombarded by two opposing forces, the network vendors who want them to stay the course and suck up the declines in profit per bit so they can keep buying gear, and the transformation players who want them to quit the connection business and compete in the OTT space. They’re not excited about either option, for obvious reasons. Is there a solution that they can adopt? If there is, then the cloud infrastructure vendors, the IBMs and Dells and HPEs and Red Hats and VMwares, will probably have to step up and make that solution clear and credible. Otherwise those hundred thousand data centers are lost.