What kind of carrier cloud we finally get, and when we get it, will depend on what drives its deployment. There are a lot of drivers of carrier cloud, and the network operators probably all emphasize them in different ways. It also turns out that there are options for how carrier cloud services are hosted, but here we see two clear choices. Network operators, it seems, see these two choices differently too, and we are starting to see some signs of how they assign drivers to hosting choices. AT&T is presenting a particularly interesting (if somewhat confusing) example.
Multiplicity is one reason for confusion. AT&T has announced public cloud deals with both IBM and Microsoft, and at the same time is committed to its own “Network Cloud”. The IBM deal focuses on AT&T Business and services to enterprise customers, and the Microsoft deal makes Microsoft the preferred cloud provider for AT&T’s “non-network” applications outside AT&T Business. The whole picture is confusing enough that AT&T did a blog to explain it, which is the first of my three links in this paragraph.
Most early deals between operators and cloud providers have been focused on providing cloud services to customers, meaning that the operators believe they have to take a market position in public cloud services before they have enough customer demand to justify building out to host those services themselves. AT&T is taking things a bit further by moving some of its own stuff to a public cloud partner, but even after its blog to clarify its position, there’s still a question of just what a “non-network” application or workload is.
I think it’s pretty clear that data-plane connection services would be network workloads. It’s not clear whether control-plane features associated with data-plane connection services are also network workloads, but that seems more likely than not. It’s clear that AT&T’s operations support services (OSS/BSS) activity, is not considered a network workload, but network operations and service lifecycle management…who knows? This is more than a semantic game, because if AT&T’s Network Cloud is to fully realize “carrier cloud” potential, it has to address all the demand drivers of carrier cloud, and we have to be able to decide if each driver is driving a “network” or “non-network” workload.
The demand drivers for carrier cloud are NFV/vCPE, personalization of advertising and video, 5G and mobile, network operator cloud services, contextual services, and IoT. You can argue that the first one is at least substantially a data-plane or connection service mission, which makes it a “network workload”. 5G (if you believe in 5G Core) and mobile IMS/EPC would include some data-plane functions, but everything else is really a higher-level (OTT) service opportunity. In the way AT&T sees things, that could mean that some or all of the hosting generated by these non-data-plane drivers could end up outsourced to the public cloud.
I want to emphasize here that I don’t believe most operators are determined to sustain a public cloud platform commitment for any of their “carrier cloud” services; even public cloud services might come in-house if they had the hosting resources in place. The issue I think they all face is that of “first cost”. To make carrier cloud useful, you have to deploy it where the drivers are operating, which could be anywhere. That could mean a massive early build-out with a high cost, and much of it would sit idle while demand built. Given operators’ sad record in marking new things, that demand-building period could last a long time, perhaps long enough to render early infrastructure obsolete. Better to rent than buy, at first, but why fatten the coffers of public cloud providers if you have your own infrastructure? Even given their announcements, AT&T may decide, eventually, to shift some of its public cloud work back to the Network Cloud if they build enough economy of scale.
It’s my view, and I think most operators would agree, that all of the carrier cloud drivers except public cloud services demand the operator implement or acquire cloud-native functionality to support the opportunity. That adds to the problem of first cost I cited earlier; not only do you have to build out data centers, you have to recognize and buy, or build, cloud-native applications/features to support the opportunities, which is another cost and takes a non-zero amount of time. Operators are all over the place relative to when they might have “cloud-native” capability; it might be a month or it might be several years, depending on who you talk to and how much cloud-native capability qualifies to be counted.
A proving ground would be nice, but nobody wants to run a trial on something important and expensive. However, as the AT&T story proves, operators are generating requirements that fall outside my six drivers, in areas like network and service management. These probably would not be large enough to consider a true driver of a carrier cloud (and in my modeling they didn’t qualify, which is why they’re not included), but they could qualify for cloud hosting. If that were done on a public cloud, not only would it bypass the first cost of infrastructure deployment, it might offer operators a way of learning cloud techniques before they dive into cloud-native. Remember, we don’t have at this point a single architecture or toolkit to define cloud-native development or behavior.
I think that the notion of public cloud hosting for non-network services, which in my view could also include control-plane cloud-native elements associated with services, is a potential game-changer. Public cloud providers have good economies of scale and (in combination, in particular) enormous geographical scope. Using them could give an operator like AT&T a position in every market they were interested in serving, without building out a data center there. However, there are some risks that will need to be addressed.
The primary risk is a loss of uniformity in feature/application architecture principles. Every public cloud provider offers low-level hosting (IaaS and in at least some cases, container hosting) based on fairly standard models, but nearly all of them also offer higher-level “web services” that are not at all uniform. An operator planning to host in the public cloud would have to accommodate the differences in the implementations of these higher-level services, or not use them and instead build or select tools to replace them. Every cloud, including something like AT&T’s Network Cloud, is likely to need some web or platform services above simple IaaS or container hosting.
AT&T has expressed a commitment (in Airship, ONAP, and the recent relationship with Dell) to promoting, supporting, and in some cases initiating open-source projects that combine to build a framework for cloud-hosting of their network and network-related functionality. According to AT&T “Dell Technologies is working closely with AT&T to combine our joint telco industry best practices with decades of data center transformation experience to help service providers quickly roll out new breeds of experiential Edge and 5G services.” This seems to suggest that Dell would be involved in the higher-layer carrier cloud demand drivers, and since Dell isn’t a public cloud provider that suggests these drivers would be addressed in AT&T’s Network Cloud.
Or maybe not. Remember, the edge and hosted-element vision of the cloud is really platform-independent, and it will almost surely use open-source tools that could be ported to the public cloud. Airship frames a platform model, currently below the level of full container-and-cloud-native development but likely inclusive of it at some point. In my view, that would mean that AT&T could then apply their “experiential and 5G services” framework, when complete, to an arbitrary public cloud or to their own data centers. For operators who don’t have any commitment to select/build a toolkit to frame their deployment in the cloud, the risk of incompatibility among cloud-provider tools could well be a deal-breaker…if they recognize it in time.
An associated risk is what I’ll call the “ONAP risk”. The operator universe is inhabited primarily by box-thinkers, as the fact that operator-centric standards activities keep falling into the trap of virtualizing boxes not services proves. If you are trying to do the wrong thing, there is no right set of tools to do it with. Almost every operator I interact with in any way says they do not have adequate technology resources for cloud-native projects, period. As long as that’s true, it will be difficult for them to even select packaged solutions offered by others, because they’d have no strong framework within which to assess them and inadequate staff to conduct the review.
A third risk, specifically associated with public cloud services is the portability problem. As I’ve noted above, web services differ among operators. In public cloud applications as they’re currently developing, web services are almost surely a part of the cloud service that an enterprise purchases. Thus, enterprise applications can quickly become non-portable, and that means an operator who serves enterprise cloud via a public cloud provider deal may end up locked in. In addition, it may be difficult to port these users to an operator’s own public cloud infrastructure, unless they duplicate these web services—which they likely can’t do.
While these risks have to be managed, they can be, and I think that the public-cloud partnership concept has very significant benefits. Without it, I’d be concerned that operators might never have the kind of safe on-ramp to their own cloud infrastructure that they need to have to address future service opportunities. The key to addressing the risks is to establish a carrier-cloud platform model, and that should be a goal of operators and of the open-source and standards activities they support.
AT&T is trying hard to establish a leadership position in what they call the “cloud-first” approach, which includes public cloud in a broader mission than just offloading commercial cloud compute hosting to a third party. They seem to be succeeding overall, and so they should be watched carefully as a barometer for where “transformation” at the network operator might take operators overall, and thus the industry.