NETWORKING

  • 04/02/2015
    8:00 AM
  • Rating: 
    0 votes
    +
    Vote up!
    -
    Vote down!

Yes, NFV Is Important For The Enterprise

Due to its origins and complexity, it's tempting to view network functions virtualization as a service provider technology. That's not the case.

Network functions virtualization (NFV) is a concept that erupted just a year and a half after the Open Networking Foundation (ONF) started talking about software-defined networking (SDN). The initial proponents of NFV were major service providers that tried to get network services components that would allow them to build more agile networks at lower costs. They formed an Industry Specification Group within the European Telecommunications Standards Institute (ETSI), which eventually created a number of documents, including the pretty complex NFV Architectural Framework.

Looking at the context in which NFV started, the standardization organization where work takes place, and the complexity of the NFV standard documents, one is tempted to conclude that NFV applies primarily to large service provider environments and has nothing to do in a typical enterprise environment.

Nothing could be further from the truth -- we just need to look at NFV creatively, take its best principles, and forgo the complexity of large-scale fully automated environments. 

Which NFV principles are usable in an enterprise environment?

Let’s start with the Wikipedia definition of NFV:

Network Functions Virtualization (NFV) is a network architecture concept that proposes using IT virtualization related technologies to virtualize entire classes of network node functions into building blocks that may be connected, or chained, to create communication services.

In layman terms, NFV is all about deploying network functionality (routing, firewalling, load balancing, WAN optimization, etc.) in virtualized environment (virtual machines or Linux containers). Does that apply to enterprise environments? Of course!

A typical enterprise data center has a number of firewalling and load balancing devices. They are usually implemented as physical appliances with fixed performance. Most enterprises buy these appliances as part of a major project, or as part of a new data center deployment -- in both cases buying appliances that are way beyond current needs to ensure the future increase in traffic won’t overload the appliances.

When a physical appliance fails, you cannot simply restart it on different hardware; you have to order a replacement part, which arrives in few hours or days. In the meantime, your data center has to remain available, which forces you to buy two appliances of the same kind.

In short, we commonly end up buying a pair of 10 Gbps firewalls or load balancers to support 1-2 Gbps of traffic… just because we might see increased traffic in the future, and because one of the devices might fail.

Enter the brave new world of network function virtualization. Most network appliance vendors already offer their solution in virtualized format. You can deploy those virtual machines on any hardware (although I would recommend using high-quality servers to deploy mission-critical infrastructure services), move them around at will, and automatically restart them if they or the underlying hardware fails.

Even more, you can easily move a virtual appliance to a different data center together with the associated application workload, making disaster recovery process way simpler than it was in the days of physical appliances.

Does it work?

Short answer: Yes. Will a firewall or load balancer implemented in virtual machine format give you the same performance as a physical appliance? It depends. To learn more, make sure you drop by my presentation on What NFV Means to the Enterprise on April 30 during Interop Las Vegas, and if you want to know more about other enterprise benefits of NFV, join the half-day workshop Simplifying Application Workload Migration Between Data Centers on Tuesday, April 28.

Finally, there are other interesting uses for NFV in enterprise environment -- you can use it to simplify remote site setups. Interested? You’ll learn more on April 30.


Comments

NFV in the enterprise

Ivan, thanks for this practical perspective on how NFV can help in an enterprise data center. I have usually thought of NFV in the service provider context. I'm interested in hearing about the performance ramifications of using a virtual machine format vs. an appliance at your Interop presentation.

Re: NFV in the enterprise

Aside from the cost savings the real key to NFV is the performance attribute. If you are happy and satisified with the use of your server type assets to perform at an accecptable and scaleable SLA over purpose built applicances with the custom asics/processors then it makes good business sense. However, for some low latency shops the purpose built solutions need to stay and for other shops there may be a mix. The real trick is finding the right combination of general HW for NFV that matches or exceeds the performance and scalabilty of purpose built solutions and you are good to go.

Re: NFV in the enterprise

Hi Jeffrey, thanks for chiming in here. Given the performance of commodity hardware, do you see many scenarios where NFV can play a major role in an enterprise environment?

Re: NFV in the enterprise

Funnily enough, I had been intending to comment on the post about SD-WAN that one of the interesting related use cases for these kinds of solutions is not only to manage the WAN, but also to be able to push out functions to remote sites without requiring special hardware. For example, a basic site might use a simple appliance for SD-WAN control. For a larger site, ship a half decent commodity server and use it not only to run the virtualized SD-WAN software but also to offer NFV-type services like firewalling, content acceleration, load balancing, IDS/IDP and so on. Deploy it on demand, virtualized, and use service chaining / insertion within the virtualized environment to be able to turn services on and off with relative ease. If we can get this kind of thing going, it has the potential to be super cool. To Ivan's point above, rather than buying a pair of 10GB firewalls for 1-2GB of traffic, push the policies out to the egde and then you only have to handle 100MB of traffic in the first place, rather than deal with the painful consequences of centralizing these capabiilties.

Re: Yes, NFV Is Important For The Enterprise

It's nice to hear someone come out and take a potentially-contrarian position in no uncertain terms, and defend it so well. That is, I think many analysts would refuse to even admit the position you start with here, Ivan - that many enterprises have yet to see what benefit NFV has for them. Many are inclined to ride the hype train and bypass that question completely in favor of promoting growth in the space - which is perhaps commendable in it's own way, but more than a little disengenuous. You sound here like you're advocating for the enterprises that are unsure, which I think is a smart bet - many of those looking to attend an Interop presentation on the matter probably fall into that camp. They need pragmatism, they need a crash-course approach, and they need it to be results-oriented. Good stuff.

I've heard from lots of people that were intitially nervous that the automatic failover capabilities afforded by NFV have been the single greatest cost-saving measure of their implementation, and make it worth the effort on it's own. As you go some way towards suggesting, even enterprises that don't have the manpower or resources to build this out themselves are not stranded. There are plenty of great options from vendors both for specialized hardware purpose-built for NFV and great prebuilt software solutions that streamline the process and only require you to plug in that which is specific to your needs. Not to mention the great dedicated support you can get as part of that for staff that might not be one hundred percent ready for the switch. Once again, conferences like Interop where you can meet others pros in the same boat also have an important role in this process.