[st3fan]

"developing on GAE introduced such a design complexity that working around it pushes us 5 months behind schedule"

This is the core of all their problems. It is a mindset incompatibility between these app designers and GAE.

The GAE APIs and rules are actually pretty simple and well defined. It works really well, but only if you work WITH those rules. You have to adopt the GAE application design philosophy.

If you don't, and if you work AGAINST the rules and best practices set by GAE then you are in trouble. Big trouble. This is what happened here.

I understand this is easy to say afterwards. And you can't really blame them for finding out the hard way.

Note that the same applies to for example all the great services that Amazon Web Services provides; they only work if you build your apps with the Amazon specific design approach in mind. Things like eventual consistency, expect things to fail, don't do large amounts of work in single jobs. Etc. Etc.

These appoaches suck more or less if you come from a 'total control over a bunch of machines' background. But they are so needed to scale.

[jlees]

Learning to do things the App Engine way frustrated me at first, too, until I realised in a very roundabout way it was - as you say - teaching me how to engineer for scale.

[grandalf]

Exactly, the blog post's author doesn't seem to have realized that the limitations are simply design tradeoffs.

[herrherr]

That is exactly our experience with the development of Metric Mail.

Yes, there are limitations. And most of them might get you upset first, but if you "work with the rules" it is a fantastic platform.

Metric Mail has been running absolutely fine since its launch in August, it has never failed us. Even under severe traffic it scaled without any problems.

We knew from the beginning what the limitations are and this way there were no big suprises during the development.

[ntoshev]

There is less difference in expectations from AWS though, probably because it's lower-level.