I don't think my remarks were particularly offhand given that their post indicates a lack of understanding of how App Engine works. Based on that misunderstanding and poor architectural / implementation choices, they then go on to say that the data store is slow, App Engine creates too many instances, requests were timing out, and memcache is too limited. These criticisms of App Engine might be valid for certain uses, if it were not for the fact that the way they built the application is likely the very cause of their problems.

For instance, I'm 95% confident that the work they did upon instance startup was build the search index based on reading:

  "We HAD to use the search API for the last few months
   because we couldn’t keep our indexes in memory, because
   of the start up time (discussed earlier)."

I'll make some assumptions here because I don't have access to more information, but their search index is likely being built off of what is stored in the datastore. First off, calculating this all at instance startup is inappropriate. What if App Engine switches to a ZeroVM implementation where every request is effectively a new instance? They would be building an index just to throw it away right after. Or if instance lifetimes were limited to five minutes, it's the same problem. What if the amount of data in their datastore scales up by three orders of magnitude? Were they planning to burn through hours of instance startup time to build this index?

Not to mention that this index is most likely a deterministic function. In other words, given input data X, the result is always going to be output data X'. The fact that they recalculate the results of a deterministic function upon each instance startup is 100% wasteful. This is the direct cause of their request timeouts. Additionally, it's also the likely cause of the datastore slowness. As they state:

  "Pre-computations at start up kept the new instances 
   busy, and app engine was creating more and more instances
   to handle this."

So startup was taking such a long time because it had to (1) pull data from the datastore and (2) perform lengthy calculations on that data. App Engine saw the instance as being exremely busy therefore it spawned a new instance. Rinse and repeat. The datastore is going to get hammered with overlapping requests. No wonder it's slow. They may have also used a sub-optimal schema. It's been about three or four years since I've worked with App Engine, but I recall that their default datastore performed much better based on your choice of entity groups, etc. They should have used a background task for index building (if absolutely required), which is able to run for hours if needed. Store the results of the index build into the blob store. Retrieve that as needed without any recalculation.

Another thing they criticize is search API performance as being too slow. The current live application appears to do realtime search as you type. If they were implementing realtime search on top of App Engine's search API, I can see how that would be unsuitable as well. The search API is designed to take the results of a single query and fetch the results. If a search operation takes 500ms, that's not very fast but overall isn't a big deal. If that's 500ms per keystroke, then that will be massively slow. Searching upon hitting ENTER or clicking a button would have solved that. Or they could have re-thought their implementation if realtime is required.

App Engine is definitely not suitable for all problems, but it too deserves more credit than their blog entry gives it.