The answer depends on your definition of SDN.

There have been several vibrant discussions via Twitter of late on the relationship between SDN and DevOps, with some calling for a distinction to be made by referring to the marriage of the network and DevOps as “NetOps”, others dismissing that as unnecessary, and a whole lot of enthusiasm on all sides.

Couple that with the revelation that nearly 40% of network professionals recently surveyed by Network Instruments have determined that SDN is “undefinable” and it’s no wonder we can’t definitively establish if there is or is not a relationship between SDN and DevOps.

As Vizzini told Inigo Montoya in the Princess Bride, it’s time to go “back to the beginning” and look at the relationship from the perspective of the problem SDN is trying to solve in the first place. And not the problems vendors put forth as being solved by SDN, but the problems the market wants SDN to solve.

What Problem is SDN Trying to Solve

A good place to start exploring what that might be is the Open Networking User Group (ONUG) and its recent white paper authored from the ONUG Board of Directors, “Open Networking Challenges and Opportunities.” The authors clearly state what it is they expect out of “open networking” (which includes SDN) and then smoothly ties to that DevOps and other operationally-focused concepts:

“The key pain point open networking must address is the configuration, operations, and management challenges of current networks. Studies indicate that up to 80 percent of network engineers’ time is spent performing manual configuration. From an IT perspective, the network has become the problem; for example, it takes seconds to minutes to configure a Virtual Machine (VM), but days to weeks to configure the network and associated Layer 4-7 appliances. Open networks with SDN software can develop an orchestration stack and significantly reduce network deployment times by leveraging open DevOps (e.g. Puppet, Chef) and other Linux based capabilities.”

While there are elements sprinkled throughout the paper that carry the original essence of SDN with it, namely the decoupling of control and data planes across the network, the majority of the requirements from this community fall squarely into solving a specific pain point: accelerating network service provisioning. And not just network as in layer 2-3 (routing and switching) where OpenFlow-based SDN focuses, but the rest of the network: layers 4-7 where firewalls, load balancers, identity and application access reside. Services critical to the successful deployment of an application that take up the bulk of the deployment lifecycle.

DevOps is, to be sure, as much misunderstood as SDN (as was cloud in its early days) but inarguably one of its goals is to improve application deployment across a variety of measures, including time to market and deployment frequency. Which is exactly what’s being required above – improving the time to market by reducing the time it takes to provision network services. All network services, not just a subset.

If we look at where the actual market wants SDN to be based on ONUG’s dissertation, it’s not about packet processing and OpenFlow. What the market actually wants is a DevOps approach to provisioning network services to reduce both the time to deploy all those layer 4-7 services and the time spent performing manual configuration. There are, right now, two emerging SDN camps: one focused on packets and the other focused on process. The former holds tightly to the original (and allegedly official) definition of SDN and takes it quite literally by focusing on dynamic, programmable packet processing. The latter looks at SDN as an opportunity to operationalize the network; to apply concepts of consistency, predictability and repeatability to network service provisioning by focusing on optimizing and orchestrating processes.

The difference between DevOps and what ONUG is proposing is that DevOps is focused on operationalizing application deployment and SDN is focused on operationalizing network deployment. Both recognize the need to treat infrastructure as code, for standardization on common platforms to reduce the variation that in part contributes to higher error rates, and to automate configuration to reduce the operational costs associated with application deployments.

So is SDN the equivalent of DevOps for the network?

If it isn’t, it should be.