Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google App Engine Pricing Angers Developers, Kills PlusFeed

readwriteweb.com

Post reply on HN
Print view View original

121–130 of 148 posts

Re: Google App Engine Pricing Angers Developers, Kills PlusFeed

#121

Post by angusgr »

buff-a wrote: post #93
angusgr wrote: post #92

Can anyone tell me how the new and old prices compare to running a similar app on AWS, Heroku or other competitors? ie was GAE ridiculously cheap before compared to other options, and now comparable? Or was it somewhat cheaper than competitors before, and now somewhat more expensive? I realise it's never that simple, but nearly everyone's complaints seem to be (understandably) given in relative terms of before vs. af…

It was cheap by comparison. Now it appears to be orders of magnitude more expensive. I base this on the fact that their billing estimator is claiming that 1 cpu-hour on the old system equates to 100 instances-hours on the new system. Its not the $0.04/hour cost that worries me - that is a competitive number - its that their instances only appear to be able to do the work of a 80286.

Thanks. :)

Re: Google App Engine Pricing Angers Developers, Kills PlusFeed

#122

Post by fuckgoogle »

catch23 wrote: post #89
wccrawford wrote: post #37

Earlier quoted context omitted.

$81/month for a fun project that gets you noticed and looks good on your resume is nothing to sneeze at. Blog about it, and suddenly you have a hidden revenue stream from it. Let people know its yours and suddenly you have some weight to throw around.

For $81/month, you can get a 4 processor 2GB Linode box, which is enough to run a few dozen fun projects on there.

For $69/month you can get a 8 GB dedicated server with Core i7-920. http://www.hetzner.de/en/hosting/produktmatrix/rootserver-pr...

With Google the only thing you'll get for $69/month is a sore ass.

Re: Google App Engine Pricing Angers Developers, Kills PlusFeed

#123

Post by iki23 »

ChuckMcM wrote: post #24

Heh. TL;DR version - Google starts recovering their costs, hits people in unexpected places. So back when I worked there Google had no clue what it cost to run their infrastructure at a fine grain level. Sure they knew the aggregate cost, that was easy, but knowing on an application level didn't exist. This was a problem since as more and more things were using the machines, how did you "bill" a department for their…

Yep, but one would expect Google being able to do better and get it work for lower cost at their scale and level of expertise, which is raising the doubt among developers.

Re: Google App Engine Pricing Angers Developers, Kills PlusFeed

#124

Post by [deleted] »

wulczer wrote: post #118
buff-a wrote: post #116

Earlier quoted context omitted.

Denormalize. Match your data rows to your access pattern (i.e. your UI). Naive example: if you have a webpage that displays a list of employees, and it must have their department name and boss in that list, you put that data in the employee row. What is the probability that a boss will change his or her name causing you to have update a ton of records? Very low. (not zero mind you, so you have to be able to do it). S…

The problem is not having to update tons of records, the problem is seeing one day, after 2 years of having the app in production, that the listing shows that employee X works in department Y and her boss is Z, but Z is not the head of Y. Bugs happen and referential constraints go a long way towards keeping your data clean.

[deleted]

Re: Google App Engine Pricing Angers Developers, Kills PlusFeed

#125

Post by buff-a »

wulczer wrote: post #118
buff-a wrote: post #116

Earlier quoted context omitted.

Denormalize. Match your data rows to your access pattern (i.e. your UI). Naive example: if you have a webpage that displays a list of employees, and it must have their department name and boss in that list, you put that data in the employee row. What is the probability that a boss will change his or her name causing you to have update a ton of records? Very low. (not zero mind you, so you have to be able to do it). S…

The problem is not having to update tons of records, the problem is seeing one day, after 2 years of having the app in production, that the listing shows that employee X works in department Y and her boss is Z, but Z is not the head of Y. Bugs happen and referential constraints go a long way towards keeping your data clean.

Yeah, I was worried about all that. Hell, I was worried NoSQL couldn't possibly work at all, given my experience of SQL and the joyful things that happen there.

But I've found that my object model has evolved to handle the "scariness" of the back end. If someone wants to change the boss of an employee, they are doing if via an http post. So I've got to check that the key I was sent over http is even an employee at all and not some javascript bug. Since I have to do that, I might as well read the data into my employee object. Then the code to update employee X with employee Y as a boss is pretty straight forward and thoroughly unit tested. The code to serialize an employee is thoroughly unit tested.

Not saying shit cant happen. Now look me in the eye and tell me you never had some noob drop a constraint and forget to put it back.

Re: Google App Engine Pricing Angers Developers, Kills PlusFeed

#126

Post by buff-a »

DanielChatfield wrote: post #117
bane wrote: post #111

Earlier quoted context omitted.

It means that GAE is horribly, amazingly, inefficient. This. We always knew GAE was inefficient. There's no doubt about that. Serving 30 or 40 requests per second would spawn quite a few instances and start producing request errors. This is a load a 4 year old machine could handle with ease. Why did we put up with this? Because Google didn't make us pay for the crappiness -- the pricing made sense. You don't pay Ferr…

It would only start producing request errors if there was bad coding. Many of Google's stuff (like the chrome updates) are done through GAE and receive no "special treatment" from GAE (except lifting the request limits which wouldn't affect any sites you make). GAE was made to be fast - and it is. It was made to be reliable - and it is (100% uptime in over 500 days).

Postmortem for August 18, 2011 outage

http://groups.google.com/group/google-appengine-downtime-not...

Re: Google App Engine Pricing Angers Developers, Kills PlusFeed

#127

Post by nicksdjohnson »

Hi folks,

I'm on the App Engine team, and I just wanted to clarify one thing: The main difference between CPU hours and Instance hours is that CPU hours are charged based on CPU usage, while instance hours are based on wallclock time. The high ratio between the two you can see with PlusFeed is because it's spending a lot of time to serve each request, most of which is spent doing nothing - likely because it's doing outgoing HTTP requests.

Previously, we had no way to account for apps like this, that take a lot of wallclock time but very little CPU time, and as a result we couldn't scale them well. Under the new model, the charges reflect the real cost here - memory pressure. Every second an instance sits around waiting is a second that the memory occupied by that instance can't be used to serve other requests.

As others have pointed out, we're in the process of launching Python 2.7 support - it's currently in Trusted Tester phase - which will support multiple concurrent requests, and services like PlusFeed are likely to be able to take great advantage of that, reducing their instance hours by a large factor. Likewise, doing asynchronous URLFetches (where that's practical) can cut a huge amount off instance time.

Re: Google App Engine Pricing Angers Developers, Kills PlusFeed

#128

Post by nicksdjohnson »

buff-a wrote: post #96
hga wrote: post #95

Earlier quoted context omitted.

I feel your pain, but that said: From what else I've read, it sounds like engineers who didn't also wear green eye-shades (or good enough ones, or who didn't possesses or use good enough crystal balls) set up this debacle. And it was people wearing green eye-shades (who we can sincerely hope are also engineers) who aligned it with reality. Causing way too many people way too much pain. Object lesson: if you're going…

The problem is how does one get from 31 cpu-hours to 879 instance-hours. You might be thinking that in the original measure they did something insane like measure only user time of a process, or only when its executing a request, not booting or whatever (or fuck, I don't know because honestly there is no reasonable explanation). That is to say, that the 31 cpu-hours is a misread, and if the fellow in the article ran…

One gets from 31 cpu hours to 879 instance hours if your average CPU utilization is about 3.5% - see my other post for details.

Re: Google App Engine Pricing Angers Developers, Kills PlusFeed

#129

Post by ja27 »

buff-a wrote: post #85

Here's my complaint: I, and many others, spent a lot of time figuring out how to write apps that do it the "app engine way": * Fast completes (30 second timeout) * Offloading to task queues when you cant * Channels * Blobstore two-phase upload urls * Mail eccentricities We did so, because we believe Google when they told us If you write your apps in this really weird way then we will be able to give you scale and cos…

I put my faith in Google's engineers and they have utterly destroyed my credibility.

Come to a Microsoft event some time and let a Silverlight developer buy you a sympathy beer.

Re: Google App Engine Pricing Angers Developers, Kills PlusFeed

#130

Post by white_devil »

buff-a wrote: post #116
white_devil wrote: post #113

Earlier quoted context omitted.

Its just that I put the (small) effort in to figuring out how to make it work without joins. Care to elaborate?

Denormalize. Match your data rows to your access pattern (i.e. your UI). Naive example: if you have a webpage that displays a list of employees, and it must have their department name and boss in that list, you put that data in the employee row. What is the probability that a boss will change his or her name causing you to have update a ton of records? Very low. (not zero mind you, so you have to be able to do it). S…

What is the probability that a boss will change his or her name

That's obviously an example of something that will practically never happen, which is why it doesn't work all that well as a justification for ditching SQL databases altogether.

I've never used NoSQL for anything, so there must be a lot that I'm missing, and that's why I asked. But it seems to me like you'd be digging up necessary information through quite a few steps if everything is "flat".

Post reply on HN