Question for Cloud Campers: The Cloud and Standards

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

Cloud Camp, in case you’d missed it, is tonight. The usual suspects – and a few unusual – will be in attendance for what promises to be an interesting evening.

Personally, I would being going if I had managed to swing a trip to San Francisco this evening, but there was no joy on that front. Sadly, having been seriously out of the office more or less the entirety of last week, I won’t be in attendance (though my colleague will, so look for him).

But let me toss a question out for the attendees to consider, if they happen to be so inclined: when will standards arrive, and who will be driving them?

The answer to the latter question is more predictable, of course: standards are nearly always driven by market laggards (as an aside, I highly recommend Stephe Walli’s standards primer – excellent educational work from someone whose lived the standards battles). And so it might be expected in the burgeoning but still nascent cloud computing market. But there are de jure standards, and there are de facto standards, as the office productivity players are intimately familiar with after all these years.

And based on the offerings to date – or rather, the lack of same – it seems apparent to me that major would be cloud players have yet to digest the potential for the incumbents to achieve de facto status. It’s arguable, in fact, that with players from CohesiveFT to Elastra to Enomaly to Red Hat targeting Amazon’s EC2, we could see AMI’s quietly become the cloud standard sans fanfare. Which, as any of the non-VMWare virtualization players may tell you, is suboptimal for the non-originator of said standard.

The question of standarization is, I believe, an important one because the most important metric for cloud services might well be control. Or choice, if you prefer. As Simon Phipps once famously declared, “it takes full substitutability for me to have the confidence to stay as well as the freedom to leave.”

As yet, there is no real Freedom to Leave to be found in the cloud. I could move an application from Google App Engine to Amazon, perhaps, but not easily. And Salesforce.com’s Force.com takes that even further, as Cote observed during his time yesterday. Here’s how I contrasted a handful of the would be cloud providers approaches in discussing the launch of Google’s App Engine:

If we think of cloud computing offerings on a spectrum of closed to open, with Salesforce.com’s Force.com on the closed end and Amazon’s EC2/S3 at the open (though the Joyent guys can credibly argue to be more open than Amazon), Google’s App Engine is somewhere near the midpoint. It does impose a proprietary database (Bigtable) on would-be developers, as does Force.com, but it allows for the use of a standard programming language (Python) rather than the proprietary one required of Force.com developers. It’s more constrained than Amazon, of course, which essentially offers developers the freedom to pick and choose from the bare metal of a virtualized platform on up, but Google’s approach does offer some advantages to with its disadvantages.

Or, for those of you that are more graphically inclined (clearly more so than myself, as the primitive nature of the graphic attests), here are a few of the cloud providers portrayed in simple fashion visually along the dual axises of control and effort to scale.

Cloud Providers

The fundamental differences in approach – Amazon chooses virtually nothing for you, Joyent the operating system, Google the programming language (non-proprietary), operating system and database, Force.com the os, database and language (proprietary) – would seem to preclude easy or efficient standardization. And yet it will arrive, if only because customers will demand it. When the overwhelming deployment paradigm of the age is application on top of database on top of general purpose operating system on top of commodity hardware, it would seem difficult to convince the late or mainstream adopters that the entirety of that approach is wrong.

Which leaves the question of who will seize the opportunity that remains: standardizing cloud platforms such that migration – live or otherwise – becomes possible. Technically, the tools are there, as virtualization providers prove daily. The business justification may prove more difficult, with the current stable of cloud vendors perhaps too enamored of Shapiro and Varian’s switching cost to net present value equation.

That standardization will, in spite of that, occur, seems inevitable to me. Who will seize the opportunity and when, to me, are the real questions, and it just might be that the answer is to be found at Cloud Camp. I’ll certainly be watching as an analyst, but also as a customer.

Disclosure: Of the mentioned vendors, only Red Hat is a client.


  1. Cote gets to have all the fun these days.

    Anyway, I will not be their either. However that never stops be from pontificating on “Clouds”. I think there are two leaders in the movement to form standards for cloud technology. However they will both tell you it is a little early in the game.

    1) 3Tera w/Cloudwware

    2) Elastra w/ECML,EDML

    Other vendors are basically focusing on the evolution of the solution. In recent podcasts w/both Elastra and 3Tera I had suggested that the best place in today’s world (IMHO) to get standards going is the Open Source way. Neither one said “John” that’s a great idea. I think you also need to look at Scalr and Eucalyptus for possible cloud solutions that could force standards. With all that said I certainly interested in others views who are attending CloudCamp and Structure08.


  2. What about Heroku (http://heroku.com/), which I think is an interesting hybrid in this space, although they’re only in a beta period now? Rails hosted on Amazon’s EC2+S3 infrastructure. It covers an interesting sweet spot between Joyent and Google Apps in that you don’t get to choose the OS, but you do have Freedom To Leave and take your app you to some other hosting environment supporting Rails that makes either more or fewer choices for you regarding OS/database: e.g. Joyent or Dreamhost, or even Amazon EC2+S3 if you wanted. It’s extra interesting in that it is also layered on top of Amazon’s cloud entry.

  3. Your post regarding standards for cloud computing is quite timely. 3tera announced last month that as part of our Cloudware architecture we’ll begin over the next few months to publish the interface standards between the control plane, the execution environment, metering etc as well as our descriptor language ADL, and use them as the basis for a standards body submission to get the ball rolling.

    As for standards being the work of laggards, that can be true in slow moving markets where large laggards freeze the market with long protracted standards efforts. However, standards can also serve to provide a solid foundation for further innovation at higher levels and IMHO that’s what we hope to spur here.

  4. […] end-to-end monitoring. After that, of course, is moving beyond just Amazon. Mixed into all of that, as Stephen brilliantly pointed out, is jimmying standards into the cloud to avoid (valid) lock-in […]

  5. Nice post. That graphic is extremely confusing, though, because the boxes appear to be standalone items instead of logo descriptions. Perhaps that’s because of the way they’re drawn and connected.

  6. […] on 2008/6/25: Stephen O’Grady has an interesting post about the role of standards in Cloud computing. But he only looks at it form the perspective of possible standardization of the interfaces used by […]

  7. […] lock-in, then, is the question, what’s the answer? You guessed it: standards. Since we’ve talked about it, I’ve heard numerous names thrown around as potential […]

  8. […] ain’t so easy… Mi compadri Stephen O’Grady recently posted some good thoughts on Cloud Standards but its also worth considering the physical limits of data portability (we might be talking […]

  9. […] aspects of what Dion Hinchliffe has defined as Cloudsourcing. Perhaps we could even create some standard templates for […]

  10. […] piece this week on lockin echoes the concerns that I have had that have led to both talk (1, 2) and action (ping me for details) on the question of […]

  11. […] portability ain’t so easy… Mi compadri Stephen O’Grady recently posted some good thoughts on Cloud Standards but its also worth considering the physical limits of data portability (we might be talking about […]

Leave a Reply

Your email address will not be published. Required fields are marked *