Français
Telecom networks have been undergoing a profound transformation for several years. Network functions, once executed on proprietary hardware, were first virtualised as VNF, then re‑designed natively for the cloud as CNF. Understanding the difference between these two approaches is not a theoretical exercise: it is an architectural choice that determines performance, costs and the evolution capability of a network for the next five to ten years. If you are a network architect, infrastructure manager or simply curious why your operator talks so much about containers and Kubernetes, the following should clarify things. We will compare VNF and CNF on concrete criteria: architecture, performance, costs, operational agility, and strategic relevance.
Evolution of Virtualisation: from VNF to CNF
The shift from physical network equipment to software functions did not happen in a single leap. There were two major steps, each driven by different technologies and philosophies. Understanding this trajectory is essential to see why CNF are not just “improved” VNF, but a paradigm shift in how network functions are designed and operated.
Definition and Architecture of VNF (Virtual Network Functions)
VNF, or Virtual Network Functions, appeared in the wake of the NFV (Network Functions Virtualisation) movement launched by ETSI in 2012. The core idea was simple: take network functions that ran on dedicated physical appliances (routers, firewalls, load balancers, etc.) and run them as software inside virtual machines on standard x86 hardware.
Concretely, a VNF is a monolithic or loosely modular application that runs inside a virtual machine (VM). Each VM carries its own guest operating system, libraries and dependencies. A hypervisor (VMware ESXi, KVM, or others) manages the allocation of hardware resources among the different VMs hosted on the same physical server.
A typical VNF deployment architecture rests on three layers: the NFVI infrastructure (servers, storage, network), the virtualization layer (hypervisor), and the VNFs themselves. An orchestrator, often compliant with the ETSI MANO framework, coordinates provisioning and lifecycle management. This approach allowed operators to reduce dependence on proprietary hardware and gain flexibility compared to physical appliances. However, it retains structural heaviness: each VM consumes significant resources just to run its OS, and startup time is measured in minutes, not seconds.
The Emergence of CNF (Cloud‑Native Network Functions)
CNF represent the next step. Instead of merely virtualising an existing network function by placing it in a VM, the cloud‑native approach redesigns the function as containerised micro‑services, built from the ground up to run in an orchestration environment like Kubernetes.
A container, unlike a VM, does not carry its own operating system. It shares the host’s kernel and includes only the application and its direct dependencies. The result: a far smaller memory and CPU footprint, startup times measured in seconds, and a much higher deployment density on the same server.
But containerisation alone does not make a CNF. What truly distinguishes a CNF is its cloud‑native architecture: decomposition into independent micro‑services, API‑based communication, component‑by‑component scaling, built‑in resilience, and declarative configuration management. A high‑quality CNF follows the “Twelve‑Factor App” principles adapted to telecom. The main vendors (Ericsson, Nokia, Samsung) offer their 5G core networks as CNF, and most major European operators, including Orange and Deutsche Telekom, have embarked on migrating their critical network functions to containerised architectures.
Technical Comparison: Virtual Machines vs. Containers
Beyond the definitions, it is the specific technical differences that determine the choice between VNF and CNF. This section goes into detail about what actually happens under the bonnet.
Resource Management and Hypervisors
In a VNF environment, the hypervisor is central. It creates and manages VMs, allocating vCPUs, memory and virtual network interfaces. Each VM receives a fixed resource allocation, often oversized to absorb traffic spikes. This guarantees strong isolation but at the cost of structural waste. A physical server with 512 GB RAM and 64 cores might host ten heavy VNFs, each reserving 20-40 GB of RAM for its guest OS and libraries before any useful network function runs.
Containers change this equation radically. Without a guest OS layer, a typical container consumes between 50 MB and a few hundred MB of memory. On the same physical server, dozens, or even hundreds, of containers can be deployed. Kubernetes, the standard CNF orchestrator, handles dynamic resource allocation: an idle container consumes almost nothing, and freed resources are instantly available for other workloads.
This difference directly impacts data‑centre sizing. Operators migrating to CNF typically see a 30–50 % reduction in the number of physical servers required for the same network capacity, an important figure when managing thousands of nodes.
Performance, Isolation and Security
Raw performance is often misunderstood. VNFs, using technologies like SR‑IOV (Single Root I/O Virtualisation) and DPDK (Data Plane Development Kit), can achieve near‑native hardware packet‑processing speeds. The hypervisor adds a latency layer, but modern hypervisors keep it minimal.
Containers run directly on the host kernel. For CPU and memory operations they deliver near‑native performance without virtualization overhead. However, kernel sharing raises isolation concerns: a container exploiting a Linux kernel vulnerability could potentially affect other containers on the same host. VMs, with their hypervisor boundary, provide a thicker security wall.
By 2026 this gap has narrowed considerably. Technologies such as gVisor, Kata Containers (which combine containers with micro‑VMs), and Kubernetes security policies (Pod Security Standards, network policies, service‑mesh mTLS) offer sufficient security for most telecom use‑cases. Some operators adopt a hybrid approach: containers for control‑plane functions, VMs for data‑plane functions that demand the highest performance and isolation.
Agility and Operational Lifecycle
It is probably in the area of operational agility that the difference between VNF and CNF is most evident on a day-to-day basis. Teams managing network infrastructure spend most of their time deploying, updating, monitoring and upgrading network functions. The way in which these operations are carried out varies radically depending on the approach chosen.
Deployment and Orchestration with Kubernetes
Deploying a VNF remains a relatively heavy process: provision the VM, install the guest OS, configure virtual networking, deploy the application, then interconnect it with other components. Even with automation tools like Ansible or Terraform and a MANO orchestrator, a full deployment of a new network function usually takes 15–45 minutes. VNF descriptors (VNFD) are often complex and vendor‑specific.
With CNF and Kubernetes, deployment relies on declarative YAML manifests. Desired state is described, and Kubernetes enforces it. A complete deployment takes seconds to a few minutes. Helm charts enable packaging of complex deployments reproducibly. An operator can spin up an entire 5G core network instance in minutes, versus several hours in a traditional VNF environment.
Kubernetes also adds self‑healing: if a container crashes, it is automatically restarted; if a physical node fails, containers are redeployed on other nodes. This native resilience drastically reduces human intervention during incidents. French operators that have put CNF into production report a 60–70 % reduction in time spent on deployment and remediation tasks.
Updates, Scalability and Micro‑services
Updates are the Achilles’ heel of VNFs. Because a VNF is often monolithic, updating it means stopping the whole function, applying the patch or new version, then restarting. Even with active/passive redundancy, these operations involve maintenance windows and risk of service disruption. Operators typically schedule VNF updates weeks in advance.
CNF, thanks to their micro‑service architecture, allow granular updates. Only a single component (e.g., the session‑management module) can be upgraded without touching the others. Kubernetes natively supports rolling updates: new versions are rolled out pod‑by‑pod without service interruption. If a problem occurs, an automatic rollback restores the previous version within seconds.
Scalability follows the same logic. With a VNF, scaling means launching a new full VM, a time‑consuming, resource‑heavy action. With a CNF, Kubernetes can add replicas of a specific micro‑service in seconds, based on real‑time load. The Horizontal Pod Autoscaler automatically adjusts pod counts according to metrics such as CPU usage or active sessions. During peak events (e.g., a major sports broadcast) the network adapts in real time without manual intervention.
Strategic Advantages for Telecom Operators
Beyond technical considerations, the choice between VNF and CNF has direct implications for operators’ business strategies. The benefits cannot be measured solely in milliseconds of latency or as a percentage of CPU savings.
Reduction of Operational Expenditure (OPEX)
Operational costs make up the largest share of a telecom operator’s budget, far exceeding initial capital expenditure (CAPEX). This is where CNF deliver the greatest impact.
A concrete case study: a large European operator that migrated its 5G core from VNF to CNF between 2023 and 2025 reported:
- 40 % reduction in the number of physical servers needed thanks to container density
- 35 % lower energy costs (fewer servers → less cooling)
- 50 % decrease in time spent by teams on routine maintenance
- Maintenance windows shrank from 4 hours per month to continuous, interruption‑free updates
ubernetes‑native automation also reduces the need for highly specialised manual‑operations staff. Teams can focus on higher‑value tasks: new service development, performance analysis, innovation. This does not mean fewer jobs, but a shift toward development and engineering roles rather than manual operations.
Software licences are evolving as well. Many network‑function vendors now offer consumption‑based pricing (number of sessions, traffic volume) instead of per‑VM licences. This model aligns naturally with CNF’s granular resource tracking.
Interoperability and Multi‑Cloud Ecosystems
A recurring problem with VNFs is vendor lock‑in. Each VNF vendor uses its own descriptor formats, hypervisor requirements and management tools. Migrating a VNF from a VMware environment to OpenStack, for example, can take weeks of adaptation work.
CNF, built on open standards (OCI for container images, Kubernetes for orchestration, Helm for packaging), provide far superior portability. A CNF running on an on‑premises Kubernetes cluster can, in theory and often in practice, run unchanged on a managed Kubernetes service in AWS, Azure, GCP, or OVHcloud.
This portability enables multi‑cloud and hybrid architectures. An operator can host critical network functions in private data‑centres while leveraging public clouds for peak‑load bursts or edge‑computing deployments close to end‑users. By 2026, several French operators run hybrid setups that mix private infrastructure with public‑cloud resources, assigning each network function to the environment that best fits its requirements.
The cloud‑native ecosystem also benefits from a massive open‑source community. Projects such as Istio (service mesh), Prometheus (monitoring), Argo CD (continuous deployment) and Cilium (networking & security) provide capabilities that would have cost millions to develop internally. Operators adopting CNF gain immediate access to this rapid‑innovation ecosystem.
Choosing the Right Approach for Network Modernisation
The “VNF or CNF” question is not binary. In 2026, most operators run mixed environments, with legacy VNFs coexisting alongside next‑generation CNF. A full migration typically takes 3–5 years for a medium‑size operator, longer for the largest networks.
The decisive factor is organizational maturity, not the technology itself. Adopting CNF without internal Kubernetes expertise, CI/CD pipelines, and a DevOps culture leads to costly failures. Several operators that rushed migrations ended up with poorly‑managed hybrid environments that were more complex than the original infrastructure.
A pragmatic recommendation:
The pragmatic recommendation is as follows: start with the new network functions (5G SA, edge computing, network slicing) as CNF, and progressively migrate the existing VNF, beginning with those whose support contract is expiring. Invest heavily in training teams on Kubernetes and cloud‑native practices. And above all, do not underestimate the organizational aspect: CNF work best with product‑oriented teams, not with traditional “network” and “IT” silos.
The fundamental difference between VNF and CNF goes beyond the container‑versus‑VM technical debate. It is a shift in how a network is designed, deployed and operated. VNFs allowed the industry to escape proprietary hardware. CNF enable thinking of the network as software, with all the associated benefits in speed of innovation, resilience and economic efficiency. Operators that master this transition will be those that recognise technology is only half the journey; the other half is transforming skills and processes.
