A few days ago Google announced its App Engine, which lets folks build applications that run in Google’s cloud. Amazon has for a while had a number of services to let folks run applications in Amazon’s cloud. But in both of these cases, one must use their proprietary APIs.
For example, Google provides a datastore API that applications must use to persist state, while Amazon similarly provides a simple DB API. Amazon’s services are generally lower-level and easier to adopt ala-carte, while Google provides one-stop-shopping. Either way, one’s application code becomes dependent on a particular vendor. This is in contrast to most web applications today, where, with things like the LAMP stack, folks can build vendor-neutral applications from free (as in beer) parts and select from a competitive, commodity hosting market.
As we shift applications to the cloud, do we want our code to remain vendor-neutral? Or would we rather work in silos, where some folks build things to run in the Google cloud, some for the Amazon cloud, and others for the Microsoft cloud? Once an application becomes sufficiently complex, moving it from one cloud to another becomes difficult, placing folks at the mercy of their cloud provider.
I think most would prefer not to be locked-in, that cloud providers instead sold commodity services. But how can we ensure that?
If we develop standard, non-proprietary cloud APIs with open-source implementations, then cloud providers can deploy these and compete on price, availability, performance, etc., giving developers usable alternatives. But such APIs won’t be developed by the cloud providers. They have every incentive to develop proprietary APIs in order to lock folks into their services. Good open-source implementations will only come about if the community makes them a priority and builds them.
Hadoop is a big initial step in this direction. Its current focus is on batch computing, but several of its components are also key to cloud hosting. HDFS provides a scalable, distributed filesystem. It doesn’t yet meet the high-availability requirements of cloud hosting, but once folks who need that help to build it, it will. HBase provides a database comparable to Amazon’s Simple DB and Google’s Datastore API. It’s still young, but, if folks want, it could become a solid competitor to these.
Moral: if you want commodity cloud hosting, pitch in now.
April 9, 2008 at 5:35 pm
[...] Cutting on Cloud: commodity or proprietary?: As we shift applications to the cloud, do we want our code to remain vendor-neutral? Or would we [...]
April 10, 2008 at 10:25 pm
[...] Cloud: commodity or proprietary?: Doug Cutting (Head of the Hadoop Project) stresses open-source as the best alternative. He thinks that we can’t count on “cloud providers” to build on top of a non-standard APIs, and that only open-source implementations can counter their inevitable proprietary APIs. [...]
April 17, 2008 at 8:51 am
[...] See also: Cloud: commodity or proprietary? [...]
June 21, 2008 at 11:33 pm
CouchDB maybe?
July 12, 2008 at 11:59 am
Too bad i didnt come across this blog before. Great stuff you got here. Thanks.
July 19, 2008 at 6:28 pm
Nice post, you got some good points there - thank you.
July 22, 2008 at 3:11 am
[...] of application vendors finding themselves locked-in to the App Engine platform. Of course Amazon also has this issue, the potential impact of which was revealed this [...]
October 14, 2008 at 12:56 am
Cloud: commodity or
October 20, 2008 at 8:31 am
Nice article. Thanks. :) Eugene
November 16, 2008 at 1:00 am
Спасибо ;)
November 17, 2008 at 3:59 am
Полностью согласна!