Outrageous Gae New Pricing Increase

[James Gilliam]

Here is a spreadsheet for my price increase based on the new pricing estimates

https://docs.google.com/spreadsheet/ccc?key=0Ao2_-6cLgYDldDZGTjlrVnFkb0c5MWZJOVh0RTBfRXc&hl=en_US#gid=0

4567% increase

[Gregory D'alesandre]

Hi James,

Have you tried to do any optimizations, and if so, is this still the case for you?  If it is, let me know your appid and I can take a look to see if there are optimizations that can be done.

Greg

--
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/-/ea4BcLQ6TZgJ.
To post to this group, send email to google-a...@googlegroups.com.
To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.

[Robert Kluin]

The infinite increase is a real bummer.

[renderpaz]

From the looks of your data, it doesn't seem you have any need for a
massively scaling web host. Why did you choose GAE in the first
place?

If your answer is, "One day I may need to handle 1000 qps" - then I
think the pricing is perfectly fair, you can almost view it as
insurance. Note, i'm saying the price is fair, not the increase. I
can understand your frustration with Google's handling of this, but
that doesn't mean they should make the service unsustainable.

But maybe there is a solution...
I'm going to take a guess and say that most of your cost is instance
hours - make sure you change your min-pending latency to 15s and your
max idle instances to 1

On Sep 6, 11:15 pm, Robert Kluin <robert.kl...@gmail.com> wrote:
> The infinite increase is a real bummer.
>
>
>
> On Thu, Sep 1, 2011 at 11:03, James Gilliam <jimgill...@gmail.com> wrote:
> > Here is a spreadsheet for my price increase based on the new pricing
> > estimates

> >https://docs.google.com/spreadsheet/ccc?key=0Ao2_-6cLgYDldDZGTjlrVnFk...

[Alex Popescu]

On Wednesday, September 7, 2011 9:40:12 AM UTC+3, renderpaz wrote:

From the looks of your data, it doesn't seem you have any need for a
massively scaling web host.  Why did you choose GAE in the first
place?

If your answer is, "One day I may need to handle 1000 qps" - then I
think the pricing is perfectly fair, you can almost view it as
insurance.  Note, i'm saying the price is fair, not the increase.  I
can understand your frustration with Google's handling of this, but
that doesn't mean they should make the service unsustainable.

I'd assume that for the majority the answer is not the one you are suggesting but rather:

1/ simplicity of deployment

2/ curiosity

3/ the free tier/quota

And I'd also assume the frustration is the result of the following facts:

1/ people finding the pricing increase unreasonable (while usually subjective, please note that I'm referring to the increase and not the price itself)

2/ the short notice compared to how long GAE has been in beta.

I don't think we'd be seeing these reactions if Google would have announced the new pricing becoming active end of 2011. 4 months would have been enough for a lot of us to rethink  our applications, optimize, find alternative solutions. But how much of that can you do on such a short notice? (Aug.31st vs mid-Sept).

I'm tempted to speculate for the 3rd time here and say that it looks like Google's decision is based on analyzing three major use cases:

1. large paying customers: the alternatives for them would be more expensive and adding to that the costs of migration, the majority of them will just have to accept the new pricing

2. small paying customers: between finding similarly priced alternatives and being offline until they complete the migration, the majority of them will just have to accept the new pricing. Even if some of them will leave in the next 3-6 months, the revenue generated from the new pricing is equivalent with having them as customers for 12-15months.

3. very small paying customers/free quota customers: their decision is pretty irrelevant. If some of them stay then they'll generate some revenue. If they leave then there's a cost cut.

As James, I'm one of those very small paying customers/free quota customers where the price increase is unaffordable (in my case I'm going from a couple of bucks/month to $645/month). 

A://

[Mike Wesner]

Please stop telling people to use these settings. Nobody will use the
damn service if they have to wait for seconds for a request to load.
Please either setup an app to run well and pay for it or use something
else.

I am a bit surprised that 15s is even an option for min-pending
latency... that is just crazy.

[Tim]

On Wednesday, 7 September 2011 15:11:58 UTC+1, Mike Wesner wrote:

Please stop telling people to use these settings.  Nobody will use the
damn service if they have to wait for seconds for a request to load.
Please either setup an app to run well and pay for it or use something
else.

I am a bit surprised that 15s is even an option for min-pending
latency... that is just crazy.

I partially agree with you but there are some valid cases where latency of 10 or 15 seconds isn't an issue: for example, most of the "expense" for my app is the single-page-webapp front-end doing lazy writebacks of updates by AJAX calls (it buffers updates in the client code until there's a sizable chunk of updates or a period where the user doesn't make any updates, like the auto-save of drafts in gmail). 

So a few seconds of pending latency is not an issue. I already have to cope with the fact the user may apply more changes to the data while the writeback is in flight, or the writeback fails and has to be retried, so upping the latency isn't too much of an issue. Of course, the same latency when READING the data in the first place (the app is served mostly from static files, but the javascript then loads the user data via AJAX calls as the page renders) is less than ideal, so I agree with you in the general case.

That's why if the scheduler works more like it now sounds (see my comments on another thread about what the "15 minute" minimum count actually means), then I'm happy to experiment with my latency (of course, it would be even nicer to be able to specify the latency per handler in the app.yaml or prioritise handlers or similar), and then it comes down to whether I can get the number of datastore write operations down to a reasonable number (which might involve changing the way I model the data so every chunk of updates can be written by a single write call and then making the read operation more complex as it has to effectively unpack a collection of deltas, each of which can be modifications to a number of logical records, and apply them to form a consolidated set of data records).

--

T