Multiple Options For NFV In The Enterprise

SDN may be high on the enterprise’s list of priorities heading into the New Year, but network functions virtualization (NFV) is also poised to remake IT connectivity, even though it is primarily seen as a carrier solution.

Exactly how this will play out, however, is the subject of some dispute. On the one hand, NFV is supposed to provide the same flexibility in infrastructure design and deployment that white box commodity hardware is bringing to the data center. On the other, vested interests in the networking industry appear to be okay with some level of abstraction, but not a fully vendor-neutral framework.

According to No Jitter’s Yishay Yovel, this divergence of views has evolved over the past few years as network carriers started to warm up to the idea of delivering networking services to the enterprise via NFV. The idea was that virtual routers, firewalls, wide area appliances and other devices could be provided more cheaply and with a great deal more flexibility than the fixed hardware solutions most organizations are used to.

What they failed to take into account is that this would require the cooperation of device makers in the form of a common management and orchestration layer to replace proprietary policy engines. Instead, the vendors went with virtual-layer management while reserving the more granular physical-layer management to them. The results were predictable: service providers could only roll out NFV on proprietary hardware, which undermined the business case for carrier-level network services, and deployments slowed to a crawl.

So now we have a situation in which service providers who wish to cash in on enterprise NFV must pursue one of three options: they can try to sell micro services architectures that break the appliance form factor and, by extension, the need for proprietary management; they can leverage existing APIs to create a common management infrastructure, although it probably won’t be as good as the proprietary ones; or they can buy the appliance vendors and incorporate their hardware into the NFV service layer, basically creating what Yovel calls the software-defined carrier (SDC).

It seems, however, that most NFV deployments are aimed at replacing traditional wide area services with new virtual and service-based infrastructure, which would basically provide a new foundation for today’s cloud-facing workloads. But what if NVF proves to be more suitable to an entirely new infrastructure, one in which proprietary solutions have yet to take hold, and in fact probably never will, due to a need for universal connectivity? Maybe something like the IoT edge?

Adva Optical’s Prayson Pate touched on this recently, noting that providers are already using NFV to deliver a range of services to uCPE platforms on the edge. As the enterprise becomes more dependent on the IoT, they will naturally wish to extend this edge network all the way back to the data center. Initially, this will likely evolve on proprietary hardware, but over time, businesses will see the benefits of breaking vendor-specific silos, utilizing generic servers for hosting, and upgrading network services without buying new hardware.

Indeed, if initiatives like DevOps, NetOps, SecOps and all the other Ops continue to take root, it seems like fixed hardware solutions of all kinds are facing a very limited future. Tech analyst Roy Chua noted at the recent KubeCon/Cloud Native Con in Seattle that the biggest disconnect in current DevOps processes is that developers only need to worry about a tiny piece of the network stack (L3) while network and security admins often need time to reconfigure the whole network to accommodate any changes that come out of the pipeline.

What’s needed, particularly in containerized environments, is a Network Service Mesh (NSM) that allows applications or micro services to request key high-level services, such as secure Internet connectivity or remote network transport, on their own. This kind of thing is already emerging in some NFV implementations that are bundling things like service function chaining and network service headers into container workloads running on Kubernetes.

There is still time for virtual networking to play out in all kinds of ways, however. In fact, the very flexibility and customizability of the technology all but ensures that each deployment will be unique to its organization.

But in all likelihood, NFV will come into play somewhere along the line, which means the enterprise needs to figure out how best to leverage the technology for its own needs, not the service providers’ or the vendors’. .― Enterprise Networking Planet