Hear, hear. This is a clear case of moral hazard. The incentives to optimize and reduce latency are backwards, since more efficiency leads directly to reduced revenue for Google. We just have to trust that Google wouldn't screw us?
Like Jeff says, there's a large amount of goodwill, but there has to be some give from Google's part. On Saturday, March 17, 2012 12:26:50 AM UTC-4, Jeff Schnitzer wrote: > > To repeat that important point: > > The problem with the current (new) billing model is that when the > service provider screws up, the customer pays. In the long run this > can only alienate the customer. How many times do I want to call my > cellphone provider and tell them that they screwed up my bill, even if > they apologize and give me a credit? Having actually gone through > exactly this scenario, the answer is "twice" before I change > providers. > > Google has a significant reserve of goodwill with me, so it would take > a lot more than a few billing issues to make me choose another > platform. But I can't imagine that too many other people feel the > same way. > > The solution to this *seems* pretty straightforward - Google should > "stop the clock" when executing internal RPC calls. We're already > paying for datastore operations. If you need to change what a > datastore operation costs to make it revenue-neutral, so be it. But > we've gone a step backwards - the whole point of moving to > bill-by-datastore-ops was to make pricing more transparent, yet what > we've actually produced is "bill by datastore ops plus a random > additional amount of instance hours depending on how sick the > datastore happens to be right now". We were better off with > api_cpu_ms, at least that was consistent. > > Actually, when you think about it, charging instance hours only makes > sense for single-threaded apps. In multithreaded apps, concurrency is > dependent on CPU usage, so charging by the megacycle really does make > sense. Really, single-threaded GAE needs a totally different billing > model than multi-threaded GAE. > > Jeff > > On Fri, Mar 16, 2012 at 10:34 PM, Brandon Wirtz <drak...@digerat.com> > wrote: > > More seriously… > > > > > > > > Waleed has one of those apps that I believe the concistency model makes > MS > > the “right” choice for. Because eventual is not as instant as you might > > want. > > > > That said, I think MS seems to be a lot more temperamental in terms of > how > > fast it performs and how the scheduler responds to conditions. > > > > > > > > 1200 is a crap ton, and while I realize the SLA doesn’t cover MS. This > seems > > like a “Billing” error kind of thing that Google should take some > > responsibility for. > > > > > > > > > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Google App Engine" group. > > To post to this group, send email to google-appengine@googlegroups.com. > > To unsubscribe from this group, send email to > > google-appengine+unsubscr...@googlegroups.com. > > 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 view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/8j0IhBVMbV4J. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
