Shift from On-prem to Cloud Networking Environments with CNFs

This post is the first in a series around the Cloud-Native Network Function Orchestrator (CNFO).

Part 1: What are CNFs?

Before we dig into the Cloud-Native Network Function Orchestrator (CNFO), let’s start with Cloud-Native Network Functions (CNFs).

The bare bones definition of a CNF is a container which is running a network function, such as a firewall or VPN. Contextually, CNFs are the next stage of an evolution that began with physical devices, progressed to virtual network functions (VNFs), and is now heading towards CNFs. As evident in the name, “Cloud-Native” Network Functions ultimately represent a shift from on-premises environments towards cloud-based networking environments.

Physical Devices

Physical devices, like routers or switches, are monolithic and purpose built, meaning that they run on dedicated hardware and house all their own applications. While dedicated physical hardware have their boons, they only perform one job (i.e. be a router). Consequently, physical devices are expensive as building out scale and redundancy requires investing in more hardware. If hardware goes down, engineers must spend time and resources troubleshooting the device. Network engineers saw a way to remove dedicated hardware dependency by implementing virtual network functions (VNFs).

Virtual Network Functions

By shifting to VNFs, network engineers started breaking network functionality into smaller pieces. Engineers could rack a generic piece of hardware and then run a hypervisor, which allows the operating system to run multiple virtual machines. Each virtual machine runs a VNF. One VNF might house a VPN gateway while another could run a firewall. Segmenting network functionality and removing hardware reliance made building scalability and redundancy cheaper. In addition to cost savings, VNFs were a natural first step, as they are architecturally and operationally similar to physical networks.

In practice, VNFs fall short of their initial promises. VMs are taxing on resources, have long boot up times, and, often times, sit idle. Most notably, VNFs resemble physical devices in that they are built as monolithic, single-purpose virtual applications. VNFs have started the networking world on its journey to the cloud, but fall short of making the final leap.

Cloud-Native Network Functions

CNFs represent the next step into cloud-based environments. CNFs break monolithic VNF applications into individual components. Multiple containers work together inside of a cluster to create the overall network function.  Each cluster is managed by a Kubernetes-like lifecycle manager, such as basic Kubernetes, Openshift, or EKS.

Since CNFs are composed of individual, lightweight containers, they are easy to spin up or down, which has a cascade of implications. CNFs are capable of self-healing: if an individual container fails, it’s easily and quickly replaced. Engineers don’t need to troubleshoot like they would a VNF or physical device. In addition, CNFs can run on private servers or on the public cloud, which reduces the need for hardware investment.

However, this last jump into the cloud will probably be the biggest jump. With the shift to the cloud comes the merging of two established fields, DevOps and Network Engineering (coined NetDevOps). Right now, there is a technological and cultural gap as network engineers learn to be developers and vice versa.

Conclusion

Part of what we’re trying to do with CNFO is help bridge the gap between the cloud and the existing networking world. As such, I want to hear from you. Are you familiar with CNFs or are they entirely new? How do you see yourself using them? Let me know your thoughts in the comments and if you’d like to connect.

To be clear, we do not think that physical devices or VNFs are going away entirely. Rather, network engineers will need to orchestrate a field composed of all three network function types. Luckily, orchestrating across device types and at large scales is where NSO excels. We will dig into how NSO can orchestrate CNFs (as well as VNFs) in Part 2 of this blog series.

Related resources

We’d love to hear what you think. Ask a question or leave a comment below.
And stay connected with Cisco DevNet on social!

LinkedIn | Twitter @CiscoDevNet | Facebook | YouTube Channel

Share: