Public Cloud for Telco Applications - A Sales Guide
Feb 14, 2021 · 1206 words · 6 minute read
How to sell public cloud for Telco Applications?
Over the past year the focus of Hyperscalers (AWS, Google, Microsoft) on cloud solutions for core Telco applications has intensified. This has many reasons: Telco application suppliers are in the process to re-design their software to a more cloud-native architecture - driven for example by new 5G stand-alone (SA) core software releases. Furthermore, edge cloud is getting more relevant and the disaggregation of applications and platform will also happen at the edge with initiatives like O-RAN. Thirdly, Hyperscalers see a competitive advantage to move their public clouds infrastructure closer to end users (and Telco’s are the obvious partner for this). Finally, on-premises offerings of all big cloud players - like AWS Outpost, Google Anthos and Azure Stack - have been developed to fulfil data sovereignty requirements in many industries and those offerings could be also a good fit for telco workloads where location and data sovereignty are key requirements, too.
This blog posts addresses mostly the question how to make attractive public cloud offers to Telco’s for core telco applications - things like 4G/5G data core, voice platforms like IMS, VoLTE or messaging - legacy SMS/MMS, RCS,…. But the obvious questions first: why do I explain this when we at Pan-Net build cloud infrastructure exactly for this purpose ourselves (and operate cloud instances in nine countries throughout Europe today)? There are three main reasons:
- We need the best cloud infrastructure for telco application and this is also our goal at Pan-Net. We believe that a hybrid cloud strategy involving private and public cloud will be the target solution as in all other industries.
- We do see a lack of understanding of telco requirements when disaggregating application and platform. At least today, there are some differences compared to other verticals moving their workloads to a public cloud that I would like to explain transparently.
- A well-prepared sales approach is simply more efficient and enjoyable :-)
Questions that need to be answered
There are a couple of key questions that need to be answered when moving telco apps to a public cloud environment – here are the TOP 5:
Location Requirements
Technical requirements (e.g. latency) or - even more important - legal/regulatory requirements enforce that core telco applications are hosted within the same country where the telco operates. As the footprint of Hyperscalers is limited, this mostly leaves on-premises offerings of public cloud providers. In many countries also the management of telco infrastructure needs to stay within country boundaries which makes those on-premises offerings difficult that are mandatorily managed from a public cloud region and do not support a “disconnected mode”. As there are no technical reasons to centralise the management plane (and many critical apps are already migrated to public cloud regions) - this barrier could be overcome with time via joint lobbying of Telco’s and Hyperscalers.
Software only vs Integrated Offerings.
Typically, the amount of resources needed for core telco voice and data application is surprisingly small when comparing to other industries moving their IT workloads to public cloud. Therefor - in many cases - it is needed to scale down solutions to a small number if bare metal servers. Given this requirement, software only proposals - like Google Anthos or AWS EKS anywhere - seem more beneficial and suitable compared to fully integrated hardware & software solutions like AWS Outpost. Those integrated solution might be scaled down (e.g. as in the Azure stack portfolio) but Telco’s are used to multi-vendor scenarios and software only models would still be beneficial as they can be changed more easily (this might be different once telco apps make more use of specialised hardware like GPUs or FPGAs)
The support of some telco specific features will be needed in any case - especially those that arise from current telco standardisation (e.g. multiple interfaces for containers via Multus) or SR-IOV and/or SmartNIC support for acceleration of packet processing.
Value of Platform Services
The main value of public clouds is a rich set of platform services and the flexibly to scale resources up and down dynamically. On the other hand, Telco’s are still considering changes in their core production rather a threat and true devops practices are not yet widely spread. Also, even though telco applications are moving towards containerised production on top of a managed K8s layer the use of further platform services, like service meshes , is very limited today. The reason for this is not only the speed of changes to the software architectures of large Telco application suppliers like Ericsson, Nokia or Mavenir but also the desire of Telco’s to outsource responsibility to those partners to a very large extent: If a Telco software supplier needs to accept very strict (end-to-end) SLAs for their software there is not much incentive to make use of platform services that are outside the scope of the telco software provider. This problem has limited the willingness to disaggregate application and platform in the past and it will still slow down the adoption of more rich platform services. Building up software and cloud skills in Telco’s is one part of the solution here, partnering of application providers and public cloud providers (see for example this recent Nokia-Google-Partnership) this other part.
All the above limits the value that Telco’s draw today from public cloud offerings for this workload class (which in turn explains their price expectations….)
Operations and SLAs
The requirement of 5x9 availability is ubiquitous in the telco industry and this cascades down to all components involved in the production - also to public cloud offerings in case they are involved in the production. Two things are important to understand here: For Telco’s not only availability KPIs are important but also single incident resolution KPIs are widely used. This is quite against cloud principles where any component may fail, and failures are compensated by a very robust application architecture that makes use of cloud regions and availability zones. It will be very difficult today to make an public cloud (on-prem) offering that does not contain an incident level SLA with a resolution time of 4h from a P1 incident :). Another principle of Telco SLAs compared to public cloud SLAs is that typically public clouds provide quite conservative availability SLAs that are usually exceeded significantly by the real operational performance. Telco’s tend to push to “over-promise” on SLAs - secured by contractual penalties - which makes commercial negotiation more complex.
Costs
The cost expectation is directly related to the value discussion that I mentioned above. As long as dynamic resource scaling or rich platform services are of limited value, Telco’s are not willing to pay for them and rather see a “cloud” as a group of servers with a Kubernetes layer to orchestrate containers. From this point of view Telco’s would compare on-prem public cloud offerings rather with “Kubernetes-anywhere” solutions like Rancher or Openshift. Therefore, monthly subscription models that price the public cloud benefits based on used vCPUs will not be accepted today. This may change in the next 2-3 years when telco applications evolve further and the benefits of the cloud layer itself become more relevant.
With this, I hope that I explained some aspects of telco requirements towards public cloud offerings. Happy sales!