A few comments inline. On Tue, May 31, 2011 at 14:18, Jeff Schnitzer <[email protected]> wrote: > Some thoughts on your comments: > > I don't think the amount of RAM supplied to a frontend instance is > particularly relevant - in most web architectures, frontend instances > just shuttle data back and forth between the user and backend data > services (datastore, memcache, facebook, etc). So it's really hard to > compare $/MB figures between Appengine and, say, EC2. > > A better measure for frontend instances is $ per request throughput. > For each dollar spent on frontend instances, how many requests can you > serve? It's certainly going to be a major issue with single-threaded > python, especially if you make urlfetches to latent services. On the > other hand, if GAE's Java servers achieve the same levels of > concurrency that standard Java appservers achieve, then the limit will > be CPU power - and, to my knowledge, nobody has made any comparative > $/CPU measurements with GAE.
I've thought about $/request throughput too, particularly since I use Python.... > > On the other hand, $/MB is a perfectly useful way of measuring GAE > *backends* since RAM is often the primary constraint of a backend > service. For many applications, comparing GAE backends to Other Cloud > backends is apples-to-apples comparison, and GAE's value is > extraordinarily poor. > > I also totally agree with your point about excluding datastore pricing > from this comparison, since it is charged separately (as is Amazon's > SimpleDB). However, we need to start looking in greater detail at the > pricing of datastore operations, because it sounds like this may also > be a very significant price hike, and possibly will affect people much > more than the instance pricing that everyone has been talking about. Excluding datastore pricing is a fair point. I also think defining datastore pricing is important. From a discussion with Greg (last IRC office hours), it sounded like the new pricing is going to be somewhere around 25% above the current HR datastore pricing. Honestly, that is not as bad as I first thought it was going to be. Of course for master-slave apps it is going to be very noticeable. > > Jeff > > On Tue, May 31, 2011 at 10:02 AM, Ugorji <[email protected]> wrote: >> I want to continue to use GAE. I understand the value immensely, and I >> invested a whole year into building a significant codebase around it and its >> limitations without caring about lock-in. If I can help keep Google honest >> and encourage them to revise their pricing so it is more palatable, then I >> am a happy camper. The alternative (re-writing my code and taking on some of >> the scalability features GAE gives me for free) is very unattractive. >> Having said that, I think the datastore in GAE is the biggest selling point >> which is hardest to reproduce. This is what is distributed geographically. >> However, the price for that is separate from the hosting. The hosting is a >> compute instance (with CPU and RAM) running your code on a simplified and >> uniform stack. I think there should be a premium for the hosting, but a 4X >> to 8X should be explainable to the customers or revised. >> To your points (and I am making assumptions here just to respond to your >> points): >> - HR is charged separately from hosting (so should not be factored into why >> the GAE hosting is significantly more expensive) >> - simplification of stack to just app code makes operator management and app >> scaling easier for the admins, not harder (I worked with BEA/Oracle team >> where we created the JVM without OS, and that was a big selling point that >> Ops became much cheaper. It makes it cheaper than what u get for managed >> hosting.) >> - isolated instances (ie the instances don't communicate or know about each >> other) makes app scaling easier, not harder. (contrast with your typical >> J2EE app server where instances communicate via multicast or unicast and >> keep config and stuff in sync and auto deploy in live instances and maintain >> sessions in-process, etc). >> - I read somewhere that all app instances share the same memcache instance, >> and there's no guarantees on anything, so memcache implementation in AE is >> pretty simplistic, and can easily be reproduced on a VPS >> GAE main expensive piece is in the datastore scalability and features built >> on it, and that is charged separately. Most of the other bundled features >> which can be charged are charged separately. >> In summary, I'm not underestimating the GAE value (at all). I worked at >> BEA/Oracle for 10 years with WebLogic in engineering and with customers (I >> left last year to focus on some startup ideas) and appreciate the simplicity >> of the GAE model. I just think that a 4X or 8X cost against AWS seems like a >> high premium, and it would be nice to see some justification/explanation in >> Greg's response. >> NB. Regarding AWS outage, this was caused by storage problem, not the actual >> EC2 instances. The closest analogue in GAE land is the datastore, which is >> priced separately from hosting. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Google App Engine" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/google-appengine?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
