update2: yeah, waitlisted as well... http://code.google.com/appengine/downloads.html (where code samples are)

update3: API: http://code.google.com/appengine/docs/gettingstarted/

update4: everyone who signed up recently should have received an invite by now!

Lots of limitations:

- Python-only for now but the complete architecture is language neutral and they will add other language support (will rely on feedback on which language support to add next). Before they add a language, they need to 'harden' it (i.e. remove some features from it).

- Django is the only API that's currently supported, can upload other framework(s) but you're on your own (which will be an issue since there will be some issues with other frameworks due to other limitations)

- you cannot write to the filesystem - due to distributed nature of the system, you have no idea where the file will end up.

- you cannot open sockets! you can only use the limited API that they provide (URL & mail sending API). Forget about Twisted :(

- no threads (Google says they provide scalability in other ways)

- limits on how long an app request can run – forget about uploading large files for now.

- admin console contains version source deployment client (svn or git?) which means Google will have easy access to your source code. If you're competing with Google, beware... Google potentially has access to your source code (and data of course) so you will have to trust them and their legal agreement! Definitely some conflict of interest is possible.

Update: Here's the relevant info from the TOS: http://code.google.com/appengine/terms.html

By submitting, posting or displaying the Content on or through the Service you give Google a worldwide, royalty-free, and non-exclusive license to reproduce, adapt, modify, translate, publish, publicly perform, publicly display and distribute such Content for the sole purpose of enabling Google to provide you with the Service in accordance with its privacy policy.

Seems to me that there's a lot of magic happening behind the scenes but you get simplicity for that.

They demoed few interesting applications:

- Huddle chat - like 37sig's Campfire - client queries the server every few seconds to pick up deltas.

- Jaiku - twitter clone that Google bought was partially converted to Appengine

- some social app that allows you to pick a place to go out with friends (clubs etc).

I would be far more skeptical of what they do with your data, which would live in bigtable.

I was refreshing the wrong link, http://code.google.com/appengine/

Edit: got an invite!

Looks like the SDK has been live there for 2 days. Wish Google would have an RSS feed for new things on code.google.com (if they do, let me know)

update at 12:55 (EST):

Thanks for signing up to try Google App Engine! Your account has been activated, so you can begin building applications!

edit: just did.

I just got an invite via email... now I can be the evil genius I always dreamed of! bwahaha!

Oh, whats that you say?.. "Don't be evil".. nevermind. :P

I'm in.

This isn't an issue with EC2 because EC2 apps can run anywhere the proper distro is located (assuming you don't rely too much on other AWS services).

anything to do with your code that stores data, interfaces with external data / services, runs new threads etc pretty much everything that makes it useful, cannot be ported, by 'hardening' the language sandbox, they tie you into their api. their query language is even google specific.

any application written on this platform looks to need to be entirely rewritten from scratch to port to another architecture

I wonder, though -- what if you used something like a remote REST interface to do authentication, passing MD5'ed or SHA'ed passwords as one of the arguments, and then based auth on that? Google wouldn't like it, but technically it appears to be within the scope of the TOS.

Very, very good point, though... users and data are basically the only things that matter for this type of application.

I did find one of your other points spurious, though:

their query language is even google specific.

Oh for crying out loud -- if you can't write a Perl one-liner to convert every instance of GQL to SQL with bind variables, or if you don't already use placeholders in any instance of raw SQL in your own code, you've got worse problems than that. This is the least of the problems IMHO.

Something has occurred to me regarding NumPy, SciPy, R, etc. Since it's Google's CPU time, it's not my problem if a loop or matrix calculation is inefficient. I'm going to deploy some grad students to stress test their TOS... :-)

Probably not, but again, you don't necessarily have to use the bits that lock you in :-)

Nothing new under the sun here...

It would be vastly easier for them to get at the creamy nougat filling of acquired startups if said startups were already using the google pixie dust.

I understand these articles are written in a rush, but this is plain wrong. From Google's site, it seems pretty clear to me that this will be true out of beta:

Every Google App Engine application can use up to 500MB of persistent storage and enough bandwidth and CPU for 5 million monthly page views.

I'm surprised nobody has mentioned this - does this mean the tech cost of a web-based startup is now $0?

And as a number of people are gleefully pointing out, Appengine comes with a strategic cost that is not trivial.

After playing with the .zip file they provide, I think fears of lockin are overblown. It should be relatively trivial to port existing apps to GAE, and apps developed for GAE should be easy to port to a WSGI enabled server.

Google will be a good place to run the free version of your web app that serves as an ad for the premium version that does the same thing with crypto, or with C extensions that add value to the transaction, you'll be able to use the same core code in relatively similar application containers.

I'm definitely going to use it for that. And if I can get away with it, I'm going to try doing some unclever implementations of semi-supervised ML, maybe a few matrix calculations, and see what I can get away with before they kick me off their grid :-)

It occurred to me that, since no one is paying me to optimize the usual tight loops that crop up, or write a C extension to speed them up, I can try just running a shit load of them in parallel and storing the results in their ObjectStore. Now I just need to randomize the ''request'' IP blocks and we're all set for the billion or so simulations that my officemate wants to run.

Sounds like a feature to me.

This worries me. It sounds like Google is trying to become the new single sign-on, completely blowing off OpenID, a perfectly good open solution. Microsoft Passport all over again...

This is (potentially) a much much deeper locking to googles cloud (its not just an OS, its your hardware too !).

Of course, it seems django - like, maybe that is enough to avoid the trap?

From the "Google App Engine Terms of Service" (http://code.google.com/appengine/terms.html):

"6.3. Except as provided in Section 8, Google acknowledges and agrees that it obtains no right, title or interest from you (or your licensors) under these Terms in or to any Content or the Application that you create, submit, post, transmit or display on, or through, the Service, including any intellectual property rights which subsist in that Content and the Application (whether those rights happen to be registered or not, and wherever in the world those rights may exist). Unless you have agreed otherwise in writing with Google, you agree that you are responsible for protecting and enforcing those rights and that Google has no obligation to do so on your behalf."

"Our Users API allows you to authenticate users with Google Accounts"

from some of the quotes earlier,

"you cannot write to the filesystem - due to distributed nature of the system, you have no idea where the file will end up."

"you cannot open sockets! you can only use the limited API that they provide (URL & mail sending API). Forget about Twisted :("

"no threads (Google says they provide scalability in other ways)"

To me looks very specifically that applications built on this framework can not be transferred without a major to full rewrite, thats very much lock in, it doesnt make it easier for google to buy startups, it makes them easier to no longer need to buy them. your users become their users. your applications become part of the google infrastructure.

This looks like the most dangerous and hopfully damaging thing google have done so far

It doesn't in any way disallow you from using something like openid, but your post seemed to imply that.

and you will see the problem ;)

Rather, this enables a new category of applications, personalized web applications for non-programmers. Instead of getting a blog on wordpress.com, in the future I will upload a wordpress image to google. Eveybody can have their private bug tracker easily now. And so on. I think there will be opportunities for new applications, or for enhanced user-friendliness of existing applications.

Not that I expected otherwise -- there are plenty of people (like, say, my officemate) who would pay a few bucks to run a few million simulations on Google's infrastructure. (I would too, but it'd have to be a lot of nodes, since I have my own farm of client machines due to the way I arrange consulting)

I hear they are actually CPU starved these days, which quite literally boggles my mind... if Google can run out of cycles, anyone can. But that informs the current deployment and limitations if it is true.

Market prices? What exactly does that mean, will it be determined by supply and demand, via an auction like AdWords perhaps?

- Easily integrate with other Google services. It’s unnecessary and inefficient for developers to write components like authentication and e-mail from scratch for each new application. Developers using Google App Engine can make use of built-in components and Google’s broader library of APIs that provide plug-and-play functionality for simple but important features.

http://steve-yegge.blogspot.com/2007/06/rhino-on-rails.html

It would be super fun to play with a well-supported server-side JS framework. He mentioned open sourcing that code eventually too :)

Why? The Google "big 3 language" choices are Cpp, Java & python ~ http://panela.blog-city.com/python_at_google_greg_stein__sdf... You may see perl or other languages but the "big 3" are the officially supported ones.

"... python ... but it will be a non-starter for many developers. ..."

I find that an interesting statement. Why say that? Python is a pretty easy language to learn & use.

I polled HN about a month ago to see what percentages of HN readers used what languages for web development, and while Python was the most common, its still only used by 22% of those polled. Take this data with a grain of salt, but still an interesting statistic:

http://spreadsheets.google.com/pub?key=pxT7jIffmj3lGdXFcn9hK...

Prophetic suggestion ~ http://code.google.com/appengine/articles/django.html & http://news.ycombinator.com/item?id=157648

pyRuby anyone :p ??

Wouldn't matter if they did -- you can't open-source a bunch of contracts with trucking companies, nor would any sane company want to open-source their testing routines for the hardware they build in house to manage the mess. Parts of the infrastructure are, however, published as patents :-)

Google's operational efficiency in deploying new capacity is the crushing advantage they possess over 99.999% of the companies on the planet.

no buffer overflows or fork bombs in this sandbox baby.

http://code.google.com/appengine/terms.html

Couldn't you have waited a bit over a week to release this? :P

It wouldn't let me pick my Gmail name (which is fairly obscure) but appending "1" to the end worked...

But hooray for the limited transaction support. That was a real limitation in Amazon SDB.

I keep getting Application Identifier: App already exists. Even when I pick random App names. Odd.

I'm sure Amazon doesn't mind though, they'll just continue to get all of this business.

I did just read that Python is just the first step, other languages will be supported soon. :)

not a big deal to most people... but from what ive read this seems more like a competitor to heroku/appjet than ec2/s3 as others have mentioned

but as a django user, i am pleased

If they fuck this up, and lose developers' trust, they're done. I don't think that's the plan. I could be wrong.