Decoding the Impact of Cloud-Native Technologies on Network Delivery and Operations

In the Information Technology (IT) domain, cloud-native computing, also referred to as container-based virtualization, abstracts away low-value infrastructure complexity by fully decoupling app software from hardware. By contrast, total disaggregation of software from hardware may not be wholly possible in telcos. The reasons vary. Telco networks often require tight software-hardware integration, especially at the edge, to achieve high reliability and ensure deterministic performance of complex telco functions. In addition, the hardware/software disaggregation, or cloud-native technology implementation, introduces new challenges in terms of how Communication Service Providers (CSPs) build and operate networks. For example, how to go about picking a Container-as-a-Service (CaaS) platform, what Continuous Integration/Continuous Delivery (CI/CD) approach to use, and what is the ideal lifecycle management approach are all imperatives that warrant some consideration as CSPs continue to implement cloud-native technologies. In this ABI insight, cloud-native technology and container-based virtualization are used interchangeably.

Virtual Machine (VM)-based virtualization is simpler for operations for many reasons: 1) it is not as dynamic as container-based virtualization; 2) tenant isolation may well be better achieved with VMs; and 3) integration is potentially less complex with VMs. VMs “virtualize” the hardware layer so that hardware resources can be used efficiently. Containers provide a thinner abstraction layer by isolating the Operating System (OS) and associated app dependencies. This allows apps to be agnostic to the underlying hardware. It also compels CSPs to think more about software and Application Programming Interfaces (APIs) when creating new services. That stands in contrast to offering network services that require deep and complex vertical hardware integration. This new way of operating networks makes cloud practices like CI/CD more valuable, and the “new” cloud practices make the new ways of operating highly complex telco networks more possible. For example, implementing a network service or telco app may require support from various Network Functions (NFs), third-party software, and a diverse set of cloud infrastructure. CI/CD must accommodate this technological diversity for lifecycle management of network resources, and automated maintenance of virtual and cloudified resources.

For CSPs to implement CI/CD, they may have to adopt a microservices design. However, just having microservices is not enough. If a microservice image is 1 Gigabyte (GB) or more, it won't fit the CI/CD framework. The images need to be Megabytes (MB) in size. Vendors like Mavenir claim to offer 5G Core software with sufficient granularity for CI/CD. Beyond image size, equally important is a small Central Processing Unit (CPU) and memory footprint. That stands to be the hallmark for how cloud-native networks need to be implemented in the future. In fact, in most cases, for a true cloud-native design of some NFs, microservices may well have to use fractions of 1 CPU core. Today, most NFs require multiple CPU cores because of two reasons: 1) existing NFs have “legacy” code buried inside them; and 2) often, a vendor puts together multiple NF components in the overall design. For example, 5G Access and Mobility Function (AMF) can be packaged with components like Non-3GPP Interworking Function (N3IWF). Cloud technologies segregate these functions to allow efficient use of CPU and memory. But there are challenges, namely the network becomes more dynamic, and different components will have different life spans and unique lifecycle states.

The networks of the future will be based on advanced technology like cloud-native tooling, automation software, and Artificial Intelligence (AI). For example, network maintenance and fault diagnosis will be done within minutes instead of hours. But, on the other hand, cloud-native software leads to radical changes for CSPs. It upends how CSPs build and operate networks and that is a transitional journey. To better navigate that transition, CSPs should define a cloud blueprint to ensure cloud-native technology improves their operational maturity. CSPs should place network transformation as the driving principle behind cloud-native adoption. ABI Research outlines three key aspects CSPs should consider:

1. Define Cloud-Native Blueprint Early: CSPs should define their cloud blueprint as early as possible, and then they should iterate—consult with other peers, return to it, and refine further. Next, CSPs can give the “half-baked” blueprint to a partner for further adjustment. The blueprint should be the reference for vendors to implement their software against, not the other way around. Defining a blueprint avoids suppliers steering CSPs in different directions.
2. Measure Cloud-Native Software in Terms of Hardware It Requires: Software-hardware decoupling is not mandatory in 4G, but it is an inherent feature of 5G. So, one of the steps for CSPs to evaluate cloud-native product design may be to measure the software they buy in terms of hardware needed to deliver capacity. That said, user-plane NFs continue to have high performance requirements, so most CSPs (e.g., China Mobile) opt for dedicated hardware implementation.
3. Link Cloud-Native Technologies to Operational Efficiency: Most CSPs have yet to realize the benefits of adopting cloud-native tooling. But, with the right cloud roadmap and strategy, CSPs can develop a simplified and highly automated operations model and improve their overall digital maturity, while potentially supporting new business models—in that order.

To conclude, for a wider adoption of cloud-native technologies in telco networks, vendors like Canonical, Red Hat, VMware, and Wind River, among others in the market, should continue to focus on what makes cloud tooling (e.g., CI/CD) different for CSPs, which is (network) delivery and operational stages. CSPs’ network transformation partners should reimagine cloud-native principles in line with the complexity of CSPs’ environments. They should guide CSPs on where they stand in terms of operations maturity. For example, which workloads should be hosted on a telco cloud and which should be hosted on a public cloud, what is the right automation strategy, and which CI/CD framework works best are key transformation planning phases. Answers to these questions vary from CSP to CSP. Lastly, vendors should guide their CSPs’ partners on how to handle change, support CSPs with seeing and embracing opportunities, and aid CSPs with seeing challenges posed by cloud-native technology and how best to face them.