While a lot of vendors profess to have a software-defined networking (SDN) strategy, these strategies tend to vary in coherency. While SDN has its place and purpose in IT service delivery, there is a danger of it becoming a solution in search of a problem. Consequently, it is important to start the SDN conversation with the business case in the first instance, to assess whether the investment now, as an early adopter, is worth the risk.
Why do anything?
SDN is about programmability in the network. But why would we want this? Adding programmability to the network is the first step in moving away from static connectivity and towards the ability to rapidly react to requirements. How did the need for SDN arise in the first place? An excellent example of this comes from the telecommunications industry.
The industry has progressed considerably from staffed telephone exchanges connecting our calls to the cellular telephony we use today.
Present technology allows us to maintain a call even while in transit, maybe on a train or in a car (while using hands-free technology, of course). This is made possible due to the service itself, the telephone call, and not relying on every physical device it traverses.
Learn from cellular handoff
In cellular telecommunications there is a process called handoff. One example of when ‘handoff’ may occur is when the phone is moving away from the area covered by one cell tower and entering the area covered by another cell tower.
With handoff, the call is transferred to the second cell tower in order to avoid call termination when the phone gets outside the range of the first cell tower.
The ability to do this within the data centre would be immensely beneficial. However, this is not something we have achieved in the past without great effort. A rigid network slows a businesses ability to react to increased demand or to roll out a new service.
The rest of the solution
Handoff is fine for cellular services because of the nature of the services. Once a call is made, the properties of that call do not change throughout its duration: a two way street of voice data runs until the call is terminated. This two way street can move cells so long as the flow is not interrupted. The new cell tower, post-handoff, requires no more information than the source and destination of the voice data.
Applications and services running in the data centre exist in changeable states and with varying demands throughout the length of interaction. For example, an HTTP application delivers different media types to the consumer even for a simple web page. At a minimum there are both graphical and text-based data types. More common today is the addition of rich media content (e.g. HTML5) and dynamic scripting technologies that must track state and interaction at all times. With the added complexity of an application, the process of handoff becomes increasingly difficult.
SDN’s purpose is for the underlying plumbing of the network to take instruction and invoke change. However, it is important that these instructions take into consideration the complexities of the applications and services on which they run. Simply implementing a low level, cell-handoff style solution would likely break most data centre services.
If the promise of SDN’s programmability is intriguing, consider the following checklist:
Will all of my applications and services support change? Many organisations are running legacy apps and services that cannot cope with change. They may have been developed under the assumption that the network would always remain static and consistent. This alone could prevent any SDN adoption plans.
We all like a shiny new gadget but ask yourself, is it really necessary for my business? Many organisations don’t have aggressive rollout or upgrade cycles in their data centre. If your data centre operations are relatively static then maybe early adoption of network programmability is not for you.
Do you have the in-house skills to run such a technology? With SDN comes new concepts like SDN Controllers. While the running of your network should become simpler with the maturity of SDN controllers, is the significant change worth the future gains. They may well be but only after evaluating 1) and 2) first.
SDN is an important step towards greater data centre agility and the reduction of delays to business. However, only when adopted in the right circumstances and when coupled with the intelligence of application properties and behaviour will it really make an impact.
Matt Miller is senior manager of systems engineering for F5 Networks in Australia and New Zealand.