More on Utility Computing Standards

The conversation about which I wrote has been getting appropriate attention and more people with credentials weighing in.

James Urquhart points to utility computing market's need for "a standard for server (VM/framework/application/whatever) portability across disparate utility computing service providers."

To which I say: Amen. He then (correctly, IMHO) questions the ability of the virtual appliance concept by itself to be the answer. I got on a soapbox yesterday regarding a standard representation or description of VM assemblages. Were that available, it would go quite a distance to addressing the problem James points out.

For added goodness, Bert and Simon have commented on the post, summarizing their respective points of view. Simon's comment succinctly sets the context by stating that the creation of a non-proprietary standard and encouraging its adoption through open source availability is "...based upon the assumption that you have an engine with allows for portability between one CSP (common service provider) and another." This is the precondition I wish I'd stated as well as he has.

To return to my point: The engine to which he refers will require an accepted standard of description or, perhaps, of prescription. What's needed is a uniformly understood representation of VM assemblages: the application level components (VMs or physical servers), the network's components and the connections that lash them together as a functioning system. A standard limited only to VM description and representation of individual active units is necessary but not sufficient to meet the goal.

Service Level Automation in the Datacenter: utility computing

Recently, I have been telling anyone who will listen that this nascent utility computing market is still searching for a standard for server (VM/framework/application/whatever) portability across disparate utility computing service providers. I like the concept of a virtual appliance, but we need a (non-proprietary) standard, or we need another portability mechanism besides VMs.

Technorati Tags: utility computing, virtualization, standards

Technorati Tags: Standards, Utility computing, virtualization

Comments

[James Urquhart]

Man, I love the idea of a prescriptive standard for portability, as long as it is additive--in other words, there are a base, primitive set of technologies that must be implemented just so, but from there innovation can flourish through additive infrastructure and capabilities. These "extensions" could then be loosely coupled to the underlying implementation, so that a user moving a system from Amazon to Salesforce would just replace the management/monitoring/billing extensions tied to their functionality.

The problem, IMHO, is what makes up the prescriptive layer? It could be at the chip level, ala virtual machines, but does everyone really want to be prescribed to x86? How will Sun feel about that, for example? It could be against a translation layer between a virtual chip and a real one, but we all know the performance issues that come up there. The OS level is a bust, in my opinion, so I won't even go there.

This is why I continue to feel that there are no real standards to propose at this time...except, maybe, the filesystem. With the addition of the metadata you describe, a filesystem could be packaged, passed from vendor to vendor, and booted on whatever compatible infrastructure the vendor has available. The software is *truly* decoupled from its compute capacity, virtual or physical.

Make sense?

[Rich Miller]

James, it does make sense. I have to admit that I was taking the notion of a prescriptive standard in a different direction.

First, I'd have to agree that a filesystem that could be packaged and passed from vendor to vendor would be a big win.

Second, I believe that an assemblage of VMs configured for a specific use (e.g. an N-tier web-based offering) requires the same kind of packaging and portability with respect to the network on which it's placed. This is the direction I'm personally going to dig into, with greater frequency in the next weeks.

- Rich

[Bert Armijo]

Standards, by their nature, are a trade-off in the pace of innovation in exchange for accelerated adoption. When done properly this also allows change to accelerate in other complementary technologies.

IMHO we haven't explored enough of what's possible in utility computing to truly understand that trade-off today. While both James and Simon wrote their posts about VM portability, Rich notes that some systems already provide the ability to migrate entire services, complete with data. Achieving a level of mobility that moves a system of hundreds of VMs and volumes between providers with a single command requires more than simply layering a few services on a VM; it fundamentally changes the requirements for a VM.

Frankly, I don't think even mobility of a service is the end point. I can think of at least a couple more vectors of improvement to work on and I don't consider myself the most imaginative guy tackling the problem.

[Rich Miller]

Bert, thank you for your comments. With respect to your comment that "(a)chieving a level of mobility that moves a system of hundreds of VMs and volumes between providers ... requires more than simply layering a few services on a VM..." , I could not agree with you more. It's NOT simply an issue of minor mods to the VM.

Among other things, a necessary aspect is the ability to abstract/virtualize the network on which that assemblage of VMs rely. I'm sure there are others, but I know that's the one that interests me most.

If we had to characterize the other vectors, what would put on the list?