The Cloud Native Computing Foundation, or CNCF, just announced the launch of a new project named the “CNF Testbed,” which aims to help the community evaluate and compare networking performance between Virtual Network Functions (VNF) and Cloud-native Network Functions (CNF).
In this blog post we will dive into the definition of VNF and CNF and discuss their impact on the stack of the network virtualization, in light of this testbed project.
Cloud Native: A Definition
The CNCF proposes a definition of “Cloud Native” development in these terms: it consists of “using open source software stack to be containerized, where each part of the app is packaged in its own container, dynamically orchestrated so each part is actively scheduled and managed to optimize resource utilization, and microservices-oriented to increase the overall agility and maintainability of applications.”
What Are VNF and CNF?
When it comes to network and virtualization, we often juggle a handful of acronyms –some of them anagrams of each other: NFV, VNF, CNF, etc. It is worth, at this point, taking a minute to restate some of these definitions as well.
A nice summary of NFV is provided in this blog post, which states: “Network Function Virtualization is the virtualization of network functions. Virtualize means to abstract from the physical. Network Function often refers to Layer 4 to Layer 7 functions such as firewall, load balancer, DNS or IDS/IPS.”
On the other hand, a similar definition appears in this other post about SDN and NVF:
“NFV is the application of software defined appliances to the network. These appliances include devices such as edge authentication, firewalls, load balancers, and some routing functions”
The first implementation of Network Function Virtualization was called “Virtual Network Functions” and consisted of porting the then-existing physical appliances into virtual machines running in VMware, Openstack clouds, or perhaps on some of the public clouds. Today, thanks to the introduction of containers, the same functions can be re-implemented by moving the application part of it from virtual machines to containers. Those functions are then called “Cloud-native Network Functions” or CNF.
For instance, CoreDNS, which is a DNS server, is in fact one of these CNFs. The CoreDNS container image is available at https://hub.docker.com/r/coredns/coredns.
CNCF and ONF’s New Project
The new CNF TestBed project proposes to prove that concerns about networking performance should not prevent you from moving your network function from a VM to a container. It actually offers the tools for any networking company to compare the performance of the same function as a VNF or as a CNF. The change will not affect the overall networking performance. In fact, the lightness of container technology allows switching user context more quickly than with VM Hypervisors. With the help of memif –a new technology of virtual interfaces developed at the frontier between physical and virtual– the delivery of IP packets is becoming more efficient for containers than for VMs.
Another amazing early result is that the delay of deployment goes from 3.30 minutes for a VNF to less than 30 seconds for the corresponding CNF.
Figure – The CNF Testbed project’s preliminary results on throughput of packets processed are clearly in favor of the CNF
You can now confidently take advantage of all the benefits of containerization and orchestration by Kubernetes, which among others include:
- Cost savings (CapEx/OpEx)
- Improved resiliency (with dynamic scaling and safe upgrades)
- Higher development velocity
Based on these facts, in a slide deck presentation of the project, Dan Kohn, executive director at CNCF, drafted the most likely evolutions of Network Virtual Functions:
In other words, in the near future, Kubernetes will become a fundamental layer of network virtualization, and the development of Network Functions in containers (CNF) will also become the de facto standard.
Conclusion
The path to virtualization is in progress, taking advantage of grouping huge amounts of physical machines together, be it in a private or a public cloud. While various components of the network virtualization stack remain somewhat fluid, it seems that Kubernetes’ role has solidified, thus becoming a fundamental layer between the Cloud and services.
As a company, Infoblox foresaw very early on that Kubernetes was going to become one of the key components of this stack. In fact, Infoblox’s own SaaS service for DNS Security is already designed around these layers. It includes running CoreDNS as a CNF, thus taking advantage of Kubernetes orchestration. Infoblox has also delivered a number of network services as CNFs and is in the process of doing this with it’s on-premises NIOS product as well.
Joining CNCF (at its inception in 2016) and contributing to CoreDNS is Infoblox’s way of preparing for the future and consolidating its role as a major player in that future, just as it is today thanks to its DDI appliances.
Credits
Graphics extracted from slide deck “CNF TestBed” by Dan Kohn, Executive Director, CNCF and Arpit Joshipura, General Manager, LF Networking
