Deploying Network Functions on Public Cloud? Challenges continued for Telcos!

(I have been often asked if Telcos should deploy Network Functions on public cloud. There is no easy answer, and it depends on multiple factors. The blog dives deep into question to find answer.)

Should Telcos choose Public Cloud (or hyperscalers) for 5G/4G Network Function #NF deployments?

It’s an interesting question.

Two years back, when we saw hyperscalars thronged to MWC, Barcelona (MWC21), everyone talked about how public cloud is going to win over the complex beast named telcos. It appeared easy win at first glance!

Two years down the line (or two and half now), hyperscalers momentum couldn’t win many telcos as customer esp. from Network perspective. By network I mean, telcos choosing public cloud for deploying their 5G NSA or SA Core, RAN and other network functions. Barring Dish (AWS), AT&T (Azure) and few more, I don’t see many adopters for public cloud for Network workloads (NFV). These are just handful of examples and some of them are pilot stages or couldn’t scale to pan nation network yet.

But why aren’t many telcos adopting public cloud for network workloads?

There are few obvious reasons for not choosing public cloud. Let’s dive deep into them.

1. Complexity of Network Functions (NFs): VNFs and CNFs, are complex stateful applications. They may involve hundreds of microservices as one application or more. They could include databases, message queues, cache, and storage apart from stateless containers or VMs. Typically, these NFs are quite large compared to equivalent enterprise grade applications getting deployed on any public cloud platforms. Deploying this scale of NFs on any virtualised or containerised platform is extremely complex process. Although public cloud offers rich tools for automated deployment, telcos haven’t yet zeroed down completely on adopting DevOps based automation yet. They are in early stage of automation adoption, which could not only complicate deployment of NFs but also upgrade and entire life cycle aspects of it.
2. TCO: Cost or TCO is another crucial factor which weighs in slowly with hyperscalers. Public cloud providers use Pay-As-You-Go model. Running the complex and extremely large NFs all the time, puts the hole in pocket of telcos. Despite all discounts and ephemeral instances positioning, running heavy workloads on public cloud is quite expensive. All benefits of saving #CAPEX and simplicity of usages are gone, come 3-5 years down the line. I believe there’s no TCO benefit running NFs for 5 years or beyond with hyperscalers. Moreover, with public cloud, you are entirely operating with OPEX model. The benefits of cloud elasticity, easy scale out and scale in doesn’t fit the OPEX math as well.
3. Operations & Management: Operating public cloud with complex NFs brings another layer of complexity in addition to managing existing private cloud deployments. Telcos already running a large network on-prem, including 4G LTE VNFs. Only with 5G, and arrival of 5G Core SBA (Service Based Architecture), they are opting out for public cloud. Proponents might believe in creating a single pane of glass of observability across multi-cloud, but enabling resource ops, automation, finops, security & policy automation across multi-cloud with day1 and day2 ops is quite challenging and adds to ongoing opex costs budgets. Moreover, telcos typically lack skillset to manage and operate multi-cloud setup efficiently and cost effectively. O&M of public cloud NFs, in addition on-prem OSS, could add huge burden to telco ops teams if they decide to move large NFs to public cloud.
4. Vendor Lock-in: While it is known fact by now that it’s easy to move into public cloud, it’s not possible to leave them, if at all you wish to. Reason? The tech stack differences. Every cloud provider has its own way of building virtualisation and containerisation layers. On high level, they may appear same, but these platforms are quite different from each other. They use different OS and their libraries to build platforms. Even hardware is quite customized for each cloud provider. Your applications containers, once sit on those platform layers, it’s extremely difficult to port them to another platform, which anyways runs a separate set of OS and libraries. We normally call it as vendor lock-in. Many people believe that by containerizing workloads (VNFs to CNFs), they become portable automatically. That's not the case. Would a telco want to lock their big fat NFs to single public cloud provider platform? If your CNF strategy demands portability of workloads, you need to build it on right platform foundations. The cost/efforts associated with porting workloads from one cloud provider to another, at later stage, is huge and takes weeks or months to even execute the migration.
5. Security/Data Sovereignty: Moving your NFs workloads to public cloud could lead to loss of control, esp. the infra and platform layers. You just don’t own those layers, as hyperscalars had invested millions or billions to build their own state of art DCs. It’s big deal. Moreover, as you move workloads to them, your data, which was until now was well guarded within on premises boundaries, now reside on some other public network (still private), gets processed and stored outside. It could be quite challenging to deal with this, albeit fact that, hyperscalars offer excellent set of security of their own stack, leaving door open for managing security to your workloads on your own. Moreover, there’s ingress and egress costs associated with data transfer, which is quite complex to factor in.
6. Solutions Stitching: It’s important to understand why public cloud doesn’t solve your problems unless you do. Although you get multitude of ready to consume services with single click, in the end it’s telcos responsibility to create a complete solution blueprint out of those services. Moreover, you need to now manage and stitch multiple moving parts, as part of blueprint, even on single public cloud provider. Telcos have always relied on their vendor partners to help them here and possibly lack of skills could lead to not building right blueprints on cloud. Managing these architecture blueprints, and version controlling architectures over longer period is immensely challenging in multi-cloud environments.
7. Workload Performance: Many telco grade workloads need to run at specific performance benchmark of network and compute latencies, including RAN (DU), it’s not easy to get similar set of performances when deployed on public cloud platforms. There are all sorts of hardware acceleration (SRIOV, DPDKs) required for faster data paths to meet latency requirements of workloads. While public cloud has evolved to great extent, it’s not easy to deliver similar performances always, and telcos could face challenges in delivery requisites performance

While telcos are quite reluctant for adopting public cloud for network workloads, they are certainly embracing it for running their IT workloads namely BSS and OSS. Public cloud is quite well suited for these types of IT workloads and allow them the benefit of faster time to market for their offerings, and elasticity required for those services. I assume, above challenges of adopting public cloud for IT workload continue to be there for those workloads (except performance), but in those cases, benefits outweigh the drawbacks. It's still to be seen, how IT workloads run cost effectively for prolonged period.

In the end, there's no clear answer here, if a telco should adopt public cloud for network (or IT) workloads or not. It depends on multiple factors including size and scale of workloads, current and future traffic growth, regional spread of services and should be aligned with long term vision of telcos transformation. Some smaller to mid-size telcos have quickly adopted public cloud for 5G, while large telcos, with wider geographic spread, large customer base, mayn't have agility to move to cloud easily.

People often cite names of early public cloud adopter telcos when they debate about the subject. But I believe many of those adopters aren't being able to run a nation-wide network, at sizable traffic volume yet. I would tag those names as outliers and not early adopters. It's still to be seen how those telcos can run their NFs on public cloud at scale for wider geographies handling decent traffic size, efficiently and cost effectively.

There's an excellent discussion around the subject few months back from ABI Research, when they debated the topic about telco cloud vs public cloud. It could be seen that, ABI research found that, running NFs on telco cloud, on your premises is cost effective than running it on public cloud.

When we talk about public cloud, many proponents believe that OPEX operating model (Pay as You Go) outweighs over CAPEX model of DC build outs. But again, as per ABI Research, OPEX operating model of public cloud providers proven to be costly, compared to CAPEX based model. Or in other words, building your own private telco cloud and run NFs on it, over a period of ten-years, offers better TCO benefits.

It is to be seen how telcos adopt public cloud, and address those challenges mentioned above. Telcos can still adopt public cloud for onboarding NFs, provided they address those challenges effectively by adopting solutions such as Red Hat OpenShift Container Platform, which offer no vendor lock-in approach for hybrid multi-cloud environment, offering complete control over costs, and manageability with single dashboard for containerised environments across on-prem, public cloud and edge.

#telcocloud #publiccloud #networkfunctions #CNF #VNFs #redhat #openshift

(All views are personal, and author doesn't endorse or claim the credits of any research on subject by any third parties.)

The blog published earlier with Telecomblogs.

ABI Research Whitepaper could be found here.