I see the much-ballyhooed Open Cloud Manifesto is now on the air. IBM’s Bob Sutor says some unsurprising things in When you choose your clouds, don’t make foggy choices. The standardization drums are throbbing in the political undergrowth; does it mean anything?
I’m happy to see Sun’s name on the Manifesto list (no, I didn’t know anything about our involvement till just a couple of days ago), but I’m not expecting it to change the world. The Manifesto’s theses are right up there with Motherhood and apple pie; not much to disagree with, and, to be honest, not much to run with either.
Old Story · I’ve seen this movie before: There’s a new area of technology, there’s a dominant incumbent who got there first, and there’s a bunch of other voices calling for standardization, being genially ignored by the incumbent.
It’s perfectly reasonable to suspect the incumbent of wanting to protect their turf, and also to suspect the standards-promoters of simply wanting a piece of the action.
Cynicism aside... · Now that that’s out of the way, it is extremely reasonable to worry about lock-in, and how to avoid it, with a big new infrastructure component like this. As I’ve said before, the world’s CIOs know what it feels like when some vendor gets control of a piece of your IT budget, and it doesn’t feel good.
So... I’ll help. If it starts to seem like there’s some rough consensus lurking in the industry needing to be teased out and written down, I’d put some cycles into that work. But there’d be a lot of ways to go wrong.
Practical Advice · Been there, done that, got the T-shirts. So:
Don’t make a new consortium. The Manifesto refers to “Cloud computing standards organizations” but as far as I know there aren’t any, and I like it that way. We already have the IETF and W3C and OASIS and I see no reason why this technology is so different that it needs a new home.
Don’t go too fast. When standards organizations try to invent technology, it usually comes out badly. I’d really like to wait until there are some actual deployed running APIs with a couple of different parties coding to them and the stuff actually working. Then standardize that.
Maybe it’s a variant of the Amazon Web Services APIs, or something growing out of our own proposal. Whatever; as long as it works.
Aim low. Bear Gall’s Law firmly in mind and start with the smallest thing that could possibly work.
I smell a committee in my future.
Comment feed for ongoing:
From: Seth Ladd (Mar 30 2009, at 16:02)
This is definitely putting the cart before the horse, so thank you for suggesting we slow down until we have a broad selection and experience with Cloud API's before we go running with scissors.
There's added danger here as well, because so many of the cloud offerings are fundamentally different. Amazon's EC2 is incredibly different than Google's App Engine. The point is, the ad hoc definition of cloud is so broad that trying to create standards around it is like trying to create standards for transportation. Sometimes, planes, trains, and automobiles are just too different to lump together.
And I shiver to think there's a committee that will go out and try to create abstractions for "Transportation" that are so abstract they offer no value.
So agreed, let's sit it out, wait a bit, and watch how the Cloud(s) evolve. Only after we have a few years of experience will we know which models, API's, and abstractions will work.
[link]
From: Paul Hoffman (Mar 30 2009, at 19:28)
If it ends up being an API, it's not clear that any of the three you listed are appropriate homes (although the OASIS folks will insist that they're good for it). If it's a format, the IETF can handle this easily, and even bring some security expertise to the table for free.
[link]
From: Joe Cooper (Mar 30 2009, at 22:53)
You're quite right. I think it's relatively premature to standardize in this area. We don't even know exactly what the best solutions look like yet (though quite a few companies have good ideas on several pieces). I do think everyone ought to be concerned about the ability to get their data out of one cloud service and into some portable format for migration to another.
The API for spinning up new nodes or expanding storage or whatever is far less important than the user data, and so far the talk mostly seems to be about the API (though the purpose document does mention data portability, no one is really talking about it, nor does anyone seem to be working on it). Moving from Amazon's API to some other API would take a few hours of developer time (assuming reasonable bindings in your language exist). Moving data from Amazon's SimpleDB to a Hadoop HBase or even MySQL and updating your application to use the new DB would be dramatically more work. I think that's where the real danger lies.
[link]
From: len (Mar 31 2009, at 06:41)
Once again, good advice from the Master.
I've business concerns different from the technical concerns, but that is ever changing face of competition. Yet what Tim has to say is truer now than when we started on this trek. The stories at CNet and elsewhere indicate this is shaping up as another war of the titans which if inevitable is still wasteful. Given all the other strains on business, this seems to be a good time to slow down and consider how patient and transparent negotiation would be a greater good. Just 2 cents from the cheap seats.
[link]
From: Mitch Garnaat (Mar 31 2009, at 09:22)
This sort of seems like the "platform spanning" marketplace in the early 90's. Everybody was concerned about vendor lock-in so a market was created for API's that abstracted everything from the filesystem to the screen. But, then the web showed up and changed the calculus for everyone. The same thing will happen here. A new abstraction layer will be created/defined/invented that will change the way we think about clouds and computing. Trying to create a layer of abstraction on our current half-baked idea of cloud computing will be a waste of time. It's early days, give it a little time to coalesce.
[link]
From: David Kavanagh (Mar 31 2009, at 10:46)
Agreed. I've seen people get pretty caught up in database lock-in. On every project I've been involved in where we try to take that into consideration, we end up with one database and stick with it for the life of the project. So, what's the big deal with flexible compute lock-in? Pick a vendor you believe in and build your app! By the time anything changes significantly, either the app is obsolete, or there's an easy migration path. Not sure what all the fuss is about.
[link]
From: Brendan (Apr 03 2009, at 19:55)
With all this talk about clouds, has Bob Sutor and company taken any real classes in meteorology such as cloud physics? ;-)
[link]
From: Simon Brocklehurst (Apr 04 2009, at 09:02)
Well, I agree with a lot of what Bob says there. I find what he wrote surprising though; given that Bob works for IBM.
In that blog, he clearly explains IBM's business model, and then promptly describes it as "offerings and prices (that) aren’t good enough to keep customers, so we need to find another way."
Not only surprising then, but amusing too...
[link]
From: Michael Bernstein (Apr 23 2009, at 08:50)
Right now, the horse to watch in this race (ie. multiple implementations of defacto standards) is probably AppScale on Eucalyptus: http://code.google.com/p/appscale/
[link]