
A few adjustments to App Engine’s upcoming pricing changes - moultano
http://googleappengine.blogspot.com/2011/09/few-adjustments-to-app-engines-upcoming.html
======
programminggeek
AppEngine is a fantastic product, but every time I started using it I always
had that nagging feeling that at some point the other shoe would drop (higher
pricing, service outages, worse vendor lock-in) and the whole pricing change
is about what I expected to happen eventually.

AppEngine over promised and under delivered. Now they're back pedaling in
hopes of finding the sweet spot. It's costing them customers and making them
look 2nd rate. I think most devs would have preferred if Google started with
realistic pricing and worked their way down.

It's simple human psychology, if you set an expectation and surpass it, people
are happy, if you fall short, people are unhappy. If pricing started in line
with Amazon, Azure, Rackspace, Linode etc. people would say, "Ok, that's
fair." and if Google made it cheaper, people would be ecstatic. Instead, they
fell short and made people mad. Now they have to reset the expectations and
hope to not screw up again.

Take this as a lesson, under promise and over deliver. Always.

~~~
bane
Google is in serious need of a professional community interaction manager,
this bouncing about of plans and pricing, lack of a conversation with the
customers, etc. just reeks of amateur hour, not a $30billion/yr company.

------
StavrosK
Ah, much better. They've fixed some things they should have done from the
start (a few more free hours per day for some leeway, charges not taking
effect before Python 2.7 is available), and new, more useful features (min
idle instances, rather than pay $9/mo).

I was unsure about using GAE for new projects, but I'm definitely more pleased
again now. With the ease of migration away from it with Django-nonrel, I will
definitely be giving it a shot for production apps that are a good fit for it.

~~~
biot

      > charges not taking effect before Python 2.7
    

Almost. "We'll continue to offer the 50% discount on instance prices until
December 1st, at which time Python 2.7 should be available."

The new pricing goes into effect November 1st. For the goodwill that would
result, it would have been much nicer of them to keep the pricing as-is until
2.7 was rolled out rather than charging a rate that is too high (albeit
discounted by 50%) because of a platform limitation, then correcting it 30
days later.

~~~
StavrosK
Ah, I didn't notice that, thank you. You are correct, that would have been
much better.

Fortunately, it's pretty easy to convert to Python 2.7, so hopefully people
will do it quickly.

------
bane
Better Google...Better...

Finally some reasonable communication, reasonable pricing models (extended
discount) that don't penalize certain platform users (Python) over others
(Java), better information on pricing and analysis of applications, reasonable
free instance hours etc.

Keep this up and my rage will finally start to simmer down.

Now one thing that still hasn't been addressed is the following catch-22.

It's my understanding that in order to take advantage of scaling, user will
have to pay a minimum $9/month (or whatever it is) fee. However, free users
are resource capped. However, if you pay for scalability, but never need it
for some reason, or only need it a couple times a year, you may as well have
just stayed free -- otherwise you're out $108/year!

Still it's too bad that this pricing change and the charge-metrics are such a
moving target, it's virtually impossible to figure out how to optimize for the
change since any work somebody does to fix a 1000% price increase might go out
the window tomorrow as pricing gets revised, or a metric gets changed (we've
decided to measure electron transfer across system buses!).

This is a huge PR lesson -- heck this could be a 2 semester course! Google
should have fixed the major pricing issues from the beginning, set a fixed
target for people to work towards, been earlier with discounts and
understanding language penalties, actually (shock) _communicated_ with their
developer base and done some actual price comparisons across their entire
hosting environment to realize what a huge change this is introducing.

It's clear even Google didn't realize what a clusterfuck the new pricing model
has introduced and Google's biggest problem, communication, has been the root
of all the trouble.

~~~
StavrosK
> It's my understanding that in order to take advantage of scaling, user will
> have to pay a minimum $9/month (or whatever it is) fee. However, free users
> are resource capped. However, if you pay for scalability, but never need it
> for some reason, or only need it a couple times a year, you may as well have
> just stayed free -- otherwise you're out $108/year!

Looks like they're retiring that. Instead, you'll have "min active instances",
which you can set to 1 to always have a multi-threaded instance preloaded, and
still stay under the free tier, while only paying for anything that goes over
it.

Win/win, it seems.

~~~
bane
Interesting...our new monthly bill is showing a strange ~$.30/day charge
increase over everything else which averages out to about $9/mo. I'm looking
forward to them fixing the new billing preview a bit more and will take
another look.

If you are right, their solution sounds optimal. It's been my understanding
that what the $9/mo was _really_ for was the SLA, but frankly I could give a
hoot about the SLA, but I _need_ the instance scalability.

~~~
StavrosK
The $9, as far as I can recall, was for the three always-on instances you got.
Since they're retiring those, allowing you to set your own, you can take that
off the bill. It sounds to me like you can be on the free plan with enabled
billing and only pay for overages.

------
briggers
Whew. I could have optimized and coped with the initially announced rates, but
this is a hugely welcome set of changes.

For a solo technical founder running multiple businesses, AppEngine is an
incredible product. Thank you Google, for doing all my sysadmin and scaling
for me at an incredible price. I'm really looking forward to scaling up and
paying more.

~~~
wiradikusuma
I'm in the same page with you. I kind of upset with the price changes, but I
thought it as a stick to optimize. Reading this announcement increases my
trust to the service.

It might not be the best platform, but it serves me well so far (particularly
because I'm a solo founder and don't have the expertise to manage server and
stuff).

------
georgemcbay
"Python 2.7 will include support for concurrent requests, which could further
lower your costs."

Could?

For me the biggest hindrance to using GAE isn't even the new pricing (though
the new pricing makes it far less compelling than it was compared to other
services), but rather the uncertainty of virtually everything.

The fact they they aren't even sure how future developments will impact their
own pricing pretty much sums things up and ensures that I can't invest a lot
of time developing something tied to their platform.

~~~
supersillyus
How could they possibly know with certainty that concurrent request support in
Python will lower your costs? For one, you may not be using Python. Or, you
may not enable concurrent requests. Or, your app may be structured in such a
way that concurrent requests don't make a difference, either in function or in
pricing.

It's fine to be distrustful of AppEngine, but the example you've picked to
illustrate the uncertainty is silly.

------
SpikeGronim
"""Always-On reflected in bills: Currently the side-by-side bills still
include the cost of always-on even though it will be retired when the new
pricing launches (to be replaced by min idle instances). We’re working on a
fix for this. Until then you can comfortably subtract 48 instance hours per
day from the estimate. """

Please don't provide a calculator for a new billing system and then ask your
customers to manually adjust the output of the calculator. Terrible user
experience and in this case it inflates the apparent bill.

~~~
StavrosK
> We’re working on a fix for this. Until then you can comfortably subtract 48
> instance hours per day from the estimate.

~~~
SpikeGronim
Fair point. I sometimes ship bugs too.

------
retrofit_brain
We are evaluating Cloud foundry (Java GWT App) and so far changes seem doable
to port. The reason cloud foundry is viable is that there is no lock in and if
one provider flips another one is just round the corner.

