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

101–110 of 148 posts

Re: Google App Engine Pricing Angers Developers, Kills PlusFeed

#101

Post by chubot »

ChuckMcM wrote: post #59
chubot wrote: post #34

Earlier quoted context omitted.

Your last point is very confusing. You're saying you think Google can't spin up more App Engine front ends if it wants? ("every machine in their data center can [not] be a web server") Or any other kind of front end?

Google historically splits off their "front end" which is dealing with messages from the internet and their "back end" which is processing what those messages want to do. It was briefly described in the original search paper they presented. Of necessity, most machines that Google runs have 'private' (as in not directly addressable) addresses. This is how it seems that everyone runs things when they get above a certai…

Not trying to piss all over this, since I thought you might have been saying something I didn't know. But I have worked at Google for a long time and basically everything you wrote is incorrect and has been since at least 2005 before App Engine even existed (why would a paper written in 1998 be relevant?).

Without going into too much detail, it shouldn't surprise anyone that physical machines are interchangeable via cluster management software, so application front end and back end software all end up running on the same machines. They aren't addressed through DNS but by another mechanism. There is no special system administration for application-specific front ends vs back ends. Spinning up more instances of a particular server is a 1 line change. Reverse proxies (i.e. a non-app-specific front end) are also involved but they're not a bottleneck AFAIK (this problem is well "commoditized" in open source whereas other parts of Google's stack are not).

I would be curious to see a comparison with competitors like Heroku, which I've heard are pretty expensive too. Theoretically Google should be cheaper because Heroku runs on AWS and thus is paying for Amazon's profits (I have no idea how they compare.)

Re: Google App Engine Pricing Angers Developers, Kills PlusFeed

#102

Post by buff-a »

davisml wrote: post #62

It appears that the chart is being misinterpreted. The cost per hour is less under the new pricing and I believe the total hours is calculated for the month.

I wish that were true. Could there be some huge fuckup on the part of the kid programming the chart? I'm just going to keep clicking my heels and pretend that Google doesn't really want to take my monthly cost and charge me that per day.

Re: Google App Engine Pricing Angers Developers, Kills PlusFeed

#103

Post by buff-a »

gte910h wrote: post #6

I'm wondering if google is just trying to encourage an architecture which is less bad for their site. I'm guessing a small minority of apps were doing things in a way that was eating up tons more resources than they were paying for. I bet for many apps, this could end up no worse or better.

I wrote an app from scratch for GAE. Its cost is increasing 5000%. In fact the increase seems more than people who just slapped django on it.

Re: Google App Engine Pricing Angers Developers, Kills PlusFeed

#104

Post by jamieb »

georgemcbay wrote: post #67
andymoe wrote: post #60

An alternate perspective: Google App Engine is still a fine platform even with the new price increases. (Which they told us were coming by the way) And by the time the pricing takes effect the updated python runtime should bring costs down even more. The instance costs are comperable to Heroku AND you get a high availability data store AND the ability to store really huge amounts of data in the blobstore AND a CDN fo…

"An alternate perspective: Google App Engine is still a fine platform even with the new price increases." This depends a lot on what you're doing. GAE is now pretty terrible if you're using it for high-bandwidth applications (say, a data proxy or similar). Especially when you compare it to other providers for whom bandwidth prices have been dropping (AWS, Linode, etc now offer incoming bandwidth totally free and the…

the new prices aren't too bad at all.

c1.xlarge on EC2 is $1.16/hour. How many of the $0.08 GAE units does it take to match one of those? How many of those GAE units can run optimized SSE4/AVX? (Answer: none of them). I've run 250 c1.xlarge units at a time. GAE wasn't even possible, let alone affordable.

Re: Google App Engine Pricing Angers Developers, Kills PlusFeed

#105

Post by wisty »

chubot wrote: post #101
ChuckMcM wrote: post #59

Earlier quoted context omitted.

Google historically splits off their "front end" which is dealing with messages from the internet and their "back end" which is processing what those messages want to do. It was briefly described in the original search paper they presented. Of necessity, most machines that Google runs have 'private' (as in not directly addressable) addresses. This is how it seems that everyone runs things when they get above a certai…

Not trying to piss all over this, since I thought you might have been saying something I didn't know. But I have worked at Google for a long time and basically everything you wrote is incorrect and has been since at least 2005 before App Engine even existed (why would a paper written in 1998 be relevant?). Without going into too much detail, it shouldn't surprise anyone that physical machines are interchangeable via…

It sounds plausible that "on demand" instances i.e. search servers are a bottleneck, while bulk offline processing (in the back-end) i.e. PageRank calculations is not such a constraint.

Yes, those offline processing instances could be suspended while dealing with a traffic peak, but peak traffic is still often a challenge, especially now that Google is pushing more and more stuff onto the web servers (Instant).

That might be what he meant.

Disclaimer - I don't work for Google, it's just a guess.

Re: Google App Engine Pricing Angers Developers, Kills PlusFeed

#106

Post by Locke1689 »

Locke1689 wrote: post #54
z92 wrote: post #47

Earlier quoted context omitted.

Probably he is saying that because their expertise and focus lies in backend, it's costlier for Google to increase frontend service and server compared with say, other web-hosting companies.

Web servers still count as backend. This is not a lack of talent problem.

People who are downvoting me don't really understand what I'm saying. I'm finishing up my internship at Google now. This is a nomenclature problem -- what ChuckMcM is properly referring to is front-facing backend vs "back" facing backend. They're really just two different types of backend servers. SREs manage both and they are installed similarly. It could be argued that Google perhaps has certain weaknesses in frontend (i.e., UI/UX design), but this is clearly a case where engineering talent is not lacking -- they're the same engineers as the ones working on private servers.

Re: Google App Engine Pricing Angers Developers, Kills PlusFeed

#107

Post by Locke1689 »

chubot wrote: post #34
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…

Your last point is very confusing. You're saying you think Google can't spin up more App Engine front ends if it wants? ("every machine in their data center can [not] be a web server") Or any other kind of front end?

I think I know what he's talking about. My LDAP is the same as the email in my profile. I'll wager a guess at what the real problem is.

Re: Google App Engine Pricing Angers Developers, Kills PlusFeed

#108

Post by wisty »

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'd recommend GAE to people who are prototyping - it's easy to do simple stuff in.

But mostly, GAE doesn't make sense for larger apps. You can't buy your way out of trouble, by putting your db on a dedicated server with fast drives and tonnes of RAM. You can't really use relational data without performance and reliability issues.

It's not just about the "app engine way". It's not like learning C or Haskell, and having to find a new way to write the code. You fundamentally cannot do big ad-hoc database operations.

And consider this - it was July last year that they introduced the MapperAPI. Before then, I don't think you could do Map-Reduce without manually re-implementing it yourself (on top of the cantankerous Appengine Datastore). Just think about that for a minute - how were you meant to do stuff the Appengine way without map-reduce?

Anyway, I don't think your credibility was "utterly destroyed". It was really hard to know whether or not the learning curve was worth climbing until you had tried. You just had to judge the book by its cover, and the "Google" brand is pretty compelling to an engineer. It's not the first time someone has been fooled into buying something because the provider has a good reputation.

Re: Google App Engine Pricing Angers Developers, Kills PlusFeed

#109

Post by wmf »

wisty wrote: post #108
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'd recommend GAE to people who are prototyping - it's easy to do simple stuff in. But mostly, GAE doesn't make sense for larger apps. You can't buy your way out of trouble, by putting your db on a dedicated server with fast drives and tonnes of RAM. You can't really use relational data without performance and reliability issues. It's not just about the "app engine way". It's not like learning C or Haskell, and havin…

I would argue that all the forced scaling in App Engine makes prototyping harder. You can't use SQL. You can't reuse whatever open-source components you find on GitHub. You can't just let your app run slow and optimize later.

Re: Google App Engine Pricing Angers Developers, Kills PlusFeed

#110

Post by buff-a »

wisty wrote: post #108
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'd recommend GAE to people who are prototyping - it's easy to do simple stuff in. But mostly, GAE doesn't make sense for larger apps. You can't buy your way out of trouble, by putting your db on a dedicated server with fast drives and tonnes of RAM. You can't really use relational data without performance and reliability issues. It's not just about the "app engine way". It's not like learning C or Haskell, and havin…

I have several ideas that would scale well on GAE and neither want not need a relational db. I'm not making do without SQL, I'm actively not using it and its very successful. Even when I move to EC2, I still wont be using SQL. In fact I have only one idea that needs any kind of relational data and that is so relational that SQL is a bad fit too. EDIT: Actually, sorry, all my data is relational. Its just that I put the (small) effort in to figuring out how to make it work without joins. In the last 15 years, I've not done a single project that could not have been done with a NoSQL database.

In fact if you look at the recent comments of certain GAE engineers, they seem to believe that GAE is precisely for scaling, and that's why it now costs so much: its only for the big boys.

The problem is that I can never become one of the "big boys" on their system, because pretty much as soon as I get any traction, I have to move to EC2 or heroku or go broke. Their new found belief in the scalability of their system is just arrogance. Anyone can claim to handle lots of traffic when you require that your customers run 20 times as many frontends as they should reasonably need.

Good luck to them in the Royal Wedding market.

EDIT: on the nature of "relational"

Post reply on HN