Five characteristics of a cloud-native network function

Unlike legacy VNFs — often monolithic and dependent on virtual machines — CNFs are designed from the ground up for cloud environments

As telecom networks evolve to meet the demands of 5G, edge computing and automation, traditional physical and virtual network functions (PNFs and VNFs) are being replaced by cloud-native network functions (CNFs), which are network functions implemented as software running in containers, typically orchestrated by Kubernetes that deliver greater scalability, resilience and efficiency. Unlike legacy VNFs — often monolithic and dependent on virtual machines (VMs) — CNFs are designed from the ground up for cloud environments.

Spirent Communications’ Principal Product Manager of Cloud-Native 5G Deployment Validation Bill Clark provided the following five defining characteristics of a CNF:

They support microservices

The Access and Mobility Management Function (AMF) was traditionally deployed as a single monolithic application running on dedicated hardware. With the shift to VNFs, AMF was broken into multiple components, often spread across different VMs depending on the vendor’s architecture.

Now, in the cloud-native era, AMF is further disaggregated into microservices running inside containers. Instead of a single application, we now see 100-plus Kubernetes pods — containerized workloads that host telecom network functions and their supporting services — each handling a discrete function that, in aggregate, make an AMF.

“Why would you do that? Well, if you have little pieces and they fail, you can repair them very quickly. If you need to scale, you only need to scale a little bit, not the whole application,” said Clark.

They are container-based

Cloud-native functions also represent an evolution from VMs to containers, with containers being much more efficient. Clark said that this because CNFs do not require a full host application or operating system inside each container. This architectural difference leads to several major benefits including reduced resource overhead, faster startup and scaling, simplified management and automation, enhanced security and better agility.

They have orchestration that is most likely Kubernetes

“It doesn’t have to be Kubernetes — no one says it must be — but it typically is,” said Clark. In fact, while previously in the VNF world, you may have VMware, Red Hat Openstack and AWS — all VMs — utilizing different orchestration mechanisms, now in cloud-native, Kubernetes has become the de facto standard. “Kubernetes EKS [Amazon Elastic Kubernetes Service] is Kubernetes, Red Hat Openshift is Kubernetes,” he illustrated. “The core of all of the cloud environments and what enables multi-cloud much easier is now fundamentally Kubernetes.”

Kubernetes simplifies network function orchestration, enabling multi-cloud deployments, seamless scaling and automated management.

They are self-healing

One of the key advantages of CNF is their self-healing capability, which ensures high availability and resilience in telecom networks. CNFs leverage Kubernetes’ built-in orchestration to automatically detect failures and recover without human intervention. If a CNF pod crashes, Kubernetes immediately restarts the failed pod, reschedules it on a healthy node, or spins up a replacement to maintain service continuity.

Additionally, the health and status of CNF workloads are continuously monitored, ensuring that only healthy instances handle network traffic.

They can scale, automatically 

Clark noted that Spirent is seeing CNF vendors adopting Horizontal Pod Autoscaling (HPA), in which Kubernetes automatically updates a workload resource so that it scales to match demand.

Horizontal scaling will response to increased load by deploying more pods. This is different from vertical scaling, which for Kubernetes would mean assigning more resources such as memory or CPU to the Pods that are already running for the workload. Then, if the load decreases, and the number of pods is above the configured minimum, HPA would instruct the workload resource to scale down.

And for Clark, it’s the scaling down telcos should be paying attention to: “What is much more interesting about scaling is not scaling up but scaling down — at night when there is no traffic, you can start turning off resources which directly correlates to cost savings,” he said.

He adds that without effective scaling strategies, the entire cloud-native model could be questioned: “If the Tier 1s don’t figure out scaling, it arguably puts the whole cloud-native thing in question — why are we investing all of this money to build something that looks very much like what we’ve always built?”

What Clark is getting at, perhaps, is that ultimately, CNFs are not just an evolution but a necessity for the future of telecom. As operators continue their cloud-native journey, the key to success lies in leveraging automation, optimizing scaling strategies and ensuring seamless multi-cloud interoperability. And the transition to CNFs promises networks that are more agile, more resilient and more cost-efficient than ever before.