Shuttleworth declares goat rodeo over, picks AWS as winner
As we all know by now, cloud computing is a veritable goat rodeo, an unseemly sight for anybody’s stomach. Disconcerted by these proceedings, Mark Shuttleworth lets his stomach have the better of him, and declares it over by picking the winner. That, of course, is not how you end a goat rodeo: you end it by pointing out that there are goats, not horses, involved.
The goat in question is the undisputable fact that, in North America, Amazon’s Web Services are the front runner in the IaaS cloud computing space. Which makes Amazon’s API the most used and most widely studied IaaS API. Mark’s recommendation for the OpenStack project, which currently has multiple API’s, but should, for a number of reasons, settle on one is to just adopt the AWS API. And does this with arguments that are simultaneously breathtaking and misleading. In particular, the discussion of HTTP belittles how crucial it was that the definition and evolution of HTTP was not controlled by a single vendor.
I completely agree with Mark that whether the AWS API is a good or bad API is completely besides the point for this discussion — where we disagree is his assertion that API’s aren’t a place where meaningful innovation is going to happen. Anybody who has followed the evolution of the API’s of any single cloud provider, let alone the wider cloud ecosystem, will immediately see the folly of this assertion. And there is no reason to assume that this API evolution will stop any time soon, there are still way too many important debates on modeling familiar concepts for cloud, and on streamlining cloud usage to be had.
The big problem with adopting the AWS API wholesale though is that it puts the future of OpenStack, and if Mark had his way, the whole IaaS space, into the hands of a single vendor. There is absolutely no way for anybody to get a feature into that API, unless they can get Amazon to agree with them and implement it in their version. Mark addresses this concern with a brusque
It’s true that those API’s would better be defined in a clean, independent forum analogous to the W3C than inside the boiler-room of development at any single cloud provider, but that’s a secondary issue. And over time, it can be engineered to work that way.
This is not a matter of ‘better’ or ‘cleaner’ — it is a question of how we, as a community, want to see the world of cloud to shape up. Especially from a North American viewpoint, that landscape looks disheartening right now, as if IaaS cloud will sooner or later be the domain of two or three large vendors; that is not the case in Europe, nor does it have to be the future. The much-used analogy with the early ISP market comes to mind, with AOL’s seemingly unstoppable march to world dominance. One of the reasons this never happened and we all can choose from a large number of ISP’s today of course is the dogged pursuit of truly open standards.
Sticking to one vendor’s offering is the exact opposite of an open standard; and there is no reason to believe that Amazon can be engineered into a more open process for API innovation. For one, I am not aware of a single standards effort, be it through an SDO or an open source project, that Amazon is involved in. Adopting AWS API’s wholesale and widely will reduce the incentive for Amazon to join any open API effort, not increase it.
Amazon’s API’s should be studied because Amazon is a pioneer, a first-mover in the IaaS space, who were in many cases the first ones to think through specific issues. Whatever the technical merits, their lack of participation in open processes makes their API a dangerous bet, no matter how benign they might be today.
P.S.: There’s some talk of Deltacloud in the comments; the analogy with JDBC is completely oblique, since we are talking about loosely coupled web services here, and not tightly coupled in-process API’s. Which also makes the second point, that Deltacloud is and has to be a lowest common denominator, moot. There is enough flexibility in a RESTful API to avoid that. Interestingly though, the comment directly contradicts Mark’s assertion that API’s aren’t a place to innovate — certainly, there is some innovation in all these different models.
Watzmann.Blog by David Lutterkort is licensed under
a Creative Commons Attribution-Share Alike 3.0
United States License.
Generated with Jekyll