In a previous blog posting “What is Enterprise NFV Infrastructure Software” I described NFVIS and what it does within the Cisco Enterprise NFV solution. When people first look at the solution, occasionally the question comes up “what is the difference here with server hypervisors”?
I generally don’t like to compare Enterprise NFV with NFVIS to standard server hypervisors. The reason is that although there are some common uses of virtualization technology, they are developed, applied and used in a much different way. It’s like trying to compare a full sized pickup truck and mini-van. They both have combustion engines and an area to carry things, but what you need to carry in the back of a pickup is not the same as a mini-van. Also, what is important to the person who buys one or the other is very different.
What about using other hypervisors for NFV?
Standard server virtualization evolved for use in the data center. The idea was to take applications running on standalone servers and run them on top of a large sever(s) sharing the CPU/Memory/Storage. When looking at the commercially available hypervisors, attention was given to specific features and scale without as much around controlling footprint. This makes perfect sense at the data center and when you are running tens of thousands of VMs the overhead of the hypervisor is minimal to the load of the VMs. In standard server virtualization a common means of efficiency is to oversubscribe the hypervisor since at the data center there can be a high random rate of use to any given VM. This can be further stretched when considering that remote users may be from far different time zones allowing for further oversubscription.
Branch needs to be different
When at the branch, this is no longer the case. Many times branch footprints can be small and if you are running a few VNFs like router, firewall, IPS/IDS, proxy, and such, each one is processing nearly all of the same packets sequentially. In this case, there is no opportunity to really oversubscribe to gain efficiency. On top of software enhancements to maximize the use of resources, we’ve built in and we’ll be using hardware assistance coming soon.
One of the other differences to the more standard approaches of server virtualization is that the management system for hypervisor generally does not do much with the VM itself. What I mean by that is if you are configuring a VM to be a virtual router, the management system for the hypervisor does not know or care about the function of the router. The Enterprise NFV solution comes with components in its management framework that configure and managed services within the VNF as well as to spin up the instance; and this will only grow over time.
Hardware does make a difference
Another point is with the hardware itself. Management for standard server virtualization systems has a lot of features for interfacing to systems like external storage. They generally do not have capabilities for configuring hardware elements themselves and especially not devices that the hypervisor only connects to and does not run on. The management framework for the Enterprise NFV solution performs configuration much more broadly and includes other network devices such as routers, switches and wireless components. There is more to come on the topic of hardware but I’ll save that for the next post.
Looking at the commercially available hypervisor solutions there are specific functions on what is done by API directly to a standalone hypervisor instance or done without special licenses. This makes sense when looking at the vast majority of use cases around the data center or private clouds. To ensure reliable execution of features, especially under high load, the approach seems to be to keep the system a little more under control of the management system. With NFVIS, we designed the system with the idea that our NFVIS was in remote sites that are generally not staffed by IT. The REST or NETCONF APIs can be accessed and used by systems other than the Enterprise NFV management devices.
Let me make one last point on hardware. Recently, while talking with customers on Cisco Digital Network Architecture (DNA) one of my colleagues, Cisco Distinguished Engineer Dave Zacks, had a quote in his discussion on Fabrics. The quote made me think of what we are doing with Enterprise NFV so will borrow it. Steve Jobs, who was actually quoting Alan Kay, said, “People who are really serious about software should make their own hardware”. I’ll be adding another posting as we get closer to CiscoLive Las Vegas in July 2016 with a lot more detail on this point.
Hopefully that helps shed some light on the differences.
Wrapping it up
The Cisco Enterprise NFV solution is built to be the next evolution of deploying network and applications services using automation and programmability to simplify turn up and on-going management. Along with many other technologies and innovative approaches, it leverages virtualization. However, in the solution, virtualization is just one tool used to achieve the end result.
In a technical whitepaper located here Enterprise NFV Whitepaper, my friend and colleague Cisco Distinguished Technical Marketing Engineer Matthias Falkner and I provide and overview of the solution and guidance for when you would use each type of platform. Also, I’ll be giving two new deep technical sessions on Enterprise NFV; one technical breakout (BRKCRS-2006) and one hands-on lab session (TECCRS-3006) at CiscoLive Las Vegas July 10th to July 14th this summer.
When combining these hardware options with NFVIS, the result is a pretty powerful NFV platform. You can get more information on Enterprise NFV via these resources:
- Mar 22, 2016 @10am PT, @1pm CT webinar: Exploring the Advantages of Enterprise Network Functions Virtualization. Register
- http://www.cisco.com/go/enfv
- Watch this overview video to learn more.
- Enterprise NFV white paper
- Enterprise NFV Infrastructure Software Blog
