« Infrastructure Services: Hard Core, Soft Core, Fluffy Core...? | Main | Next Gen Infrastructure Virtualization v. Infrastructure Management »

Workload Mobility and "The Intercloud"

James Urquhart has a thought-provoking post this week when discussing a recent post by Doug Gourlay.  Perhaps the most interesting aspect of Doug's post was his explication of what workload mobility implies when it is no longer restricted to migration within the confines of a physical datacenter: the bandwidth and traffic management requirements of workload mobility in the datacenter are in great part supplied by shared network storage. 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 absolutely 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 by 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. 

  • By drawing on the principles deployed for the internet (with a small "i") to solve the cumulo-workload problem,  it implies a mix of autonomously, (self-)managed units of workload mobility combined with "just enough" collaborative agreement (and delegation) of command and control. 
  • The operation, administration and management of the scaffolding and structural underpinnings must be considered with respect to all the same considerations.  (I'll tip my hand here by referring to the ISO-OSI-TMN FCAPS taxonomy.)

The data network problem seems to have resulted in solutions 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".

, , ,

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
All HTML will be escaped. Hyperlinks will be created for URLs automatically.