Trends often get truncated into buzzwords. The buzzword may be important on its own, but the danger comes when its use as shorthand for the broader trend causes confusion. Also, buzzwords often don't explain the motivations behind the trend. A great example is the use of "VDI" as a catch-all for the broader trend towards desktop and application virtualization, which has been motivated by desktop management headaches and security concerns. If you didn't get all that from "VDI", you're not alone.

In this post, I'm going to explore a universe of terms for network programmability and automation. Software-defined networking, or SDN, has emerged as that catch-all buzzword (surprise! Another three-letter acronym), but there's a lot more to this trend. Before we dive into the vocabulary list of related terms, let's review what is motivating the need for network programmability and SDN:

●      Eliminating box-by-box configuration

●      Gaining end-to-end traffic control

●      Managing the network by policy, programmatically (see network programmability)

●      Accelerating time to market with new services (see service-chain automation)

●      Accelerating M&A integration - as Steve Riley reminds us, "every organization on the planet is one M&A away from a renumbering exercise"

●      Adopting cloud services - now you can have a logical network that extends into your cloud provider.

Now, let's take a look at several of the hot terms in this space:

OpenFlow: According to Wikipedia, OpenFlow is "a communications protocol that gives access to the forwarding plane of a network switch or router over the network." If it sounds boring and geeky (to a layperson), it's because in the big picture, it kind of is. It's pretty specific and doesn't - on it's own - solve the bigger headaches of network management. Over time, layer 2-3 routers and switches will probably support OpenFlow (or perhaps some other protocol that wins the standardization war), and we'll all take for granted that OpenFlow and SDN have enabled network virtualization.

Software-defined networking (SDN): SDN decouples a virtual network topology from the physical network, so that upper-layer virtual services can operate as they would in a physical network. When this decoupling happens, the control plane needs a way to communicate with the forwarding plane (physical network), which is where protocols like OpenFlow come into play. Riley argues that the virtualized network is the more interesting destination, and SDN is just the means of getting there. That's like comparing SDN to the hypervisors used in server virtualization - over the last ten years we spend less time talking about the hypervisors and more about what we can do with our virtualized machines. Whether "SDN" goes the way of "hypervisor" will have to play out over time.

If you want to dig into this a bit deeper, and understand how Riverbed fits in, I highly recommend Riley's paper on software-defined networks from a Riverbed perspective (pdf).

The "NFV" term emerged from the network service provider industry - this is important because they are operating multi-tenant networks at a massive scale (motivation). Essentially, NFV is about all those network services that have been delivered as hardware appliances - firewalls, load-balancers and application delivery controllers, WAN optimization, etc. - become virtualized, software-based services running on standard hardware. To illustrate how mature this concept is, note that all of Riverbed's network function products are available as virtual appliances.

Just as with virtualizing servers, virtualizing network functions offers a host of efficiency benefits. But what's implied in many NFV discussions - including this one by Ciena's Bo Gowan (@bogowan) - is that these virtualized network functions (yes, "VNF") will also take advantage of programmability features to enable things like service-chain automation. The automation is what is really game-changing for a lot of enterprises and service providers - NFV and programmability are the critical means of achieving it.

Service-chain automation: The concept of "service-chain automation" actually comes from manufacturing. Businesses have been working on making factories more efficient for generations, but now that's moving to the network. Often building upon network function virtualization (NFV), service-chain automation is about using policies to define the creation, configuration, and execution of network services. This ultimately supports dynamic scaling of those network services.

While OpenFlow and SDN are means to improve network management, automation is an outcome that IT organizations are trying to achieve. In fact, according to a recent survey by Forrester Consulting, 85% consider the ability to customize automation to their needs an important or very important feature of network management and automation vendors. The Stingray Services Controller is an example of the logic required for service-chain automation. It goes beyond the virtual appliance form-factor for ADCs to enable rapid provisioning of right-sized instances of ADCs.  

Network programmability: This is the ability to manage and operate a network and network functions by software, often through application programming interfaces (APIs). It's necessary for service-chain automation, but it provides the flexibility to meet many other forms of automation, customization, and integration. While SDN enables programmability of the network topology, network operations involve more than that. A holistic approach to network programmability will need to incorporate performance, security, and visibility to business needs.

According to Forrester Consulting, network engineers will need to embrace programmability in order to deliver the automation benefits back to the business. You can read more about network automation and the impact on network professionals and vendors in Forrester's study, "The Future of the Network Engineer Is Automation." (reg required).

Image credit: Dormain Drewitz, Wikipedia

distributed by