Open Stack

The complete lack of evolution of the OSAPI combined with the irrational resistance to the EC2 API has struck a nerve with me.

#1 Feature coverage in the OSAPI is atrocious. And I don't get the feeling there's anyone seriously doing anything about it. Of course, you can always say, "George, it's an Open Source project. If you don't like it, feel free to fix it." Of course, I'm not worrying about all kinds of bizarre OpenStack projects that have nothing to do with building a basic, functional cloud platform either.

#2 The Netflix API is not an IaaS or PaaS API. Different problems for different audiences and different use cases.

#3 Push scales a hell of a lot better than having tools polling a cloud constantly. It doesn't matter whether it is polling the API, polling a feed, or polling a message queue. Polling is one of the most unscalable things you can do in any distributed systems scenario. Calling it a feed doesn't magically solve the problem. Actually, it's quite hard on its own in an IaaS scenario and has scaling issues independent of the polling issue.

Push notifications are the only mechanism for solving the scaling issue. You push any changes to a message queue. Agents pick up the changes and send them on to subscriber endpoints. Not that hard.

#4 The use cases you mention don't demand API versioning in the URI.

#5 For all the reasons I have already outlined, API versioning in the URI is a bad idea. I say this, again, as someone who made the dumb mistake of putting version in the URI.

#6 Unstructured content does not belong in an API except in select circumstances in which you are providing mechanisms for machine to machine transfer and the machines themselves don't care about the underlying unstructured content. For example, a document repository pulling a PDF report from a system and storing it in the doc repository. In such cases, it again does not need the meta-data information in the URI. Keep meta-data in structures for describing meta-data. The URI is not such a structure.

On EC2 vs OSAPI, I actually have no opinion. I do have an opinion that you pick one and make it work. We have a situation in which certain parties don't like the one that works (EC2), but they spend a bunch of time doing nothing on their alternative solution (OSAPI). And I say this as someone who things the structure of the Rackspace API on which OSAPI is based is one of the more elegant, well-designed APIs. But a well-designed API with no feature coverage isn't an API.

-George

On Oct 27, 2011, at 9:29 AM, Jorge Williams wrote:
> 
> Wow, I seem to have struck a nerve there George which was not my intent.  To add some context, I was under the impression that we're simply having a discussion here about versioning and extensibility in general, in order to help shape our future APIs in a consistent manner.  I don't think that we're re-inventing our current API design, more than discussing how it should evolve. We're also not talking about any particular API (identity, compute, image, object store), but simply discussing things in general in the hopes of moving to some consistency.
> 
> Overall, I like the idea of push but it's difficult to scale and techniques like atom have proven themselves.  I don't think that the use case is extraneous or imaginary, in fact, I presented two APIs that use the technique, today in production, at scale.  In the netflix case, I'm simply pointing out that they go out of their way to support variants, precisely to support the browser case.
> 
> -jOrGe W.
> 
> 

--
George Reese - Chief Technology Officer, enStratus
e: george.reese at enstratus.com    t: @GeorgeReese    p: +1.207.956.0217    f: +1.612.338.5041
enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com
To schedule a meeting with me: http://tungle.me/GeorgeReese

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20111027/a1e5ca4e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4395 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20111027/a1e5ca4e/attachment.bin>