Rudimentary New Pricing Analysis

252 views
Skip to first unread message

Ugorji Nwoke

unread,
May 29, 2011, 8:06:45 PM5/29/11
to google-a...@googlegroups.com
The other threads don't address this in isolation. I'm hoping Greg can address this in his updated document. 

On-demand pricing (using 1.2 GHz processor for baseline compute):

GAE Frontend: 128MB RAM, 1.2 GHz processor ... cost 0.08cents/IH
GAE Backend: 256MB RAM, 1.2 GHz processor ... costs 0.16cents/IH

Compare With:
Amazon EC2 micro instance: 613MB RAM, ~1.2 GHz processor (burst to ~2.4GHz). 
--> COST: 0.02cents/IH
--> SUMMARY: GAE costs 4X on front end with 1/4 RAM, and 8X on backend, with 1/2 RAM
1and1 DEDICATED server: 2 X 2.2 GHz CPU, 2GB RAM. 
--> COST: $60/month (roughly 0.08cents/IH)
--> SUMMARY: GAE provides 1/8 RAM and 1/4 CPU for equal pricing

Closing
It's hard to understand or justify how the hosting prices can jump so aggressively that they are not even close to being competitive against other established players (like Amazon). It feels atypical of what we would expect from Google. 

** Note that this comparison is just for the hosting prices. This is fair since the APIs are charged separately (so are not compared here).

References:

Barry Hunter

unread,
May 29, 2011, 8:27:31 PM5/29/11
to google-a...@googlegroups.com
For what it worth, I dont think it fair to compare a GAE instance like for like to a VPS. 

they are very different 'beasts'. GAE in theory provides you much more. Google handle all the setup, configuration, provisioning, load balancing. 

Granted it does seem expensive, if you only using equivient of one VPS. But once you start need to manage multiple VPSs, provision load-balancers, re-provision in case of failure etc, make backups. All that happens 'magicically' with GAE. 

Dont forget you also get a free quota of instance hours too. 



--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To post to this group, send email to google-a...@googlegroups.com.
To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.

Barry Hunter

unread,
May 29, 2011, 8:53:40 PM5/29/11
to google-a...@googlegroups.com
Or put it another way, the actual "instance" is a very small part of the overall infrastructure. 

Static files are not served off your instance (on a VPS they would use CPU cycles, or need a separate VPS/CDN  etc) 

Other capabilities, like image manipulation apis, and memcache etc, are using CPU/memory outside your instance. On a VPS, would need to dedicate some of your instances (or another VPS) memory to hold memcache items. 

To to provide all the capabilities, that your one little instance can do on GAE, may* well need a substantially larger VPS. Maybe one that costs $0.35 an hour. Or more realistically a larger number of VPSs. 


* say may, as we dont yet know what the full capabilities of the new instances will be. 

Which in fact shows another issue, all these comparisons are based on speculation (I've used a bit of speculation above in how they work) - its not really fair to compare pricing based on speculation ;)

Andrei

unread,
May 29, 2011, 10:46:30 PM5/29/11
to Google App Engine
If you don't mind working from shell and doing little admin go with
AWS
Since you are also learning more with AWS it's better for resume

On May 29, 8:06 pm, Ugorji <ugo...@gmail.com> wrote:
> The other threads don't address this in isolation. I'm hoping Greg can
> address this in his updated document.
>
> *On-demand pricing (using 1.2 GHz processor for baseline compute):*
>
> GAE Frontend: 128MB RAM, 1.2 GHz processor ... cost 0.08cents/IH
> GAE Backend: 256MB RAM, 1.2 GHz processor ... costs 0.16cents/IH
>
> *Compare With:*
> Amazon EC2 micro instance: 613MB RAM, ~1.2 GHz processor (burst to
> ~2.4GHz).
> --> COST: 0.02cents/IH
> --> SUMMARY: GAE costs 4X on front end with 1/4 RAM, and 8X on backend, with
> 1/2 RAM
> 1and1 DEDICATED server: 2 X 2.2 GHz CPU, 2GB RAM.
> --> COST: $60/month (roughly 0.08cents/IH)
> --> SUMMARY: GAE provides 1/8 RAM and 1/4 CPU for equal pricing
>
> *Closing*
> It's hard to understand or justify how the hosting prices can jump so
> aggressively that they are not even close to being competitive against other
> established players (like Amazon). It feels atypical of what we would expect
> from Google.
>
> ** Note that this comparison is just for the hosting prices. This is fair
> since the APIs are charged separately (so are not compared here).
>
> *References:*http://www.google.com/enterprise/appengine/appengine_pricing.htmlhttp://order.1and1.com/xml/order/ServerPremiumDualCoreMhttp://www.rackspace.com/cloud/cloud_hosting_products/servers/pricing/http://aws.amazon.com/ec2/instance-types/http://aws.amazon.com/ec2/pricing/

kwellman

unread,
May 30, 2011, 2:20:13 AM5/30/11
to Google App Engine
I've been keeping an eye on AWS Elastic Beanstalk (http://
aws.amazon.com/elasticbeanstalk/) and looking forward to the day they
roll out the Python version. With Beanstalk it seems Amazon is moving
towards providing some of the auto-scaling functionality we've become
accustomed to on GAE (and at no additional cost). It would certainly
make the transition easier if it ever comes to that.

Also EC2 does have a free usage tier for new customers.

On May 29, 8:27 pm, Barry Hunter <barrybhun...@gmail.com> wrote:
> For what it worth, I dont think it fair to compare a GAE instance like for
> like to a VPS.
>
> they are very different 'beasts'. GAE in theory provides you much more.
> Google handle all the setup, configuration, provisioning, load balancing.
>
> Granted it does seem expensive, if you only using equivient of one VPS. But
> once you start need to manage multiple VPSs, provision load-balancers,
> re-provision in case of failure etc, make backups. All that happens
> 'magicically' with GAE.
>
> Dont forget you also get a free quota of instance hours too.
>
> On 30 May 2011 01:06, Ugorji <ugo...@gmail.com> wrote:
>
>
>
>
>
>
>
> > The other threads don't address this in isolation. I'm hoping Greg can
> > address this in his updated document.
>
> > *On-demand pricing (using 1.2 GHz processor for baseline compute):*
>
> > GAE Frontend: 128MB RAM, 1.2 GHz processor ... cost 0.08cents/IH
> > GAE Backend: 256MB RAM, 1.2 GHz processor ... costs 0.16cents/IH
>
> > *Compare With:*
> > Amazon EC2 micro instance: 613MB RAM, ~1.2 GHz processor (burst to
> > ~2.4GHz).
> > --> COST: 0.02cents/IH
> > --> SUMMARY: GAE costs 4X on front end with 1/4 RAM, and 8X on backend,
> > with 1/2 RAM
> > 1and1 DEDICATED server: 2 X 2.2 GHz CPU, 2GB RAM.
> > --> COST: $60/month (roughly 0.08cents/IH)
> > --> SUMMARY: GAE provides 1/8 RAM and 1/4 CPU for equal pricing
>
> > *Closing*
> > It's hard to understand or justify how the hosting prices can jump so
> > aggressively that they are not even close to being competitive against other
> > established players (like Amazon). It feels atypical of what we would expect
> > from Google.
>
> > ** Note that this comparison is just for the hosting prices. This is fair
> > since the APIs are charged separately (so are not compared here).
>
> > *References:*

Ugorji Nwoke

unread,
May 30, 2011, 2:12:12 PM5/30/11
to google-a...@googlegroups.com
I'm very aware that GAE and AWS are different beasts and understand the advantages of IAAS. 

My point still stands though. Let's forget GAE and AWS for a second. If someone said you can use IAAS at 4X to 8X the cost of PAAS, is it justifiable in your mind? 

Back in the day, we had dedicated servers and managed servers for a 25% premium. I don't know what the premium should be, but 4X to 8X premium sounds a bit high. Just something for the GAE team to think about. It would be nice to see some price justification - it makes it easier to continue to evangelise GAE. I can see an AWS ad as below: 
"AWS hosting costs 1/8 the price of GAE, and gives you double the RAM". 


Barry Hunter

unread,
May 30, 2011, 3:05:37 PM5/30/11
to google-a...@googlegroups.com
I still think you are basing your comparsion on assumptions, ones yet to be proved. 

Its almost certainly better to wait until the promised price comparisons are available before jumping to conclusions. 


Ugorji Nwoke

unread,
May 30, 2011, 3:16:16 PM5/30/11
to google-a...@googlegroups.com
Just to clarify:

I'm not making any assumptions here. I just printed out facts from the official websites, and asked Google for some price justification. ie. Amazon gives a micro instance with some specs for a price, Google gives a front end and backend instance with some specs for a price. I listed both, and said that a rudimentary (basic, undeveloped) analysis looking at the price alone shows a 4X to 8X increase for GAE while giving significantly less RAM.

There's no assumption there. There's some listed prices, and a request for a justification from Google. If anything, an explanation by a non-googler on Google's behalf would be considered the assumptions. 

roberto.cr

unread,
May 30, 2011, 3:57:22 PM5/30/11
to Google App Engine
I know all of this, I just wish app engine got cheaper...

It's a hard choice, you really have to analyze per case.

If only it got cheaper, it'd be a lot more suited to a wider range of
projects.
I could bet this factor isn't present in google's price analysis,
while it definitely should.
If we, as app engine developers who enjoy the system, start to think
about pricing every now and then... something's not right.

* Here's hope for anyone from the app engine team to read this humble
opinion from a fellow GTUG member and app engine enthusiast! *

Raymond C.

unread,
May 31, 2011, 2:10:49 AM5/31/11
to google-a...@googlegroups.com
By "GAE provides you much more", you mean much more limitation right?

The cost on setup is trivial for a long run application when compared to the hosting cost.  I dont think the high price worth that cost for long term.

Also remember a GAE instance allows you to handle exactly one request at a time.  The cost is not just 4X or 8X, but 40X or 80X if one instance on EC2 can handle 10 requests at a time, which is normally much higher than this number.

Denis Volokhovskiy

unread,
May 31, 2011, 3:03:41 AM5/31/11
to Google App Engine
- "Also remember a GAE instance allows you to handle exactly one
request at a
time."
It is not true for JVM application instance - it handles requests
concurrently.

Besides, GAE memcache is globally visible to all instances, but in AWS
you need to setup your own per instance or 3rd party thru REST.
If you have 8 instances up, then you'll have to have 8x more memory
for your
caching - separate record for each instance.
Plus, with global cache, you may store temporary flags/signals/locks
etc.
Memcache requests will be faster inside GAE than to 3rd party.




On May 31, 9:10 am, "Raymond C." <windz...@gmail.com> wrote:
> By "GAE provides you much more", you mean much more *limitation* right?

Andrei

unread,
May 31, 2011, 10:58:09 AM5/31/11
to Google App Engine
Denis
How do you know gae memcache is not part of 128 Mb?
May be it is
How do you know how much memcahce is available to your app, is it
documented?


If you look at http://code.google.com/p/memcached/wiki/NewOverview,
which is one alternative for aws,
you do not need to replicate cache across all instances
If you look at large aws instance it has 7.5 Gb of memory, 4
processors and 850 Gb of space for 34 cents
Even if you take .5 Gb for memcache, which is more than enough you
still have 7Gb of RAM left
http://aws.amazon.com/ec2/instance-types/


On May 31, 3:03 am, Denis Volokhovskiy <altitudebre...@gmail.com>
wrote:

Stefan Podkowinski

unread,
May 31, 2011, 11:01:37 AM5/31/11
to google-a...@googlegroups.com
The comparison drawn in this post is valid as long as you assume a capped ~$60 budget such as spend by many hobby enthusiasts. Technically its apples and oranges, as GAE scales out far beyond a single machine setup. But thats not worth a lot as long as your budget isn't highly scalable as well, which should be the case for most private projects hosted on GAE. 
I'd very much like to see how much requests GAE (I'm using python) would be able to handle after the scheduler changes compared to a $60 dedicated system say running a node.js + mongoDB + memcache stack. If you'd need to scale out such a dedicated system, my guess is it would financially ruin you to do this with GAE if you have profitable business model behind it. 

Robert Kluin

unread,
May 31, 2011, 12:29:49 PM5/31/11
to google-a...@googlegroups.com
Backend servers are a different story, but I find it very difficult to
compare the cost of front-ends to most other things. Yes, a dedicated
machine / VPS can handle more requests per second and doesn't impose
many of the restrictions faced on GAE (native code, etc...), but on
GAE there is no OS management overhead, no "low-level" software stack
management, *and* GAE front-ends can scale up/down with demand *plus*
they can be moved to a different data center when needed. That last
points are the important ones. Look at the AWS outage, how much is it
going to increase your costs and complexity to be able to handle those
types of outages? It is included in the price of GAE. There is no
way to know how bad it will hurt until we see how the adjustments they
make to the system, specifically the scheduler, impact apps.

That said, I also wonder how friendly this new pricing is going to be
for small and very large apps. I'm sure there will be several classes
of applications that will need to reevaluate hosting options.

When comparing prices, don't underestimate the value of the HR
datastore, scalable front-ends, memcache, *and* the management costs
of those things. I've managed geographically distributed databases,
if you've not done it -- it is significantly more involved than you
think (assuming you care about your data). Don't forget to factor in
the cost of that management into your comparisons; if things run very
smoothly it will still be several thousand dollars per year.

Robert

Ugorji Nwoke

unread,
May 31, 2011, 1:02:41 PM5/31/11
to google-a...@googlegroups.com
I want to continue to use GAE. I understand the value immensely, and I invested a whole year into building a significant codebase around it and its limitations without caring about lock-in. If I can help keep Google honest and encourage them to revise their pricing so it is more palatable, then I am a happy camper. The alternative (re-writing my code and taking on some of the scalability features GAE gives me for free) is very unattractive. 

Having said that, I think the datastore in GAE is the biggest selling point which is hardest to reproduce. This is what is distributed geographically. However, the price for that is separate from the hosting. The hosting is a compute instance (with CPU and RAM) running your code on a simplified and uniform stack. I think there should be a premium for the hosting, but a 4X to 8X should be explainable to the customers or revised. 

To your points (and I am making assumptions here just to respond to your points):
- HR is charged separately from hosting (so should not be factored into why the GAE hosting is significantly more expensive)
- simplification of stack to just app code makes operator management and app scaling easier for the admins, not harder (I worked with BEA/Oracle team where we created the JVM without OS, and that was a big selling point that Ops became much cheaper. It makes it cheaper than what u get for managed hosting.)
- isolated instances (ie the instances don't communicate or know about each other) makes app scaling easier, not harder. (contrast with your typical J2EE app server where instances communicate via multicast or unicast and keep config and stuff in sync and auto deploy in live instances and maintain sessions in-process, etc).
- I read somewhere that all app instances share the same memcache instance, and there's no guarantees on anything, so memcache implementation in AE is pretty simplistic, and can easily be reproduced on a VPS

GAE main expensive piece is in the datastore scalability and features built on it, and that is charged separately. Most of the other bundled features which can be charged are charged separately. 

In summary, I'm not underestimating the GAE value (at all). I worked at BEA/Oracle for 10 years with WebLogic in engineering and with customers (I left last year to focus on some startup ideas) and appreciate the simplicity of the GAE model. I just think that a 4X or 8X cost against AWS seems like a high premium, and it would be nice to see some justification/explanation in Greg's response.

NB. Regarding AWS outage, this was caused by storage problem, not the actual EC2 instances. The closest analogue in GAE land is the datastore, which is priced separately from hosting. 

Jeff Schnitzer

unread,
May 31, 2011, 2:18:56 PM5/31/11
to google-a...@googlegroups.com
Some thoughts on your comments:

I don't think the amount of RAM supplied to a frontend instance is
particularly relevant - in most web architectures, frontend instances
just shuttle data back and forth between the user and backend data
services (datastore, memcache, facebook, etc). So it's really hard to
compare $/MB figures between Appengine and, say, EC2.

A better measure for frontend instances is $ per request throughput.
For each dollar spent on frontend instances, how many requests can you
serve? It's certainly going to be a major issue with single-threaded
python, especially if you make urlfetches to latent services. On the
other hand, if GAE's Java servers achieve the same levels of
concurrency that standard Java appservers achieve, then the limit will
be CPU power - and, to my knowledge, nobody has made any comparative
$/CPU measurements with GAE.

On the other hand, $/MB is a perfectly useful way of measuring GAE
*backends* since RAM is often the primary constraint of a backend
service. For many applications, comparing GAE backends to Other Cloud
backends is apples-to-apples comparison, and GAE's value is
extraordinarily poor.

I also totally agree with your point about excluding datastore pricing
from this comparison, since it is charged separately (as is Amazon's
SimpleDB). However, we need to start looking in greater detail at the
pricing of datastore operations, because it sounds like this may also
be a very significant price hike, and possibly will affect people much
more than the instance pricing that everyone has been talking about.

Jeff

Robert Kluin

unread,
May 31, 2011, 2:45:11 PM5/31/11
to google-a...@googlegroups.com
A few comments inline.

On Tue, May 31, 2011 at 14:18, Jeff Schnitzer <je...@infohazard.org> wrote:
> Some thoughts on your comments:
>
> I don't think the amount of RAM supplied to a frontend instance is
> particularly relevant - in most web architectures, frontend instances
> just shuttle data back and forth between the user and backend data
> services (datastore, memcache, facebook, etc).  So it's really hard to
> compare $/MB figures between Appengine and, say, EC2.
>
> A better measure for frontend instances is $ per request throughput.
> For each dollar spent on frontend instances, how many requests can you
> serve?  It's certainly going to be a major issue with single-threaded
> python, especially if you make urlfetches to latent services.  On the
> other hand, if GAE's Java servers achieve the same levels of
> concurrency that standard Java appservers achieve, then the limit will
> be CPU power - and, to my knowledge, nobody has made any comparative
> $/CPU measurements with GAE.

I've thought about $/request throughput too, particularly since I use Python....

>
> On the other hand, $/MB is a perfectly useful way of measuring GAE
> *backends* since RAM is often the primary constraint of a backend
> service.  For many applications, comparing GAE backends to Other Cloud
> backends is apples-to-apples comparison, and GAE's value is
> extraordinarily poor.
>
> I also totally agree with your point about excluding datastore pricing
> from this comparison, since it is charged separately (as is Amazon's
> SimpleDB).  However, we need to start looking in greater detail at the
> pricing of datastore operations, because it sounds like this may also
> be a very significant price hike, and possibly will affect people much
> more than the instance pricing that everyone has been talking about.

Excluding datastore pricing is a fair point. I also think defining
datastore pricing is important. From a discussion with Greg (last IRC
office hours), it sounded like the new pricing is going to be
somewhere around 25% above the current HR datastore pricing.
Honestly, that is not as bad as I first thought it was going to be.
Of course for master-slave apps it is going to be very noticeable.

Ugorji Nwoke

unread,
May 31, 2011, 4:15:19 PM5/31/11
to google-a...@googlegroups.com
I agree that RAM for front end instances *should* not be particularly relevant. And RAM *should* really only be relevant for backend instances.

However, RAM becomes more relevant as we try to push up the number of parallel requests that can be handled by a single instance. For example, suppose for each request, you pull out from memcache a bunch of data, and crunch and filter through them in-process and then return a response. Assume each request works on say 2MB of transient RAM (to be garbage-collected later). In this situation, the number of parallel requests can be limited by the RAM available for each process ie at n parallel requests, you can be at 20% CPU utilization but start getting java OutOfMemoryErrors (for example). 

[IIRC, you mentioned that in similarity.com, you store some serialized data structures in the datastore, and pull out of the datastore a batch of entities and do crunching in-process for some requests]

In most current single-threaded GAE instances, this is not an issue. But it will become more an issue once we start doing parallel requests more on GAE. 

One way to architect around it is to do a lot of this type of work on the backend. But even an option like that may be un-natural to your architecture, and the cost of the backend instances make them very unattractive.

With everything else, I completely agree. It's hard to discuss datastore operations, since Google has been vague about what an operation encompasses (is it dependent on size of the returned result set as Greg alluded to, or does it map linearly to a single API call as some docs allude to). Without getting into assumptions, it's a wait-and-see. 

Jeff Schnitzer

unread,
May 31, 2011, 4:56:41 PM5/31/11
to google-a...@googlegroups.com
These are all very relevant points for application design, but don't
particularly impact the proposed pricing changes... these are the same
limitations we have to live with today.

FWIW, Similarity does frequently load 50+ entities at a time (say, one
set of match results) each of which is a hefty structure that could
theoretically be up to the 1M limit in size... but in practice,
they're not likely to be more than a couple K. The chance of blowing
the heap is finite but very, very low. You're absolutely right,
memory consumption goes up with concurrency, and the multithreading
option is new, and the scheduler is still being tuned... this is just
something to keep an eye on.

Jeff

Reply all
Reply to author
Forward
0 new messages