The easiest answer would be the vendors. My first NFV experience goes all the way back to Cisco Unified Communications Manager (CUCM). This product used to run only on Cisco Media Communications Servers (MCS). The installation routine was very thorough in checking for the proper hardware. Even having a CPU that was a few megahertz too fast would halt the process.
The dependence on third parties to manufacture those servers began to sour over time for Cisco. It also took too long to certify new hardware to run newer releases. That's when Cisco started allowing CUCM to be virtualized in VMware. Today, you can run CUCM on almost any hardware inside a virtualized container.
Vendors want agile software that can be rapidly redeployed to meet changing customer needs. A failing hardware appliance in a data center is a displacement target for the competition. Customers want their network services to be able to grow to fit new data center rollouts.
[What’s the future for hardware ADCs in a virtualized world? Tom Hollingsworth makes some predictions in “Will NFV Kill Hardware Load Balancers?”]
Faced with a choice between buying an inflexible, fixed-configuration hardware device and a software container that runs on VMware, Hyper-V, or KVM, the choice is usually made very clear by the customer. So, is the customer driving adoption of NFV? While the customer is a loud and clear voice, I think the true driver is someone else entirely.
I talked to Tom Schroer from Dialogic about its line of virtualized telecommunications gear. He told me all about how the company is taking its SIP IP-to-IP gateways and pulling them out of hardware and into virtualized containers. When I asked who was primarily buying those NFV devices, Tom told me the service providers had really latched on to the idea. They were far and away the largest purchasers of the NFV offerings Dialogic had put out.
Service providers know the value of NFV. Instead of retiring an old purpose-built server or bringing management under one GUI, NFV represents opportunity. With an agile software container that can be inserted into the packet flow, providers can now resell NFV devices as a service.
Rather than talk to the budget people inside an organization about allocating capex to buy five or 10 new widgets, service providers can pitch widgets-as-a-service, and customers can use opex budgets instead. You can even use a credit card if you want. Tell us what you'd like from our a la carte menu, and we'll take care of the hard work behind the scenes.
The ability to rapidly deploy additional services to existing customers is a money-making machine. Much like my idea for a VMware NSX app store, I think that service providers are embracing NFV because it opens the door to increased customer spending and makes it easier to provide critical services.
If I own the NFV devices in a customer stack and something goes haywire, my provider staff can quickly absolve the virtual devices of any issues. That prevents SLA violations and allows me to offer additional troubleshooting services to the customer. At the very least, it eases support calls and prevents any finger pointing during post-mortem analysis.
With the service providers leading the charge, I think that NFV will enjoy explosive growth. Customers will be adopt it because it's an easy option to check when filling out a new service order. Vendors will embrace it because they are no longer beholden to hardware vendors. Vendors will also sell the daylights out of it because more and more providers are going to start offering NFV services, either to stave off competition or to capture that discretionary customer OpEx budget.
Is your provider offering NFV services? Or are you going your own route and transforming your old hardware appliances into software? Let me know in the comments below.
[Network overlays are gaining traction as an SDN architecture. Greg Ferro digs into the technology at Interop New York in his workshop “Introduction to Overlay Networking.” Register today!]