Public cloud economics aren't adding up for some telcos

Since the olden days of the twentieth century, students and foreign workers have been taking the multi-tenancy model to its apogee, stacking bodies in London apartments so that rent and utility bills, when divided, are lowered to the smallest amount for each person. The same basic principle is applied in the public cloud. Cramming tenants into a data center effectively cuts the infrastructure and energy costs for each customer.

This partly explains why public clouds operated by AWS, Google and Microsoft may seem like attractive destinations for some telco workloads. "The 5G core on Telefónica runs in the Frankfurt region, and that's a public cloud," said Ishwar Parulkar, the chief telecom technologist for AWS, in reference to a tie-up involving his employer and Telefónica Germany. "It's a data center that runs other workloads as well."

The alternative is to keep the 5G core on premises or in a private cloud. The latter might be used by other workloads, but – as the designation implies – it would not be shared with other companies. And that means it would not provide the same economic benefits as the public cloud. Under pressure to slash costs, telcos may view the so-called "hyperscalers" as a means of doing it.

Unfortunately, an operator cannot simply put all its telco workloads in a hyperscaler facility, as it might do with standard IT applications like customer relationship management (CRM) software. Regardless of what government authorities think about such arrangements, networks sprawl across the geographies they serve. Hosting all functions in a single place just isn't possible. Even the core, the domain allowing for the most centralization, is increasingly distributed across multiple facilities at the network "edge."

Public cloud, sort of

These and similar demands outside the telecom sector have necessitated an adaptation of the traditional public cloud approach. To run its entire core and various other functions on AWS, US telco Dish Network is using what the hyperscaler markets as "local zones," smaller facilities dotted around the country. These local zones are still classed as shared infrastructure, but the tenancy numbers are naturally lower. And that means the economic case is not as strong.

"As you move to the edge, you have infrastructure that is smaller and smaller," said Parulkar. "Obviously, it is going to be less shared, or less dense, and some of those benefits start getting a little bit reduced as you go to the edge." In the case of Dish, this is relevant for a critical part of the core known as the user plane function (UPF), a kind of network traffic cop. "That is how they cover different markets in the US," said Parulkar. "They use several local zones for the UPF."

But there is today no such use of AWS local zones for the UPF by Telefónica Germany, he says. And AWS appears to have just one local zone in Germany, in the Hamburg area. According to this page on its website, no others are currently planned. By contrast, the UK's BT, opposed to using the public cloud for telco workloads, was running the UPF across 16 of its facilities last year. Even its control plane functions, easier to centralize, were hosted at eight facilities.

Telefónica's immediate objective is to support only 1 million customers on AWS (it serves between 45 million and 46 million in total), a number dismissed as laughably low by one experienced industry source. But the plan is to move millions off an older core provided by Ericsson.

This, at least, is the assessment of Raghav Sahgal, the president of cloud and network services for Nokia, which provides the core network functions used on AWS. "We took an initial set of customers and as they bring on new customers that platform will continue to scale, so we will only become bigger and bigger," he said. "If you only did this for the minimum set of customers, then why go through the pain?"

Feeling edgy

An alternative to local zones for network functions is AWS Outposts, described by AWS as an "on-premises private cloud." With this, AWS brings an equipment rack into another company's facilities. Outposts is identified as an option in AWS's technical blog about the Telefónica deal. "With Telefónica, we started with the region and the plan is to expand it to use other assets as well, to be Outposts on their premises or local zones," said Parulkar. "We don't have a plan we can announce right now, but that's the idea."

The obvious drawback of Outposts is the lack of sharing. If the hyperscaler data center is a vast urban apartment buzzing with tenants, Outposts is a rural home with a single dweller. Many of the arguments about public cloud economics are invalid. Light Reading's industry source, who shared insights on condition of anonymity, said this partly explains why many telcos would prefer to have their own multi-vendor platform than use a hyperscaler. There is not enough sharing to make the public cloud "cost effective" for core functions, said our source.

But Parulkar insists the benefits of sharing do not entirely disappear at the edge of the network, and he highlights various other attractions of the AWS cloud. "You can failover to the region," he said. "It's still elastic. It still has all the security, reliability and sustainability features that come with the cloud and, most importantly, you can move between all of those in case of failure, so for backup, and whenever you want to split functionality."

Thanks to parent company Amazon's investments in artificial intelligence, silicon and other technologies, AWS also has a formidable range of tools it can incorporate into local zones and Outposts. Technology and infrastructure investments last year across the whole group climbed to an ear-popping $85.6 billion, from $73.2 billion in 2022. "We offer Nvidia GPUs [graphics processing units] alongside our own silicon and x86," said Parulkar on some of the chip options available to customers.

RAN resistance

Nevertheless, if the public cloud – in its strictest sense – presents challenges for core network functions, it is an even harder sell for the radio access network (RAN). Centralization can only go so far in this domain. Indeed, some operators now "virtualizing" the RAN with general-purpose compute technologies are choosing to leave servers at mast sites rather than pooling them in data centers near the edge. Infrastructure sharing might not even be feasible with other functions, let alone with other cloud tenants.

To complicate matters further, ordinary general-purpose silicon cannot meet the performance demands of some RAN functions in advanced 5G networks. In response, vendors are pushing different forms of customization. But the preference of Intel, the world's biggest supplier of general-purpose silicon, is to integrate these customized "accelerators," as they are called, with its central processing units (CPUs). The result is that forthcoming products like Granite Rapids and Diamond Rapids look tailored to the RAN and unsuitable as common, off-the-shelf servers.

In principle, Granite Rapids could be used for other purposes, says Parulkar. "If you look at it from an architectural perspective, there are other applications for that type of silicon, like digital signal processing," he said. Despite this, he doubts it would have any other application in a telco network. "I'm just saying that as a silicon piece, it is capable of doing that. I'm not completely sure what it would do in the RAN space in that actual location in a server that is being used for the RAN."

Intel's dominant role in the market for server CPUs, in general, and virtual RAN, in particular, is another turn-off for many telcos. AWS is one of several companies trying to do something about this with Arm, a UK-based architectural alternative to Intel's x86 technology. Using Arm blueprints, it has already built its own CPU, branded Graviton, to handle some workloads.

But Graviton still has no presence in the RAN sector. "We are still working on it," said Parulkar. "The challenge is porting software to Arm. Today, it is all primarily Intel-based, and there is work to be done, and it is engineering work. It is not rocket science. It is porting it to a different architecture. But it's a stack that's been built and tested and validated on x86, so there is some engineering work." That work is happening in conjunction with independent software vendors such as Ericsson and Nokia, he said.

Stalling

Much of all this explains why public cloud providers have made such limited progress in the telco sector. Like other companies, operators are increasingly persuaded of the case for running standard IT workloads in the public cloud. But when it comes to their telco workloads, they have largely avoided engagement. Dish and Telefónica remain AWS's two notable customers. Microsoft parades similar deals with AT&T and Etisalat. More telcos are developing their own clouds.

Microsoft's recent decision to make substantial cuts at Azure for Operators, its telco-facing unit, provides further evidence of the still-weak telco appetite for deals of this nature. Microsoft is apparently reversing out of applications – the Affirmed and Metaswitch companies it bought in 2020 – but will continue to work on infrastructure. Rumors are, however, that it failed to make Affirmed and Metaswitch run effectively in the public cloud. Either way, this sounds worrying for AT&T and Etisalat.

Parulkar insists there is no read-through for AWS. "I can't speak to Microsoft, or what their strategy and intent was, but we definitely don't see any slowing down and are committed to the telecom industry and we continue to march on all fronts," he said. A widespread industry view is that public cloud providers will continue to make inroads. But right now, that march seems like a very hard slog.