
Google App Engine leaves preview, new pricing - endlessvoid94
http://www.google.com/enterprise/cloud/appengine/pricing.html
======
riobard
The single most import reason that I like GAE is that it used to charge based
on CPU usage, so that I could carefully optimize my web apps to reduce costs.
This is also why I think cloud computing is a good thing: shared resources are
generally efficiently used.

Now that GAE starts charging by instance-hours, however they are calculated,
the drive to optimize is significantly reduced: I no longer have to worry
about a web app's CPU usage if I have to wait for I/O anyway.

Some will say that's how we, as developers, should allocate our time to
improve productivity, but the cloud platform as a whole just becomes a lot
more wasteful.

And this change makes GAE much less appealing than AWS. If I'm gonna pay for
instance-hours anyway, why not just launch some EC2 instances and kill them
when I don't need them anymore? Sure it comes with admin costs, but at least I
can migrate to another cloud provider much easier. Judging from the comments
on this thread, migrating away from GAE seems very expensive, if possible at
all.

~~~
Hawramani
Wouldn't the perfect cloud platform be one that charges based on disk IO, disk
space used, network IO, RAM space used, (Ram IO?,) and CPU used? Maybe there
are other metrics I'm ignoring.

Someone should start making this.

~~~
sdrinf
<https://www.nearlyfreespeech.net/services/pricing> been around since 2002,
does automatic load-balancing, have most of the benefits of what people are
calling "cloud-computing", makes no presumptions about language of choice,
does MySQL, and is extremely competitively priced.

~~~
sciurus
"makes no presumptions about language of choice"

Yes, but don't they do this by running everything as CGI scripts? That won't
perform well.

<http://example72.nfshost.com/versions.php>

~~~
sergeys
There's a 'pools beta' that runs your stuff in bsd jail. Worked well with
mod_wsgi in my tests (I'm not using it in production though).

------
krosaen
A key point seems to be:

""" The new pricing model charges are based on the number of instances you
have running. This is largely dictated by the App Engine Scheduler, but for
Python we will not be supporting concurrent requests until Python 2.7 is live.
Because of this, and to allow all developers to adjust to concurrent requests,
we have reduced the price of all Frontend Instance Hours by 50% until November
20th. """

Our app (python runtime) is going from about $9 a month to projected $270 a
month, almost entirely due to frontend instance hours. I have to think that
once python 2.7 is live and concurrent users != concurrent frontends, this
will get waaay more reasonable.

~~~
krosaen
Oh shit, and the $270 a month is _with_ the 50% discount:

"""The Frontend Instance costs reflect a 50% price reduction active until
November 20th, 2011. Learn more about the price reduction and ways to reduce
your costs permanently."""

So come winter, I'm looking at > $500 a month... here's hoping concurrent
requests on the python runtime will make a huge difference, otherwise, sheesh.

~~~
psm
you have time before the billing switches on to tune/adjust your application.
check out the FAQ and tuning tips page. the prices are going up, but they are
also changing, in that we're measuring things differently. most apps that are
initially seeing a large multiplier are because of the latter effect, not the
former. this is why we built and launched the side-by-side billing. (i'm on
the GAE team)

~~~
buff-a
Can you explain how on earth my app goes from 0.02 cpu-hours to 2.8 instance-
hours?

Are you doing the "any part of an hour is billed as an hour" thing that
EC2/Azure do?

------
ww520
I think it's unfortunate that GAE use the term instance-hour for billing,
which is quite different from AWS instance-hour. GAE's instance-hour is
process-instance-hour while AWS is machine-instance-hour.

The difference is quite important. In AWS, you can spin up dozens of processes
in an instance. In GAE, the instance is the process. If the process is idle
waiting for IO, you are still being charged. Spinning up more processes mean
more instances running and more are charged.

In that sense, GAE's $0.08 per process-instance-hour is quite expensive
compared to AWS's $0.085 per machine-instance-hour. "Single-thread" Python
process needs multiple processes to handle multiple web requests which counted
as multiple GAE instance-hours while only a single AWS instance-hour.

------
thurn
The trouble with App Engine is that I'm now locked in to their API. They can
raise prices and I have no real recourse unless I want to rewrite a _lot_ of
code.

~~~
georgemcbay
I was an early advocate of GAE but this is now my fear as well. When the new
pricing was announced, the amount that they raised the service by seemed quite
fair, but just the fact that it went up spooked me into being afraid of the
fact that they could readjust the price at any time.

While I suspect they won't make it a habit of raising the price from here on
out, the more I thought about it the more I've come to the conclusion that it
makes sense to go with providers that use more standardized software stacks
(despite how great not having to sysadmin is and the easy deployment from
Eclipse to GAE), because that way I can take advantage of future competition
of providers. If I go with GAE the costs to switchover become greater and
greater the longer I'm there... so while they may never jack the price UP on
me, they'll have little incentive to bring the price down due to increased
competition.

~~~
psm
we encourage you to look at appscale for app mobility. we're not interested in
artificial lock-in from APIs. we're not that kind of a company. we're
confident we can make the overall service superior. please note that we
haven't changed the prices since we launched pricing, and GAE was in preview.
that's an element to the notion of "preview". we're now taking it out of
preview into a fully supported Google product. and part of that was to reprice
so we have a sustainable business. after we announced the new pricing in May
at I/O, we've actually seen our growth rate increase, since customers
appreciate that we're committing to GAE.

~~~
nknight
AppScale deeply confuses me.

They seem to do a rare (once a year or so) push of whatever they've developed
into a public source repo, and then just leave it there. No updates, no bug
fixes, no community involvement, etc.

Their site looks like they're trying to sell me something, but there's no
commercial product in evidence. And the whole thing seems to be done under the
auspices of a university.

There's a link to their supposed development branch, bizarrely on launchpad
instead of Google Code where they seem largely based, but it's empty.

I'm not really inclined to put time and effort into something whose model and
motivation completely escapes and/or scares me.

~~~
nlake44
We're very much graduate students and our testing cycle takes a lot of time
away from doing research and publishing papers. We try to keep the main branch
as stable as possible though for those who just want to get the latest and
greatest. Our branches are pretty active and we do track issues/bugs and fix
them, although you're right that we don't do so on our Google Code page.
[https://code.launchpad.net/~appscale-
maintainers/appscale/ap...](https://code.launchpad.net/~appscale-
maintainers/appscale/appscale-main)

~~~
nknight
OK, that answers a hell of a lot of questions, thanks!

I also now note that there's a "Contribute" link at the very bottom of your
main site.

If I may make a couple other suggestions:

* Fixing the "Development Branch" link on your page (it's in the "Download" menu) which confusingly points to this totally inactive URL: <https://code.launchpad.net/~cgb-cs/appscale/appscale>

* Making some sort of statement on the Google Code page about your development practices and the fact that the bleeding edge is on Launchpad. People like me go to a Google Code page expecting to see _the_ development site, complete with an active source tree, and get very confused when that's not what it really is.

~~~
nlake44
Thanks for pointing that out. Updated.

------
Fizzer
If Google had said from the beginning that their pricing was discounted for
the preview, I would not have had a problem with this. But given that they
didn't communicate this and that the cost of switching platforms is high, this
feels more like a bait and switch tactic.

My cost is only increasing about 4x, but others in this thread are seeing
20-100x increases. Changes like this impact more than GAE -- this will make me
hesitant to use any platform that I can't easily migrate away from.

------
PanosJee
We (at bugsense) have about 500k requests per day and some of the are very
intensive. Currently we pay $5.40 daily and it will go up to $22. So per month
with the old pricing we ll be at $162, with the new pricing we ll up to $660.
It's x4 increase and that makes it bit cheaper than EC2 for the same amount of
data. If we subtract the administration cost it makes it cheaper. The old,
cheap days are gone :( But still it compares well in comparison to other
popular cloud solutions.

~~~
anabanana
$22 daily after November? Without the 50% discount?

~~~
PanosJee
Yes without but there is a lot of space for improvement with better leverage
of taskqueues and async datastore operations. We hope to reduce by 50% some
some of the requests so that we spin out less instances. We also fine tuned a
bit, check out our results: <http://news.ycombinator.com/item?id=2951217>

------
cyberfart
About the huge cost increase people mention in the comments: New cost unit is
IH (Instance Hour) and GAE python scheduler has a habit of revving up new
instances aggressively. To lower costs one needs to lower Max Idle Instances
and -maybe depending on the situation- increase Min Pending Latency, thus
lowering the Instance count (and the cost).

With the price increase and very harsh cut down on API free-quotas (plus the
absence of long expected SSL on custom domains) GAE no longer seems a good
option for me :/

~~~
psm
we've cut the free quotas from super-generous to just generous. we're still
the only large service offer generic platform free quota with no time limit.

as for delay in SSL on custom domains, we're guilty as charged; we're not
happy it's taking so long and we're working hard on it.

~~~
lukeinth
Costs for our app have just gone from $120 per month to $1200. Its a service
we provide to users for free, we cant afford that level of hosting. That is a
10x price increase.

How many biz can get away with that sort of hike? This and how Google treats
Android developers (shutting down forum, not responding to issues) is making
me question why I bother building anything for your platforms.

I was on app engine from the start, I've sat though your DevFests, arranged
hackathons, and told countless people they should use your platform. I've
invested many hours learning your API. But this is it, its over, no more.

Anything but a tiny free app is going to cost the earth, if you want to scale
use AWS or Heroku. If you are an outside developer trusting Google it will
cost you.

------
anabanana
I have an online store that I custom developed in Python hosted in App Engine.

I'm paying around $15 a month. With the new prices I would have to pay $450 a
month.

Time to migrate :(

Any recommendations for a python hosting?

~~~
omfg
Might want to try out Heroku's Cedar Stack. It's been great so far.

~~~
walkon
Heroku currently supports Python, or is that something that is in the works? I
can't find much on this...

~~~
sirn
I think it's still in the works. They don't mention it, but Heroku Cedar will
happily reads and install requirements as defined in requirements.txt when you
push to it. Server setup is just a simple Procfile calling whatever Python web
server you want to use.

------
peteysd
Wow - According to their projections based on current usage, I'm seeing a 100x
increase in my daily cost. I guess I will be migrating off of App Engine. I'm
feeling pretty burned at this point.

~~~
psm
some apps get high multiples because they're using resources that weren't
counted before, or were counted differently; that's why we enabled side-by-
side billing now (before we switch on billing). if you email me your appid
(psm@google.com) we can help. you should also review the FAQ and the tuning
tips web page that we put together.

~~~
dfabulich
Could you define how high a "high multiple" is? 30x is too high, right? Is 3x
too high?

------
sylvinus
AWS: "We'll continue to cut our prices forever"

GAE: "Almost all applications will be billed more under the new pricing"

Pick one...

~~~
andypants
Well, they have said that this is the first and only price change to happen.
They won't be increasing the price anymore after this.

~~~
danssig
Never is a long time, no?

------
kkowalczyk
I'm seeing going from $0 to around $1 per day (can be as low as $0.25), all of
it for CPU hours. This can be seen in billing history.

That's obviously not something to be happy about but then again an argument
can be made that the introductory free quota that Google gave was very
generous.

This might give Go a push - as I understand it Go is the most efficient of the
supported languages which should translate into less CPU hours => less money.
On the other hand, other than template parsing/substitution, my code doesn't
do any CPU intensive tasks. On the other hand, the CPU hrs might count the
overall overhead of the platform, which for statically linked Go will be the
smallest (both Python and Java have sizable runtimes that need to be
initialized at startup - according to
<http://www.youtube.com/watch?v=HQtLRqqB-Kk>, Java runtime is especially bad
in that regard (this is towards the end of the talk in the q&a part).

~~~
ww520
I don't think it's a matter of Python/Java being slow and GO is faster. It
actually doesn't matter which language you pick. If your GO app is IO/network
bound, you will be charged for the idle CPU hours in the new billing scheme.

------
nir
Very disappointing. GAE for a while was for developers what Tumblr/WP.com/etc
are for writers, a way to put an idea online cheaply & easily. The generous
quotas made using the proprietary APIs worth it. Now it's just another PaaS.

Seems to me Google is competing in areas it'll never be really good at like
social networks instead of using its core competency of running the world's
biggest server farm.

------
andypants
What the...

The cost of my app is going from $9 per month to $200 per month. This is
ridiculous...

------
mark_l_watson
I just read all of the comments and one thing that no one mentioned
explicitly:

You can still use a free instance that is 6.5 hours a day, 1 gig of datastore,
1 gig each of incoming and outgoing bandwidth, etc. Low volume sites should
easily be able to stay in the free zone.

Free instances had better have a low loading request time (e.g., for Java
apps, use Objectify instead of JPA, etc.).

Assuming I understand the new billing correctly, I can get a paid plan for
$9/month + $36/month for one reserved always on instance. I also get 24
hours/day of free on demand front end instances to handle a bit more traffic.

I think that a paid for plan still gets the other free quotas of a free plan
and you pay each day for any use over each free limit. Is this right? It looks
like you can have 1 always on FE instance, and 1 or 2 on demand FE instances,
and a reasonable about of resource use for less than a $100/month.

~~~
ramses0
I think that's the dumb part though. If you get one user per hour for 12 hours
a day, you're still overflowing the "6.5 hour limit" (unless I'm
misunderstanding everything).

I'd love to use GAE for the reproduceability of dev environment, but lock in,
10x+ price increases and a VERY obtuse (not honest) explanations of how
pricing is measured and billed makes EC2 look much better. I'll need EC2
anyway since you can't run arbitrary binaries (ie: PDF conversion) on GAE.

~~~
dwyer
You get 6.5 CPU hours free with the current model, you'll get 24 instance
hours free with the new model.

------
philwise
I would see this as a move towards 'enterprise' (yes I know people here hate
that word), but look at the url...

$9/app/month means that it doesn't really make sense for tiny hobby sites any
more: it is comparable in cost to a tiny VPS host, and my VPS currently
handles 19 domains.

The place where GAE makes most sense is the 'line of business' app that is
basically just a set of forms backed by a database. Those kind of apps don't
have any complex things going on that are going to require integration with
existing code or custom server configuration: both places where the current
crop of PaaS offerings risky right now.

Line of business apps currently require lots of manual labour from DBAs and
IS, so paying $9/month to run the HR application is going to be a pretty good
deal.

------
ww520
I have one new app during design phase. The frontend part is going to be in
GAE since I had done couple apps in GAE and familiar with it. A part of the
backend will be in AWS because I need to run a custom 3rd party app. With the
new pricing model, it doesn't make sense to run webapp in GAE. I'll redesign
the thing to run the whole thing in AWS.

------
richardw
The source of my disappointment is that basically, they couldn't figure out
how to slice and dice page serving without dumping you with the cost of a full
VM. I was hoping they were committing to researching how to make that work, so
if you made an efficient application you never had to worry about the
infrastructure. Now, the abstractions have leaked and we have to worry about
VM's. Time to update my answer here:
[http://programmers.stackexchange.com/questions/64727/windows...](http://programmers.stackexchange.com/questions/64727/windows-
azure-vs-amazon-ec2-vs-google-app-engine/64734#64734)

I guess the problem of really efficient web serving remains unsolved.

------
sriramk
I just sent some mail to my old colleagues in Windows Azure. If you're working
on a cloud provider, a large one or a startup, you and your biz-dev/sales team
should be out there actively trying to get people dissatisfied with GAE's
announcement today (and from what I hear, that is a significant number).

------
flocial
This pretty much confirms my reservations of investing in a closed stack.
However, it's really a shame that Google didn't take the time to provide a
clean migration path for people to take their apps out of the platform so they
can scale up to a regular hosted or self-hosted application.

------
ConceitedCode
App Engine seems like a great platform, but unfortunately it's a pain in the
ass to switch away if you decide you want to. Unless I'm building a
small/quick app I do not want to be 'locked in' to App Engine.

~~~
wescpy
It's easier to switch away and not be locked-in if you develop your app using
Python/Django (see my comment above).

------
papaf
Meanwhile, VPS and dedicated server providers are getting cheaper, faster and
more competitive.

I'd imagine that the majority of the people on GAE have found that they don't
actually need to scale as much as they thought when they signed up to it.

------
ayanb
The difference in features between the free and the paid ($9/app) plans are

1)Usage based pricing, 2) Infinitely scalable and 3) an SLA

------
DennisP
The biggest problem I see is that they charge per datastore operation, and
last I saw they were defining each entity returned as an operation.

If you were building a social network or twitter clone using the techniques
they recommend in this talk:
[http://www.google.com/events/io/2009/sessions/BuildingScalab...](http://www.google.com/events/io/2009/sessions/BuildingScalableComplexApps.html)

...you could easily pull back a hundred entities each time you pull someone's
feed. It'd cost you a buck for every hundred pageviews or so.

------
fernandotakai
One app I manage is going from $0.05 a day to as high as $4.00.

That's _really_ too much.

------
jay_kyburz
The most disappointing thing for me was that the little bit of banner
advertising I have on the games is no longer going to cover the cost of the
hosting. It was nice a thought that the games could sit there forever and
people could enjoy them for free.

------
yoknapatawpha
It's obvious that there are many people who are upset about this price hike,
how poorly it has been explained (showing "this is how much more we'll be
charging you really soon!" side-by-side with the current pricing really
doesn't help), and that it feels like a bait and switch given how AppEngine
was originally sold on the basis of scaling against CPU usage rather than
instance hours.

Telling us that Python 2.7 may reduce the cost multiplication factor by a bit
just isn't very helpful.

Additionally, it also makes Google look a little bit stupid. We're supposed to
accept that a world-leading company in the field of data processing, storage
and server farms weren't able to determine ballpark running costs for their
selling off their excess machine hours until now? Pfff.

In light of the fact that GAE hasn't exactly been the most stable platform,
technical support has been untimely and poor, high priority bugs can stay
acknowledged for years, a timeline for SSL support is still non-existant, and
full search capabilities are only now impending at some unknown date (and how
much will that cost when it finally arrives?), it really does make them look
like rank amateurs.

The AWS team must be laughing.

------
ww520
I don't understand how the instance-hours are being calculated. One of my apps
has the old 2.5 CPU-hours/day to the new 34 instance-hours/day calculation.
The app is not CPU-intensive and 2.5 hours of work sound reasonable. It
certainly is not hogging the CPU 34 hours the whole day. Does the new
instance-hour include the process idle time of app?

~~~
Zakuzaa
Hours when CPU is ON are counted. Not actual CPU usage or cycles.

~~~
ww520
So it counts idle time. When a process is idle, it doesn't use the CPU, which
can be used by other processes.

This basically punishes IO/network bound apps and favors CPU-intensive apps.

I can see why some of the web apps has 100X cost increase since they spin up a
process to handle a web request which can take fair amount of network time but
uses very little CPU.

The new pricing model is not web-app friendly but favors heavy CPU-intensive
backend processing kind of apps.

~~~
antrix
Not really, if you enable multi-threaded request handling. While one
thread/request is waiting for IO/network to complete, other threads are still
handling requests. All in the same instance.

------
chrisboesing
Just a quick note: App Engine hasn't left preview.

This[1] blog post from today says at the end: "[...]and we hope you find these
tools useful as we get closer to our goal of leaving preview!"

They just rolled out the new pricing.

[1]: [http://googleappengine.blogspot.com/2011/08/50-credit-for-
ne...](http://googleappengine.blogspot.com/2011/08/50-credit-for-new-billing-
signups-and.html)

~~~
bigwally
The email I received was titled "Google App Engine Leaving Preview". And it
states "We plan to roll this out in the second half of September...."

The scariest part of looking at my billing history is "Frontend Instance Hour
costs reflect a 50% price reduction active until November 20th, 2011"

------
2AM
After I read the email from Google, I didn't think the impact would be huge on
my small app that just started gaining users, but it was a little shock, I
headed to HN to find out if other people are affected or my app was badly
written. I think everyone is affected.

I will be moving my app, if anyone else likes to use a freelancer, please drop
me a line: varese4@gmail.com

------
tantalor
If your app can survive on 1 instance, but occasionally uses 2 or more, you
should immediately change your "max idle instances" to 1 so you won't be
charged for the extra instances.

The new free limit for frontends is 24 CPU hours, or 1 instance. I was seeing
my frontend time in the 25-30 hour range each day.

------
markokocic
Everyone is talking about huge cost increase for python applications, but I'd
like to know what are the numbers for Java applications, since Java is
multithreaded?

Is the price increase still tenfold, or something more acceptable?

~~~
jasonkiefer
Our Java application has gone from $240 per month to $6000. Total bait and
switch. This is a business killer.

------
jasonkiefer
This is a total bait and switch. On the same day that Appengine took our site
down for 18 hours with no apology(we support 3000 daily visitors with an
average time on site of 13 min). They announced that costs would increase from
$240 per month to $6000. SIX THOUSAND! This is truly the definition of evil if
you ask me.

------
datastorebackup
Those who are talking about being 'locked in' to App Engine, there are
solutions, like <http://www.datastorebackup.com>

The essence of your data is saved. Nothing to worry about then..

And regarding the pricing... We'll see.. I'm not sure WHEN exactly it's going
to be shifted - does anyone know?

~~~
A1programmer
It's not only about the data, however. It's also about the x lines of code
that are GAE specific. The datastore API is non-standard, and cannot easily be
ported elsewhere.

------
jbaker
There has been a lot of confusion and complaining about the price increases,
and this is understandable given the way it has come about. This is one of
those oh so obvious things, but you just have to look at it and evaluate.
Besides scalability, app engine can be a great platform from a rapid app
development standpoint. It has other nice aspects in addition to the
scalability.

And don't forget to look into what may be able to be done to minimize some of
the quota impact. Good design changes may be able to have a noticeable
positive effect there.

Have a look at AppScale if you are looking at moving off the platform. That
may be a way to get 80% of the way there with less monumental changes.

~~~
angkec
"And don't forget to look into what may be able to be done to minimize some of
the quota impact. Good design changes may be able to have a noticeable
positive effect there."

You mean concurrency? That won't be available until November. And if it fails
to save the bill, you'll be screwed big time.

------
thebootstrapper
Migrate to EC2 with Appscale is a better way?

------
eridius
Strange, there's no mention of the Go runtime on the pricing page. I realize
it's still a beta runtime, but it's still odd to leave it out.

------
EastSmith
When is Python 2.7 coming to GAE?

