I haven't given up on GAE yet, although I came pretty close to it after walking out of that I/O session. I've actually spent almost all my free time over the last few weeks trying to get the next Objectify release out the door.
By DI the speaker meant Guice, Spring, CDI, etc. By AOP he meant the interceptors that Guice, Spring, etc can create for you. I've never been a fan of Spring, but my app would be unmaintainable without some sort of DI system (I use Guice). And I tend to use a fair number of interceptors, especially around JAX-RS methods. If someone had told me at the beginning "if you want to use GAE, you must hand-wire your services and copy-paste shared logic all over your code", I would have gone elsewhere. GAE is a productive environment, but all that productivity will disappear if I have to write spaghetti code to perform in production. The number of classes and jax-rs endpoints in my app is continuing to expand, and all the classloading is pushing up my startup time. I'm never going to have a large number of instances; as a ticketing system, people tend to come to my website when they want to buy something. High value per customer, but very bursty traffic. The speaker had one suggestion that looks valuable - use Dagger instead of Guice - which might help, although it doesn't look like Dagger supports interceptors, so that may be out. I've been doing a lot of consulting on other people's Heroku/Appfog/EC2/EB/etc projects (sadly, GAE consulting doesn't pay well). Honestly I think no-autoscaling is better than GAE/Java's autoscaling. Elastic Beanstalk has the best solution - it's easy to understand, easy to configure, and doesn't produce dead user requests. Also, I forgot how much I miss being able to execute ad-hoc queries or queries that update data... and hosted MongoDB is getting cheaper. This is not to say that these other systems are better that GAE; they all have pretty serious flaws. But it's hard to get over dead user requests. Jeff On Thu, May 16, 2013 at 8:08 PM, Nick <naoku...@gmail.com> wrote: > I don't really understand the philosophy currently in play here. > > Obviously when load goes up, new instances need to be spun up. That makes > sense. > The idea that its better for the last invoker to wait 5-10 seconds, rather > than sharing a reduced latency of say 0.5 seconds by being sent to a > 'fully' utilised instance just doesn't make sense to me. The > characteristics of this also result in being more punishing when you have a > low number of instances, which tends to happen if you have frequent > releases. > > It would be good to get some insight into why this approach is favoured. > > On a wider note, Jeff (or anyone else attending that panel), what in > particular did they mean by DI in this context? Spring style annotation > scanning, Guice itself, IOC in general (passing objects through > constructors/setters) or just not using purely static access patterns? > > Building large, maintainable apps without the use of IOC/DI bends my mind. > Its painful enough using the static access patterns laid out by all the > appengine APIs themselves, the idea that i'd tightly couple all my own and > all the library code I consume as well seems bonkers. > > > > > On Friday, May 17, 2013 9:21:22 AM UTC+10, jeffrey_t_b wrote: >> >> Jeff, I believe that you had asked on this list, a while ago: In what >> circumstance is it _ever_ good for user requests to see cold starts? >> >> Did you ever get an answer to that? That is the part that puzzles me >> still. Is it just too hard? Maybe they don't have a _scalable_ algorithm >> for directing requests to already-existing instances? >> >> Anyway, with all of the focus on the Compute Engine side, I wonder if >> improvements to App Engine are going to deprioritized. >> >> >> >> On Wednesday, May 15, 2013 4:52:51 PM UTC-7, Jeff Schnitzer wrote: >>> >>> I attended the "Autoscaling Java" session at Google I/O. In summary, the >>> advice is: >>> >>> * Don't use dependency injection. >>> * Don't use AOP. >>> * Hardcode configuration values as much as possible. >>> >>> In other words, go back to Java circa 2002. There was no discussion of >>> changing routing so that user requests don't see cold starts. I asked about >>> this in person - apparently they're still "talking about it" and nothing >>> has been done about it. >>> >>> I am sad. >>> >>> Jeff >>> >> -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
