Google App Engine: Fish or Foul?

We’ve been paying attention to the launch of Google App Engine over the past day and a half and we will continue to keep an eye on it on behalf of our consulting clients. As is often the case with paradigm-challenging products, people often try to characterize the new thing in terms of what they already know. But we don’t believe that Google App Engine is directly competitive with Amazon EC2 today, although it could be in the future. We also don’t believe, as a few people have asserted, that it’s competitive with social networks like Facebook either. Here’s why.

Amazon EC2 is one of the most open platform products in existence today. When you spin up an instance of an EC2 server, you get to make all the choices regarding operating system and software. You log in as root. You can write applications on an EC2 instance using any language and tools you want. You pay only for what you use.

Google App Engine, on the other hand, is a walled garden. In the words of Tim Bray, if you go the App Engine route, particularly if you choose to use Google authentication, you are essentially a sharecropper, working on Google’s farm. You write the application, but Google owns the infrastructure and, more importantly, they own your users.

Ah, you say, but it’s certainly true that closed platforms can be spectacularly successful, at least some of the time. Look at Facebook, for example, one of the most popular walled gardens in existence today. Facebook exerts a great deal of control over what applications running on its platform can do through frequently-changing terms of service and rules enforced in its technology stack. But the difference here is that Facebook asks you to trade off openness and control of your application in exchange for something valuable — its users’ attention. The deal you make with them goes something like this: give me access to your millions of users, and in exchange I’ll adhere to your terms of service and accept your proprietary application framework — I’ll even go so far as to learn the only programming language that you really support well (which in Facebook’s case is PHP).

Google App Engine is neither fish nor fowl. It requires developers to write to their framework without the commensurate benefit of access to a huge built-in audience of users.

Google is providing access to App Engine for free for now, although traffic and storage is limited and we haven’t seen information about commercial licensing, which is troublesome and probably a deal-killer for all but the most trivial applications. It’s true that in many cases “free” can trump “open” or “complete”, but in the case of Google App Engine we believe that “free” won’t make a huge difference. It may attract experimenters and people writing demonstration applications, but virtual hosting (through EC2 or fixed-price virtual hosting providers such as Slicehost) is so close to free today that the “free” part of Google App Engine should not make a difference to anyone who is looking to write a non-trivial application.

The design choices that Google made with this product are pornographically good news for Python developers, who now have their own dedicated application server and a way to build web applications using their language of choice. This may well put Python on the map (as the second language of choice alongside Java, PHP and C#) as one of the Languages That Matter. But it’s also important to remember that consumers don’t use Python (or any other programming language), they use applications. In this respect, Google App Engine is one of many Google products that seems to have been created with technologists, as opposed to consumers, in mind.

On the consulting side we’ve been getting a ton of inquiries from customers regarding strategies and tactics for virtualization on platforms like Amazon EC2, and we’re in the process of adding a formal software development practice dedicated to supporting Amazon’s EC2 and S3 products. That doesn’t mean that we wouldn’t support something like Google App Engine if a client asked us to and there was a good reason to, but for the reasons we’ve described here, we’d prefer to take a wait-and-see attitude towards this and carefully weigh the drawbacks and limitations before devoting serious time or development effort to the platform.

All that having been said, we still believe that Amazon has missed an opportunity by positioning EC2 as a developer product as opposed to a hosting product. If the Google App Engine product were to make a dent in EC2’s momentum, we’d recommend that Amazon provide better support for multi-server scalability scenarios. Amazon recently started moving in this direction with the release of new features intended to give administrators the ability to assign IP addresses and machine instances to specific data centers, but providing explicit support for an adaptive clustering package like Scalr would give EC2 a vital edge, particularly for professional applications.