The irrelevance of hardware to network service provisioning speed

#devops #sdn #virtualization #nfv #sdas Hardware isn't the problem.

Inarguably, the pressure is on "the network" to get in gear, so to speak, and address how fast its services can be up and running. Software-defined architectures like cloud and SDN have arisen in response to this pressure, attempting to provide the means by which critical network services can be provisioned in hours instead of days.

Much of the blame for the time it takes to provision network services winds up landed squarely on the fact that much of the network is comprised of hardware. Not just any hardware, mind you, but special hardware. Such devices take time to procure, time to unbox, time to rack and time to cable. It's a manually intensive process that, when not anticipated, can take weeks to acquire and get into place.

Enter virtualization, cloud, containers and any other solution that holds, at its core, abstraction as a key characteristic. Abstraction all but eliminates the time it takes to procure hardware by enabling software to be deployed on any hardware, making the procurement process as simple as finding an empty server in the data center. After all, the majority of networking functions are just very specialized software running on very specific hardware.  Decouple the two and voila! Virtualized, containerized or cloud(erized) networking. Instantaneous! No more waiting for the network. Just push a button and you're done.

Only you aren't. 

See, that's not counting the time it takes to actually provision and configure the desired services.

Most of the lamentable time it takes to provision network services has absolutely nothing to do with the underlying hardware. Whether it's commoditized off the shelf hardware or custom designed silicon makes no difference whatsoever in the actual time required to provision network services.  Both proprietary and commoditized hardware support a layer of abstraction - of virtualization - that enables them to be sliced and diced into discrete, consumable chunks of computing power. Within that "container" are the actual network services that need to be deployed to provide the breadth of network services required to keep today's applications scalable, secure and fast enough to satisfy both consumers and business constituents alike.

To point to "hardware" as the primary impediment in rapidly provisioning these services is ludicrous. The hardware has nothing to do with the configuration of the minute and complex details associated with any given network service today. The slowdown is in the configuration of the services and the complexity of the topologies into which such services must be deployed. 

This is the nature of application-focused networking. Each service - in addition to the nuts and bolts of IP addresses and VLANs and DNS entries - requires specific settings to ensure the network is able to provide the services upon which business rely to deliver applications. An optimized TCP stack for one application can mean disastrous performance for another. The specific application security details that protect one application may result in gaping holes in yet another application and completely break the functionality of another. The route one application takes through the network may provide excellent performance for one application but introduce unacceptable latency for another.

It is this reality with which network service configuration is concerned and why services absolutely must be application-driven with respect to their particular configuration. One size does not fit all when it comes to applications.

And thus it is these configurations - not the underlying hardware model - that impede service provisioning in the network and slow down application deployments. Manually flipping a bit here and a byte there and writing rules that deny access to that device but allow it from another are time consuming, error prone and terribly inefficient.

Virtualization of network functions a la NFV is only a panacea when one is deploying services that can be configured exactly the same, every time. That happens to be a model which works for service providers, who are concerned with scaling out specific functions in the network and not necessarily supporting new application deployments. In the enterprise, where the focus is on delivering individual applications with their own unique performance, security and reliability profiles, virtualization is nothing more than a means of squeezing out a greater economy of scale across existing hardware resources - whether commoditized or not.

Enterprises whose continued success relies on the fickle and highly volatile demands of consumer-facing applications are not so fortunate. Each network service must not only support the basic needs of an application but provide value in terms of improving performance, ensuring security or maintaining availability. To do that, each service must be tailored to the application - and sometimes to each client device - in question.

That takes time, and whether that service is deployed on a piece of commodity or custom hardware is irrelevant. The configuration is accomplished in software, which is the same whether running in a container, a virtual machine, or in plain old software daemon form.

That's why operationalization of the network is so critical to improving the alacrity with which application deployments are concluded. Going "virtual" isn't going to change the requirement for provisioning and configuration of the services, it only addresses the underlying process of acquiring and provisioning the appropriate resources.