Google opens its Web application engine to 10,000 developers

The engine that powers the company's online applications suite will soon be accessible by a select number of developers, for testing their own Web services at their own pace...on Google's servers.

In a highly anticipated move given the fact that it had publicized that something would emerge today for a company retreat billed as "Campfire One," Google this morning announced it is granting developmental access to its application servers, to the first 10,000 developers who apply.

The Google App Engine is what enables the company's own online applications to run portably from any Web browser. Google's intention is to completely open access to that engine to developers who use its SDK, whose initial release for Windows, Mac OS, and Linux took place this morning.

"Google App Engine lets you run your web applications on Google's infrastructure," reads this morning's company description of the service. "App Engine applications are easy to build, easy to maintain, and easy to scale as your traffic and data storage needs grow. With App Engine, there are no servers to maintain: You just upload your application, and it's ready to serve your users."

While the initial SDK is generally released, though, for now Google is limiting developers' access to its servers to the first 10,000 applicants. Interested parties are requested to sign in using their Gmail accounts, where they can ask to be put on a waiting list. Though the service will be "open," it won't be entirely free: Unpaid accounts will be limited for now to 500 MB of persistent storage and five million page views per month, and Google will not be unveiling its paid service tiers until after the App Engine service exits beta.

For now, test applications will be hosted under the appspot.com domain name.

App Engine could be the next big shot in the arm for Python, the open scripting language that mixes Java-like classes with PHP's economy of grammar. Google provides the development environment for App Engine -- most fittingly, it too is an online app. Developers need Python 2.5 pre-installed on their systems, though of course, that's free as well. (Microsoft's IronPython, of course, doesn't count, nor do the current alpha versions of Python 3.0.)

With Python on the development system, a programmer can build a simple scripted app that's deployed to clients' browsers. Those deployed apps communicate with Google's servers using CGI, and it's Python that provides the standard classes necessary for the CGI transfers to take place. Because Web-based server/client apps are asynchronous by nature, Python's event handlers were chosen to send messages to the server, and yet continue to manage the app while waiting for a response over the Web.

If you've ever developed a Windows application using 1990s architecture, which was heavily dependent on COM, then you recall how DLLs were used as libraries that could be contacted by container applications. Back then, the communication process was presumed to be synchronous; since both the container and the library were installed on the same system, the container could literally pass control to the library, and count on that library to provide a response before resuming control for itself.

For Web applications, you can't make such assumptions; imagine if Microsoft Word's container window had to communicate with the Word engine via telephone. Who knows how long you'd have to wait for a response? While modern Web applications are geared to look more like client-only apps, since the wait times are so much shorter, they still exist. And in microseconds, they're still pretty sizable. In .NET architecture, the runtime component (CLR) can be tasked with managing the application during the waiting period; but Python architecture is more limited, on purpose.

"To allow App Engine to distribute your application in this way [using Python], the application runs in a restricted 'sandbox' environment," reads Google's current documentation on the subject. "In this environment, the application can execute code, store and query data in the App Engine datastore, use the App Engine mail, URL fetch and users services, and examine the user's Web request and prepare the response."

The trick with this kind of architecture lies in determining how much local information about a deployed app must be stored on the client side, and how much can or should be retained on the server.