[nl]

Does no one read the documentation before deciding to use a platform anymore?

App Engine supports Python 2.5. The Python interpreter runs in a secured "sandbox" environment to isolate your application for service and security. The interpreter can run any Python code, including Python modules you include with your application, as well as the Python standard library. The interpreter cannot load Python modules with C code; it is a "pure" Python environment.

At the top of the FIRST page of documentation: http://code.google.com/appengine/docs/python/overview.html

Google Apps domains do not currently support HTTPS. HTTPS support is limited to apps accessed via .appspot.com domains. Accessing an HTTPS URL on a Google Apps domain will return a "host not found" error, and accessing a URL whose handler only accepts HTTPS (see below) using HTTP will return an HTTP 403 "Forbidden" error. You can link to an HTTPS URL with the .appspot.com domain for secure features, and use the Apps domain and HTTP for the rest of the site.

HIGHLIGHTED on http://code.google.com/appengine/docs/python/config/appconfi...

A request handler has a limited amount of time to generate and return a response to a request, typically around 30 seconds. Once the deadline has been reached, the request handler is interrupted.

and

While a request can take as long as 30 seconds to respond, App Engine is optimized for applications with short-lived requests, typically those that take a few hundred milliseconds. An efficient app responds quickly for the majority of requests. An app that doesn't will not scale well with App Engine's infrastructure.

http://code.google.com/appengine/docs/python/runtime.html#Th...

I could go on and on.. reading this I see "I wasted 15000€ by not reading the documentation"

I usually think the title technical architect is a bit stupid (my business card says I'm one, so I can say that) but this guy needs a good technical architect to make platform decisions prior to wasting that much money

[mmastrac]

Agreed, absolutely. Before we settled on GAE, I spent time playing with it and wrote a few nontrivial test applications to get a good feel for it. We haven't been surprised by anything on the platform, except possibly the spurious 500 errors that were happening way too often in September (and have been fixed by the latest rounds of maintenance)

We made the trade of zero platform maintenance and near-free scaling and accepted the limits placed on what we can do. Many of those limits are being lifted each month as well. I can say for sure that there are a number of items mentioned in this post that have fixes in the works right now.

I will say that choosing GAE let us ship a project much faster than we could have without it and with much less manpower. The time we spend working around limits is easily made up by not having to do IT work.

[dantkz]

In the comments he says that the restrictions were not THE problem, THE problem was the instability. List of restrictions is kind of reminder of what he had to cope with, and wasted money on, until it turned out that GAE doesn't work properly.

[nl]

In my experience "instability" with GAE means you are pushing it beyond where it wants to go. If you a have code that just completes within the timeout, then guess what? When the system is under load it isn't going to complete.

You can use all kinds of techniques to protect your application from things like variable datastore performance. For example, nowdays I usually use a pattern where user-facing servlets only ever read from the datastore - all updates go via a taskqueue, which means that even if the datastore is in maintenance mode the updates will eventually be applied.

GAE isn't for everyone, but the first step to getting the most out of it is accepting it isn't anything like a typical frontend plus database architecture.

[mmastrac]

Late September was bad for the datastore. We were seeing latency on simple queries vary from 50ms up to 5s. These were simple properly-value queries as well. This was fixed in early October I think, and a recent bit of maintenance brought latencies down even further. The datastore is now extremely fast and rarely errors out.

We (http://gri.pe) are still happy on AppEngine, even though September was rough.

[grandalf]

Very true. The datastore unreliability was a real nightmare. I was getting periods of 60 seconds where it was unusable...

But it does appear to be fixed now.

[nischalshetty]

The Datastore problems have indeed been fixed and things have been smooth since the fix.

[fauigerzigerk]

" If you a have code that just completes within the timeout, then guess what? When the system is under load it isn't going to complete."

Unless the platform scales as it should, which is the whole point of accepting all the limitations. If there are tight and hard limits on request timeout, then there must be equally stringent guarantees provided by the underlying platform. "We're working on it" is just not enough under these conditions.

[BenSS]

I wish I could upvote this more. Implementation was a 'Square peg, round hole' architecturally.

[DrJosiah]

I'm glad you wrote this comment so that I wouldn't have to. Every comment he made about the system and it's limitations were documented (except the 500's).

[known]

I think the author is right. GAE is not suitable for doing serious business.