What "Software Defined" Actually Means

There seems to be a pretty widespread belief held by many IT practitioners that “software defined” stands for something that can be dynamically configurable or something that offers all or most of its administration functions via API. While you won’t hear an argument from me against the fact that these are necessary features of “SDX” (software defined something), it’s a mistake to look at them as sufficient.

The term “software defined” first appeared in the context of networking and applied to a new paradigm in switches and/or routers.

Traditionally these units are built as relatively monolithic hardware devices. Their logical structure however can be viewed as consisting of 2 parts: data plane and control plane.

Data plane is where your data packets between hosts on the network are traveling on their way from point A to point B. Algorithms here are relatively straightforward, uniform, sensitive to speed and they rarely if ever need to change drastically - in short, a perfect candidate to be implemented in hardware.

Control plane however does not share these characteristics. As networks become more sophisticated, algorithms here can be pretty complex (and complexity often leads to bugs that need to be fixed). Algorithms here are far from uniform because they are expected to support a wide range of use cases and deployment scenarios. And they could be very dynamic.

The whole point of SDN was to realize that control plane is not a good match for rigid hardware. The idea was to implement each plane on top of something that is ideally fit for its characteristics - hardware for data plane, software for control plane.

This explains “software.” Let’s explain “defined” now.

Even in the past, you could control your network devices programmatically and they had extensive capabilities to reconfigure themselves dynamically. While this was not a intended use case and usually was an afterthought, it still was not impossible. But no matter how you did it, you still ended up managing an inflexible control plane within hardware. What SDN did was eliminate control plan from hardware. In SDN, there is no control plane within hardware - it’s all outside of hardware, implemented in software.

In SDN, there must be a clear deliniation between data plane and control plane. Data plane does not make any decisions by itself. It only performs its work and feeds runtime data to control plane and accepts commands from the latter. There can be no commands from data plane to control plane.

For example, you hear a vendor introduce API and describe it as SDN. You start digging and find out that their API is just a facade to their old control plane that still lives in hardware intermingled with the data plane such that they essentially form one inseparable piece. Is this a true SDN? No.

To sum up, “software defined” is an excellent term (not a misnomer) and it actually stands for some important design principles - separation of data plane from control plane and control plane being implemented in pure software.

All “software defined” is automation and dynamic reconfigurability but not all automation and dynamic reconfigurability is “software defined,” no matter how much marketing departments may want you to believe otherwise. <blockquote class="twitter-tweet"><p>“software defined X” is to X what a google self-driving car is to a car</p>— Dmitriy Samovskiy (@somic) January 2, 2013</blockquote>

Categories: cloud-computing |