China Electronics Wholesaler

Developers Press Google on Its App Engine

Google officials fielded questions from developers Thursday at the O'Reilly Web 2.0 Expo in San Francisco who pressed the company about its Google App Engine, asking about everything from its language support, privacy assurances, pricing and backward compatibility.

To much fanfare, Google released a preview version of its App Engine earlier this month that it said allows developers to develop and write their Web applications using Google's infrastructure. The App Engine includes dynamic Web serving, persistent storage, automatic scaling and load balancing, Google APIs for authenticating users and sending e-mail -- and a full-featured local development environment, Google said.

Asked about backwards compatibility for developers who opt to run a Web application in the App Engine, Kevin Gibbs, technical lead for the project, said that Google will support multiple versions of the APIs the company provides.

"We're committed to not breaking that API we're providing to you," he said. "We have that ability to create new versions of our APIs, and you can actually say which one you want to use."

Addressing another concern, Gibbs added that Google does not want to lock people into its App Engine, saying that doing so is not good for the Web and "when the Web is doing well, Google is doing well." And he acknowledged that the company "needs better tools to get that data back out if you decide that you want to move that app, [so] you can dump that data out in a consistent way."

Developers at the presentation pressed Gibbs on when the project would include support for languages like PHP and Ruby. The runtime now supports only Python.

"I don't have those sort of dates available," he said. "We are very, very interested in supporting different languages. This is a preview release. We're trying to get it out there so you can tell us what you like and don't like."

Paul McDonald, Google App Engine product manager, declined to offer specifics when asked about the future pricing for the offering, which is free for up to five million page views a month in its current version. But he did say that users will only pay based on the CPU and bandwidth quota they use. They will not be required to sign contracts.

"Those rates will be competitive to existing rates out there."

Asked whether Google will be "scraping" and storing information about the applications it hosts on App Engine, he said: "Privacy is very important to us. The only reason that we exist as a company today is that everyone trusts us with their searches. The trust of our users and developers is very important. Like everything at Google, there are things that we log. That is in our privacy policy. This is standard Google privacy policy; there is nothing different with App Engine."

While Google is not providing support for the App Engine because it is a preview, it has detailed documentation and a few developers dedicated to answering questions on the Google Group associated with the project, McDonald said. He acknowledged that the company may need to provide some type of support for people who would eventually pay for the service, but said no details have been worked out yet.

As for what type of Web applications are best suited to be developed and run on App Engine, Gibbs said any type of request-based, database-backed Web application would be a good fit.

"If you have an application that responds to requests from users and generates dynamic content to return that, it works well on App Engine," he said. "Some apps need an offline component. Now, we're still working to be able to support that. There are certain liabilities in the system right now that make it hard."

In addition, because response times for input or output of applications running on App Engine are limited to one megabyte for now, developers with applications that use videos or other large file uploads might find it hard to use, Gibbs said.

Gibbs also used the forum to tout App Engine's data store, which is made up of Google's Big Table persistence layer instead of clusters of SQL databases. Because of the departure from SQL, with which many developers are familiar, developers are faced with "a little bit of ramp up" getting familiar with the new APIs.

Even so, Gibbs noted, the Big Table offers better promise for scaling than SQL clustering. "Your application at any point in time is on a number of our servers. [Big Table] is fault tolerant, and any part can fail and the application can still run. It adjusts organically to hot spots and when application loads increase..., it allocates more resources to it. We use very little resources for an idle application. That is how we are able to run a lot of applications on average."