SDN Shell Games: You Won't Win

Emerging technologies that increase automation deliver a host of benefits, including greater consistency, predictability, and repeatability. Organizations embracing DevOps, for example, have seen improved application deployment stability and speed. They have also seen reductions in overall costs. These same principles, as applied to the network with software-defined networking (SDN) architectures, will no doubt yield similar benefits, but not if we're just hiding the burden under a different shell.

The basic premise of SDN is to shift the burden of provisioning and configuration (which are not the same thing, in case you were wondering) from people to technology. Today, in most shops, operators and engineers painstakingly provision services by manually configuring each and every link in the application infrastructure chain. Oh, we might use some tools, but at the end of the day, almost 100% of an application's critical network services (all seven layers of 'em) are provisioned and configured on the data plane.

[What percentage of your data center budget will be spent on maintenance vs. innovation in 2014? How about 2015? Tell us and enter to win a 32-GB Kindle Fire HDX.]

SDN promises to improve this situation by decoupling the data and control planes and moving the responsibility for provisioning and configuration to the control plane. "But Lori," you say. "This just shifted the burden from one side of the network to the other." That, my friend, is exactly the point.

There is a danger that when we embrace this new model for provisioning and configuring network services, we end up merely shifting where we accomplish these tasks, rather than how. If that happens, we risk introducing additional complexity into an already complex system architecture -- which is exactly not what we want to do.

… you simply flip the same processes over to the new control plane.

One way to set complexity running amok is by failing to consider the impact of how we automate and orchestrate provisioning and configuration processes. Adam Davis, chief architect of cloud computing for Citi, offered a particularly astute observation regarding software-defined architectures in his keynote at Glue Con this year. He noted that SDN offers control we never had, but that network folks still want to manage like traditional networks. He further noted, with respect to the shifts from people to technology, that "automation needs to be fit for purpose and not constrained by the procedure it replaces."

In other words, merely shifting procedural mechanisms from one plane to another gets you nowhere. Consider the purpose to which network automation is being put, and how to achieve that purpose, rather than merely moving the burden coin from one shell (data plane) to another (control plane).

Don't just automate what you're doing now. Consider what you want to achieve and how automation can help you realize that goal. You'd be surprised how efficient you can be when you stop being constrained by "that’s how we’ve always done it."

For example, HA pairs have traditionally met the reliability requirements of enterprise-grade network architectures and critical applications. But they cannot achieve the utilization, and thus efficiencies of scale, required to support a growing catalog of applications. Simply automating the same HA architecture will not get you the efficiency and simplification you need to support business growth in an application-centric world. That requires changing the underlying architecture so that it supports elasticity, rapid provisioning, and scale through automation and orchestration.

The bottom line is that automation and orchestration are excellent tools. But if you're not meeting expectations today with the network architectures you have in place, and you don't fundamentally rethink processes, automation and orchestration will only let you fall short of expectations at a speedier pace. Somehow, I don't think that's what the MBAs mean by "fail fast."

It's an application world, and that means we need to shift the architectural focus to delivering those applications faster, more efficiently, and with greater confidence. Simply shuffling burdens and complexity from one side of the network to the other is not going to get us there.

Could the growing movement toward open source hardware rewrite the rules for computer and networking hardware the way Linux, Apache, and Android have for software? Also in the Open Source Hardware issue of InformationWeek: Mark Hurd explains his "once-in-a-career opportunity" at Oracle.