« Hoff to Cohen to ... Watching a Meme and its Wake | Main | Geva Perry and Cloud Computing Standardization »
Tuesday
Feb102009

LISP, Resilience and the InterCloud

Catching up on some blog reading, I'm pleased to see Lori MacVittie's post on interoperability between clouds, but not for the reasons one might think. 

First, her description of LISP and it's similarity in function to UDDI was definitely helpful.  (Thanks!)  It makes clear to me one aspect of the necessarily independent set of core intercloud services that are likely to be necessary in any pragmatic solution for workload interoperability. 

The point she then makes about its lack of applicability... or, more correctly, its lack of sufficiency ... for internal workload mobility is a point we've been making at Replicate for as long as the company's existed.  What's required for workload mobility in the virtualized datacenter is "infrastructure resiliency" ... a topic I've written on in the past.  That is, the virtualized and physical access network must necessarily provide a defined connectivity, resilience (absence of single points of failure), security and performance to a set of individually administered resources.  The fact is... workload mobility within the datacenter is probably best defined as moving a "flock of resources" in such a way that, upon reaching their destination(s), the resources retain appropriate connectivity (at the various network levels), and the other measures of "goodness."  Providing the abstraction and then (under the covers) assuring that this is the end-result demands more than a configure-it-once-and-forget infrastructure. 

Finally, the organization of LISP within an intercloud environment implies the existence and availability of a publicly accessible "reverse DNS service." It seems to me that (to Lori's point) one of the key deliverables of a cloud interoperability standard would be to detail how the LISP offer (from the intercloud service environment) safely and reliably interworks with the  datacenter's internal means of "herding the flocks" of resources that define a workload.  Put that on the list of deliverables for the intercloud interop standards.

Just saying.

Interoperability between clouds requires more than just VM portability

If LISP sounds eerily familiar to some of you, it should. It's the same basic premise behind UDDI and the process of dynamically discovering the "location" of service end-points in a service-based architecture. Not exactly the same, but the core concepts are the same. The most pressing issue with proposing LISP as a solution is that it focuses only on the problems associated with moving workloads from one location to another with the assumption that the new location is, essentially, a physically disparate data center, and not simply a new location within the same data center; an issue with LISP does not even consider. That it also ignores other application networking infrastructure that requires the same information - that is, the new location of the application or resource - is also disconcerting but not a roadblock, it's merely a speed-bump in the road to implementation.

...

Applications, and therefore virtual images containing applications, are not islands. They are not capable of doing anything without a supporting infrastructure - application and network - and some of that infrastructure is necessarily configured in such a way as to be peculiar to the application - and vice-versa.

... One cannot simply move a virtual machine from one location to another, regardless of the interoperability of virtualization infrastructure, and expect things to magically work unless all of the required supporting infrastructure has also been migrated as seamlessly. And this infrastructure isn't just hardware and network infrastructure; authentication and security systems, too, are an integral part of an application deployment.

Even if all the necessary components were themselves virtualized (and I am not suggesting this should be the case at all) simply porting the virtual instances from one location to another is not enough to assure interoperability as the components must be able to collaborate, which requires connectivity information. ...

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):
Post:
 
All HTML will be escaped. Hyperlinks will be created for URLs automatically.