But what Google has done is take a totally different approach to Amazon. The Google App Engine is basically a platform for producing and deploying (robust and scalable) webservices, where as Amazon's offering is a more pick and mix affair with storage (S3) and compute (EC2) and databases (SimpleDB) being offered as components rather than being integrated into a single platform.
However, one of the reasons why Amazon's S3 storage service has taken off so rapidly is the fact that it can be viewed as a component, and startups (and much larger firms) can use it transparently. So long as you wrap the service sensibly, if Amazon went bust tomorrow (unlikely) or the service became unavailable or unreliable (slightly more likely, but still unlikely) you wouldn't have to rewrite your entire code base. You buy a whole bunch of servers, assuming you can afford it, rewrite the low level library that handles storage, and you're set. You still maintain control.
Google isn't offering as much control as Amazon, if you build your business on Google's platform you're relying on Google to support your business. It's an interesting choice from Google's point of view, and it'll be interesting to see whether people will bet on Google. It looks like a sure bet, but if I was investing a lot of money into a business I must admit that it would probably make me rather nervous to leave so much control in the hands of another company who of course have their own objectives.
It seems very clear that, unlike Amazon's EC2, the App Engine doesn't have the potential (at least in its current incarnation) to be a general computing platform, it seems to be specifically built to be request driven, and that's okay.
Google's choice of Python as its runtime is probably fairly predictable, when you work for Google you have to use one of the four allowed languages, at least for deployable code, those being C++, Java, Python or JavaScript. Of the four Python is the obvious choice...
While I'm not a Python person, my language of choice to get things done is Perl, due to circumstance I've actually had to write a bunch of Python before. So while I'm not a guru, I can get things done in Python, abet slowly, all the while muttering that I'd get it done faster if I was writing in Perl. So I've put myself into the wait list for a slot in the preview release. I'll let you know if get accepted before they open the doors properly, I guess it'll take a while though...
However the release of Google's App Engine does mean that I'm even more annoyed than I already was, which was fairly, that my travel budget won't quite stretch to a trip out to San Francisco for Google I/O. I've already had to shelf plans to head out for Where 2.0 due to the budget squeeze here in the UK, although since I've already been out to ETech this year and will be heading to OSCON in July maybe I shouldn't complain? My a Dopplr trips list is still looking fairly full after all...
Update: There is some good discussion of Google's new App Engine by Richard MacManus over at Read/Write Web and by Brady Forrest on the O'Reilly Radar, and TechCrunch have had a go at building and launching an application using the new framework.
Update: Guido van Rossum talking about Google App Engine at it's release via Robert Scoble (and QIK) in two parts...
I'd have loved to have seen Larry Wall doing one of his typical off the wall talks at the launch of Google App Engine with a Perl run time. But I guess you can't have everything...
Update: Show your support for Perl as the next language runtime to be added to the App Engine. Right now (10/Apr) this is the second most highly ranked support request, just behind support for urllib and urllib2 interfaces in Python. Surely we can do better than that?
Update: Well, so much for the lock in arguement (via Daring Fireball and the O'Reilly Radar)
No comments:
Post a Comment