The Problem With SDN

The importance of automation and orchestration (operationalization) of the network cannot be understated. Its role in improving time to market and reducing operating costs – both priorities for today’s C-level executives – is well understood at this point. Scaling a business today means scaling apps, which in turn requires scaling the infrastructure that delivers and secures those applications. This comes down to the network.

Increasingly, we’re seeing SDN tied to this notion of automation and orchestration encompassed in a shiny new acronym: MANO (management and orchestration). It’s important to note the separation of “management” from “orchestration,” lest we assume the two are the same. They aren’t, and that’s where we start to see a problem with SDN.

You see, SDN was initially designed on the correct premise that in order to scale networks to the next level and support an application world, we needed something more agile than manual operations to provision, update, and generally manage the operational configuration of the network infrastructure. Originally, OpenFlow served as the automated means by which we could achieve the speed and agility of operations necessary to keep up with the increasing rate of change in the application landscape. 

Then we saw that OpenFlow was only a partial solution; that is, it failed to enable infrastructure delivering higher order network services (layers 4-7) to be similarly automated. SDN evolved, taking on a focus that was inclusive of a comprehensive, full-stack approach to provisioning and managing network services. APIs and templates along with “master” orchestration engines like Cisco ACI and VMware NSX emerged, focusing on providing the capabilities required of applications in a modern environment.

Sounds as if we’ve got it under control, haven’t we?

Except we don’t. While operationalizing with SDN, DevOps, or even NFV certainly addresses the orchestration component of MANO, it doesn’t necessarily address the management  component.

You're thinking, "Wait, it certainly does." After all, provisioning and managing the configurations that control routing, switching, forwarding, access and other application-centric services is management.

That's true, but it’s only management of the services. It’s not enabling management of the actual devices that deliver those services, such as switches, routers, and application delivery controllers.

There’s a whole different set of management functions that aren’t necessarily covered under the SDN (or NFV) umbrella that must also be addressed if we’re going to shift the burden of scaling networks from people to technology effectively. There’s monitoring, upgrades, hot fixes and patches, redundancy, failover and other high-availability requirements that are separate but equal concerns of those building modern networks to scale. These are the kinds of functions that aren’t necessarily addressed by SDN, which focuses more on operational functions rather than the more mundane administrative functions.

There is just as great a need for the management of infrastructure – whether virtual or hardware, in the cloud or on-premises – as there is to operationalize its provisioning and configuration. 

It may be that these two functions – management and orchestration – will necessarily require two separate architectural solutions. The solution that supports automation and orchestration of operational configuration may not be the same one that enables the management of the devices and platforms that deliver the services being orchestrated.

Regardless of the ultimate solution, it must address both management and orchestration, and enable a more centralized means of doing so. That means both operations and administration must be considered, lest we shift the burden of manual operations to technology and free up engineers and architects to innovate only to realize we actually can’t, because they're still stuck managing devices manually, one by one.