James Urquhart has a thought-provoking post that seems to be an expansion on a recent post by Doug Gourlay.  The most interesting aspect of Doug's post was his explication of workload mobility when it is no longer restricted to migration within the confines of a physical datacenter; that is, when the bandwidth and traffic management requirements of workload mobility are no longer supplied by shared network storage in the datacenter. The implications of data migration, vm migration and the management required to optimally (or even sufficiently) choreograph this in "the cloud" is not yet smackin' folks in the face.  But it will.

James is on target when he relates this to the issues of data communications with which the networking community was (and continue to be) confronted.  Taking this train of thought further, I find myself asking: which of the principles on which we've constructed a functioning internet can be re-applied for workload mobility in the cloud?  And, which of these mechanisms are to be quickly and thoroughly tossed out as inappropriate?  Great for Sunday-morning rumination.   Here are the two that seem to make most sense to me.

 First, I start by drawing on the principles deployed for the internet (with a small "i") to solve the cumulo-workload problem.  For the internet and the “cloud,” the operative principle can be expressed as:  a mix of autonomously, (self-) managed units of workload mobility combined with "just enough" collaborative agreement (and delegation) of command and control.

Then, once we’ve got the operative principle, we need the operative themes for operation, administration and management.  The OA+M of the scaffolding and structural underpinnings must be considered with respect to all the same considerations that have become almost gospel within the network community -- the ISO-OSI-TMN FCAPS taxonomy.

The data network problem seems to have resulted in solutions best described as "dumb networks, collaboratively managed on the basis of the minimum number of trust relationships."  The result for workload mobility in the cloud needs to be as resilient and as adaptive a traffic system for both workload and the data (on which it feeds and which it generates for consumption elsewhere). 

I hadn't seen the term before James put it on the page, but chuckled with recognition when he dropped it at the end of his post - Intercloud... indeed.

 Workload mobility and the next Internet upgrade | The Wisdom of Clouds - CNET News

More than bandwidth though, which we can make the case for, how will the data move? Does the Internet itself have enough bandwidth and traffic management to support this data movement? And how will the addressing statefully move from one autonomous system to another? How will the security policy bound to a particular object (re: VM) stay consistent and coherent as the VM moves across the network and from one network to another. This is the longer term problem much more so than just the bandwidth issue, and one that is not currently being served by the hype-machines.

His observation about the immense bandwidth required to meet an open cloud with free workload mobility is a very interesting one. The live motion you know today typically bypasses moving data by leveraging shared network storage which is attached to a given VM regardless of which host it lands on.

    ...

Those I speak with on a regular basis about this concept have a name for it. It's a name that may take some getting used to, but a name that clearly reflects the parallels between workload mobility and data communications; parallels between this new world and what came to be known as "the Internet".

We call it "the Intercloud".

Note: This was originally posted in roughly the same form on my blog http://telematique.typepad.com/twf/