Close and Go BackBack to Viget

Why Google App Engine Matters

Clinton R. Nixon
Clinton R. Nixon, Development Director, April 16, 2008 3

I was incredibly excited to see the announcement of Google App Engine (GAE) recently. I can run web applications on Google’s grid, and have access to their authentication and back-end data store? Sign me right up!

Since it was announced, GAE has taken a lot of heat from pundits. For the most part, they are right, once you cut past the hyperbole. It is exceptionally limited: you cannot run spun-off processes on the server, there are no cron jobs, and the data store, BigTable, is not a relational database. It does threaten to lock in your application: if you use Google authentication, good luck migrating your users, and moving from BigTable to a relational database elsewhere would possibly be tough.

However, limitations can provoke creativity, and enhance applications built for that space. There are a lot of applications you can build without background processes, and if the end-game for your application is not to be bought, having Google’s authentication in place could vastly increase your user registration rate, as most users will not have to sign up for a new account. If you want to make a web application that does an interesting, simple task, GAE may be the best platform around once it gets out of beta.

From a development perspective, the fact that GAE only runs the Python programming language is definitely limiting. It is obvious why it was chosen: Guido van Rossum, the inventor of Python, works at Google, and they needed to limit the Python virtual machine to disable writing to the filesystem or other machine-specific tasks. Google’s announcement that they plan to support other languages, however, excites me. One of Google’s main languages is Java. The Java virtual machine (JVM) is a great piece of software; many languages have been ported to it including Ruby, our favorite here at Viget, and new languages have been written for it, such as Scala, one of my personal favorites. It is fairly trivial to use the JVM to sandbox these languages and limit their abilities to manipulate the machine as Google has done with Python. I expect to see JRuby supported soon, and a flood of languages thereafter. What this means for Rubyists is Google putting resources into developing JRuby, or even Rubinius, if they choose that route for a sandboxed Ruby.

The other exciting part about GAE to me is that they have a software development kit (SDK) to run GAE apps locally. This has already been ported to Amazon’s EC2, allowing you to run GAE apps there. BigTable, Google’s data store, is an interesting concept, and the development community has expressed interest lately in document databases, like CouchDB. With this SDK, we have been given a specification for the interface for BigTable. This is interesting: we may well see competing implementations of this non-relational database come out, allowing GAE apps to use any of them on non-Google machines. This can only result in innovation in database design, something which I have not seen a lot of in the last few years.

Posted in Opinions/Reviews and Trends on 04/16/08 3 comments
Gil said on 04/20 at 04:16 PM

Hey Clinton,
While I agree that AppEngine is likely to provoke creativity, unfortunately most of that will have to be focused around the limitations in the platform itself--not in new applications for the technology. That might serve to Google’s advantage, but I’d rather see all that energy focused on enhancing existing platforms rather than building an all new one.
Unless the tools get a whole lot better, designing an infinitely scalable application doesn’t make sense for a new project. And it’s probably easier to port an existing application with scalability requirements to Amazon, rather than rewriting it from scratch on AppEngine. So for now I’d rather not invest too much energy into exploring it.
I also disagree that there hasn’t been much innovation in database design lately. MySQL Proxy, a relatively simple way to implement sharding (also a newish concept), is just one example. Some of the largest web sites in the world (take Facebook and Flickr for example) have figured out how to scale brilliantly on open source database technology. How is that not innovation?

Clinton R. Nixon said on 04/21 at 06:57 AM

Gil,

You’ve got a good point about database design, in that relational databases continue to improve. I meant more in the area of exploring different concepts of a datastore. CouchDB and Amazon’s SimpleDB are interesting new ideas for how one might store data; BigTable falls in their same tradition, and will require developers to rethink data storage completely. I’m pretty wary of the idea of putting data I think of as relational in a non-relational database; but, I think having to explore that may cause me to look at my data in a different way.

I’d have to disagree that the tools need to get better for it to make sense to build a new application on Google App Engine. The scalability, which I didn’t mention much, isn’t the compelling reason. I agree with you that scaling is a problem most people just don’t have. It’s the ease-of-use and the Google ecosystem. Registration for a web app is a giant blocker that turns away many potential users. Remove it, and you’ve suddenly got a larger amount of people who might try your application. Using Google’s authentication can do that. Of course, it does mean that your app is locked in to Google. I’d contend that, like scaling, getting bought or having another compelling reason to switch grid-like platforms is a problem few have.

With all that said, I certainly wouldn’t try to port an existing app.

Gil said on 04/21 at 08:54 AM

You make a good point about non-relational data stores. I have yet to work on a project where such a data store would make sense, but I’m sure there are plenty of applications (like indexing web pages) where BigTable or CouchDB are a perfect fit, but which are simply beyond the scope of my limited experience.

I find ease of deployment a much more compelling reason to use App Engine than Google’s Users API. OpenID, among others, are set out to solve this same problem, but it just doesn’t seem that urgent. Personally, I don’t mind juggling logins for each site I visit (but I’m also a privacy nut, so there you go).

The problem is, in the context of my day to day work, I just can’t imagine why I would choose App Engine for any of my projects. Still, I’m keeping a close eye on the App Gallery - maybe it’ll give me some ideas.

Thanks for the reply.

Next entry: Installing Sphinx on OS X Leopard

Previous entry: Open Source, Take Two.

We're the Developers

at Viget Labs. We write about web development trends, tips, best practices, industry events, and our projects — all with an emphasis on Ruby on Rails.

Recent Comments

For translating strings you can use Rails I18n backend instead of using inflectors.

The `typus_human_name` is a patch to fix a problem in `human_name` [1].

[1] https://rails.lighthouseapp.com/projects/8994/tickets/2120-humanize-and-human_name-dont-separate-words

Contact Us

Have any questions, comments, ideas, or secrets to share? Let us know.


Sorry, you need to have Javascript enabled to use this form. (Don't blame us, blame the spammers!) If you'd like to contact us, please visit our Contact page.