+1 Interesting suggestion on pricing as a sum of response times, which is what a user should be worried about, not tinkering with the scheduler.
On Fri, May 20, 2011 at 7:41 PM, johnP <[email protected]> wrote: > > One more point. We all expected prices to increase. What was a > surprise is for the incentive model to flip as much as it did. > > Maybe a compromise pricing model is not based on # of instances, but > on sum of response times? This would eliminate the customer paying > for inefficiencies in the scheduler. Would return the customer value > proposition to exactly "Pay for what you use". And would bill the > same resource you are intending to bill. Maybe it's a semantic > difference, but one that would retain the attractiveness of > Appengine's original, amazing, revolutionary customer promise. > > johnP > > > On May 20, 6:56 am, johnP <[email protected]> wrote: > > Wow. So many fundamental design assumptions are being turned on their > > heads with the new incentive model!!! > > > > It is unfortunate that Google failed to make the 100% granular cost > > model work. The promise that made Appengine attractive was: You build > > an app (adhering to our limitations). We will make it scale, and you > > pay only for what you use. This was a clear promise that only an > > amazing company could provide. > > > > But as time went on, the promise has crumbled, brick by brick. > > - The limitations became more intolerable (No SSL, No Data backups, > > Reliability and uptime, > 2,500 open issues in the bug tracker). > > - The 'build it and we will scale it' promise retracted to "build it > > and we will scale IF your response time is lower than 800 ms (wasn't > > 600ms also mentioned?)." > > - The 'pay for what you use' promise has become, 'Amazon charges this > > way - we can too." > > - Finally, "Our database architecture was wrong. Pay to migrate to > > our new datastore, which has the advantage of being reliable." > > > > Google has been stating recently, "The new pricing makes it viable for > > us to continue to provide Appengine." But Appengine will exist into > > the future only if it is profitable for Google *AND* if customers find > > it valuable. > > > > It would be nice to see the Appengine value proposition restated. > > Given the new incentive model, what makes Appengine amazing? > > > > Thanks for listening. > > > > On May 20, 5:56 am, "Raymond C." <[email protected]> wrote: > > > > > > > > > > > > > > > > > As I know MapReduce rely on a relative large number of instances (on > top of > > > the normal traffic) to perform the calculation efficiently in parallel. > > > Under the new pricing model each instance will cost you 15min idle > time > > > after the job is done. Therefore 15min times n instances are wasted > (cost > > > you without using them). If n=8 (for a relatively small and slow > task), > > > there will be an additional cost of $0.16 just for one MapReduce > operation. > > > It will be very costly if you are doing sth like hourly job like > reporting. > > > 8 instances will cost you $115.2/month for hourly MapReduce task, > which is > > > *in additional* to the cost of the actual run time, just for MapReduce > > > tasks. > > > > > My question is, is it still a flexible mechanism on AppEngine? Or we > should > > > rely on external service to do these kind of calculation? (complex but > could > > > be more cost effective?) > > -- > 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.
