[occi-wg] Unlocking the formats deadlock

[Sam Johnston]

Afternoon all,

As you know I spent last week evangelising OCCI at the Cloud Computing Expo
in Prague (Monday/Tuesday) and Cloud Computing Expo in London
(Wednesday/Thursday), presenting the Introduction to the Open Cloud
Computing Interface<http://docs.google.com/Present?docid=ddqm27m2_298fsf9mqdg>presentation
at both. I was only scheduled for Prague but the organisers
found a spot on the technical track in London too. I also ended up on the
panels at both which was even more opportunities to talk about cloud
interop. I'll be in Portugal for Cloud Views from Wednesday and will try to
get involved in OGF 26 time permitting as well. By now people certainly know
we exist and that we're doing real (hopefully good) work.

Unfortunately we're somewhat stuck on the formats decision despite hours of
face to face discussion with 1/2 a dozen of the more active working group
members (myself, Alexis, Chris & Richard from ElasticHosts and the Fujitsu
guys). While this is not at all unusual for technical discussions we do need
to fairly urgently find a solution before people (myself included) lose
interest and wander off. I can't overstate how important this working group
is to the future of cloud computing and both of the alternatives are rather
unpalatable:

   - On one side we have Amazon EC2 APIs which are not only encumbered but
   inelegant and inflexible (at least in the context of the enterprise use
   cases I spend most of my time thinking about - no offense intended). Other
   APIs designed to expose the functionality of a single implementation fall
   into the same category and while they meet their specific needs well, we
   need to expose the current and future functionality of all current and
   future implementations, not just one today. At the extreme end of the
   simplicity scale you have text-based APIs which we all now agree won't meet
   our needs.
   - At the other end of the scale we have VMware's vCloud API which has
   been injected into the DMTF process, following in the footsteps of OVF. I
   fully expect the resulting "open API" to be almost word-for-word identical
   to the new VMware APIs which is something the
DIGISTAN<http://www.digistan.org/>guys call "vendor
   capture <http://www.digistan.org/open-standard:definition>". Unlike the
   public cloud APIs, this will be well-suited for enterprise and you can be
   sure that service providers will deploy VMware en masse to provide it as
   part of their [semi-]private "I can't believe it's not cloud" offerings.
   Good on them for being first and forcing the rest of the industry to follow
   their lead.

This working group's job is to find the middle ground - something which is
simple enough to be useful for public cloud offerings but extensible enough
to be useful for more challenging tasks (e.g. enterprise). This is also
critical for hybrid clouds (unless you're all happy to implement DMTF's APIs
in addition to your own). The business case is easily justified even if only
on the basis of getting access to customers who are currently kicking the
tyres with tactical deployments but unable to deploy strategically.

As you know I have been pushing Atom[Pub] hard, perhaps too hard, and the
XML-xenophobes have dug their heels in as a result. It was made painfully
obvious in London that blanket application of AtomPub to the problem isn't
going to fly with at least one of them and to that end I've spent the
weekend working on paring it back where it's not absolutely necessary. I've
also purchased and read O'Reilly's RESTful Web
Services<http://oreilly.com/catalog/9780596529260/>book by Leonard
Richardson <http://www.crummy.com/> and Sam Ruby from cover to cover and am
largely sold on their concept of a Resource Oriented Architecture
(ROA)<http://www.infoq.com/resource/articles/richardson-ruby-restful-ws/en/resources/04.pdf>-
do read this sample chapter if you have time.

Fortunately I think I've found a simple, elegant solution which obviates the
need for Atom (at least where collections are not required). I've captured
it in a series of 3 blog posts which I'll forward to the list for the sake
of convenience and the archives.

Cheers,

Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090525/d91a5633/attachment.html