• 10/20/2015
    8:00 AM
  • Rating: 
    0 votes
    Vote up!
    Vote down!

Why The Business Needs SDN

Software-defined networking provides network programmability, which helps contain operational costs and enables business growth.

Ultimately, programmability of the network will be critical for business growth. The traditional methods of management -- device by device and system by system using manual methods -- simply cannot scale at the rate required today. Consider that in 2014, according to Computer Economics, the median network device to engineer ratio was 37 to 1. In 2015, that number was 59 devices per engineer, a jump of 60% in a single year. If that rate holds, engineers will be overwhelmed in short order or business will see its IT budget for the network skyrocket. 

Neither is a desirable outcome. Automation via network programmability (adopting a DevOps approach for the network) is one of the ways in which IT can combat the costs associated with rapid growth without burning out engineers.

This is why software-defined networking is not only good for the network, but for the business. With SDN, we’re making the network programmable. And when we take a deeper look at what it means to make the network programmable, we find that it involves both the control plane and the data plane and that both are valuable in containing costs and enabling business growth.

The classic, OpenFlow-based definition of SDN offers programmability for both planes, though we tend to focus on the control side. In that respect, OpenFlow offers a protocol-based means to essentially reprogram the path of any packet, at any time. Operators can programmatically instruct switches and routers (and really any OpenFlow-enabled device on the network) to change routes in addition to a limited set of other actions.

Other SDN-solutions offer similar capabilities -- that of programmatically modifying the device’s behavior -- but instead of relying on OpenFlow, they offer APIs. These APIs provide the means to provision, configure, and manage those devices from a centralized command-and-control console. These are the APIs that are used by a growing number of data center automation and orchestration providers (think Puppet and Chef and SaltStack) to support network infrastructure along with application infrastructure.  

Regardless of the form it takes, both are examples of network programmability of the control plane. Control plane programmability is the basis for reducing operational costs by shifting the burden of configuration and management from people to technology via automation.

The data plane, too, is enhanced by SDN with programmability. Both classic and evolving SDN solutions provide for data path (plane) programmability. In the classic OpenFlow SDN, the provision is made for “apps” or “plug-ins” to the SDN controller via a standard API that can interact with and change the behavior of the network based on the real-time flow of data. Security plug-ins, for example, are quite popular among those building these apps and capabilities such as IDS/IPS are often seen as add-ons for SDN controllers.  

Other devices -- usually up the stack -- whose network services focus on the stateful layers of the network (4-7) also provide for data path programmability. This programmability is generally more along the lines of what developers would consider programmability, requiring the use of some sort of scripting language to interact with and modify traffic in the data path in real-time.

Both control and data plane programmability are desirable characteristics of network services and devices. Control plane programmability, however, is generally the more useful to the broadest set of organizations as it is what enables the automation and orchestration that leads to greater stability and reduced operating costs. Whether it’s via OpenFlow or APIs, the ability to automate the provisioning of services increases the velocity with which those services can be deployed, but has the added benefit of providing consistency (and thus repeatability).

Codifying the tasks and processes necessary to provision and configure all the various network services required by an application provides a foundation for moving toward a truly software-defined data center in which the full stack is offered as a service, enabling ops to self-serve for all but those services requiring physical changes to the network.

Data path programmability offers a platform for rapidly deploying a new service or modifying an existing one. This is particularly important to organizations in the realm of security when vulnerabilities crop up that are difficult to address in a timely manner. Heartbleed, for example, targeted not applications, but the platforms on which those applications were deployed. An organization may have had hundreds of vulnerable web/app servers, requiring hours if not days to patch and secure. Data path programmability offers many organizations the ability to programmatically detect and stop attempts to exploit this vulnerability.

Both control and data plane programmability are critical characteristics of a modern network, one that enables and supports the rapid growth of business and applications. Without network programmability, a business faces getting dragged down  in operational costs due to the explosion of devices and services needed to support those applications.  



Hi Lori -- Do you think C-level executives are aware of these business benefits of SDN?


I think there's an abstract understanding of the benefits. There's been a good effort at promoting the various benefits of SDN from an operational and business point of view, but there's less available describing how those benefits are derived from the technology. The "why" SDN lowers costs, or improves time to market or increases stability of the environment. It's easy to say it does but I think budgets are such - and the network critical enough - that you really have to dive deeper into how it's going to achieve those business benefits to encourage greater adoption. 


Agreed, the IoT alone is expected to add billions of devices to the network in the next few years, without SDN it seems impossible because of the cost and/or availability of skilled network professionals. If we plot PCs, mobile devices and IoT devices on a single line, it seems that the further down an end-user is on the line, the greater is the user's requirement to experience a plug and play environment. This leaves the network engineers responsible for security and connectivity. 


Good article. Yes, SDN is the future and it is now. We need it, but do we have it ?

There is the question. Do we really implement what we need ?

Death of cables. birth of IoT

Have any of you looked into and or heard about ubiquiti networks? They are on pace to globally link wifi, a solar grid, and IoT. Im honestly shocked a search on this website has no articles whatsoever leading back to ubiquiti networks. The fact that I havent really talked to anyone else who knows SunMAX even exists and is being manufactured by Ubiquiti Networks, tells me alot.  Keep on with that cisco!!~

 This is not a network hardware company, they are just smart enough to let us beta test their backbone??