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.
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.
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.
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!!
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.
- 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;
Prices have grown tremendously, since their new model is similar to Amazon's AWS, only more expensive.
apps are still free below reasonable quotas
the Backends feature could be a game changer
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
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.
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.
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.
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?
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.
That all said, porting scaled-up apps is never fun-- the above only applies to smaller apps.
Basically, if you're not using the GAE API for dealing with the datastore, you're asking for trouble.