WAN on a Software Timeline
WANs are slow. Not in terms of data rates and such, but in terms of change. In most enterprises, the WAN changes more slowly than just about any other part of the infrastructure. People like to set up routers and such and then touch them as infrequently as possible—and that goes both for enterprises and for their WAN service providers as well.
One great benefit of SDN, SD-WAN, and the virtualization of network functions (whether via virtual appliances or actual NFV) is that they can put innovation in the network on a software timeline rather than a hardware timeline. IT agility is a major concern for any organization caught up in a digital transformation effort. Nemertes’ most recent cloud research study found a growing number of organizations, currently 37%, define success in terms of agility. So, the speed-up is sorely needed. This applies whether the enterprise is running that network itself, or the network belongs to a service provider.
When the network requires specialized and dedicated hardware to provide core functionality, making significant changes in that function can take months or years. Months, if the new generation of hardware is ready and “all” you have to do is roll it out (and you roll it out aggressively, at that). Years, if you have to wait for the new functionality to be added to custom silicon or wedged into a firmware or OS update. If you are an enterprise waiting to implement some new customer-facing functionality, or a new IOT initiative, waiting that long can see an opportunity pass. If you are a service provider, having to wait that long means you cannot offer new or improved services to your customers frequently, quickly, or easily—you have to invest a lot, between planning for and rolling out infrastructure to support your new service, before you can see how well customers take up the service.
When the network is running on commodity hardware such as x86 servers and whitebox switches, you can fundamentally change your network’s capabilities by deploying new software. Fundamental change can happen in weeks, even days. Proof of concept deployments take less time, and it is easier to upshift them into full deployments or downshift them to deal with problems. Rolling a change back becomes a matter of reverting to the previous state.
Whether enterprise or service provider, this shift lowers the barrier to innovation in the network, dramatically. It becomes possible to try more innovations and offer more new services with a much lower investment of staff time and effort, a lot less money up front, and with a much shorter planning horizon. The organization can work more to current needs and spend less time trying to predict demand five years in advance in order to justify a major capital equipment rollout.
For enterprises, shifting to a software-based networking paradigm (incorporating some or all of SDN, SD-WAN, virtual appliances and/or NFV) allows in-house application developers unprecedented opportunities to affect or respond to network behavior. For service providers, it means being able to more quickly meet changing customer needs, address new opportunities, and use new technologies as they become available.
Of course, making a shift as fundamental and far-reaching as moving from legacy to SDN, from specialized hardware to white boxes, is not trivial. But it should be on the roadmap for every organization, for all the parts of the network they run on their own; it should be a selection criterion for their network service providers as well.