While software-defined networking (SDN) and network function virtualization (NFV) don’t necessarily require each other to add value to an enterprise, they are collectively being joined at the proverbial hip. The fact is many network administrators have resisted SDN because it requires them to learn new programming skills. But once physical network appliances start to be replaced by NFV, it’s increasingly clear that the proliferation of NFV will finally force the adoption of SDN.
From both a capital expense and operational cost perspective, NFV is just too compelling an advance for IT organizations to ignore. Instead of having to acquire, deploy, and manage a plethora of physical appliances, most network and security functions going forward will be deployed and processed either on x86 servers or some other type of commodity processor. NFV will in turn be programmatically managed via SDN in a way that servers will create much higher levels of scale at a significantly lower total cost of ownership (TCO).
In fact, a recent market research report published by ACG Research suggests the total cost of ownership (TCO) of NFV versus physical appliances could be as much as 62 percent lower. Return on investment (ROI) for the NFV transition will range from 33 percent in the first year to more than 350 percent by year five of a deployment, says the report.
Naturally, the amount of ROI that is achieved will be heavily dependent on how extensively an organization opts to make use of both pre-integrated NFV/SDN platforms as well as lower cost white box switches, also known as brite boxes, which cost substantially less than proprietary network infrastructure. The one thing that is for certain is that NFV and SDN have a symbiotic relationship, which tends to increase the total ROI in direct proportion to how much they are employed in concert with one another.
In the meantime, the most important thing for IT organizations to focus on is the vested interest they have in making sure they don’t get locked into any specific NFV/SDN implementation. One of the primary reasons to embrace NFV software in the first place is to be able to take advantage of innovations more rapidly as they occur. Being able to swap one NFV implementation for another will require strict adherence to open application programming interfaces (APIs) that enable integration across multiple SDN environments.
In addition, IT organizations will also find themselves trying to support hybrid cloud computing environments where, for example, they are trying to deploy the same NFV software in a cloud as they are in an on-premises IT environment. Given the disparate physical and virtual networks involved, that goal is only going to be achievable by employing an open federated SDN/NFV framework.
In time, IT organizations will have their choice between programmatic and declarative approaches to SDN/NFV frameworks that require less reliance on programming skills. In some instances, NFV may be deployed by a network administrator. In other cases, an application delivery controller (ADC) in the form of NFV software, for example, might simply be invoked via a self-service portal by a developer. Regardless of the path pursued, open APIs will be the key to maintaining a flexible IT environment.
What is clear is the combination of NFV and SDN will have a profound impact on networking. The challenge will be to make sure that IT organizations do not bring any legacy networking baggage into the virtual networks of the future.