The Telco Cloud Manifesto 2.0

Nearly two years on from our first Telco Cloud Manifesto published in March 2021, we are even more convinced that going through the pain of learning how to orchestrate and manage network workloads in a cloud-native environment is essential for telcos to successfully create new business models, such as Network-as-a-Service in support of edge compute applications.

Since the first Manifesto, hyperscalers have emerged as powerful partners and enablers for telcos’ technology transformation. But telcos that simply outsource to hyperscalers the delivery and management of their telco cloud, and of the multi-vendor, virtualised network functions that run on it, will never realise the true potential of telco cloudification. By contrast, evolving and maintaining an ability to orchestrate and manage multi-vendor, virtualised network functions end-to-end across distributed, multi-domain and multi-vendor infrastructure represents a vital control point that telcos should not surrender to the hyperscalers and vendors. Doing so could relegate telcos to a role as mere physical connectivity and infrastructure providers helping to deliver services developed, marketed and monetised by others.

In short, operators must take on the ‘workload’ of transforming into and acting as cloud-centric organisations before they shift their ‘workloads’ to the hyperscale cloud. In this updated Manifesto, we outline why, and what telcos at different stages of maturity should prioritise.

Two developments have taken place since the publication of our first manifesto that have changed the terms on which telcos are addressing network cloudification:

  • Hyperscale cloud providers have increasingly developed capabilities and commercial offers in the area of telco cloud. To telcos uncertain about the strategy and financial implications of the next phase of their investments, the hyperscalers appear to offer a shortcut to telco cloud: the possibility of avoiding doing all the hard yards of developing the private telco cloud, and of evolving the internal skills and processes for deploying and managing multi-vendor VNFs / CNFs over it. Instead, the hyperscalers offer the prospect of getting telco cloud and VNFs / CNFs on an ‘as-a-Service’ basis – fundamentally like any other cloud service.
  • In April 2021, DISH announced it would build its greenfield 5G network with AWS providing much of the virtual infrastructure layer and all of the physical cloud infrastructure. In June 2021, AT&T sold its private telco cloud platform to Microsoft Azure. In both instances, the telcos involved are now deploying mobile core network functions and, in DISH’s case, all of the software-based functions of its on a hyperscale cloud. These events appear superficially to set an example validating the idea of outsourcing telco cloud to the hyperscalers. After all, AT&T had previously been a champion of the DIY approach to telco cloud but now looked as though it had thrown in the towel and gone all in with outsourcing its cloud from Azure.

Two main questions arise from these developments, which we address in detail in this second Manifesto:

  • Should telcos embarked or embarking on a Pathway 2 strategy outsource their telco cloud infrastructure and procure their critical network functions – in whole or in part – from one or more hyperscalers, on an as-a-Service basis?
  • What is the broader significance of AT&T’s and DISH’s moves? Does it represent the logical culmination of telco cloudification and, if so, what are the technological and business-model characteristics of the ‘infrastructure-independent, cloud-native telco’, as we define this new Pathway 4? Finally, is this a model that all Pathway 3 players – and even all telcos per se – should ultimately seek to emulate?

In this second Manifesto, we also propose an updated version of our pathways describing telco network cloudification strategies for different sizes and types of telco to implement telco cloud. We now have four pathways (we had three in the original Manifesto), as illustrated in the figure below.

The four telco cloud deployment pathways in STL’s Telco Cloud Manifesto 2.0

Source: STL Partners, 2023

Existing subscribers can download the Manifesto at the top of this page. Everyone else, please go here.

If you wish to speak to us about our new Manifesto, please book a call.

Table of contents

  • Executive Summary
    • Recommendations
  • Pathway 1: No way back
    • Two constituencies at operators: Cloud sceptics and cloud advocates
  • Pathway 2: Hyperscalers – friend or foe?
    • Cloud-native network functions are a vital control point telcos must not relinquish
  • Pathway 3: Build own telco cloud competencies before deploying on public cloud
    • AT&T and DISH are important proof points but not applicable to the industry as a whole
    • But telcos will not realise the full benefits of telco cloud unless they, too, become software and cloud businesses
  • Pathway 4: The path to Network-as-a-Service
    • Pathway 4 networks will enable Network-as-a-Service
  • Conclusion: Mastery of cloud-native is key for telcos to create value in the Coordination Age

Related research

Our telco cloud research aligned to this topic includes:

 

VNFs on public cloud: Opportunity, not threat

VNF deployments on the hyperscale cloud are just beginning

Numerous collaboration agreements between hyperscalers and leading telcos, but few live VNF deployments to date

The past three years have seen many major telcos concluding collaboration agreements with the leading hyperscalers. These have involved one or more of five business models for the telco-hyperscaler relationship that we discussed in a previous report, and which are illustrated below:

Five business models for telco-hyperscaler partnerships

Source: STL Partners

In this report, we focus more narrowly on the deployment, delivery and operation by and to telcos of virtualised and cloud-native network functions (VNFs / CNFs) over the hyperscale public cloud. To date, there have been few instances of telcos delivering live, commercial services on the public network via VNFs hosted on the public cloud. STL Partners’ Telco Cloud Deployment Tracker contains eight examples of this, as illustrated below:

Major telcos deploying VNFs in the public cloud

Source: STL Partners

Enter your details below to request an extract of the report

Telcos are looking to generate returns from their telco cloud investments and maintain control over their ‘core business’

The telcos in the above table are all of comparable stature and ambition to the likes of AT&T and DISH in the realm of telco cloud but have a diametrically opposite stance when it comes to VNF deployment on public cloud. They have decided against large-scale public cloud deployments for a variety of reasons, including:

  • They have invested a considerable amount of money, time and human resources on their private clouddeployments, and they want and need to utilise the asset and generate the RoI.
  • Related to this, they have generated a large amount of intellectual property (IP) as a result of their DIY cloud– and VNF-development work. Clearly, they wish to realise the business benefits they sought to achieve through these efforts, such as cost and resource efficiencies, automation gains, enhanced flexibility and agility, and opportunities for both connectivityand edge compute service innovation. Apart from the opportunity cost of not realising these gains, it is demoralising for some CTO departments to contemplate surrendering the fruit of this effort in favour of a hyperscaler’s comparable cloud infrastructure, orchestration and management tools.
  • In addition, telcos have an opportunity to monetise that IP by marketing it to other telcos. The Rakuten Communications Platform (RCP) marketed by Rakuten Symphony is an example of this: effectively, a telco providing a telco cloud platform on an NFaaS basis to third-party operators or enterprises – in competition to similar offerings that might be developed by hyperscalers. Accordingly, RCP will be hosted over private cloud facilities, not public cloud. But in theory, there is no reason why RCP could not in future be delivered over public cloud. In this case, Rakuten would be acting like any other vendor adapting its solutions to the hyperscale cloud.
  • In theory also, telcos could also offer their private telcoclouds as a platform, or wholesale or on-demand service, for third parties to source and run their own network functions (i.e. these would be hosted on the wholesale provider’s facilities, in contrast to the RCP, which is hosted on the client telco’s facilities). This would be a logical fit for telcos such as BT or Deutsche Telekom, which still operate as their respective countries’ communications backbone provider and primary wholesale provider

BT and Deutsche Telekom have also been among the telcos that have been most visibly hostile to the idea of running NFs powering their own public, mass-market services on the public and hyperscale cloud. And for most operators, this is the main concern making them cautious about deploying VNFs on the public cloud, let alone sourcing them from the cloud on an NFaaS basis: that this would be making the ‘core’ telco business and asset – the network – dependent on the technology roadmaps, operational competence and business priorities of the hyperscalers.

Table of contents

  • Executive Summary
  • Introduction: VNF deployments on the hyperscale cloud are just beginning
    • Numerous collaboration agreements between hyperscalers and leading telcos, but few live VNF deployments to date
    • DISH and AT&T: AWS vs Azure; vendor-supported vs DIY; NaaCP vs net compute
  • Other DIY or vendor-supported best-of-breed players are not hosting VNFs on public cloud
    • Telcos are looking to generate returns from their telco cloud investments and maintain control over their ‘core business’
    • The reluctance to deploy VNFs on the cloud reflects a persistent, legacy concept of the telco
  • But NaaCP will drive more VNF deployments on public cloud, and opportunities for telcos
    • Multiple models for NaaCP present prospects for greater integration of cloud-native networks and public cloud
  • Conclusion: Convergence of network and cloud is inevitable – but not telcos’ defeat
  • Appendix

Related Research

 

Enter your details below to request an extract of the report