Only one of the article's points is related to Java and the long startup issue. And it fully applies to Python as well - GAE does not load large, sophisticated Python apps in under a second. Looking at recent reviews of the app (EA's "The Simpsons: Tapped Out") suggests they may still be having server issues (although it's hard to tell what's the fault of the client).
Going through them point-by-point: * Hidden Arbitrary Quota Limits - no idea if this has changed, but you can probably be certain there are some still (although maybe not this particular issue). If you're ramping up to "EA game" scale, it's probably a good idea to frequently check in with support. * Hidden Arbitrary Library Behaviour - from comments in the article, the specific issue about header lengths seems to still be an issue. It's not clear if the failure behavior is the same (silent drop), but you can assume that as you push the boundaries of GAE you will bump into a few undocumented quirks like this. While certainly a legitimate criticism of GAE, it's not unique to GAE - pretty much every platform and library has quirky quasi-documented behavior that you will only discover at runtime, usually in ways that displease users. GAE is a little tougher because it's not opensource, but it's actually better documented than most - although, as the article points out, it's not perfect. * No pre-scaling mechanism - this is true, but the answer from GAE support (which the author dismisses) is a legitimate answer. You basically hit the new version of your app with fake load to spin up a bunch of instances. It's not as graceful as having a button somewhere, but it will work. Use 'ab' to flood thenewversion.yourapp.appspot.com with requests. * The scheduler loop of death - IMHO, user-facing startup requests are GAE's biggest problem right now. It's more of a problem with Java and less of a problem with Python and pretty much nonexistent with Go, but let's face it, this one issue is not why you pick development a platform. So let's say you want to use Java. To avoid the 'loop of death' you need to keep app startup times reasonable. This gets harder as your app gets bigger. You can partially fix it by running larger instances (F4 starts up a lot faster) but that costs $$. You can partially fix it by streamlining your startup flow (mostly by lazy initialization). You can tell the EA devs were using some standard Java dev patterns that should not be used on GAE - in particular, pre-warming caches is a terrible idea. However, even if you keep startup times low enough to prevent the loop of death, some user requests will still see cold starts. You can try to tune this with lots of resident instances but I don't think this works very well and it only reduces the effect. In truth, it doesn't matter if a request comes back in 20s or never; the user has already reloaded the page or assumed the app crashed or whatnot. Huge back mark. Star this issue: https://code.google.com/p/googleappengine/issues/detail?id=7865 * Under-powered application front-end instances - this is true. It's also true with Heroku and pretty much every other PaaS provider. * Under-performing Google Data Store and under-provisioned Cache - this is the first one that seems to no longer be true. Datastore access seems to be quite a bit faster these days, and if you want dedicated memcache you can buy it. * User Interface for Androids - I don't know what this is about. The admin console is actually pretty good. The backup functionality is not great, true. But the logs - especially the new logs console - is *amazing* and vastly better than anything I've seen on any other PaaS platform. The only thing that bugs me is that it's hard to debug data issues without a full query language like SQL - the datastore viewer is really primitive. And having worked in EA Online, the GAE console is lightyears ahead of anything they had during my era. I don't really understand what he's comparing it to. There are some pieces of advice I would have given to that team before they started: * Don't go "all in" with every GAE service. Just use the core features that bring the most value: the datastore, the task queue, memcache, blobstore. Avoid the edge features that are less well maintained and lock you into proprietary protocols or implementations - Channel, Endpoints, XMPP, Authentication. * Lazy initialize everything. Startup time is the #1 failing of GAE. * GAE is not "all or nothing". Some components are better off run in other clouds, maybe even GCE. Latency is not that big. * Load test. Running game backends at EA scale is hard. I really would love to have seen them try this with ElasticBeanstalk, which, last time I tried it, was a _disaster_. There's a lot of things about GAE that suck, but they start to look a lot better when you compare GAE to the alternatives. Jeff On Tue, Aug 5, 2014 at 7:01 AM, Joshua Smith <mrjoshuaesm...@gmail.com> wrote: > As far as I am aware, that’s all pretty much still true. > > A couple points though: > > 1. They were using Java. If they used Python (or better yet, Go), two of > those issues would disappear because Python and Go can both spin up a new > instance in less than a second. If you are doing a big production scaling > mess like they are, using Java on GAE is a REALLY bad choice. A REALLY, > REALLY, REALLY BAD CHOICE. Don’t do it. > > 2. If you do not expect massive usage, then this article is completely > irrelevant to you. I have several applications with just thousands of daily > users, and I’ve never had an issue with any of this stuff. > > The only complaint I have about GAE is the lack of API stability. I hate > that I need to go back and change my applications that are working > perfectly fine because Google decided to migrate from one datastore to > another, or one python version to another, or whatever. But even that is > balanced by the fact that they leave the deprecated stuff working for THREE > YEARS, which is really kind of amazing. > > -Joshua > > On Aug 5, 2014, at 1:37 AM, James Foster <jamesfos...@gmail.com> 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?) > > > -- > 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 google-appengine+unsubscr...@googlegroups.com. > To post to this group, send email to google-appengine@googlegroups.com. > Visit this group at http://groups.google.com/group/google-appengine. > For more options, visit https://groups.google.com/d/optout. > > > -- > 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 google-appengine+unsubscr...@googlegroups.com. > To post to this group, send email to google-appengine@googlegroups.com. > Visit this group at http://groups.google.com/group/google-appengine. > For more options, visit https://groups.google.com/d/optout. > -- 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 google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/d/optout.
