Various pundits such as Garret Rogers at ZDNet and Richard MacMannus are viewing Google versus Amazon Cloud Computing as Apples to Oranges. The reason is that Google’s App Engine bundles all the services together and forces you to use Python while Amazon’s services are unbundled and can be accessed piecemeal.
At 100,000 feet, it’s an accurate analysis. Certainly the pundits need some way to pigeonhole the two offerings into distinct flavors. But as is often the case with technology, there is more to it than that.
For one thing, it isn’t all that desirable to use Amazon piecemeal due to latency issues and bandwidth charges. Do I really want to run my database in a completely different datacenter than my business logic? The answer is no, I do not. I already have a big speed bump between the client and data center, having a third speed bump would be painful. Also, Amazon doesn’t charge for bandwidth between nodes within its cloud, but costs to get data in and out of the Amazon cloud are higher than for most datacenters. Hence the smart money views Amazon as an all-in-one anyway.
Historically, companies have gotten their feet wet with Amazon a little at a time, perhaps using S3 to replace backups. But that isn’t the money play for Cloud Dominance. It’s just an entry-level experiment. Over time more and more gets sucked into the Cloud. Google simply short circuited that thinking.
We can turn it around and look at it another way. Suppose you want to use Google File System strictly as a substitute for Amazon S3, and you plan to ignore as much of the rest of Google’s App Engine as you can. You can certainly do that. You simply need to write a wrapper in Python that exposes the API of your choice to let you talk to the Google GFS. I wonder how long before someone clever mimics the Amazon S3 API’s in this way?
There’s also a lot of chit chat among the pundits about what a poor choice Python is. I hear things like it is an unpopular language, yada, yada. That’s more silly business for several reasons. First, Python is quite a popular language as O’Reilly’s book sales would indicate. Ruby and some others are more popular (by book sales), but it would be hard to view Python as “unpopular”. Second, Python is but the very first language they’re tackling. There will be more and I understand there are groups inside Google already working on others. Be patient, the rest will follow. Meanwhile, as I pointed out already, you can view Python simply as the way create API’s to get started playing with Google App Engine if you like.
Personally, I think Google could acquire Heroku and Zend and immediately pick up Ruby on Rails and PHP. If I were at those two companies I would be eagerly trying to have the conversation. I would also be calling up Amazon. Heroku is Ruby on Amazon already, and would instantly give Amazon parity again with Google App Engine only with Ruby instead of Python. That would make a wonderful return shot from Amazon.
And for all those pundits that worry about trusting their apps to big companies (hello MacMannus again!) like Google, fear not. MacMannus fears developers will be locked into a single source the way people used to fear Microsoft. But it isn’t so. Google doesn’t own Python and will be supporting other languages they also don’t own. They’re also supporting frameworks for these languages that they don’t own. They are Open Sourcing their SDK. By placing their platform at the language level more than the API level, they actually make it easier to port into or out of their world.
And, despite the conspiracy theory that Google is doing this to make it easier to acquire companies that built on their fabric, Cloud Computing is not going to be a one horse race. We now have two horses. I would expect another couple to show up before it’s all over, maybe more. It will be an arms race and in that situation, the startups can win because the competition will create price pressure and tons of new features they benefit from.
It’s a good day on the Cloud Computing Apple and Orange farm!