This has the potential become a breach of trust that will never be forgotten/forgiven by the developer community. There are lots of man- years devoted to the platform, based on trust and belief that the essential value proposition will not suddenly change (by an order of magnitude!!).
One action can indelibly destroy trust. Think about that. You might permanently lose the trust of developers. Bloggers will always note, "Yes, your business or school can start using Google Apps. But Google has suddenly raised pricing in the past, and you must assume they will do it again." Or "Yes, Android is free right now. But Google has broken trust with developers before." Ballmer must be sharpening his tongue with witticism on the topic of, "Do no Evil" So please, be careful with this move. johnP On May 11, 10:57 am, Philip <[email protected]> wrote: > Hi Greg, > > suppose there will be an issue with the python runtime resulting in > very high latencies for a period of time, do we have to pay for the > extra instances that are needed? > > The instances chart on the dashboard does also contain "active > instances", can we orientate at that number (+-10%) for the new > scheduling algorithm? > > Thanks for any answer. > > On May 11, 7:46 pm, "Gregory D'alesandre" <[email protected]> wrote: > > > > > > > > > On Wed, May 11, 2011 at 7:19 AM, Vinuth Madinur > > <[email protected]>wrote: > > > > Important concerns raised on the blog comment: > > > > <Quoting @Deep> > > > > "Due to customer feedback and to better service memory intensive > > > applications, we will be eliminating CPU hours." > > > > I can't imagine anyone actually requested this. That's corporate bs for > > > "we > > > are making this unpopular change but going to pretend customers requested > > > it". > > > Hi Vinuth, I can imagine how it sounds like corporate bs, but in reality > > with the current CPU-only based model, we have a number of limitations that > > many potential customers were unhappy about. High latency apps essentially > > hold on to lots of memory without any CPU usage, this means that we can't > > scale it because it would just continue to gobble up more memory unbounded. > > Under the new model any app can scale, but will be paying for the memory as > > well as the cpu used, this opens App Engine up to a number of > > developers/applications that weren't able to use it before and wanted to. > > > > "Instead, our serving infrastructure will charge for the number of > > > Instances running" > > > > As companies age, they start looking for ways to make free money without > > > actual work. (Think of the big banks.) Sad to see signs Google is going > > > that > > > way. If this move results in charging even for instances sitting idly > > > (while > > > we don't even have direct control over the # of instances!) that would be > > > a > > > pretty big change from "no evil". My app has light load and is set to > > > multithreaded yet AE keeps spawning new instances for no reason. I refuse > > > to > > > pay for those. > > > This is why we are working on our scheduler, even idle instances cost > > resources, not CPU but essentially the opportunity cost of other > > applications that could run but can't because the idle instance is taking up > > space. Our goal is to only run the number of instances you need for your > > traffic. > > > I hope that helps! > > > Greg > > > > "These instances will be similar to the instances you can see in the Admin > > > Console today with the exception that we will be improving our scheduler > > > to > > > ensure each instance has an appropriate level of utilization." > > > > Make the scheduler calculate costs based on CPU usage and I might stay. If > > > you try to charge me for idle CPU cycles (in whichever instance) I can't > > > see > > > any reason not to just rent a VM instead. That's the point when Google > > > loses > > > any advantage over VMs. > > > > </Quote> > > > > On Wed, May 11, 2011 at 7:37 PM, stevep <[email protected]> wrote: > > > >> My $0.02 cents (old model, $0.08 new Google estimate, $1.00 other user > > >> estimates). > > > >> Having done a lot of work in finance for a large tech company, my main > > >> disappointment with the new pricing is the me-too approach from > > >> Google. Great engineering, but very lax with respect to innovation for > > >> the whole product. In this case pricing. > > > >> GAE had promised more of an activity-based model. Great I thought, an > > >> application of Activity Based Costing to a business. ABC is truly a > > >> gift for businesses WTR good decision making. However, the discipline > > >> needed to apply it often goes lacking. The main area where the lack of > > >> discipline applies is upper management decision making. ABC is a > > >> disciplined approach to running your business. It lays bare good > > >> operations, and forces poor management decisions into the open -- > > >> which is why upper managers hate it. Anyway, enough theory. > > > >> Here's the example the applies to GAE. The $0.01 charge per 10,000 > > >> files. For nearly the entire time I've been in this forum, I've heard > > >> Ikai and others describe the efficiency and sophistication of GAE > > >> content delivery network. "Use static files because of our great > > >> efficiency" or something like that. Unless I'm mistaken, there is > > >> nothing that would suggest using ABC that the number of files drives > > >> costs at $0.01 per 10K. > > > >> Another take on this is a question someone asked long ago in the > > >> forums about why static files bandwidth charges under High Replication > > >> got the higher bandwidth charge when the system used to deliver the > > >> bandwidth is THE SAME system used for Master/Slave. Never answered of > > >> course. > > > >> The penny per 10K files is simply Google lazily looking at AWS and > > >> saying, "Hey, this is how we can really juice the profit, and compare > > >> well with AWS." The problem with these types of decisions that the > > >> pricing system becomes arbitrary, and guided ultimately by board-room > > >> decisions rather than operating discipline. > > > >> I'm happy that GAE is upping its pricing as it is a clear indication > > >> that this may become a viable P/L driven business. However, seeing > > >> this type of mee-too-ism in the pricing area rather than something > > >> such as the original promise from GAE strongly suggests that Google > > >> sees little value in hiring great accountants in addition to great > > >> engineers is disappointing. I say that having been part of Hewlett > > >> Packard during its great years in InkJet printers where things like > > >> ABC delivered incredible value for consumers, and then seeing that > > >> morph into a company that stopped being disciplined, and started to > > >> think solely about how to juice its quarterly profits. Google is > > >> simply coming out the gates appearing like the sad shell of a company > > >> I left. Larry suggests he's not a quarterly-profit focused guy, but > > >> this pricing tells me that he doesn't understand how things like > > >> taking the simple route on pricing decisions because you don't think > > >> great decision-based accounting systems are important MAKES YOUR > > >> ORGANIZATION LAX. > > > >> </rant mode> > > > >> Still happy, and somewhat trustful of GAE. Sorry to see that the > > >> pricing decisions look mostly like "...this compares well to AWS." Oh > > >> well. > > > >> -- > > >> 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.
