Even based on early numbers from network vendors, it’s clear that network operators are at least slow-rolling, and likely constraining, capital spending. While it’s easy to blame the pandemic, network usage for most consumers and businesses has increased since the lockdowns began. It’s obvious that operators don’t make incremental money on traffic absent usage pricing, so the pandemic is proving that revenue per bit for traditional services is much more likely to continue to fall than to suddenly start rising.
In my recent blog, I noted that TV as a revenue kicker was losing its luster. VoIP services from operators are also in decline, which means that there are no “traditional” add-on services to broadband access that can be expected to fill the developing gap in revenue versus needs. My expectation, and the expectations of most of the thoughtful carrier planners I hear from, has been that higher-level services would do the filling. That means “carrier cloud” in some form.
There are two basic models of carrier cloud emerging. The “classic” model is that the operators deploy their own cloud computing data centers, justified by a mix of virtual-function applications relating to current services and an increasing contribution of the new higher-level services that could provide the revenue kicker needed. The “outsource” model is that the operators buy cloud computing services from public cloud providers, fulfilling their virtual-function and higher-level needs. I’ve been getting some insight from carrier planners on the question of which option seems best, and why.
A year ago, every single carrier planner I talked with said they would be deploying their own carrier cloud. Today, the number is hovering around half, and that’s an astonishing shift in so short a period of time, especially given the traditional inertia of the network operators. What’s responsible for this shift, according to those key planners?
The biggest factor, according to the planners, is increased sensitivity of executives in general, and CFOs in particular, to high first costs and stranded asset risks. Every planner who said that classic carrier cloud was less likely to be deployed now versus a year ago, or who said that it would be deployed more slowly or on a smaller scale, cited this factor. The causes of the increased sensitivity were much more varied.
Tied for the top reason was pressure from the financial markets and lack of confidence in a stable architecture for classic carrier cloud. Like the vendors who support them, network operators have to report their financials to shareholders and regulators, and a decline in profit equates to a risk of a decline in share price. Embarking on a new hosting model for service features generates a risk of stranding assets, and even suggesting that future path would create a demand for an explanation of how it would work, which operators are unsure they could provide.
It’s my own view that the architecture problem is the fundamental one. The problems with revenue per bit were very clear to operators as far back as 2012, and for some even in 2010. The idea that some form of open-model technology to replace vendor-proprietary (and high-priced) network equipment could improve profits was discussed widely in 2012. Then, and now, operators were unsure about just what their open-model network would look like.
Open devices, a combination of white-box hardware and open-source software, is currently the most appealing choice for operators because it doesn’t stretch their current understanding of network-building or operations practices. An open device could be switched in 1:1 with a proprietary device, with a promise of minimal (if any) changes overall. Cloud-hosting functions instead was recognized as having a greater impact on capex because of the obvious economy-of-scale benefits at the hardware level, but operators are not currently comfortable that they understand how to accomplish cloud-hosting of virtual features/functions. They’re also not comfortable that they understand the operations complexity and cost implications.
According to the planners, this has caused most operators to shift their strategy from hosting of virtual features in a cloud to open devices. The latter approach, obviously, doesn’t justify carrier cloud data centers, and given that rather enormous change in thinking, it reveals the financial risk of jumping into the classic model of carrier cloud.
The obvious question at this point is what the lack of classic carrier cloud means to those higher-level service opportunities, the ones that could provide the revenue kicker and enhance profit per bit. The planners are mixed on this point too, and again almost evenly divided.
The two explanations are higher-layer opportunities for carrier cloud, when they emerge, will justify the carrier cloud buildout, without any seeding of data centers generated by hosting virtual features, or that outsourcing cloud requirements to public cloud will fulfill the needs in higher-layer services. In other words, the planners say they’re split between “build” and “buy”, but that may not be exactly the case.
Most of the planners say that they think they will “eventually” start to build out carrier cloud on their own, in the classic model. Thus, the question is whether they start to do that as soon as they have a credible architecture and a credible target business case, or whether they start building the business case by hosting on public cloud, and then move to self-hosting as their confidence in both technology and business case grows.
My sense is that the common thread in this dualism is a lack of architecture comfort. Those who think they will start their buildout when they’re confident obviously have that issue in mind. But even those who think they’ll start in the public cloud and move over have architecture concerns, as I’ve noted. And there’s a special concern that the latter group should have, but apparently don’t recognize yet.
Applications aren’t automatically compatible with any given public cloud; you have to write them for the target. In most cases, the more you use specialized cloud features to enhance your application, the less portable it becomes. Could operators build a higher-level service on a public cloud and then simply move it? It would depend on how it was built.
The few operator planners who have apparently considered this issue are split into three groups (but this is a small number, so there’s not a lot of statistical confidence in the breakout). One group thinks they can define a cloud model and tools and simply host on IaaS, which would facilitate their movement to their own cloud by eliminating any special cloud-specific features. One group thinks that they’ll simply adapt the applications when they decide to move them, and a third group thinks they’ll simply keep higher-level services on a public cloud provider, using classic-modeled carrier cloud only for virtual feature hosting in things like 5G.
The weak point for all of them is the architecture issue. Early operator attempts to define function hosting deviated from public cloud and cloud software conventions, defining their own elements instead of reusing either the architecture or the tools. They also left many issues uncovered, including the optimum model for deploying software-based, versus appliance-based, network functionality. The key planners know this, but they’re not aware of initiatives that are on track to address the problem. Thus, they don’t know how carrier cloud applications will be built, and without knowing that, where they can be run.
It’s very possible that this will have a major impact, to the point of making the build/buy decision for operators once and for all. Operators admit to be looking more at SaaS contributions from public cloud providers as solutions to their higher-level services, and even for function hosting. That approach would bypass the architecture question by letting public cloud providers build the applications and simply expose the interfaces for consumption. And this is pretty much what the “web services” offerings of the public cloud providers already do, so we might wonder whether Amazon, Microsoft, and Google will be offering carrier cloud service-as-a-service in the future.