TyphoonAE: a new Google App Engine stack | Hacker News Reader

TyphoonAE: a new Google App Engine stack

code.google.com

62 pointsshykes15 comments

I'm waiting for the first hosting company to offer a drop-in replacement for AppEngine. It should be easy to compete on support with Google, and there are tons of AppEngine applications out there that can turn into big successes.

The appengine to me 'personally' has always felt too restrictive and suitable for pet projects than full scale apps.

But then again, i might be stuck in a "relational" mindset.

Maybe, maybe not. We just wrote a big app (enstore.com) on top of it without too much problems. It's another way of thinking, but I actually started to like a restrictive datastore with very consistent characteristics. Now if they only can get it up to speed again (http://bit.ly/as4sij) :-)

Enstore is running on Django, right? Did you run into any gae specific issues?

That's a seriously phenomenal idea. Just by charging for the service and using a SQL database they could avoid 90% of the problems GAE has experienced. I would pay $1000/month without a second thought to have a quick migration away from GAE, and no doubt a lot of other people would as well.

How would quick migration work from BigTable to SQL?

And which language do you use (on AppEngine), out of curiosity?

My guess is a migration from key value(or most NoSQL) to relational would be an easier path, right?

We're using Python with Django. AppScale (similar project as TyphoonAE but a bit more mature) has done a decent job of writing a layer that implements all datastore functionality on top of variety of databases (some SQL, some not.) It's not too tricky actually since in most ways the App Engine datastore interface is a subset of SQL (kind if like SQL without joins actually.)

I used App Engine for over a year on different projects and ended up leaving it. My first reaction to TyphoonAE was 'cool', because it's exactly the sort of thing I wanted to see back in those days so I could get over the sense of lock-in. If I knew there was an easy way out I wouldn't have to think about it.

But if you consider what this project actually means... if it's about providing a way out while maintaining compatibility then all it really does is give people a reason to stay on App Engine. Are the developers cool with that? Or is this an intermediate system that allows you to migrate an active project away and then expand it beyond AE's limitations?

If you're ok with the limitations inherent in AE then it makes sense to stay there given the fairly high level of reliability and very low cost. If you need to move beyond AE's limitations then you should just port your app to another platform. Given the amount of Java/Python frameworks out there it's not really a big deal to find a better platform without having to start completely from scratch.

Another issue is that it's not just finding a compatible db but being able to get your data moved while maintaining the current key/id/parent/etc relationships. If you're like me, you probably used id/key lookups extensively because they're faster.

I'm curious how they'll address the actual migration issues beyond api/module compatibility.

Could you talk about some of the limitations that led you away from AppEngine?

I'm working on an app now that uses PIL to create some fairly complex composite graphics with serial numbers printed on them. Can't do that on App Engine.

Their version of PIL is buggy. I had to use composite() to do crop() in order to get rid of black lines on the edges of images (seemingly random, couldn't get repeatable results).

The datastore is slow and requires a lot of planning to do even basic stuff. You also have to manually memcache everything to speed things up.

Hard 10 second limit on db queries and a 30 second limit on requests. There's a famous bug that kills db queries randomly. I'm not sure they ever fixed it but there's a monkey patch floating around that keeps trying until the time limit is reached.

Deploys timeout constantly. A one click deploy isn't that attractive if it takes over a minute to complete.

Mail handling is terrible and only got introduced (inbound) after I had been using it for a long time. When I say terrible I mean buggy and unpatched. You have to write your own attachment handling to work around it.

If you don't have a heavily trafficked app, your app 'goes to sleep' often (gets unloaded from memory). There's a pretty long wait when it fires up again.

When they (or you) do have a problem, there's really no connection to support. There's a group but you have to wait for a response.

There are a lot more but I can't remember all of them at the moment. I've since just moved to a vanilla Django deploy. I would never go back.

:-( Sorry to hear about all this. I'm still tempted to use it but will be more prepared to be disappointed.

This looks pretty cool. I am installing it right now to kick the tires. I use and like AppEngine, but another framework that would support migration away from AppEngine seems like a good idea to me.

If you need help installing it, feel free to post any questions to http://groups.google.com/group/typhoonae

Google should be happy too, as this removes vendor lock in, which I guess is one of the last barriers to App Engine adoption for a lot of customers.

Reply on news.ycombinator.com