One more exchange on the AWS API question.

Robert Scoble of Rackspace just waded into the OpenStack API issue in response to Randy and others. I tried to post a comment, but it looks as if comments were shut down while I was in the middle of typing it. [UPDATE@9:49AM PDT: Looks like comments are working again.] So I’m reposting it here. Read Robert’s piece first… then:

Here’s the problem as I see it. We’re three years in to OpenStack, and we still haven’t got one of the basic IaaS services: elastic load balancing. Why? In large measure, it’s because we’ve spent too much time on accommodating diversity — different hypervisors, different storage services, plugins and metaplugins for networking — and not enough time on creating a crisp set of requirements and executing against them. Too much time accommodating vendors (and I work for one of them, though I’m speaking for myself), too little time on delivering a consistent vision for the customer. We can do better.

In engineering, constraints are useful. They help you stay focussed, they make it clear what’s core and what is not. (See Rob Hirschfeld’s recent posts on the subject.) Linux succeeded because of POSIX. MySQL succeeded because of SQL. And the ironic thing is that the current OpenStack APIs don’t provide an alternative set of constraints, because there are so many extensions and options. (Hence Josh’s “RefStack” proposal.)

Innovation doesn’t have to be expressed at the service/API level. Adopting the S3 API in full wouldn’t limit the competition between Swift, Ceph, Riak and others to come up with an object storage system that offered kick-ass operational and economic benefits. And if ELB compatibility had been included in the original set of goals, I expect that LBaaS would be much further along than it is today.

Comments are closed.