[occi-wg] Is OCCI the HTTP of Cloud Computing?

Wed May 6 15:44:53 CDT 2009

Tim,

Thank-you very much for this extremely thoughtful and helpful email.
OCCI was in an important sense inspired by your work and we really
appreciate your voice in this room.

To introduce myself: I am a co-chair of OCCI. I run RabbitMQ which an
open source AMQP messaging broker that has a number of cloud users.
Through co-developing AMQP I have some of my own standards scars.  I
also co-founded a cloud company - CohesiveFT - that I no longer work
for since RabbitMQ just became full time.

AMQP has taught me that:

- Simplicity really matters
- And is hard
- User contribution is vital
- But consensus is also hard: value it
- Standards take time
- Over-reach causes delay
- People get bored quickly these days
- The state of the art may be wrong
- Most technology has been done at least once before
- But, things are changing all the time
- It is not sufficient to be correct
- Less is more

I hope to be a voice for these principles in OCCI.

Comments, questions and other ramblings - below:

On Wed, May 6, 2009 at 6:33 PM, Tim Bray <Tim.Bray at sun.com> wrote:
>> About the choice of format, as much as I like XML and Atom specially,
>
> Sorry about my low level of participation.  Anyone who has worked with
> Sun engineers knows that in the weeks leading up to JavaOne, we're
> typically useless for anything external.  In my case, I'm actually
> working on making a cloud-computing facility deployable.  But a bunch
> of things have gone by that I should really comment on.  [For those
> who don't know, I was co-editor of XML 1.0 and co-chair of the IETF
> Atom working group.  So I like XML and Atom too.]

All forms of participation are crucial and we really want to hear what
Sun's cloud team have to say.

> 1. Background
>
> I am neither a supporter nor an opponent of this OCCI work.  My
> personal opinion is that the best time to do standards is after there
> is experience with interoperable implementations; so on that basis
> this is too early.  On the other hand, I'm aware that there may be
> market pressure for standards sooner than would be ideal, so this work
> might prove to be very useful.  I'm amused that there are at least
> three organizations working on cloud interoperability standards before
> we have any experience with cloud interoperability, but that's the IT
> business.

Understood.  Our hope is that we can reflect what has *been done* with
public clouds and in so doing not invent new technology or demarcate
behaviours prematurely.  Failure is a possibility and for this reason
we have set ourselves a very tight schedule so that if we fail we can
fail fast and the interoperability community can learn from our
findings.

That said, we do not plan to fail.  I believe that among the benefits
of our approach will be to demonstrate that more than a few people can
agree on *something* and that this *something* can be useful.
Therefore, people can attempt to provide interoperable implementations
quickly, and from this we can gain insight at least, and I hope much
more.  We can create real value if the deliverables are based on real
world experience and humbly pursued.

The issue of multiple efforts is IMO a natural consequence of the
technology extravaganza that "Cloud" has become.  Ho, and indeed, hum.
 I hope our efforts can make a mark and do not see this as a
competition.  If I had to pick one thing that makes us different, I
would like it to be 'community based approach'.  There are some really
talented people helping OCCI move along and many of them have learnt
their trade through open source and other developer communities.  This
is not in any way to cast doubt on the voice of the large vendor, but
it may give OCCI a certain flavour.

> 2. Sun Position
>
> We are going to run with our CC-licensed REST API until we have some
> experience operating a cloud-computing service because we think we
> have a whole lot to learn about where the real pain points are.  That
> API is *not* frozen.  There are other parties also experimenting with
> using it as a front-end to various cloud-computing services.

Cool - can you or they contribute some use cases please?   We needs
dem use cases :-)

> BTW, I saw a remark in some earlier email about the Creative-Commons
> licensing being a problem for someone who might want to use some or
> all of our API spec.  That is very surprising to me; if it's going to
> be a problem for people we'd like to hear about it.  Our idea was
> simply to make it clear that we assert no intellectual-property claims
> on the API itself.

Sam - could you comment on this please?

Tim - we obviously want to achieve harmony here and I hope we can clear this up.

> 3. General advice on making standards
>
> 3.1 Dare to do less.  Consider Gall's Law.  Try to hit 80/20 points.
> Build "The simplest thing that could possibly work".  When in doubt,
> leave it out.  Essentially all the technologies that have enjoyed
> widespread rapid adoption on the Internet have been initially lean and
> mean, and were criticized for being incomplete and insufficient.
> Also, this increases the chances that you get it done in time to be
> relevant.

+1

"in time" is key to our approach and thanks for these comments

> 3.2 No optional features.  Every time, in a standard, you say "you can
> do this or you can do that", you lose interoperability.  The best
> example is SQL; the committee, whenever they came to a fork in the
> road, took both paths.  As a result, SQL compliance means essentially
> nothing in practical terms, and database vendors use SQL to lock in
> their customers.

+1 again.  We have just learnt this with AMQP and as a result the 1.0
work is starting to look really rather good.

Strategic silence for the win: Success breeds use and hence trust,
which leads to innovation.

> 4. Specific advice on multiple formats
>
> Don't do it. Pick one data format and stick with it.  Look at the RFC
> series, which is the most successful set of protocol designs in the
> history of the universe.

That's a big place :-)

> They do not rely on interoperable models,
> they rely on agreement on what bytes I send you and what bytes you
> send me and what the meanings of the fields are.  Allowing multiple
> formats in general, or XML and JSON in particular, is actively
> harmful.  It is very easy in XML to create formats that can't be
> represented reasonably in JSON, and JSON carries a bunch of useful
> semantics (lists, hashes) that require extra work to specify in XML.

That sounds like a protocol mindset - consistent with your RFC comment
above.  But is OCCI a protocol?  Or is it an API?  What are your
thoughts here?

(note - I like protocols)

> I have opinions on which formats are most useful for a cloud-computing
> protocol, but the choice isn't that important.  What is important is
> to pick one and stick with it.  See 3.2 above.

OK.

We are heading to consensus in which we stick to really simple
(currently: flat) formats so JSON or XML are both candidates right
now.

More generally: What is the right way to make a cloud interface more
like a protocol?

> 5. When to use XML
>
> 5.1 When the order of elements in the message might matter.
>
> 5.2 When you anticipate trouble dealing with i18n, and can't simply
> say "Use UTF-8".
>
> 5.3 When you have document-like constructs, e.g.
>
>  <p>This <a href="/docs/policy"> is <em>important</em>.</p>
>  <p>So is the discussion above.</p>
>
> That kind of thing can't be represented sanely in anything but XML.

How would you recommend we deal with cases where XML is well supported
but JSON is not well known?

* .NET
* Many 'enterprises'

Though of course this can change very fast.

If we 'went with JSON' then would it be plausible to have XML adaptors
for non-JSON settings?

What about plain text - any view on that?

> 6. When to use Atom
>
> 6.1 When you are usually dealing with ordered collections of resources.
>
> 6.2 When it's essential that every item have a human-readable title, a
> globally-unique identifier, and a time-stamp.
>
> 6.3 When you have to wrap up document-like content, e.g. blog posts or
> HTML pages.
>
> [Is it now obvious why we chose JSON?]

No :-)

I am a dullard so please can you be more explicit.

Do you think Atom is a bad thing for our use cases?

alexis

> 7. Suggested reading:
>
> 7.1 Architecture of the World Wide Web: http://www.w3.org/TR/webarch/
>
> 7.2 Modeling is hard: http://www.tbray.org/ongoing/When/200x/2009/04/29/Model-and-Syntax
>
> 7.3 On XML Language Design: http://www.tbray.org/ongoing/When/200x/2006/01/09/On-XML-Language-Design
>
> - Tim Bray,  Sun Microsystems
>   Distinguished Engineer,  Director of Web Technologies
>   +1-877-305-0889 Sun ext. 60561 AIM: MarkupPedant, Jabber:
> timbray@{gmail,jabber}
>   http://www.tbray.org/ongoing/ http://twitter.com/timbray
>
>
>
>
>
>
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>