On Tue, Aug 5, 2014 at 12:37 AM, James Foster <[email protected]> wrote:
> I came across this article today: > > http://techtraits.com/system%20admin/2013/02/24/The-problems-of-working-in-App-engine/ > > I'm considering undertaking my second project in App Engine (larger than > the first), but am a bit worried about some of the pitfalls in the article. > Does anyone know if any of them have been addressed? (and if so, which > ones?) > It's quite difficult to answer that question without access to the source code and assets the blog writers used. But a quick overview: *Quota Limits*: The writers picked on the App Identity API as having a quota limit of a million+ calls. That's enough for the vast majority of applications, and the API was (I believe) still listed as experimental in 2013 when this was written. The experimental tag is there for a reason; the writers should have waited until Identity became a GA feature or implemented their own ID service. Furthermore, this is an Electronic Arts (EA) application; for a company as big as that <http://www.ea.com/simpsons-tapped-out-android> you really need to buy a support contract with Google and talk with Google engineers directly, because Google can usually increase quota limits if you have a good enough reason (and they can be quite flexible on other topics as well). I'd like to see EA explain exactly what premium support said, and what support package EA bought. *HTTP Header*: The writers complained about HTTP header character limits. Lengths are debatable, most servers enforce a max limit on headers (individual headers and the entire header text). I'd like to see what data they were actually sending in the header and their auth requirements. *Pre-scaling*: Nope, all wrong. If you want to transition smoothly between two versions of an application, use the Traffic Splitting option to slowly migrate users from one app version to another. If you need to force the spin-up of a bunch of instances (what they're calling "pre-launch"), use ApacheBench or another load testing tool to generate fake load. The writers are claiming that it took up to 30s to open up an instance; I'd be curious to see the average, median and general statistics about their instance start times. By the way, this is also good advice for other cloud services such as ELB. *Cryptography signing time*: The writers compare the time to sign a token from their local laptop to the time it took on frontend instances. I'd rather see a comparison using GCE and Managed VM instances to run the signing code. Signing time is dependent on more variables than just the listed speed of the CPU and RAM space. Can't comment without further details. *Cache*: It sounds like the writers were using shared memcache and were experiencing cache invalidation. If they're relying on memcache so much, they should have paid for dedicated memcache space. *UI*: The post you linked to was written last year, before the new Google Cloud Console was launched ( cloud.google.com/console ) so the UI is getting much, much better. I don't think this item applies. And frankly complaining about long names for backup data strikes me as weird anyways; many enterprise level backup apps have even worse UIs. The blog post authors note - in the ending - that if they had to do it again, they would use Amazon Web Services. I'll leave this last thought: EA has another game backend hosted on Amazon: it's called the latest version of SimCity released in 2013: http://www.reddit.com/r/SimCity/comments/19xx7d/trying_some_technical_analysis_of_the_server/ . And that game has a rating of 1.7 stars out of 5 on Amazon's store because of how badly the networking and DRM code was done: http://www.amazon.com/Electronic-Arts-71481-SimCity-Standard/dp/B007VTVRFA . Frankly, the problem is not the cloud service that the writers picked. The problem is that EA has a poor track record of designing game backends. I say that as a person who bought SimCity myself. So to directly answer your question, Mr. Foster, I would say to build your web app wherever you want to. Just pay attention to the docs and ask questions if you're puzzled about something. We're all very friendly on this mailing list :-). I wouldn't take the blog post you linked to very seriously - I think they missed a lot of things that would have been caught if they had more detailed discussions of their app requirements. On Tue, Aug 5, 2014 at 3:58 PM, Jeff Schnitzer <[email protected]> wrote: > On Tue, Aug 5, 2014 at 9:25 AM, Joshua Smith <[email protected]> > wrote: > >> >> Brandon made a pretty good case for this a long time ago. And he >> certainly put a lot of time and effort into it. >> >> > Brandon made a case for breaking your application down into zillions of > separate appids that all communicate with REST calls. I don't think we need > to rehash that debate. > If I recall that thread correctly, one of the major issues that the app was facing was that intra- and inter-app urlfetches (even to other app IDs owned by the same owner) were still subject to the default urlfetch throttles, and some requests were failing due to safety quotas. ----------------- -Vinny P Technology & Media Consultant Chicago, IL App Engine Code Samples: http://www.learntogoogleit.com -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/d/optout.
