A few adjustments to App Engine’s upcoming pricing changes | Hacker News Reader

A few adjustments to App Engine’s upcoming pricing changes

googleappengine.blogspot.com

62 pointsmoultano21 comments

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.

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.

     If pricing started in line with Amazon, Azure, 
     Rackspace, Linode etc.

I don't agree, because them pricing for CPU and not for instance/hour is what separated them from the others.

And now with the new pricing scheme they are more expensive than Amazon.

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.

  > 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.

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.

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.

What bothered me the most is that they originally said the new pricing scheme is in response to customers feedback.

sigh it was also a $50 credit, not a 50% discount. It appears that what they are trying to say, and not terribly successfully is that the "customer feedback" was the need for an SLA...which is really what they are charging for...and what gets lost in all this confused information and repricing and remeasuring nonsense.

Personally, we're not big enough to really care about the SLA...

> 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.

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.

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.

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.

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).

"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.

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.

Python 2.7 will magically make all code work multithreaded. Making code written single threaded run on multiple threads at once is well known to be easy. It is a solved problem that the compiler will just take care of. Just install 2.7. It will work out-of-the-box with no bugs, and it will transform your single-threaded application into a multithreaded application. You'll have a few weeks to actually install 2.7. That should be more than enough time to do that. Once you do that, it'll just work!

Oh, and during those few weeks, we'll only charge you 10 times the amount you are paying now, instead of 20! We're not evil!

o_O

What?

"""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.

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

Fair point. I sometimes ship bugs too.

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.

Reply on news.ycombinator.com