Re: The Business of Building Clouds

> Cloud Nine: Specification for a Cloud Computer. A Call to Action.
> http://www.joyeur.com/2008/05/08/cloud-nine-specification-for-a-cloud-computer-a-call-to-action

I think there are a number of assumptions here that are worth
discussing.

- "Cloud computers must operate on some sort of virtualization
technology for many of the following features to even be feasible."

Really? Why can't it just work on pre-installed capacity? Blade
arrays have been doing this for many years.

Certainly virtualization is important long term, but, in the open
systems world at least, it's still _very_ new in the data centre.
What happens if enterprises just aren't ready to adopt VMWare or Xen
for a variety of technical or political reasons? To paraphrase what
one person here asked, "will you trust your hypervisor more than your
OS?"

- "API for Creation, Deletion, Cloning of Instances"

I agree here, though I could see this as contentious, depending on
whether people disagree on what an 'instance' is'.

BTW, wasn't this the point of the Open Virtual Machine Format (OVF)
from VMWare, Xen, etc? [ Of course, it's yet not ratified by the DMTF
to my knowledge. Oh, and also, DMTF... not exactly a well known
standards body, yet. ]

- "Application Layer Interoperability"

It'll be interesting to see if user-packaging standards start to form
here, like WAR files. Or wouldn't a tarball be enough for many of
these frameworks?

- "State Layer Interoperability"

There are billions of dollars thrown at interoperability, semantics,
and integration annually by both vendors and customers, flowing like a
river into a tarpit of epic proportions. A large neon sign hangs
over this tarpit that says "Abandon All Hope, Ye Who Enter Here."

There is some hope, of course - cue talk of the Semantic Web. It's
still too soon to tell what pieces remain to make it work, but a
standard XMPP-based information bus is probably low on the list of
priorities -- it's too specific a solution. (The technical challenges
in financial markets don't apply to every industry). I'd say data
model interoperability probably is a more important nut to crack.

- "Application Services".

Yup, I agree here. But It'll be hard-fought street fighting to get
the standards in place over the next few years.

- Automatic Scale (deploy and forget about it)

Funny, I keep looking for the "fast=true" parameter in my
infrastructure, and I still haven't found it.

Joking aside, I do agree that 'adding & removing resources on demand'
should be a feature of how one provisions cloud infrastructure. (Not
coincidentally, that's one of Elastra's features in our preview
release). Though I'll go back to our conversation on performance
management a couple of weeks ago: many times, the best way to scale
is to fix the application.

Barring that, the cloud would have to detect and rewrite the
developer's shitty code for them. This isn't completely out of the
question, btw -- recent Oracle releases can rewrite a developers' SQL
to perform better, and a DBA can choose to "swizzle" the statement at
runtime without requiring a code change. They added this feature so
shops could workaround the crappy code in many packaged applications
that somehow never seem to be fixed.

"- Hardware Load Balancing"

This seems very much aimed at web application hosting. While clearly
important, that would be pretty limiting, especially if we're trying
to shift the enterprise onto the cloud. I'd go further and suggest
that the network capacity and (virtual) topology itself needs to be a
cloud service.

"8) Storage as a Service"

WebDAV?! Why not AtomPub?

On another note, has anyone seriously considered iSCSI? Certainly we
can't think of storage just as web resources -- there also need to be
mount points as a service, like Amazon EBS. Or is this just a pipe
dream?

Cheers
Stu Charlton
Elastra

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cloud Computing" group.
To post to this group, send email to cloud-computing@googlegroups.com
To unsubscribe from this group, send email to cloud-computing-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.ca/group/cloud-computing?hl=en
-~----------~----~----~----~------~----~------~--~---