Welcome!

Virtualization Authors: Esmeralda Swartz, Kevin Benedict, Alfredo Diaz, Andreas Grabner, Pat Romanski

Related Topics: SDN Journal, SOA & WOA, Virtualization, Cloud Expo, Big Data Journal, DevOps Journal

SDN Journal: Blog Feed Post

Stop Conflating Software-Defined with Software-Deployed

Can we stop confusing these two, please? Kthanx.

Can we stop confusing these two, please? Kthanx.

For some reason when you start applying "software" as a modifier to anything traditionally deployed as hardware folks start thinking that means that hardware is going away. Software-defined networking (SDN) is no exception.

There's a big difference between being software-defined and software-deployed. The former implies the use of software - APIs and the like - to configure and manage something (in this case, the network). The latter implies service functionality deployed in a software form-factor, which could mean pure software or virtualized appliances.

These two are not the same by any stretch of the imagination. Software-defined networking - the use of software to control network devices - is not a new concept. It's been around for a long time. What is new with SDN is the demand to physically separate control and data planes and the use of a common, shared control-plane protocol or API (such as OpenFlow) through which to manage all network devices, regardless of vendor origins.

This abstraction is not new. If you look at SOA (Service-Oriented Architectures) or OO (Object-Oriented) anything, you'll see the same concepts as promoted by SDN: separation of implementation (data plane) from interface (control plane). The reason behind this model is simple: if you abstract interface from implementation, it is easier to change the implementation without impacting anything that touches the interface. In a nutshell, it's a proxy system that puts something between the consumer and the producer of the service. Usually this is transparent to the consumer, but in some cases wholesale change is necessary, as is true with SDN.

abstraction-in-sdx

The reality is that SDN does not require the use of software-deployed data path elements. What it requires is support for a common, shared software-defined mechanism  for interacting and controlling the configuration of the data path. Are there advantages to a software-deployed network element strategy? Certainly, especially when combined with a software-defined data center strategy. Agility, the ability to move toward a true utility model (cloud, anyone?), and rapid provisioning are among the benefits (though none of these are peculiar to software and can also be achieved using hardware elements, just not without a bit more planning and forethought).

The reason software-deployed seems to make more sense today is that it's usually associated with the ability to leverage resources laying around the data center on commodity hardware. Need more network? Grab some compute from that idle server over there and voila! More network.

The only difference, however, between this approach and a hardware-based approach is where the resources come from. Resources can be - and should be - abstracted such that whether they reside on commodity or purpose-built hardware shouldn't matter to the provisioning and management systems. The control system (the controller, in an SDN architecture) should be blind to the source of those resources. All it cares about is being able to control those resources the same way as all other resources it controls, whether derived from hardware or software.

So let us not continue to conflate software-defined with software-deployed. There is a significant difference between them and what they mean with respect to network and data center architecture.

More Stories By Lori MacVittie

Lori MacVittie is responsible for education and evangelism of application services available across F5’s entire product suite. Her role includes authorship of technical materials and participation in a number of community-based forums and industry standards organizations, among other efforts. MacVittie has extensive programming experience as an application architect, as well as network and systems development and administration expertise. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she conducted product research and evaluation focused on integration with application and network architectures, and authored articles on a variety of topics aimed at IT professionals. Her most recent area of focus included SOA-related products and architectures. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.