Live data from Hacker News

Google App Engine Pricing Angers Developers, Kills PlusFeed

readwriteweb.com

21–30 of 148 posts

Re: Google App Engine Pricing Angers Developers, Kills PlusFeed

#21

Yeah I still don't understand why the Khan Academy and other educational/open source developers are using Google App Engine when it suffers from vendor lock-in.

some of it yes, but if you write modular code then its a none issue. Doing Java development, GAE supports most Java EE and popular frameworks, so if done correctly porting would not be an issue. I can't say the same about Python stack.

It's still an issue -- you have all this data that you have to migrate off of app engine. Some of my friends who migrated on to GAE said it took them almost 2 full weeks to load data into GAE, and now I'm sure it would cost them at least a full month to load data off GAE. The code changes are probably the easy part of the migration.

Re: Google App Engine Pricing Angers Developers, Kills PlusFeed

#22
post #19

Can someone please explain frontend versus backend instance processing? Does backend here mean processing that takes place in data storage systems?

I believe frontend means requests handled through normal frontend hits from end users, while backend instances are for longer running background processes.

Re: Google App Engine Pricing Angers Developers, Kills PlusFeed

#23
post #18

What's most interesting to me about this article is that the management of GAE seems to actually be getting worse over time. GAE has always had two main disadvantages. First, there is vendor lock-in because you code specifically to the data store, worker API, and so on (though arguably there are alternative platforms that implement the GAE API). Second, you cannot run custom code (custom C in some virtual machine) or…

Yeah, the hard limitation to request duration is pretty nasty too. It's a pretty limited platform overall, and never took aoff, so maybe they are trying to push people off it so they can eventually sunset it?

Re: Google App Engine Pricing Angers Developers, Kills PlusFeed

#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 machine usage? That really crystallized when the bottom fell out in 2008 and suddenly there was going to be no more new machines/data centers for a while and everyone had to 'make do.'

They mobilized an effort to figure this out, its not like it isn't knowable, and ever the data driven company the first signs of light were appearing just as I was leaving. It should not be a surprise but they discovered many things they did not previously believe was true, and I don't doubt it has driven a lot of change going forward. One of the more interesting outcomes was that projects/products were actually getting cancelled if they cost more to run than they could generate in revenue (I'm looking at you Goog-411)

So this knowledge is being applied to GAE, which is great, its also another way to back compute some of their operational efficiencies.

But that it costs money to run stuff? Well that isn't really news is it? That it costs that much? Well there is the whole if it doesn't make money it will get cancelled threat.

And the kicker is pricing out the scarce resource. It looks (and I've been gone over a year and half so I am speculating based on this move on their part) like their 'scarce' resource is web server front ends. (the labeled "Frontend instance") Traditionally they've been like most multi-tier web properties split between front end machines which host the web facing stuff, and back end machines that do the heaving lifting and storing. And by this change one can reason that residency on the 'front end' is more valuable than crunching in the 'back end.'

I'm guessing PlusFeed gets a lot of web traffic. So they spend a lot of time 'actively' on the front side, and from their numbers they do practically nothing on the back side. This fits well with the sudden massive price increase.

This gives you an insight into Google's business dynamics as well. Where page-views are the limiting resource, and computation is not. When you look at it that way, you can see that most of their 'revenue' has to be delivered through their front end services, and so consuming that resource reduces (potentially) their income. Hence the charge inconsistency.

Now contrast that to Billy-Bob's Web Farm (fictitious service) where every machine in their data center can be a web server, and front end serving is trivial, its all about the bandwidth. Their pricing would probably be more gigabytes transferred.

I would not be surprised at all if it is impractical to run such 'translation' services (basically all web traffic very little compute) on a hosted environment like Google's.

Re: Google App Engine Pricing Angers Developers, Kills PlusFeed

#25
I love using GAE and got 8 apps running currently. At first the new pricing model shocked me. But please take a 2nd look. Sure it's more expensive than the old model. But you can set the maximum number of idle instances in your Application Settings page. Just set it down so no more that X instances get spun up:

> The Idle Instances slider allows you to control the number of idle instances available to your application at any given time. Idle Instances are pre-loaded with your application code, so when a new Instance is needed, it can serve traffic immediately. You will not be charged for instances over the specified maximum. A smaller number of idle Instances means your application costs less to run, but may encounter more startup latency during load spikes.

There is another setting for latency:

> The Pending Latency slider controls how long requests spend in the pending queue before being served by an Instance. If the minimum pending latency is high App Engine will allow requests to wait rather than start new Instances to process them. This can reduce the number of instance hours your application uses, but can result in more user-visible latency.

So if you are fine with a little higher latency for your app then you can reduce your bill by a great deal. If you want all that GAE can offer with max. instances available and lowest latency you gotta pay - as you would when you run n instances at another cloud provider.

Re: Google App Engine Pricing Angers Developers, Kills PlusFeed

#26
post #18

What's most interesting to me about this article is that the management of GAE seems to actually be getting worse over time. GAE has always had two main disadvantages. First, there is vendor lock-in because you code specifically to the data store, worker API, and so on (though arguably there are alternative platforms that implement the GAE API). Second, you cannot run custom code (custom C in some virtual machine) or…

[deleted]

Re: Google App Engine Pricing Angers Developers, Kills PlusFeed

#27
post #3

I am currently playing with the idea of moving an application from all-GAE to part GAE, part EC2 with some spot instances running jobs when cheap enough. According to my sloppy math, this should reduce the load on the GAE side by at least 60%. Anyway, this is all theoretical (in the worst sense of the word) - the app is not even public.

But is it really worth the headache of such a Frankenstein architecture? I initially fell in love with the "no sysadmin" aspect of App Engine, and started building apps around it. Eventually I realized that (for me, anyway) the upside isn't really worth the trouble of having to contort my apps to work in Google's sandbox- can't run SQL, have to deal with datastore timeouts, CPU timeouts, etc. When you're done coding…

This is so true. The first step to correcting a problem is admitting you have one, and everyone on App Engine clearly does (locked-in). What I'm doing about it? Moving to Tornado/MongoDB/EC2 as quickly as possible.

Re: Google App Engine Pricing Angers Developers, Kills PlusFeed

#28
Everything Google does, they do in a half-assed sort of way. And it's getting really annoying. Even their core business of search is showing signs of neglect. SEO experts have learned to game the system such that the quality of search results is pretty abysmal now.

GAE is a half baked AWS. Google+ is a half baked Facebook. Google Docs is a half baked MSOffice. They have no blood in these projects and don't really care whether they succeed or not, which coincidentaly means they probably won't.

Google is getting absolutely clobbered in every category other than search advertising dollars. Their products wreak of ambivilence and neglect, and I'm surprised anyone expected GAE to be a good platform.

Re: Google App Engine Pricing Angers Developers, Kills PlusFeed

#29
Our charges are going to be increasing from $0/day to $5-11/day. While bearable, it's a serious problem given so little notice, and disappointing since we invested in their infrastructure & optimized for their previous pricing plan. This is a serious hit for a bootstrapped startup getting off the ground. No doubt it will kill a lot of startups.

Re: Google App Engine Pricing Angers Developers, Kills PlusFeed

#30
post #17
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 don't think it's a small minority of apps. 100% of the people I know who are using GAE are seeing the minimum of a 4x price increase for their app (before the 50% discount). The price increase would actually prevent some small ISVs from reaching ramen profitability. There's a thread somewhere on the GAE google groups containing many angry users.

Even if most of my apps would increase by 10x they would still be cheaper than running a single AWS instance for them. Not even taking into account the easy of management and automatic redundancy that GAE offers.
Post reply on HN