Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Unofficial Guide to Migrating Off of Google App Engine

www-cs-students.stanford.edu

Post reply on HN
Print view View original

11–20 of 63 posts

Re: The Unofficial Guide to Migrating Off of Google App Engine

#11

Post by lyddonb »

powera wrote: post #5

A few points (disclaimer: I work at Google on projects including App Engine) 1) It's not fair at all to say that Google "continue to ignore the two critical issues of uptime and data store latency". The HR datastore is specifically designed to address the concerns about variable latency of datastore operations, and to prevent both planned and unplanned downtime. 2) In my experience, high CPU cost for datastore operat…

1) Yep. My company moved to an HRD instance this week and our CS reps and customers have both noticed a significant difference in stability. That doesn't imply that it's perfect but to say that Google is ignoring the issue is completely false.

Re: The Unofficial Guide to Migrating Off of Google App Engine

#12

Post by [deleted] »

bane wrote: post #9

Can someone provide some enlightenment about why one would migrate away from GAE? I only ask because I'm currently building an a web application on GAE and am starting to look down the road, wondering if building on GAE will allow us to grow as a business in the ways we want to, or if there are some arbitrary limitations that will come to bite us later. (knowing of course that we're more or less tied to Google's infr…

[deleted]

Re: The Unofficial Guide to Migrating Off of Google App Engine

#13

Post by bartman »

Typhoon App Engine allows you to set up your own GAE compatible environment: http://code.google.com/p/typhoonae/

I never used it, but it sure looks interesting if your application doesn't fit GAE anymore or you want to make specific infrastructural adjustments. They support multiple different database/http/.. servers too.

Re: The Unofficial Guide to Migrating Off of Google App Engine

#14

Post by smg »

davepeck wrote: post #3

I've been a heavy App Engine user since the beta days -- even gave a talk at I|O 2009 about scaling with App Engine. I have clients that run complex GAE sites that handle millions of daily requests. I somewhat disagree with the author about scalability. There is a very narrow sweet spot of apps for which App Engine is a quite natural solution. If you're in the sweet spot, you'll probably scale well without too much u…

Could you please elaborate more on the "narrow sweet spot".? I would love to know which applications fit this sweet spot.

Re: The Unofficial Guide to Migrating Off of Google App Engine

#15

Post by shimon »

bane wrote: post #9

Can someone provide some enlightenment about why one would migrate away from GAE? I only ask because I'm currently building an a web application on GAE and am starting to look down the road, wondering if building on GAE will allow us to grow as a business in the ways we want to, or if there are some arbitrary limitations that will come to bite us later. (knowing of course that we're more or less tied to Google's infr…

The original article does point out a few reasons, but the way I see it is this: AE is great if you want to scale and your app can scale in the AE way. There is a sweet spot and the tools work pretty well if you're in that sweet spot, but if you stray outside that spot you don't have a lot of options. Even getting your data out can be difficult, making the "export data and start over" nuclear option difficult.

If you know what you're building and you want to scale it using the sort of tools AE provides -- i.e. the datastore, taskqueue, etc. all fits your app well -- it's quite good. And quite cheap; it's not really fair to compare per-resource pricing to AWS because on AE you'll only pay for what you use instead of paying for idle time on a server instance. But it definitely constrains what you can do, and also locks you to a single hosting provider. If you're still exploring what you want to do, that level of design and vendor lock-in can be a pretty severe liability.

Re: The Unofficial Guide to Migrating Off of Google App Engine

#16

Post by shimon »

bartman wrote: post #13

Typhoon App Engine allows you to set up your own GAE compatible environment: http://code.google.com/p/typhoonae/ I never used it, but it sure looks interesting if your application doesn't fit GAE anymore or you want to make specific infrastructural adjustments. They support multiple different database/http/.. servers too.

This project looks promising. Could be a good basis for a consulting business, taking apps that have hit some obstacles or design limitations on Google AE, and getting them running on TyphoonAE-based hosting with app-specific infrastructure customizations.

Re: The Unofficial Guide to Migrating Off of Google App Engine

#17

Post by thetrumanshow »

smg wrote: post #14
davepeck wrote: post #3

I've been a heavy App Engine user since the beta days -- even gave a talk at I|O 2009 about scaling with App Engine. I have clients that run complex GAE sites that handle millions of daily requests. I somewhat disagree with the author about scalability. There is a very narrow sweet spot of apps for which App Engine is a quite natural solution. If you're in the sweet spot, you'll probably scale well without too much u…

Could you please elaborate more on the "narrow sweet spot".? I would love to know which applications fit this sweet spot.

I must be in it, because I have rarely seen a downside to using AE. Here's the nature of my apps:

1) Extremely simple or very flattened data-model 2) Few writes, TONs of reads (I peak at 150 requests/second every day) 3) The occasional DeadlineExceededError causes me little or no headache. For some people this would be frustrating.

Also AE is awesome as a CDN. The latency is very tolerable for static assets.

Re: The Unofficial Guide to Migrating Off of Google App Engine

#18

Post by joshu »

lyddonb wrote: post #11
powera wrote: post #5

A few points (disclaimer: I work at Google on projects including App Engine) 1) It's not fair at all to say that Google "continue to ignore the two critical issues of uptime and data store latency". The HR datastore is specifically designed to address the concerns about variable latency of datastore operations, and to prevent both planned and unplanned downtime. 2) In my experience, high CPU cost for datastore operat…

1) Yep. My company moved to an HRD instance this week and our CS reps and customers have both noticed a significant difference in stability. That doesn't imply that it's perfect but to say that Google is ignoring the issue is completely false.

How bad was the cost differential?

Re: The Unofficial Guide to Migrating Off of Google App Engine

#19

Post by mark_l_watson »

A bit off topic: all of my customers but one in the last two years wanted to deploy to Amazon Web Services. I find this odd, being enthusiastic myself about AppEngine (no paid work, but I host some of my projects with it and I have written a few articles on GAE).

Clearly, not every web app is a good candidate for GAE.

I have found objectify-appengine to be nicer to work with than the official Java data store APIs and I think it helps minimize loading request times.

Re: The Unofficial Guide to Migrating Off of Google App Engine

#20

Post by nl »

hello_moto wrote: post #8

I don't quite understand with some of the commenters: why do you guys talk about caching immediately as if your app needs to scale from the ground? Isn't the point of GAE is that it scales (as long as you don't do stupid queries)? If we have to put everything in memcached, what's the point of using GAE? I also don't quite understand the push of using memcached for almost everything (especially for young startups). Ho…

Your site will scale well - as in it will give exactly the same performance for the millionth user as for the first user.

That doesn't mean you will have a fast site, though.

On GAE the datastore is pretty slow (it's a lot better now, but it used to be terrible), so a common pattern it to use a read-though cache to improve performance.

I wrote a thing that touched on this a couple of months back: http://nicklothian.com/blog/2010/11/23/a-pragmatic-approach-...

Post reply on HN