[pbh]

What's most interesting to me about this article is that the management of GAE seems to actually be getting worse over time.

GAE has always had two main disadvantages. First, there is vendor lock-in because you code specifically to the data store, worker API, and so on (though arguably there are alternative platforms that implement the GAE API). Second, you cannot run custom code (custom C in some virtual machine) or have a custom architecture (if, say, Redis might be useful to have around). These disadvantages probably aren't changing and are probably necessary for auto-scaling, security of Google's infrastructure, and so on.

However, there are lots of little things that GAE has been getting wrong for a while that are totally unnecessary. Lack of hosted SQL support. Lack of SSL for custom domains. Just little things that are probably annoying to implement and boring, but totally necessary for real websites or websites just gaining traction. (I know these are in varying stages of early support at the moment.)

But now, the GAE team almost seems to want to actively disappoint users. With hosted SQL being a request for years, Guido appears to have spent a bunch of time re-architecting the API for the datastore instead. With this pricing increase, they're pushing the many developers who came to their platform based on price (due to the very interesting scaling properties of the Google front-end) off the platform.

Overall, I'm very confused.

[mcantelon]

Yeah, the hard limitation to request duration is pretty nasty too. It's a pretty limited platform overall, and never took aoff, so maybe they are trying to push people off it so they can eventually sunset it?

[nroach]

Deliberately pushing people out? Probably not. They had a major decision point available when they chose to either exit beta and step onto a release product schedule or drop the project entirely. The fact that they chose to productize it bodes well for the immediate future. Adding SLA and SSL was also non-trivial from a product perspective.

But, that does mean that you have to figure out what your revenue-producing tenants are going to look like, just as you would do in physical real estate. Yes, it looks like the high-traffic commodity-product (think Halloween store) doesn't make a good tenant. But that doesn't mean that a jewelry store or office (low throughput, high value per-square foot) wouldn't be a good tenant.

[skybrian]

SQL support is in progress: https://groups.google.com/forum/#!topic/google-appengine/l0D...