This may be one of the shorter blogs in this series, as it is very straightforward. In this one I want to focus on Virtual Network Functions, where they are today and where they are headed.
In recent years, as cloud environments have become more and more common, vendors have begun creating virtualized versions of their network gear. Whether it is Nokia/ALU, Juniper, Cisco, or whoever, they all have a version of their major products that they have inserted a “v” in front of to enter the virtual arms race. Many of these were first created back before any, or at least most of us, had heard anything about Network Function Virtualization. Despite this fact, when NFV became a buzzword, along with its related terms such as VNF, these were quickly spun into being the VNFs you needed to start realizing all of your NFV dreams.
In reality these “VNFs” are nothing more than vendors taking their existing code and porting it to a virtual machine that will run on a hypervisor. Unfortunately, this includes all of its legacy, hardware related overhead. It is also reality that this was probably the logical first step toward true VNF creation…the evolutionary step where network devices first grew gills and legs to deal with the environment they were evolving toward, if you will.
The issue is that the dynamic promise of what VNFs bring to your network is not fully realized due to virtual devices that take just as long to boot up and initialize as their physical counterparts. As a result the automatic scaling and healing capabilities that NFV brings to the table don’t quite have the impact they could have. Sure, you avoid the time and cost of racking, stacking, and powering the devices, but that is all…not saying that is trivial and has no value, of course, because it does.
Another approach taken by some vendors, such as Versa, was driven by the lack of maturity in Service Function Chaining (another blog to come). While Versa did create new virtual functions from the ground up with cloud native technologies being the basis for their DNA, they limited things in a different way. Because of the aforementioned lack of SFC maturity, they decided to create a VNF platform within which each of the desired VNFs would be activated. This platform is deployed within the cloud and all interaction between VNFs happen internal to the platform. While this may seem like a not so great thing, it opens up tremendous opportunity to people with existing clouds built on technology that is not NFV ready today. For example, the proprietary nature of VMware’s cloud approach makes it pretty hard to successfully chain virtual services together. The approach Versa used totally eliminates this barrier and allows companies with heavy investments in VMware infrastructure to deploy NFV-like services without having to create an entirely new infrastructure base to do so. It is an interesting approach that definitely has its place, given the right use cases.
Currently I see vendors moving forward to true virtualized network functions that are, much like the Versa platform, purely cloud native in how they are architected. In some cases vendors are leveraging container technology to achieve this, which is exciting to see as this technology is also being merged into the OpenStack infrastructure approach. Containers have the capability to revolutionize the way VNFs are built and deployed. Based on testing with a Juniper VNF a client of ours is using, we have seen container-based versions able to boot and initialize in a few seconds, versus the same VNF in the more traditional form described above taking 5-8 minutes. This makes automatic remediation of VNFs much more in line with SLA expectations from customers, not to mention the potential simplification of the environment by lessening the need to deploy multiple VNFs in an HA configuration to achieve the same type of performance.
The bottom line on VNFs today? They are continuously evolving. They aren’t where they need to be yet, but there are options out there that allow you to overcome the shortcomings. I expect a year from now, or sooner, that the landscape will take a shift towards container-based deployments that will really move this area forward. The advances in VNF architecture and deployment will drive how easily we will be able to recognize the full promise that NFV is capable of in the future.
For further reading on this topic, I suggest:
2016 Mega NFV Report Part II: VNFs