#SDN #cloud How low (into the workload stack) can you go?

One of the more interesting sentiments expressed by attendees at a roundtable session at Gartner Data Center earlier this month was the notion that to them, "SDN is packaging app as code, server, and network and deploying where I need it". This is intimately tied to the idea of workload mobility, at least for enterprise customers, because they recognize the relationship between the application and its network infrastructure services as being critical to the success of migration from one environment to another.

Now, I'm not saying I agree with this definition of SDN, but the notion that we need to be able to package applications holistically is not a new one nor is it something that should be ignored.

What these participants were pointing to was the need for a "deep" copy of an application as a means to enable workload mobility. They don't want just the app; they need the whole kit and caboodle to be packaged up neatly and moved elsewhere, presumably the cloud. They want the cloning or packaging process to encompass everything, from top to bottom and bottom to top - not just the shallow upper reaches of the stack that starts and ends with the application.

There are two core reasons this isn't possible today. First, not all infrastructure vendors have a packaging strategy themselves. Application-related rules and policies are not often able to be managed as a group of related configuration items. Take an application delivery controller, for example, cause well, they provide the critical load balancing services required to scale applications today in every environment. There are two approaches to packaging ADC services:

1. Multi-tenant capable systems group application-related configuration objects and attributes together and enable export/import of that packaging.
2. The suggested deployment is one ADC (usually a virtual instance) per application so that the configuration of the ADC is assumed to be the application's configuration. Packaging becomes a configuration management exercise.

The latter is more common in the ADC market as most delivery platforms have not effectively made the jump from single to true multi-tenant support yet, which means configuration objects are independent of one another and not easily associated in the first place.

Second, even when this is possible, there's no holistic method that can provide the packaging of application and related infrastructure services and migrate that to a generic cloud. There's no EAR file, in developer parlance, that is cross-environment. OVF is an attempt at such a beast, but it's lacking completeness in the stack that results in some infrastructure services being overlooked.

There are a plethora of infrastructure services with which applications today are "integrated": identity federation, persistent load balancing, secure cookie gateways, firewall rules, and URI rewriting are just a few infrastructure services upon which an application may be dependent. These applications are not deployable without them, and thus cannot be migrated to the cloud - or anywhere else, for that matter - without them.

This is the challenge for providers and vendors - to figure out how to enable workload mobility of applications that are dependent on services that may not be compatible or even exist in a cloud computing environment.