How Google Compute Engine stacks up to Amazon EC2(gigaom.com)
gigaom.com
How Google Compute Engine stacks up to Amazon EC2
http://gigaom.com/2013/03/15/by-the-numbers-how-google-compute-engine-stacks-up-to-amazon-ec2/
39 comments
So your total spend on 1 reserved EC2 m1.medium instance is $579.92 a year, not including any bandwidth or EBS storage. On the other hand you could go to OVH and get a dedicated server with 8gb of ram and 2TB of disk and significantly faster processor for $468/year and that includes 5TB of bandwidth a month. (source: http://www.ovh.com/us/dedicated-servers/kimsufi.xml)
Seems like unless you are going to need the ability to quickly scale the number of instances up and down it makes more sense to put your core services on dedicated servers rather than in the cloud.
Seems like unless you are going to need the ability to quickly scale the number of instances up and down it makes more sense to put your core services on dedicated servers rather than in the cloud.
>Seems like unless you are going to need the ability to quickly scale the number of instances up and down it makes more sense to put your core services on dedicated servers rather than in the cloud.
Which is almost always the case for startups (needing to scale at will).
Which is almost always the case for startups (needing to scale at will).
I don't know too many startups that need to scale in minutes as opposed to hours. Even sites that have taken off have usually had growth over a period of months or years. I do think it makes sense if you are doing something massively cpu intensive that has hugely varied demand (video encoding, etc).
"Multi-region images
We’re not quite sure why AWS doesn’t support this, but images on GCE are multi-region (“multi-zone” in their terms)"
Whilst images are not multi-region, you can now copy them[1] across regions with AWS.
[1]http://aws.amazon.com/about-aws/whats-new/2013/03/12/announc...
We’re not quite sure why AWS doesn’t support this, but images on GCE are multi-region (“multi-zone” in their terms)"
Whilst images are not multi-region, you can now copy them[1] across regions with AWS.
[1]http://aws.amazon.com/about-aws/whats-new/2013/03/12/announc...
Keeping the image in one region allows the customer to guarantee data provenance - EU folks don't want their data accidentally getting stuck on US servers (and the other way around).
Looks impressive but would I be wrong to assume that disk write performance will go down as GCE adoption spreads?
As far as I know providing virtualized storage is not something that you can consistently limit like RAM for example. Still competition is always a good thing and especially if the giants are fighting it out (Amazon, Google, Microsoft)
The biggest problem GCE has is not performance or anything technical - it is the terrible, terrible support that Google offers (or fails to offer).
I'm pretty sure that most people who have used any of Google's pay for services knows just how bad that support can be.
What happens if something goes wrong with your billing on EC2? No problem, you call them up and sort it out.
What happens if something goes wrong with your billing on any Google product? You'll be down for days while attempting to get Google to even acknowledge a problem.
Until Google fixes their support issues, anybody using a Google service for anything business critical needs to be very careful in weighing up pros and cons.
I'm pretty sure that most people who have used any of Google's pay for services knows just how bad that support can be.
What happens if something goes wrong with your billing on EC2? No problem, you call them up and sort it out.
What happens if something goes wrong with your billing on any Google product? You'll be down for days while attempting to get Google to even acknowledge a problem.
Until Google fixes their support issues, anybody using a Google service for anything business critical needs to be very careful in weighing up pros and cons.
Disclosure: I work for a competitor to both Google/GCE and Amazon/EC2.
I think that this comment is spot-on. Google doesn't seem to understand that the infrastructure business is fundamentally a trust business: as elastic and transient as the cloud can feel, when choosing a foundation, you're making decisions that must stand for years. Not only does Google provide infamously Kafka-esque service when they're down or otherwise unavailable, they have a history of capriciously killing services and/or repricing them -- and one need look no further than the user dissatisfaction over GAE to know that GCE will be lucky to survive its infancy. Indeed, GCE is caught in a nasty catch-22: because of Google's track record of killing tertiary services, the market is very much waiting for it to become primary for Google -- but because the market is waiting, it may well never be. This is a self-fulfilling prophesy that is as obvious to cloud decision makers as it appears to be lost on Google.
I think that this comment is spot-on. Google doesn't seem to understand that the infrastructure business is fundamentally a trust business: as elastic and transient as the cloud can feel, when choosing a foundation, you're making decisions that must stand for years. Not only does Google provide infamously Kafka-esque service when they're down or otherwise unavailable, they have a history of capriciously killing services and/or repricing them -- and one need look no further than the user dissatisfaction over GAE to know that GCE will be lucky to survive its infancy. Indeed, GCE is caught in a nasty catch-22: because of Google's track record of killing tertiary services, the market is very much waiting for it to become primary for Google -- but because the market is waiting, it may well never be. This is a self-fulfilling prophesy that is as obvious to cloud decision makers as it appears to be lost on Google.
Thank you - I couldn't say this better myself. You have captured the essence of a problem with Google - trust.
After GAE and treatment of "non-essential" products under Larry, I have lost the trust in Google as a reliable business partner, regardless of any technical advantages their offerings might have at the moment.
A small shop like ours can't rely on a partner who can change major aspects of a product without any concern for its customers. And when the trouble comes, being left at the mercy of a random Googler who might come to the rescue if you are sufficiently Internet famous is not a recipee for building a stable business.
Thank you, but no thank you. I'll stick with companies who are relentlessly working on improving their products, driving prices down and care about their customers even if their products might be behind in some areas.
Until Google proves that they care and are in this for a long haul, my business goes somewhere else.
Oh, yeah, this applies to personal usage too - good bye Google Reader, my most used Google product...
After GAE and treatment of "non-essential" products under Larry, I have lost the trust in Google as a reliable business partner, regardless of any technical advantages their offerings might have at the moment.
A small shop like ours can't rely on a partner who can change major aspects of a product without any concern for its customers. And when the trouble comes, being left at the mercy of a random Googler who might come to the rescue if you are sufficiently Internet famous is not a recipee for building a stable business.
Thank you, but no thank you. I'll stick with companies who are relentlessly working on improving their products, driving prices down and care about their customers even if their products might be behind in some areas.
Until Google proves that they care and are in this for a long haul, my business goes somewhere else.
Oh, yeah, this applies to personal usage too - good bye Google Reader, my most used Google product...
GCE should be priced "correctly" since it was created after the great price rationalization.
That was for the GAE. Who is to say a new "price rationalisation" might not come for GCE?
Or that they wont close it down, like they did with Google Code, Google Wave, Google Reader and such, if they change their minds?
Now, I know that what I wrote would be considered FUD if it was for any other company. But in Google's case, it's not that people say FUD about them. It's that FUD is the very thing they emanate themselves!
Or, in other words, in Google's case, the FUD is real.
Or that they wont close it down, like they did with Google Code, Google Wave, Google Reader and such, if they change their minds?
Now, I know that what I wrote would be considered FUD if it was for any other company. But in Google's case, it's not that people say FUD about them. It's that FUD is the very thing they emanate themselves!
Or, in other words, in Google's case, the FUD is real.
Hi Ryan, have you seen the recently announced support packages for the Google Cloud offerings? It's a multi-tiered approach, from Bronze (free, online) to Silver (premium, with email support) to Gold (premium, with 24x7 phone support), all the way to Platinum (premium, with a dedicated technical account team). Announcement here:
http://googleappengine.blogspot.com/2013/02/google-cloud-pla...
Sign up here: https://cloud.google.com/support/packages
Basically, it's a way of agreeing with what I think is your point. Support does matter, and Google is taking it very seriously.
Would love to hear your thoughts once you've tried one of those support packages!
http://googleappengine.blogspot.com/2013/02/google-cloud-pla...
Sign up here: https://cloud.google.com/support/packages
Basically, it's a way of agreeing with what I think is your point. Support does matter, and Google is taking it very seriously.
Would love to hear your thoughts once you've tried one of those support packages!
It's quite funny that I'd have to pay $150/month for the privilege of email support related to "service errors".
It's completely fair to expect customers to solve their own problems, but when the problem is on Google's end, it's beyond outrageous to charge a premium to resolve those.
It's completely fair to expect customers to solve their own problems, but when the problem is on Google's end, it's beyond outrageous to charge a premium to resolve those.
I agree that it's funny, and would probably be a turn-off to most people. Consequently, I doubt Google cares if many people sign up for that. Back in the early days of GAE, I remember success stories told by some companies. Anyone established businesses building apps that will bring in serious business revenue might just jump to the Platinum Support. I know this means a lot of indie developers might not be excited about this, but perhaps Google just doesn't care since they might be making money off of the big customers...?
Funny considering the main issue we had with EC2 was amazons horrible support. Even spending a lot (lot) per month our only option was to post on the forums and wait. We ended up at Rackspace after a few years of frustrating issues.
>Funny considering the main issue we had with EC2 was amazons horrible support.
Well, support is relative. If you found Amazon's "horrible", you would find Google's utterly horrible and scary beyond any description.
Well, support is relative. If you found Amazon's "horrible", you would find Google's utterly horrible and scary beyond any description.
[deleted]
You didn't sign up for the paid support?
From my limited experience - I'm at best on the periphery of dealing with AWS support; I can characterize aws support as such -
Free tier - occasionally get answers. answers are generally vague. questions to forums. Paid tier - always get answers. answers are generally vague. you get a support portal. Top tier paid - always get answers. answers are generally vague. amazon employees will fly out to your site to give vague answers.
Free tier - occasionally get answers. answers are generally vague. questions to forums. Paid tier - always get answers. answers are generally vague. you get a support portal. Top tier paid - always get answers. answers are generally vague. amazon employees will fly out to your site to give vague answers.
So true. I ask a question on the paid support plan and I got an answer copied from a blog I already googled. After several back and forth and escalations, I keep getting the same unhelpful answers and gave up.
Welcome to 2013. To be successful you need to address an immensely huge audience. It is just not physically possible to provide everyone with the kind of customer support you got back when you bought meat from the person who had killed the pig.
We did. And we were paying enough (6 digit monthly bill, not huge but significant I would think) that we did get some nice treatment, although we were definitely not a big enough customer apparently. We adopted a lot of things right away when it came out (ie windows instances, elb). I think that was a mistake and lead to a lot of issues that resulted in responses acting like its not a problem until 6 months later when a fix came out. EC2 was a lot better then my experiences with Terremark though, but we were definitely pennies to them.
What kind of problems were you having with EC2?
(I mean, beside the 'default' ones)
(I mean, beside the 'default' ones)
What would be really nice to see would be tools to make it easy to migrate between these cloud platforms. The nice thing about making an old-school apache-served website is that you know if your host does wrong by you, you can just move. In many cases, the moving process is simply ordering service, uploading your files, and pointing your domain to the new host.
I realize that this is mainly just the difference between newer technology and decades of standardization, but until cloud providers reach that point, the prospect of bad/missing support is really frightening.
I realize that this is mainly just the difference between newer technology and decades of standardization, but until cloud providers reach that point, the prospect of bad/missing support is really frightening.
The OP does this for a living. That is why they wrote then article.
That could all be abstracted away, though, given a PaaS middleman like Heroku. You pay the PaaS piper; they worry about the headache of dealing with Google billing.
It seems like the inter-region bandwidth test would be especially likely to be negatively affected by increased adoption of GCE. They lay a fixed amount of capacity, and if there's relatively few other customers, you get a proportionately larger slice of it. Hard to prove either way, but it seems that hitching your wagon to GCE based off of these performance numbers might not pan out for the long term.
one part not accounted for is that the wide-open internet, while slower and with more latency, is going to be pretty much 100% reliable compared to their dark fiber link between regions.
So, uh, could they show what they used to get those numbers? A EC2 micro vs. the GCE big version (I'm not familiar enough with GCE).
I'll note a HUGE factor is missing: the word 'cost' isn't even in the article. How much more (or less) are you paying for the apparent increase in performance?
I'll note a HUGE factor is missing: the word 'cost' isn't even in the article. How much more (or less) are you paying for the apparent increase in performance?
It's like all those Mac reviews. Boot up time and the appearance of the default desktop is all the reviewer cares about.
If you want real useful info, go to a industry site not a pop tech chat board like HN.
If you want real useful info, go to a industry site not a pop tech chat board like HN.
If I am leaving EC2 to another cloud provider, one of the reason I can think of is Linode start offering real cloud instance..
Interesting analysis for sure, but I think the only solid takeaway here is that (unsurprisingly) Google's private backbone between regions offers a huge performance advantage over the public Internet between EC3 regions.
As the analysis stands, the individual IO stats aren't meaningful. EC2 instances offer a range of I/O throughput in different instances: a t1.micro has 'low' I/O, an m1.small has 'moderate' and an hi1.4xlarge offers 1.1 GB/s write and 2.0 GB/s write. Cost has to figure into a benchmarked analysis here.
And CPU. One of Google's big claims at launch was that CPU time was notably less expensive than on EC2. I'd love to see some data here and clicked the link expecting to find that analysis.
As the analysis stands, the individual IO stats aren't meaningful. EC2 instances offer a range of I/O throughput in different instances: a t1.micro has 'low' I/O, an m1.small has 'moderate' and an hi1.4xlarge offers 1.1 GB/s write and 2.0 GB/s write. Cost has to figure into a benchmarked analysis here.
And CPU. One of Google's big claims at launch was that CPU time was notably less expensive than on EC2. I'd love to see some data here and clicked the link expecting to find that analysis.
This benchmark provides some interesting data, but would have been far more useful if they had provided more details. There are many unanswered questions here:
How even is a comparison when GCE hardly has any customers sharing the same physical host and network at this stage? It's rather interesting that EC2 read I/O performance was higher despite this consideration.
What will happen when you start sharing a physical host on GCE with many other customers? Will you all still get 157 MB per second disk write throughput simultaneously?
What type of instances were used (and were they EC2's first generation or second generation instances?). Given the fact that they are looking at ephemeral disk performance it's probably a 1st generation instance.
I see no mention of EC2 EBS provisioned IOPs. If performance was a goal then surely having guaranteed provisioned I/O should have been considered? Does GCE even have that feature? Surely IOPS are more important than sequential I/O for most tasks?
When benchmarking EBS I/O were EBS-optimized instances selected?
Why no mention of EC2 cross region AMI copy? Also GCE is currently in the US only. EC2 is on 5 different continents currently.
What are the costs of the instances (using reserved instance pricing for EC2)?
How even is a comparison when GCE hardly has any customers sharing the same physical host and network at this stage? It's rather interesting that EC2 read I/O performance was higher despite this consideration.
What will happen when you start sharing a physical host on GCE with many other customers? Will you all still get 157 MB per second disk write throughput simultaneously?
What type of instances were used (and were they EC2's first generation or second generation instances?). Given the fact that they are looking at ephemeral disk performance it's probably a 1st generation instance.
I see no mention of EC2 EBS provisioned IOPs. If performance was a goal then surely having guaranteed provisioned I/O should have been considered? Does GCE even have that feature? Surely IOPS are more important than sequential I/O for most tasks?
When benchmarking EBS I/O were EBS-optimized instances selected?
Why no mention of EC2 cross region AMI copy? Also GCE is currently in the US only. EC2 is on 5 different continents currently.
What are the costs of the instances (using reserved instance pricing for EC2)?
> GCE is currently in the US only.
Not correct. They've had EU zones since November:
https://developers.google.com/compute/docs/faq#datacenters
https://developers.google.com/compute/docs/pricing#table
Not correct. They've had EU zones since November:
https://developers.google.com/compute/docs/faq#datacenters
https://developers.google.com/compute/docs/pricing#table
Seems the FAQ has recently been updated, a week ago there was no mention of Europe. Odd.
Of course, if you do switch and become invested in Google's technology, they'll probably just shut it down.
However, when you factor in EC2 Reserved Instances pricing, the EC2 price drops to $0.028/hour. For a small startup with a couple of instances to start with, you can run your entire EC2 setup for the price of one entry-level GCE instance.