Since trust wasn't one of the metrics tracked on the dashboard, it appears the GAE team forgot how much of a factor it is. It does not always follow that if it can't be measured then it doesn't exist.
I think the GAE team's actions have clearly demonstrated that developers are *not* their core constituency, they have their sights set on another target (quite possibly those who would have been interested in GAE4B). Message of The Day (from GAE): developers are expendable, but you're stuck with us. So deal. Amazon had its (technical) meltdown that lasted 3+ days. App Engine is having its (trust) meltdown. I wonder how long this one will last. I, for one, have started migrating my python apps to use Django-nonrel APIs. Coding directly against Google APIs is turning out to be a very bad idea. saidimu On Wed, May 11, 2011 at 2:18 PM, johnP <[email protected]> wrote: > > 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. > > -- 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.
