Google App Engine Golden RAM

[pdknsk]

Riddle me this.

B2 256MB RAM $0.16/h

http://developers.google.com/appengine/docs/python/backends/overview/

n1-standard-1-d 3.75GB RAM $0.145/h

http://cloud.google.com/pricing/compute-engine.html

[Barry Hunter]

You are not comparing like for like. 

An app-engine 'instance' is not just a generic VM instance. 

Its 'managed' for you - you dont need to install a OS, manage patches etc. Even a backed has an effective load balancer in front of it, a firewall. Access to other 'free' services, memcache, task queues, etc. 

The classic IaaS vs. PaaS difference. 

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

[Michael Hermus]

It is definitely not an apples to apples comparison, and App Engine should be significantly more expensive using a simple $/GB metric.

However, $0.039/hr/GB for Compute Engine vs. $0.64/hr/GB for App Engine (1600% higher) did raise my eyebrows as well. Part of it seems to be that the Compute Engine price (on a per GB basis) seems pretty darn low.

On Friday, June 29, 2012 8:52:34 AM UTC-4, barryhunter wrote:

You are not comparing like for like. 

An app-engine 'instance' is not just a generic VM instance. 

Its 'managed' for you - you dont need to install a OS, manage patches etc. Even a backed has an effective load balancer in front of it, a firewall. Access to other 'free' services, memcache, task queues, etc. 

The classic IaaS vs. PaaS difference. 

[Ugorji Nwoke]

The Compute Engine price is not low. Amazon charges the same price (more or less) for EC2. Some other providers charge even better prices.

ProfitBricks allows u scale up live, and sells by the RAM and Cores you need. 

OVH sells a dedicated box with included guaranteed 100Mbps up to 10 TB bandwidth per month, 16GB RAM, dual-core 3.4GHz intel core i3 sandy bridge processor, 2X1TB HD in RAID, for less than $70/month (with datacenters in NA (quebec), and France, and their own private global network)

Renting a VM (basically renting Cores and RAM) should not be crazy expensive. At Compute Engine prices, you're basically renting 1 core and 4GB RAM for $100/month. That's not cheap by any stretch, but it's the standard that AWS has set for IAAS. You then pay for bandwidth, persistent disk, etc at prices that AWS has set.

Google basically copied AWS model and added some differentiation in isolated networks, and presented it all simpler. I wish Google had done some more innovation here, more like what ProfitBricks is trying to do. Google and ProfitBricks already use the same underlying VM technologies (ie KVM, which allows some live migration, etc). With ProfitBricks, you can start with 1 dedicated (not virtual) Core, 4GB RAM, and while live, detect increased traffic, and can scale up that same instance live up to 64 dedicated cores, and 192GB RAM (without a restart necessary). KVM support for live migration is used here. ProfitBricks also support the isolated network configuration, even up to providing free loadbalancer over your instances, configurable by you. And their network storage is fast and consistent as they use only infiniband (not ethernet) for network.

But Google did say that this is a start. 

Google made a big deal of "consistent performance" for their persistent network block storage (which has been one of AWS archilles heels), but I'd have to see it. App Engine use of network storage for loading apps to startup has been anything but fast or consistent (see threads, even recent threads, about startup time variance due to slow and inconsistent times loading java classes from the "network storage").

Anyway, I have big hopes for Compute Engine. I had given up on App Engine a while back and rewrote my app for a "generic" linux VM, and looked at AWS, RackSpace, ProfitBricks and dedicated providers like 1and1, OVH. I'd like to use Google Compute Engine, and given the opportunity, would love to test it out during the preview. But I think we should hold the accolades for now. 

[Jeff Schnitzer]

I posit that for most of the use cases where backends would apply,
they really are like-for-like with IaaS. Both backends and Compute
Instances are accessed by URLFetch and neither autoscale. They
probably have similar latency numbers. Thanks to the remote api, you
can even access services in the same way.

Really, the only difference seems to be that the Compute Instance
deploy script is likely to be a little more complicated.

Let's look at some example applications:

* An in-memory index. The index keeps updated with a mirror of some
data stored in the datastore and services queries against the index.
Ikai's original description of the value proposal for backends
described some sort of free text search engine. Here you want RAM and
compute power. Massive win for compute instances.

* A cache (aka the Brandon service). Here you want RAM, RAM, RAM.
Even more massive win for compute instances. Brandon, do you expect
to migrate? Why or why not?

* In-memory game state for a realtime online game. Here RAM is
probably not as critical ad CPU power, although it's still
significant. The biggest thing you need is stability and reliability.
Here compute instances are unknown... but backends are not reputed to
be that reliable. Anyone have an average uptime statistic? It's
never ok for a gameserver to be rebooted arbitrarily.

I'm having a very hard time figuring out a use case where backends are
cost effective. Is it convenient to push the build out with the same
deploy script that I deploy my app with? Sure. Is it worth hundreds
or thousands of dollars a month just to use a different script? Hell
no.

Ok, there's one case: Backends let you run heavy data-churning tasks
with unlimited deadlines. The remote api is somewhat slower than
local access - although how much slower when running inside google
infrastructure is hard to say. However, there's a high likelihood
that most applications like this are better off doing map/reduce with
task queues.

Jeff

[pdknsk]

> You are not comparing like for like.

I'm well aware of this and don't expect parity (or close), but clearly
the RAM difference shouldn't be so dramatic.

[Kaan Soral]

Google was, capitalistically, trying to milk us/gae so that they can earn money, logical-ish
Since GAE is not for everyone, they had to increase the prices to these levels.

But, hopefully, if "compute engine" becomes successful, and steal some of Amazon's fame and fortune, I think Google might no longer feel the need to milk gae and either reduce the prices or increase the capacity.

Generally speaking, I don't think Google is developer friendly anymore, Gae is on the edge, If it was a bit more expensive I wouldn't be able to use it and Google Maps has become 10x the logical limit (look at mapbox pricing, they are on the edge, and as far as I remember it was 0.1ish of google maps prices), so my hope is for Google realizing this and pulling prices to developer-affordable limits. Especially Google Maps prices are extreme.