Google App Engine

A couple of weeks ago Google released the first iteration App Engine. As a complete package hosting environment for web apps, app engine provides a very easy point of entry to building scalable web applications in Googles cloud, with direct access to google APIs and building blocks such as an existing user authentication model.

From a development perspective, Google provides a fantastic SDK to get started. I was up and running a development server on my mac in a matter of minutes. It quickly became clear is that things are tailored to make it *very* easy to use other google services. App deployment is very straightforward. The database model is different than what most people might be used to.

In this move into Platform-as-a-Service (Paas), the direct comparison seems to be against Amazons well established suite of web services. As Garrett Rogers points out, however, this isnt really the case, at least not yet. Amazon offers a wide range of building blocks, mainly their EC2 cloud environment and tools such as SimpleDB and Simple storage. Amazon offers these services in a loosely bundled al-la-carte manner, where the developer ties them together. Google has taken a different approach by bundling everything together in a completely managed, but much more limited environment. It has actually been compared more closely to facebook than to amazons web services.

While Googles initial approach has its advantages and disadvantages, I think the real point here is that google is choosing to focus on just one subset of the market – the startup developer looking for a quick all-in-one solution. My guess is that this was a decision made in order to release the environment to the community as early as possible. It will be interesting to see what areas they focus on improving in the coming months.

The very day App Engine was released, the team at Google listed several areas that they knew the community would feel were too limited. Im really excited to see how the following areas grow as the environment matures, and watch the process with our specific needs in mind.

1. Support for more languages. Were obviously huge Python fans, but we recognize that there are other great languages out there that developers use to build web applications.

Python is a great language. Ive spent more time looking at it over the past week than I had in the past, and I already feel pretty proficient in it. This is testament to a logical and consistent nature of the language, and I think for anyone not familiar with it the learning curve will be pretty low. From a practical standpoint, however, there are downsides to this choice. For companies such as ours, the inability to re-factor legacy code where appropriate is obviously an issue. For googles core target, the startup developer, this limitation means that they do not have access to the vast amount of community resources and pre-written modules that seem (in my unscientific initial review) to be more prevalent for other scripting languages. It makes sense that Google initially opted to only support Python, since in essence they had to create a sand-boxed version of the engine to run within their environment, and they obviously have the most internal experience with that language. Im curious how they would approach doing the same thing with say PHP, and its more chaotic community.

2. Support for offline processing. Right now Google App Engine is great for web apps that do all of their processing in response to user requests, but what about apps that need to perform scheduled tasks or larger-scale data migration? Wed like to support those apps too.

Basing all processing on user requests prevents some pretty common concepts that would be required by any advanced application. At the very least, this limitation would lead to some horrible architecture hacks to support these types of tasks. Right now the excepted solution seems to be to have a separate machine that periodically triggers requests to the App Engine app. Of course that raises the question of how do you scale a separate service to keep up with an automatically scalable main environment. But really the correct solution will be some sort of scheduling service within the App Engine environment itself.

3. Support for large files. Google App Engine currently imposes a limit of 1MB on all requests, both inbound and outbound. Were interested in providing efficient support for much larger uploads and downloads.

This is an area that Im pretty sure will be addressed early on, but Im more curious as to the potential for large file storage mechanisms living within the Google cloud. The approach will be a little different from the typical LAMP paradigm, but thats not necessarily a bad thing. The white-paper on Googles BigTable database alternative has an interesting section on the way the google maps data is stored/queued.

4. Billing for additional quota. During the preview release period, all apps are restricted to a set of free resource quotas. Although Google App Engine will always be free to get started, we plan on allowing developers to purchase additional resources in the future, while paying only for what they use.

This is the area, I think, that will really show us what Googles long-term intentions for this service are. So far, very little has been said on the matter, except that basically it will be remain free for the type of usage that is possible now, with the inherent resource limitations. How the next-step pricing tier gets defined will be very interesting, and may prevent some industries from fully benefiting from all the service has to offer. In our case, we may find an opportunity to rethink the way we approach hosting completely.

Of course there are other critical areas are that are unknown at this point. When will the https protocol be supported? And theres the issue of lock-in, which Chris Anderson absurdly and elegantly addresses. Im pretty excited to see these limitations addressed as things mature, and watch what is starting out as a limited beta release quickly grow into an extremely powerful and useful service that will have lasting ramifications on the way we think about web application hosting, deployment, and development in general. Plus, it has a cute logo.