It looks very similar to Amazon's EC2 [amazon.com] hosted server service. They even have a simplified database system much like EC2. That in itself is enough to scare a lot of people away due to the pain of future migration.

However, the free 500MB worth of storage is really attrative for anyone who wants to try a few things out online. I wish it supported more than Python, but they say they are working on it now. Getting a few more programming languages supported will make this much more flexible.

I'm signing up for a block. Who knows what I'll do with it. But at no cost, what do I really have to lose?

Implement your own GDrive - It shouldn't be to hard with 500MB of storage, user authentication, etc.

Because as a business owner you recognize the benefit of not having to invest in IT administration overhead?

Because as a business owner, you recognize that Google is investing in your business by seeding your startup costs?

Because as a software developer you recognize that leveraging the tools Google is offering (and will be adding to over time) will speed your time to delivery?

You don't. The business model is flawed.

The only persons able to use AppEngine are programmers. As such, setting up a LAMP configuration shouldn't be too hard. You can get hosting for 6 euro/month. Basically what they are saying is: we are between the 6 euro/month line and 0 euro/month. I don't see the business advantage here.

Scalability and performance management: they don't mention numbers. I therefore do not trust them.

Exit strategy: I can find a lot of LAMP providers, I know of only one Google AppEngine provider.

There are a billion more holes, but one argument is enough.

The same thing that prevet google from just looking at your idear and cloning it(That is:Nothing).

But it is very very little web 2.0 software where looking at an existing implementation makes it any more easy to clone the implementation.
Remember that google still have to do a complete and independent implementation.

I do for example not really think that looknig at the slasthdot code, would make it any more easy for me to implement a complete clone of slashdot.

I'm quite excited at this announcement. Basically they are offering me:

- A system on which I can create and deploy applications that will always scale automatically, the only difference when doubling my traffic being the invoice I get by the end of the month. I don't have to deal with engineering or choosing a safely scalable application framework, looking, paying and dealing with a scalable application server, database, shared storage system (e.g. a SAN) and load balancer, run and maintain a fast network, perform backups, etc. All I do is write and run the application as I need.

- A system where such costs (application server, database, storage, load balancing, network and backups) scale perfectly with the actual use (and presumably profit) of my application, without having to make any huge investments.

- A system that will allow me to start for free and try it all, or just work freely for my hobby community, granting me no less than 500 MB. The competition today consists of a handful sub-par free hosts with 50 MB, a crappily configured PHP 4.3 and don't ask for speed or availability.

- Integration with Google applications (GMail; presumably, with all of them in the future).

- A standarized development environment based on a truly high-level, productive, modern language (not that Java business crap, but something that actually allows you to work fast and smart).

Google hosting it? I couldn't give a damn. My applications are usually GPL, including the business ones. It's not the application what's sold, it's the development and the service, and even if it were the application, I would trust Google as much as I would trust any other host.

The only caveat I see would be the datastore, which is not a relational database supporting SQL, but I'd have to see how good it is. At least it supports transactions, which are the single most difficult feature to implement in your own storage system. Everything else is just comfort, and when you work in Python, a language with first-class functions, builtin lists and dictionaries, list comprehensions, generators, a real object system, decent properties, operator overloading, mixins and dynamic modification of anything, and a dozen more features traditional languages such as Java or PHP couldn't dream of, I'm not worried about being able to query my data comfortably.

Maybe I need to clear up some confusion:

I am a Linux user(Gentoo) and I hate Microsoft. As a matter of fact, out of the 20 machines I have at home, not one runs any Microsoft product.

Just because someone doesn't like Google's business practices doesn't mean that they're a fan of Microsoft, except in some bizarre Manichean universe. If I had to rank the level of evil of technology companies I would probably rank them like so (from most evil to least evil):

1. IBM: For planning and orchestrating the Holocaust.
2. Microsoft/Gates Foundation: For subverting standards, engaging in Trademark infringement(e.g. java), and the socialist and eugenicist policies and actions of the Gates Foundation.
3. Yahoo: For engaging in censorship which has led to the incarceration of several political dissidents.
4. Google: For engaging in censorship and supporting counter-intelligence agencies against the American people.
5. Telecoms: For supporting counter-intelligence agencies against the American people.

Struts 1/Velocity smokes any other web-application framework out there.

Really? You actually LIKE Struts? You have to be kidding me. Your statement may have been true 5 years ago but most of the Java industry has tried to move past Struts (including its author) and into something more testable and less verbose. Seriously, have you actually ever unit tested Struts code?

Your code sucks.

I love how this is the default answer. Sigh. A lot goes into supporting a million concurrent users besides "good code". Often times, using good design patterns can slightly impact performance but it gets you increased maintainability. If you really want speed, why not just write your whole web app as a CGI using C/C++? I bet that would be a heck of a lot 'faster' than anything running in bytecode.

There are crappy programmers out there, sure, and crappy platforms. However, building an app in PHP or Ruby or Python is so much faster than building in J2EE that it is a natural choice for those of us low on programmer budgets. Then, when the idea takes off, you can address scalability concerns with a reverse proxy and a few more boxes. The popular app platforms of today all have advantages, and we developers choose the best tool for the task at hand. Struts is not always better than Rails, for example. They each have their place (and Struts' happens to be, generally, on legacy apps.)

They've actually released an open-source (Apache-2) reference implementation of the APIs - right there in the SDK. It's not a very /efficient/ implementation, but if anyone wants to hack on it to make it usable, it's right there.

They have been building huge datacenters for a while now, they own probably one of the largest distributed computing systems on earth

Which leads me to wonder...

Around here (developing Southeast Asia), connectivity to the rest of the world has its good days and its bad days.

People can either host locally, which means paying a lot, getting lousy customer service... and having good connectivity to internet users in the country, which is quite important.

Or they can host in the US, which means paying much less, getting much better customer service... and often having a lot of packet loss and high latency.

But Google peers directly with major ISPs around here, so the Google site is almost always fast even when many of the pages linked in the search results are barely usable.

So would their distributed system mean that our sites could take advantage of this? Or will the appserver sites all be in a single place, probably far away from here?

From the FAQ [google.com]: "Sockets are disabled with Google App Engine".

Don't get me wrong, I think the service is really cool, and I understand that maybe sockets could be abused but... am I the only one that thinks disabling access to the net severely limits a web app?

That said, I put myself on the waitlist. Even if I only ever use this for fun, it's worth exploring.

Feel stupid replying to myself, but whatever...

I realize that the fetch API will allow access to web services, which these days will probably cover most people's needs. I guess the only thing other than http that I often use sockets for in a web application is mail (pop/imap) and I suppose Google isn't clamoring to enable webmail competition for gmail.

On the other hand, I don't like the idea of having to sit around waiting and hoping for Google to implement a new API every time I want access to some new network service.