The state of SDN – have we reached the tipping point?

The notion that we’re on the edge of widespread SDN (software-defined networking) adoption has been rumoured for years now. It seems there’s always a new report on when SDN will catch on and how big of a success it will be. Research and Markets recently stated that the SDN market will be worth $9.5bn by 2023 and predicted a 43 per cent CAGR by 2023. While reports like this are usually over optimistic, it raises the question of whether we have reached the tipping point of SDN.

SDN is still largely in the testing phase, being used predominantly in proof-of-concept projects. While that means it hasn’t found much of a home in commercial projects, it also means that widespread adoption can’t be too far behind. A lot depends on the success of the PoC trials, but it’s worth noting that there are myriad other obstacles that SDN will have to overcome en route to its journey within enterprise networks.

Obstructions to SDN adoption

Maybe the expectations for SDN deployments were too high early on. Hype trains lead to rampant optimism and misunderstanding, in this case leading people to believe that SDN was some kind of network elixir. Unreasonable expectations can quickly stunt the growth of new technologies.

SDN won’t achieve anything by itself. Intelligently deploying it on top of the right infrastructure will. SDN deployments aren’t easy – they require the rigorous testing of the software’s interoperability on top of various network architectures. As you can imagine, that testing represents a significant barrier to entry. However, once SDN is used broadly, the benefits for all SDN users will increase in tandem. SDN is struggling to wriggle out from the shadow its own hype was cast in, but once expectations are tempered a bit, SDN should impress with its own merit.

Because SDN is largely still in the testing phase, there are limited use cases to point to. This makes it difficult to convince potential adopters to integrate it with their own networks. Everyone knows that SDN works, but it’s the lack of a concrete, fully-deployed use case that’s impeding its proliferation.

The lack of a pure use case makes the benefits of SDN hard to prove. It primarily benefits network efficiency, while profits are mostly made from applications. It’s obvious that the system handling the applications is just as important as the applications themselves, but the importance is less easy to measure than technology that directly benefits applications. Also hard to measure are the cultural obstructions to SDN adoption.

Most current network engineers are hardware operators and SDN requires software developers. That kind of disconnect is causing strife in the industry – engineers have to learn new skills or be displaced as SDN continues to gain acceptance. Network incumbents don’t want to have to re-train all of their engineers, nor do they want to give up their market share. Major network vendors deal in both hardware and software, and switching out one piece of their vendor lock-in puzzle destroys the whole thing. It’s in their interest to hold on to their proprietary stacks as long as they can, but even they are being pushed into developing for SDN’s inevitable future.

Unfortunately, these same vendors are adding software to the SDN ecosystem that could be described as devoutly anti-standardisation and pro-differentiation. We can talk about the various obstructions to SDN all we want, but the biggest issue is the lack of a single protocol or standard that will push people past arguing, experimenting, and differentiating, and into widespread deployment. The more SDN proliferates, the more standards will present themselves, but we could all save ourselves a lot of time if we could agree on an interoperable protocol early on.

How to accelerate SDN adoption

There’s no question that at some point, SDN will reach widespread adoption. It’ll be deployed to reduce costs and increase revenue once the testing proves that it can. Any testing environment that proves either of these goals will go a long way toward accelerating the adoption process.

Service-oriented architecture can assist SDN’s implementation by framing the debate around application delivery instead of the network itself. As we established earlier, since applications are the money makers, network improvements frequently come as an afterthought in the enterprise. By implicating the network whenever we discuss application delivery, we should be able to re-frame the discussion with an understanding of the network’s importance.

Applications are increasingly programmable, meaning they can automatically communicate what they need from the network. If an app needs to be redirected, or if it needs sudden bandwidth or storage provisioning, the network should be able to react to that demand. SDN is capable of orchestrating this dynamic response. Enterprise network operators need to understand that since applications are the money makers, they need the best network they can get if the business is to continue its success. And if SDN is really going to be a factor in the enterprise, there has to be some kind of coherent protocol that everyone can understand and work toward improving.

SDN needs a protocol like OpenFlow to manage the flow of traffic through the network, but industry experts can’t seem to agree on a single protocol, or an interoperable protocol to work with. Eventually the protocols will standardise, but at the moment it’s a sandstorm. OpenFlow, while it had widespread utilisation at one point, has fallen out of fashion. The lack of interoperability from iterations of the protocol forced developers to create their own. This had led to a dwindling OpenFlow user base and the current diffusion of various protocols throughout the industry.

Open source is about collaboration – using the best modules to stitch together something more than the sum of its parts, and SDN has to come from the same perspective. Without a unified, interoperable standard, the work behind SDN is a waste of time. SDN has been designed to improve the flow of data across various networks flexibly, while also being able to reroute traffic based on the needs of the moment, but if traffic will be funnelled into a proprietary bottleneck, what’s the point? 

It’s like buying a Ferrari and driving it towards a wall.

Jay Turner works as Vice President, Development and Operations at Console
Image source: Shutterstock/violetkaipa