Writing about SDN is like nailing jelly (jello, for my American readers) to a wall. Just when you think you have a grasp on it at last, it slips away and you find yourself in a right mess. As one of my friends joked, the initials may as well stand for Says Definitely Nothing.
Is this because of — or despite — SDN’s long list of potential benefits? These run from centralized and dynamic policy management to a more agile architecture that is much better suited to today’s evolving network traffic patterns, with lots more in between. So why has it not taken off faster?
Part of the problem is that while SDN is probably the least immature of the many software-defined schemes, that does not make it mature. Nor is it well-defined — some would argue that the Cisco/Insieme Application Centric Infrastructure, which is designed to work with legacy Cisco equipment and defend the Cisco installed base, doesn’t really count as SDN, for instance.
Others say that the hypervisor overlay route championed by the likes of VMware, Microsoft, and IBM doesn’t go far enough either. And then we have the newest option, the more purist OpenDaylight framework, which for some will be a step too far! Described as an “open platform for network programmability”, OpenDaylight interfaces between the high-level apps and the network devices, and potentially lets the former reconfigure the latter directly.
Plus, these various implementations of SDN are all different things. Sure, they share certain ambitions, but they also share many of those ambitions with VLANs and UAC 2.0.
Once you step beyond those basics and enter the realm of ‘pure SDN’, the next problem is that it needs a Big Bang approach. The minimum practical and sensible deployment is whatever is the smallest network site in your organization — and the ideal deployment is a green-field site rather than a brown-field one. After all, if you try running an SDN infrastructure alongside a traditional one you risk doubling the management load, rather than decreasing it.
So we have vendors tripping over themselves trying to ensure that a version of SDN — or something they can call SDN, at least — will work in hybrid networks too. Drop this into your existing infrastructure and get a more agile network, they cry.
It is no surprise therefore that only a tiny number of organizations reported deploying SDN into production networks during 2013. I expect a large proportion of enterprises will at least trial SDN during 2014, though, and that quite a few will actually deploy SDN-type technologies — which is to say, stuff that helps you virtualize the network to better connect with your virtualized servers and storage. A good example might be the recent announcement that Canadian service provider Cloud Dynamics is using Juniper Networks’ Contrail SDN software to automate and virtualize its cloud network across its Toronto data centers.
Could it become viable for smaller organizations, too? At the moment that seems less likely, not least because the potential benefits are mostly enterprise-level, and they rely on enterprise-level thinking. Put simply, in most smaller organizations (and quite a few larger ones) the bean-counters are not going to give budget approval for something unless it offers hard financial savings, which in this context probably means that it will enable you to cut a £50,000 a year network engineer.
But even if your organization is big enough to have several such network engineers, the chance of SDN actually saving you money looks increasingly unlikely. Instead, it is more probable that you will end up paying the same but allocated in different ways. In particular, the balance between CapEx and OpEx will shift as vendors move to consumption-based pricing models. (That at least might please the bean-counters, as they usually prefer OpEx to CapEx.)
So how do you justify and get approval for an SDN project? The most obvious route is when starting from scratch with a new site, but if you are lucky enough (for varying values of ‘lucky’…) to hit a refresh point on an existing network, you can also afford to see what new options you have.
The other route is likely to be when you have a major problem to solve. This is really where SDN scores — where changing demands and traffic patterns have outstripped the ability of conventional infrastructures to deliver. Where the traditional route of over-provisioning to meet demand peaks and overcome congestion would simply be too expensive, or where server virtualization, M2M (machine-to-machine communications), and the cloud are demanding east-west bandwidth from a network set up to deliver north-south. It is certainly where the first few real deployments are happening.
Beyond that, SDN will eventually become the norm — for higher-end campus and enterprise networking gear, at least. Centralized and automated management is increasingly the default or expectation for wireless networking, and network managers should be asking why the same is not true of wired networking. SDN can also automate the creation of new paths and meshes across an organisation or network, for example to create a link for a video call and then break it down again once it is no longer needed.
Then it is a question of when SDN becomes the norm for the WAN as well. Given how important the WAN connection is in most organization’s networks, both for linking company sites to each other and for connecting users to the application, collaboration and information resource that is the Internet, the reconfiguring of the WAN is long overdue.