
Google App Engine Pricing Angers Developers, Kills PlusFeed - jzb
http://www.readwriteweb.com/hack/2011/09/google-app-engine-pricing-ange.php
======
ChuckMcM
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.

~~~
chubot
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?

~~~
ChuckMcM
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 certain number of servers.

Thirdly because one can assume that 'attacks' (whether they depend on XSS,
overflows, or what not) are coming from the Interwebz its prudent to present
the smallest possible attack surface on a machine which is being fed internet
stuff. As you can imagine, those security constraints make for uncomfortable
restrictions on what you can do in the 'front end', so a machine that is
'front end' has a different set of security constraints than a machine that is
'back end' (they are still constraints there of course but having gone through
the filter of the front end machine which has greatly attenuated the possible
exploit vectors).

I believe it is this armored 'front end' resource which is the scarce
resource, but again, I've been gone over a year and things change quickly
inside the 'plex.

~~~
chubot
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.)

~~~
stickfigure
The original point is "almost right". The scarce resource reflected in the new
pricing model is not machines, but RAM. The old pricing model assumed CPU time
was the essential resource. The new pricing model bills you for the amount of
time your instance (which has a fixed RAM reservation) stays resident.

------
buff-a
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 cost
benefits that you wont be able to get elsewhere_

We believed them, because it seemed reasonable. We laughed at those who
complained that django would hit the 30-second limit: "Its not a general
hosting! Figure out the App Engine way!" And we educated on how to do it
right, and many were happy.

Well, it turns out that it _is_ general purpose hosting, with all of the
costs, and yet also with all of the (once rational, now bullshit)
idiosyncrasies.

\---

But that's not the biggest complaint. The biggest complaint is that when my
friends and peers objected to App Engine, its strange requirements and its
potential lock in, _they were right and I am a fucking naive idiot_. And I
_really_ don't like to be proven a naive idiot. I put my faith in Google's
_engineers_ and they have _utterly destroyed my credibility_. THIS more than
anything is the _cost_ to me.

~~~
wisty
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.

~~~
buff-a
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"

~~~
white_devil
_Its just that I put the (small) effort in to figuring out how to make it work
without joins._

Care to elaborate?

~~~
buff-a
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). So why pay for the join every query?

There are no longer, in my view, any situations where a SQL db is the best
idea. You either want a giant NoSQL database, or you want a massive in-memory
object-graph using pointers. Or you want something for $20m from Oracle or
IBM.

~~~
wulczer
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.

~~~
buff-a
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.

~~~
wisty
You could periodically run a script that checks all the records for errors
(especially embedded records that might have drifted from their current value,
and not been properly changed by the app-level constraints), and automatically
correct them (plus log the error).

If Michael Arlington changes his job from "editor in chief" to "founder,
former editor, occasional contributor, and CEO of Arlington Investments", and
his old posts aren't all updated, it's not the end of the world.

It really depends on the problem domain. You wouldn't run a bank's ledger off
MongoDB. On the other hand, a bank's ledger should be radically simple, with
little need for normalization.

------
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.

~~~
buff-a
First of all, thank you for chiming in, here, on HN. Your presence might also
be welcomed on the google forum, since I've read most of the posts there and
no one has managed to answer this question.

If memory pressure is the issue, how are the trusted testers finding their
memory pressure when they have a whole number of in-flight requests? If the
PlusFeed fellow got 2.7 working, we'd expect to see 100/3.5%= 28 in-flight
requests. Do you have data on how big the base memory vs per-thread memory
requirements of these apps are? Python isn't famous for freeing up memory.

Which is to say, do you have any solid numbers that tell us that when we
switch to 2.7, you wont have exactly the same memory pressure and either have
to up the instance-hour cost, or start charging for ram, or just limit in-
flight request to 3 or 4 so that our costs are only 5 times as much instead of
20?

Bottom line: what we all woke up to is that fact that as of right now:

* _you_ set the price of an instance, _and_

* _you_ get to decide how many instances I'm going to pay you for

Some of us are thinking that while that was a great idea when engineers were
in charge, its not such a great idea now the bean-counters have taken over.

~~~
nicksdjohnson
That's a good question. I can't point to published figures, since the 2.7
runtime is still fairly new, but I can say that based on both my personal
experience and based on fairly basic reasoning, the per-thread memory overhead
is definitely a lot less than what's required by the whole instance. The
entire of the Python standard library, along with your framework and other
libraries, are shared overhead between all the threads.

The issue with charging by CPU hour was that you could occupy memory-seconds
as much as you wanted without charge; that's no longer the case - by charging
for instances, we're implicitly charging for the memory they use.

As far as determining how many instances you run - you can do this to a large
degree, both by setting budget limits, and by setting scheduler parameters.

------
pbh
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 have a custom
architecture (if, say, Redis might be useful to have around). These
disadvantages probably aren't changing and are probably necessary for auto-
scaling, security of Google's infrastructure, and so on.

However, there are lots of little things that GAE has been getting wrong for a
while that are totally unnecessary. Lack of hosted SQL support. Lack of SSL
for custom domains. Just little things that are probably annoying to implement
and boring, but totally necessary for real websites or websites just gaining
traction. (I know these are in varying stages of early support at the moment.)

But now, the GAE team almost seems to want to actively disappoint users. With
hosted SQL being a request for years, Guido appears to have spent a bunch of
time re-architecting the API for the datastore instead. With this pricing
increase, they're pushing the many developers who came to their platform based
on price (due to the very interesting scaling properties of the Google front-
end) off the platform.

Overall, I'm very confused.

~~~
mcantelon
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?

~~~
nroach
Deliberately pushing people out? Probably not. They had a major decision point
available when they chose to either exit beta and step onto a release product
schedule or drop the project entirely. The fact that they chose to productize
it bodes well for the immediate future. Adding SLA and SSL was also non-
trivial from a product perspective.

But, that does mean that you have to figure out what your revenue-producing
tenants are going to look like, just as you would do in physical real estate.
Yes, it looks like the high-traffic commodity-product (think Halloween store)
doesn't make a good tenant. But that doesn't mean that a jewelry store or
office (low throughput, high value per-square foot) wouldn't be a good tenant.

------
Smrchy
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.

~~~
jcheng
Thanks for the info. Is there a setting for max number of simultaneous
instances? If your app gets slashdotted are your potential costs completely
unbounded?

(Just out of curiosity, I'm not a GAE customer)

~~~
angkec
No there isn't. Just "max idle instances". So you'll get a huge bill if you
get slashdotted.

~~~
groks
You won't, because you specify a maximum daily spend in the budget settings.
So when you get slashdotted the scheduler will spin up X hundred instances,
your budget will run out in 1/2 hour, and your site will be down for anything
up to the next 23 1/2 hours.

------
nir
I think Google just doesn't really get how unique GAE was. It was a fantastic
platform for small apps, and inevitable some percentage of these would grow to
big, paying apps.

Also (sorry for the armchair quarterbacking here, can't resist..) it was
exactly what Google can do better than anyone - best server infrastructure +
Guido Van Rossums - while stuff like Google+ is exactly what Google haven't a
clue how to do.

~~~
switch
This is amazing. You've hit the nail on the head. Google would be much more
successful if it focused on being Google and didn't try to be
Apple+Fecaebook+X companies all in one.

------
andymoe
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 for serving images from said blobstore. Not to mention
background processes, task queue, XMPP, memcache, Multitenancy and multiple
versions of apps so you can easily roll things back or test out updates
painlessly.

Try and replicate that setup on Heroku or AWS for anywhere near the costs and
time that you can get there with app engine.

While you're fighting with AWS and playing sysadmin or trying to think of ways
to bring down the costs of Heroku's database services by using RDS instead or
being nickel and dimed by add-on fees I'll be shipping code. Code that
actually takes advantage of the platforms strengths.

~~~
georgemcbay
"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 rates on outgoing are very low as well). If you're using it as a
number-crunching backend with relatively small in/out datasets, the new prices
aren't too bad at all.

~~~
jamieb
_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.

------
maxent
I think this comment from Wesley Chun on the GAE team is key:

[https://groups.google.com/d/msg/google-
appengine/obfGjbIkOTI...](https://groups.google.com/d/msg/google-
appengine/obfGjbIkOTI/Qji2eUm0cO4J)

"your app can be slashdotted or tweeted by demi moore --
[http://adtmag.com/blogs/watersworks/2010/10/mobile-app-
creat...](http://adtmag.com/blogs/watersworks/2010/10/mobile-app-creators-
talk-google-app-engine.aspx) \-- or perhaps you may need to build/host
something on the scale of both the royal wedding blog and event livestream
with traffic numbers that are mindblowing --
[http://googleappengine.blogspot.com/2011/05/royal-wedding-
be...](http://googleappengine.blogspot.com/2011/05/royal-wedding-bells-in-
cloud.html) ... _these_ are the reasons for using App Engine. it was not meant
as free/cheap generic app-hosting but to provide a premium service that's
difficult to get elsewhere in the market. if you're just after the former,
there are plenty of options for you."

My take-away is that GAE is hard to justify unless your usage pattern is
unpredictable and spike-y. I'm taking the long weekend to give dotcloud a
serious test-drive.

~~~
systems
DotCloud is not cheap if your application is database intensive.

------
dasil003
The strength of GAE is the magic scaling beans, but to take advantage of it
you need to lock yourself in massively. It's probably not realistic to port an
existing application that actually needs real scale to GAE given the
complexity of most apps by the time they reach that point. Therefore, the key
funnel for them is new apps with hopes of becoming truly massive. Fortunately
for Google way more people dream of scaling than actually will, but they need
to A) not scare poor startups away with the price today and B) not scare them
that they're going to get bent over and raped on price changes later.

Personally I'll never touch GAE with a 10' pole simply because of the support
issue and perpetual-beta-culture uncertainties.

------
ddon
We tried to use GAE several times on our heavy traffic production, and was
just too slow. We contacted google several times, but never received any help
from them. So, thanks to this, we don't use them and we are not affected but
the price change.

------
sasha-dv
That's unreasonably expensive. For $68.46 he payed for a day you can have an
"el-cheapo" dedicated box or a great VPS for a month. I still don't understand
why people trade a bit of system administration and superb performance for a
vendor lock and insane prices.

~~~
jcheng
But it's 880 instance-hours per day. So assuming that "el-cheapo" dedicated
box has similar performance characteristics to one GAE instance, then you'd
need _37_ of those boxes.

My question is why the heck 31.42 CPU hours turned into 880 frontend instance
hours, and whether this is something a lot of other GAE apps are seeing as
well.

~~~
ww520
Google's instance-hour is process-instance-hour. The current GAE Python can
only serve one web request by one process. Multiple web requests coming in
would spin up multiple processes. Besides the CPU, Google charges the app
while the process is waiting for IO, like waiting for receiving/sending to the
browser.

But measuring process-instance-hour is misleading. In a typical web box,
spinning up an extra process takes very little resource since most process
memory are shared with the parent process, and most web apps are IO bound,
like waiting for network/file/DB, idling taking little CPU. In a server box,
many processes can be crammed in (like the shared hosting box). But Google
counts those duplicate processes as separate ones and charge the idle time
these processes take. That's why you see the outrageous bill.

What's more insane is that Google charges the process-instance-hour like a
machine-instance-hour. GAE charges $0.08/hr for process-instance-hour while
AWS charges $0.02 to $0.08/hr for the whole machine.

------
edtechdev
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.

~~~
angryasian
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.

~~~
Estragon
Unless you're doing regular integration testing on an alternative platform,
you're bound to inadvertently introduce some painful GAE-specific
dependencies.

------
aaronf
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.

------
cd34
1.5gb out with 880 frontend instance hours in 24 hours.

Someone needs to rethink their architecture.

~~~
trafficlight
That works out to be about 36 instances each pushing 40 megabytes for the day.
That's crazy.

~~~
marcc
It's not fair to make assumptions like this. I have a Google App Engine app
which doesn't push put a lot MBs each day, but does use a fair amount of CPU,
and I'll pay for it. It's not a poorly designed service, it's a service which
doesn't generate a lot of traffic (when measured in MB), but I'm getting value
from it elsewhere. In this case, my app on GAE is an API which my front end
(hosted elsewhere) is consuming.

------
cHalgan
My understanding of all these GAE pricing story is that Google decided that
GAE is not a strategic business and that business unit need to break even or
they will be canceled. Does this make sense?

~~~
catch23
If that were the case, wouldn't apps like google calendar get cancelled long
time ago? I doubt the ads on google calendar are sufficient to sustain the
number of users it has on a daily basis.

~~~
cHalgan
Maybe Google Apps (Calendar) are part of strategic vision (connected with
Chrome OS)?

------
gte910h
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.

~~~
catch23
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.

~~~
Smrchy
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.

~~~
catch23
As Wesley Chung noted in his reply on the GAE mailing list, GAE is designed
for companies who get very unpredictable traffic. If you get a very
predictable traffic, it's significantly cheaper hosting on AWS. Some of my
apps previously cost $40 a month, now cost almost $300 per month. I can
definitely run these apps on Linode for a fraction of the cost.

I picked GAE mainly because it was fast to setup, but I could have equally
chosen Heroku over app engine when I first built it. In hindsight, I wish I
had.

------
herf
It sounds to me like the scarce resource was found to be RAM, not CPU. If an
"instance" uses a big piece of RAM to serve a request, and doesn't give it up
while waiting for a backend, then scalability is RAM-bound, not CPU-bound, and
they should probably charge that way.

------
kennystone
His app generated no revenue, so any price other than trivial would have him
jumping ship. Why does Google want apps like his?

~~~
robryan
The $2.63 a day comes out to $81 a month which for hosting is a non trivial
amount. It does come down to whether Google can turn a profit at these levels
for someone using this amount of resources but I don't think customers willing
to pay $50-$100 a month are ones you want to push away.

~~~
wccrawford
$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.

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

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

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

------
heliodor
Can people list their choice for python hosting and the main benefits?

What are some good services layered on top of EC2 to provide more management
and automation?

Does anyone have any experience with whether DotCloud is priced reasonably?

~~~
sirn
I've been playing with ep.io for a while (nothing serious), it's a standard
Python + PostgreSQL stack using few inis for configuration. Their pricing is a
bit high on bandwidth though, so I'll probably wait for Heroku Cedar to
officially support Python and use that instead.

------
bane
In my mind, the problem is not so much the extreme pricing difference, but the
change in what's being measured, so not only is there a price increase, but
it's nearly impossible to figure out how to compare the old vs. new schemes
vs. competitors.

The huge price jump _is_ a serious problem, but the weird metrics switch makes
it feel like such a bait and switch. I'm going to be highly surprised if this
isn't challenged in court.

------
rbanffy
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.

~~~
kaffeinecoma
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 work-arounds for all of these things,
are you really coming out ahead?

~~~
cellis
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.

~~~
rbanffy
You could also move to Django-nonrel, but I know - it's a lot of trouble. Like
I said, I am exploring.

------
wccrawford
I think we're missing a big part of this...

How many users were using it?

~~~
groks
More than 100,000: <http://goo.gl/wiDj6>

------
mark_l_watson
A question for anyone on the AppEngine team that may also be useful for other
developers:

I have an app that I want to deploy and control my costs. I would like to pay
for 1 FE instance to always be running and limit temporary FE instances to a
maximum of 1 (free?) instance when needed. I expect my app to have a
relatively small number of users, but they will be active.

I would like to prevent the scheduler from ever spawning more than these 2 FE
instances. Occasional unavailability when the site is busy is OK. Except for
bandwidth and storage, I would like to know roughly what my costs will be.

Just to be clear, how do I set this up?

------
angusgr
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. after. I'd be
interested to know how it stacks up before vs. after vs. if-we'd-taken-
another-route.

~~~
buff-a
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.

~~~
angusgr
Thanks. :)

------
davisml
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.

~~~
vessenes
Agreed. The number of instance hours is vastly different on the two charts;
the price seems to be going from .10 / hr to .08 per hour (currently .04).

~~~
mtogo
That's the point. Appengine is changing their pricing from CPU hours to
Instance hours, so an app that previously had 3-4 hours a day is now going to
have 48-72.

~~~
davisml
Damn it. It appears the only solution is limiting the amount of instances in
the application settings. I manage a free sync service with approximately
20,000 active users on App Engine. I just checked the billing history for our
application and saw similar results, the cost will increase 10 fold.

------
allad
I also have an app on GAE. <http://www.tubesmix.com> Right now there's no
charge as there's only a couple hundred users and the resources used are low.
But this change worries me a lot. Even more so since all my backend code is
tied to GAE infrastructure. This is very disappointing coming from Google.
Since when did they become so nickel-and-dimey?!

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

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

------
wavephorm
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.

~~~
jonknee
> 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.

Except for the largest business on the internet... Well search, video
delivery, mobile phones, email, mapping, news, RSS, web analytics, and web
browsers. Getting clobbered in almost everything else though.

~~~
wavephorm
They make no money on those products. They can't charge money for their
products because they are half-assed knockoffs that nobody will pay anything
for.

~~~
jonknee
They make a ton of money on those products. It's all part of the ecosystem.
Android users use Google search. So do Chrome users. Analytics users use
AdWords (get too many hits with Analytics and you need to start spending some
sweet AdWords bucks). YouTube and Gmail users see ads (Google Apps business
users pay money directly).

~~~
wavephorm
Nonsense. Google makes 97% of their revenue from search advertising, they
can't make any money elsewhere and they even say so themselves. Everything
else they do is to keep up appearances that they are a market leader, which is
very far from reality.

Android is a junky iOS-knockoff operating system they pawn off for free
because it can't be sold. This comapany can't produce a single product worth
paying for other than search ads, and even that is going down the tube. Sure,
maybe their shareholders have been fooled, but the paying consumer hasn't.
Whether they admit it not, Google is in severe trouble if search advertising
decreases even a few percent.

Everyone seems to have a crush on Google, but they are going to get fucked
pretty badly long term unless they find some alternative, major, multi-billion
dollar sources of revenue of which they've found zero so far. Self-driving
cars maybe?

~~~
jonknee
Those products bolster search advertising... That's the point. Android
produces a ton of search revenue. So does Chrome.

> Android is a junk iOS-knockoff operating system they pawn off for free
> because it can't be sold.

It's the most popular smartphone OS... Is Linux free as well because it can't
be sold? Your blind hatred of Google is bizarre.

~~~
wavephorm
I said they are half-assed products. Google is not commited to GAE, or
anything for that matter. Perhaps they lead in indirect ways to advertising
revenue. But that's no excuse for having no support at all for any of their
products. The poor quality of GAE is a symptom of an ambivalent company that
doesn't deserve your respect.

~~~
libraryatnight
Poor quality? Did you not read the posts of all the devs saying they really
like GAE, some of them so much that the pricing change isn't really even an
issue?

You're not contributing to this conversation at all, you're just spewing
opinionated venom with no support for your claims.

~~~
wavephorm
My original points of Google building half-assed products they don't care
about was succinct. It's others on this board that keep dragging on and
defending the company for some reason or another. Perhaps it's because they're
employed by them?

------
crizCraig
I've been developing for app engine since 2008 when it came out and absolutely
love it. The price changes are a result of turning a successful and massively
growing product into a profitable one a la search, youtube, etc... Google
should be praised for this. The changes in price also accompany an SLA that
guarantee developers will receive three years notice before a breaking API
change or service shut down.

The SSL problem is a limitation in some browsers that causes the type of
certificates that GAE needs to use a CNAME, not IP, based routing to display
huge warnings.

------
igorgue
I hope PlusFeed's author read this:

Man that's some nasty code, horrible, don't open source that kind of "code"...
it's bad, even for a 5 minute projects, it's really bad.

Open Source software is not a dumpster of your bad code.

~~~
thematt
He wrote software that many people found useful and gave it away for free.
That's awfully damn generous as far as I'm concerned. You see an improvement
that can be made? Then make it. But stop complaining.

~~~
igorgue
I don't want to sound like a troll... but you're better off re-writing the
whole thing... I mean look at it.

[https://github.com/russellbeattie/plusfeed/blob/master/plusf...](https://github.com/russellbeattie/plusfeed/blob/master/plusfeed.py)

Global variables galore, tabs no spaces, no documentation, compares to empty
not just once but multiple times, pokemon style exception handling (you gotta
catch them all!), 'is not None' lol, type checking instead of duck typing...
Just to name a few.

14 pople forked it already, I hope those are Github bots.

~~~
humbledrone
You realize that you're looking at a 399 line script, right? A couple of
globals are perfectly reasonable at that scale.

Also note that checking for "x is not None" is the recommended, idiomatic
Python style (see <http://www.python.org/dev/peps/pep-0008/> for reference).

More importantly, the script works, and was apparently used by quite a few
people. Rewriting something that is already known to work, just because you
don't like its style, is generally a bad idea.

~~~
dev360
This code is a complete abomination, why would you stick your neck out and
defend it? What igorgue is saying is, even if somebody gave me this code, I
wouldn't take it, and I concur.

