Hacker News new | past | comments | ask | show | jobs | submit login
The Year Ahead for Google App Engine (googleappengine.blogspot.com)
83 points by vanni on May 10, 2011 | hide | past | web | favorite | 29 comments

This will be a HUGE pricing increase.

My applications are heavily optimized for low CPU usage, but now they removed CPU usage based charging and added a bunch of new charges that I haven't optimized for. I did some initial calculations and basically unless I do some major redesigning I will face a 61x price increase. Based on chatting with some other GAE users, I can confirm that such huge price increases aren't limited to just me.

This is quite ridiculous. I feel like I am part of a bait-n-switch scam.

Uhh yeah, 0.01/10k datastore operations? lol. This is highway robbery.

Wow, what a day... I had an ear-to-ear grin this morning when I learned of support for Go on App Engine. I'm releasing my 3rd GAE app this week (Python) and have big plans to dive into what would've been my 4th and 5th...

Now I've just finished reading the announcements about the road ahead for pricing and support, and I'm having hard time trying not to be upset...

y = mx + b

The big selling point of GAE for me was minimizing the cost of 'b'... I don't mind paying a little extra 'm' if it allows me to avoid 'b'.

For billing-enabled apps, it appears the smooth real-time transition between free and paid will no longer be supported. Now there will be a fixed cost associated with every app every month. Gone is my fantasy of launching great little apps and marketing them until one of them happens to hit the jackpot (possibly by pointing out another great idea -- "the next big thing").

This completely changes the dynamic of GAE for me. Now, If I'm going to support an app, it's going to cost me money whether it's used or not.

$9 per app per month doesn't sound like much for scalable hosting, but sometimes the best ideas stem from little baby ideas, and little baby ideas are prematurely eliminated from consideration if it costs $9 a month to host them.

Why can't you start with a free app and later upgrade to paid, if you need to?

For users who have optimized for the current pricing structure, this is an insane switch, to give you an idea I just did the calculation for our AppEngine costs. Ouch...

We currently pay about $0.60 a day, so $18 a month

On the new system we have 25 instances on average so 24 * 25 * 0.08 = $48 a day or $1440 a month, even with reserved instances this is $900 a month, a x50 increase....

We do thousands of small requests, optimized for low CPU usage and not instance count, guess its time to move.

Don't jump to conclusion too fast.

Enable safethreading and you will likely go to 2 or 3 instances, due to the many small requests you have. You may even go to 1 or 2 instances when they have finished optimizing their scheduler. So who knows, you may even end up with a lower monthly bill!!

The free quotas will still be ok but only for fairly low-traffic apps and sites (less than 1GB/day, one instance). For everyone else, though, this is a massive price increase and pretty much kills a major part of why App Engine was so appealing in the first place.

Huge disappointment.

e: The part that really gets me is there's now no way to easily transition from a free app to usage-based billing app without paying $9/month up front. If I'm just starting up a new site or app, I'll have no idea if I'll go over the free quotas or not. Now, if I stick with the free quotas and happen to go over, will my site go down? The old model was far, far more developer and user friendly than this.

This is introduces an annoyingly complex pricing model, but on the plus side:

- the fees are more predictable;

- $9 a month for an uptime SLA of 99.95% is a pretty good deal;

- apps are still free below reasonable quotas;

- the fast High Replication Datastore is now the default, half the price and free for the first 1G;

- Google embracing app engine as an official product will mean a) more resources will be invested in improving the platform, b) more startups might start seeing GAE as a serious platform (the Backends feature could be a game changer), meaning a stronger development community might grow as well.

Or startups could keep mostly ignoring GAE. But so far GAE is still the only PaaS that offers auto-scaling. All other companies are either crashing our apps on heavy loads or charging us hefty amounts for unused CPU cycles. To me personally and professionally, that makes GAE's pricing and ease of use still leagues ahead of any other PaaS out there.

    $9 a month for an uptime SLA of 99.95% 
    is a pretty good deal;
That's only the initial fee you have to pay per application.

Prices have grown tremendously, since their new model is similar to Amazon's AWS, only more expensive.

    apps are still free below reasonable quotas
Until now quotas have been fairly reasonable, but now they are announcing more restrictions. Considering the new pricing scheme I'm afraid the new quotas are going to be useless.

    the Backends feature could be a game changer
No, not really, they are just removing an awful limitation.

In the meantime you could do the same thing with Amazon's AWS (slightly cheaper too), and Amazon also provides real map/reduce powered by Hadoop - you can specify how many instance you want, you give it the scripts to run, and it runs them for you, getting billed for the instance-hours used.

     GAE is still the only PaaS that offers auto-scaling
I liked GAE because it was a cheap hosting solution suitable for the quick hacks I would do in PHP.

But now I'm not liking it any more. GAE is awful for scaling when you actually need scaling - IMHO, you can't scale unless you have complete control, and judging by GAE's past behavior (I'm especially referring to datastore latencies here), I don't have much confidence in it.

Migrating away is also a nightmare, unless you're talking about a 10-minute blog engine.

Disclosure: I'm the ceo of dotcloud.

Tons of Google App Engine users are currently migrating to dotcloud: they tell us it's simpler, with less API lock-in and more choice of stack.

GAE has a few sweet features that we lack - but not for long.

Can you give some examples of pricing comparison? Currently GAE is ridiculously cheap for us, but we wouldn't mind paying a little bit a month to keep it up and running with a pay-for-usage in case it needs to scale.

+1. DotCloud looks promising, I love its modular concept, but I'm avoiding giving its beta a go without having the slightest idea of its future pricing.

You're right, pricing is the single most important thing we're working on. In my opinion nobody figured out how to price a platform properly. We intend to change that.

I can't say too much, but 1) we'll announce it soon, 2) it's unlike any other PaaS, including GAE, and 3) I think you'll like it.

Looking forward to finding out more. Please put me on an email list when you announce it and we'll definitely consider the service, it sounds like a great platform.

I couldn't find the price here: http://www.dotcloud.com/ What costs can i expect? (Currently App Engine is ridiculously expensive for me).

So is this just for GAE4B or GAE? The post isn't really clear on this point.

If it's GAE...it's a pretty big bait and switch. I wonder what the average markup is going to be? 1000% 2000%?

sigh time to start looking for another platform and rewriting six months of work.


considering the potential magnitude of this announcement, did anybody using GAE today get at least an email from Google? Or were we all just expected to keep abreast of random pricing fluctuations?

I was really excited for App Engine when it came out. However, I don't think Google has realized its potential.

First, I want to comment on price. When it was introduced, I thought it would be cheaper than alternatives (like AWS, Softlayer, Linode, and the Rackspace Cloud). It doesn't look cheaper now.

They introduced "backend" processes today that look really pricy (http://code.google.com/appengine/docs/python/config/backends...). For 64cents, one gets 4.8GHz and 1024MB RAM for an instance that can do long running processes. For 68cents, Amazon is offering 20GHz and 7GB RAM - or 5GHz and 1.7GB RAM for 17cents. That's a huge price disparity. Google is billing with 15 minutes tacked onto the end of the usage and so it feels a lot more like AWS billing. If I'm spinning up a "backend", how is that different from spinning up an AWS instance for an hour? I can programmatically launch AWS instances and then shuffle work to them and then terminate them when they're done. Likewise, if I'm only sending work to the backend every 10 minutes, the instance will be always-on and so I'm not taking advantage of anything more advanced that would see me not being billed for the time I'm not using.

The move to instance hours over CPU used similarly means that I'm not taking advantage of advanced multi-tenancy tools Google might have created, but rather am using something that's basically Heroku. Google is charging 5cents per hour for a reserved instance - basically a Dyno at Heroku. If you're doing pay-as-you-go, you're paying 8cents per hour. At 8cents per hour, you could nearly get a full 1.7GB instance at AWS. In that 1.7GB, you could probably fit a dozen or more instances of your app. Heroku makes its living off the fact that a Dyno is probably taking up 100MB of RAM and some CPU and that 5cents/hour is a lot to pay for that. Now, Heroku is making up for that because they make it really easy to deploy and forget about server stuff. While Google is also making it so that you don't have to deal with the server stuff, there's a part of me that says the situation is very different - that I could take most generic Rails apps and put them on Heroku (as long as they don't need filesystem access), but I couldn't take most generic Django apps and put them on App Engine without modification. Not only that, but Heroku throws in bandwidth for free.

It just seems like this area is heating up and Google hasn't stepped up. Heroku is very well-established. VMWare has started to enter the fray, there have been Django ones that I've seen, and even the Play Framework has one. With the pricing changes, Google is certainly not cheaper and doesn't have the flexibility that most of them have to run applications not coded specifically for it.

Second, there's the issue of migration. I can't really go between App Engine and something else easily. Django non-rel exists, but it's been over 3 years since App Engine's launch and it doesn't look like migration is going to be trivial. So, unlike Google's growing number of competitors, there's a lot more lock-in there. If Google decided to discontinue the product, it would be painful to move. If they started charging more money, it would be hard for me to move to another provider. I guess I thought that Django might have done more work to make App Engine supported (even without joins and such) in a way that one could move on/off App Engine with the caveat of not using joins, the filesystem, etc. Heck, I even remember reading about Brad Fitzpatrick working on an App Engine-like package so that App Engine apps could be run on one's own servers (with a NoSQL store and such) if one wanted/needed to migrate away, but it hasn't made much news lately and might have been semi-abandoned. App Engine support didn't go as mainstream as I thought it might and that means that my expectations around migration aren't quite as positive.

Third, I guess I'm disappointed at the amount of attention paid to it. To me, it looks like this is a cool project that Google thinks is cool, but that they haven't found a way to monetize it. Like, AWS is a huge thing for Amazon. App Engine seems like something they want to dedicate some resources to, but not something they're too worried about progressing quickly on or really getting a foothold in the market. It's hard to commit to it when there are things it doesn't do (or doesn't do well) and it isn't clear if they ever want to do it well. For example, geo-querying isn't impossible, but isn't the easiest thing on App Engine. While Google might be forcing you to use a technique that would work even if you had billions of users, bounding box (and other) queries can be a much easier technique. Yes, they've trotted out SQL again and it might happen, but you're putting yourself in a situation where the product feels incomplete in some ways with Google not feeling too pressed to make it complete fast. I know that's not the best argument - the word "feel" should give that away - and that one can say that other providers can't do everything either. However, it's a lot less concerning if Heroku doesn't do something because I can more easily leave Heroku and host it myself.


I guess I felt that my implicit feelings on App Engine were something like, "Hey hackers! You should totally rewrite your apps for our Google systems that are a lot more efficient than other systems. Yeah, there are some annoying restrictions that you'll have to get used to and are totally a pain for some things. Still, out service is cheap for loads of usage and really cheap even after that so you're spending a little programmer time for no-hassle-scaling and cheaper hosting than anything you can get!"

However, they've consistently lowered the free usage tier to being a fraction of what it once was, they're now charging a ton more with their instance-hour model compared to the old CPU based model, a bit of the reliability/scaling sheen has worn off as it's had problems, other competitors have been aggressively entering this space, and you still have to alter your apps specifically for their architecture. I'm not saying that App Engine doesn't have value, just that it feels very different.

2c: I never worried about migration-- GAE is so much simpler than other systems, unless you went crazy with the datastore, most issues are a few hours to port. In addition, TyphoonAE has a reasonable reputation and is very active.

That all said, porting scaled-up apps is never fun-- the above only applies to smaller apps.

Django-rel cannot work because the Google datastore is very different from a relational-database, having low-level features that can't be exposed in a database abstraction layer in a general / elegant way.

Basically, if you're not using the GAE API for dealing with the datastore, you're asking for trouble.

More restrictive free plan, and a monthly fee for the basic plan. Back to AWS!

"More restrictive free plan" <- this really sucks, would like to know details, i hope they dont restrict the CPU hours less than the current 6.5 hours/day

They won't use CPU hours anymore, they'll switch over to "instance hours." The free tier will get 24 instance hours.

$9/mo fixed cost is a big step up from a pure pay-as-you-go. (But, also the cost of two cups of coffee at Starbucks, so still a bargain for the service provided.)

They still have a free version though, which is probably $9/mo worth of service that you get for free, so you can ramp up under that umbrella.

I really wish they would allow the $9 fee to be paid automatically if my app reached quota rather than making me plan for it. The beauty of appengine for me was that I didn't have to think about scaling. I guess I'll now have to pay for that privilege.

Yes, but if your instance count goes over 1 for a time, your site will spend an equal amount of time down, presumably.

You can limit the amount of instances. If you set it to 1, your site will be slower, not completely down. Just like a normal hosting box.

my thoughts: New App Engine Pricing policy, the good the bad and the ugly. http://gaengine.blogspot.com/2011/05/new-app-engine-pricing-...

Tornado + MongoDB is what I'm moving to. App Engine just went from bad to worse.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact