Ask HN: How is Google Compute doing with respect to AWS? | Hacker News Reader

Ask HN: How is Google Compute doing with respect to AWS?

16 pointssalilpa10 comments

We are planning to shift our server from linode to some other service. Now the dilemma is around AWS or GCE. We would love to know are there any tech guys who have had migration from AWS to GCE or from linode to any of these service and how was their experience.

View on HN

GCE is better than AWS in terms of cost and performance. But, lags in community support/3rd party tools. Read Janakiram's Gigaom research articles. Here is his answer on quora - http://www.quora.com/What-are-the-advantages-of-Google-Compu...

Where does it say that GCE is more cost effective on that page?

Plus some of his Google perks are pretty niche (e.g. 10 TB disks, "migrations from something AWS no longer does is hard") and his sources actually are really terrible.

Most of his sources are fake, they're back to himself via "gigaom." Who then don't go on to cite or further clarify. The graphs link to a page which have a retraction at the top (by the same guy) who says they need to "update" them to be more "accurate" (whatever that means).

edit: The person above also appears to be linked to this "gigaom" place. So I'd take that with a massive pile of salt. Seems like it isn't a reliable source.

Janakiram was with Amazon as AWS evangelist (and Microsoft as Azure evangelist) before writing for Gigaom. Calling someone you barely know as fake is very rude. I suggest you focus on merits/demerits of the products.

Cost advantage is based on my personal experience with my current product Guesswork that runs on Google cloud and my previous product Kissflow that ran on both Google cloud and AWS.

I didn't say someone was fake, I said the source(s) were/are fake.

You cannot call something a "source" then link back to yourself, that isn't a source, that's just repeating. In this case the way they're citing sources is quite misleading, in particular as the articles they quote as sources don't themselves have sources.

So ultimately it isn't sourced material, it is just one person's quantitative and qualitative material.

I also find it a little suspect that you link to quora which is just a reference to Gigaom which you yourself likely have links to but fail to mention that as if you're some impartial party pointing at a useful piece of material. There's nothing wrong with referencing your own blog or site, but it is nice to let people know you're doing so rather than sending people through a quora answer as if you just randomly ran across it on Google.

The whole thing smells funny...

Ok. Is my credibility at stake now? :) You should read his article on AWS Lambda, in case you think he is one sided - http://research.gigaom.com/2015/01/why-aws-lambda-is-a-maste...

GCE definitely has good tooling. The biggest complaint I have with their tooling, however, is the stupid business about authorizing your workstation/gcloud client with your Google account. The tool sets up a local web server and tells the Google OAuth stuff to redirect you back to that local webserver address.

So, you literally have to do the Google OAuth process, but on the machine you're running the gcloud tool from. In my case, that was a server out on the internet. I had to open the link in lynx, for god sakes. I probably could have port forwarded it, but still, what a pain in the ass. They need to do better. For better or for worse, just having keys (AWS) is way more straightforward: put these keys in this file, then you can use XYZ tool, etc etc.

Besides that, their actually performance/price ratio is on point. They've simplified the whole elastic storage bit with persistent disks, but you're still going to pay for a bunch of IOPS, if you need them. We run a 10TB disk on a master database because IOPS only scale with volume size, yet we use a few hundred GBs at most. We haven't explored CloudSQL or any of their object storage. We strictly use them for compute, and run all of our own class of machine.

Their firewall / addressing stuff is very simplistic compared to VPC and security groups. Even bigger than that, and not a showstopper, is that they have no split-horizon DNS like AWS does. So when you see those ec2-xx-xx-xx-xx.compute-1.amazonaws.com addresses, those will resolve to the private IP of the host if you query them inside EC2. Likewise, they resolve to the public IP when queries from the outside. So, if you have a vanity domain you use to do overlay DNS - machine2.prod.mycompany.io, or something - it's trivial with AWS. You just point it at the public DNS record given to the machine, and it works anywhere. Not possible in GCE without doing it yourself, and when you add up split-horizon DNS with VPCs and security groups, and did I mention private DNS in Route53?.. it makes for a really simple way to lay out DNS and get all your security on point. It's not a huge problem, but when we got to GCE, it was frustrating to not be able to snap together that stuff as easily as in AWS.

Beyond that, their outages / maintenance windows have been historically meh but are getting better. There's been more than a few hiccups of the "we pushed a router change accidentally, and now 33% of storage traffic is broken" variety. Zone stability used to be an issue, too. Oh, we're going to deprecate this zone entirely, so you need to move all of your shit. Wat? It used to be two US zones, so one of them going under for "maintenance" meant you now had to situate your workload in a single zone, unless you wanted to deal with transatlantic/transpacific latency and all the fun of that stuff. It was bumpy, that's the most succinct way I can put it.

Their support is good / can be very helpful, but it's not super cheap. I don't think AWS is particularly cheap either for that sort of "gold" support, though. (I don't know specific numbers off the top of my head.) We've had their PD team (PD is their EBS equivalent, Persistent Disk) talk to us looking for information on our workload, why we were doing the things we were doing with our resources, so they clearly are looking to better their service based on customer needs... I just don't think they've found their rhythm, internally, to straddle customer needs and the overall stability of the platform. They haven't nailed the basics.

+1 for OAuth process.

Google cloud has mature abstract services (evolved from PaaS), while AWS has mature low level services (evolved from IaaS). So, you might experience better stability with Google cloud, if you use abstract services like BigTable/Cloud SQL instead of persistent disk and use GCE for compute alone.

Thanks for the feedback..

Note that you can use the --no-launch-browser option to give you a easy cut-and paste option for headless servers. https://cloud.google.com/sdk/gcloud/reference/auth/login

Also, you can use service accounts rather than personal accounts with gcloud...

https://cloud.google.com/sdk/gcloud/reference/auth/activate-...

The Google Cloud Platform also has keys. If you go into the Developer's Console and create a service account [1] you can tell gcloud about that file [2] and it will use it instead of doing the web flow.

And, as bradabrams notes below, the --no-launch-browser option works if you want user credentials on a headless machine.

(I wrote the 'gcloud auth' commands, so if you have a suggestion for how to make this clear, reply and it will go to the right person).

[1] https://cloud.google.com/storage/docs/authentication#service...

[2] https://cloud.google.com/sdk/gcloud/reference/auth/activate-...

Thanks for the heads-up. Admittedly, I was a little frustrated at the whole thing and didn't take the time to do a deep dive on the docs for a simpler approach. I'm not sure if there's a better way to try and detect what's going on to proactively give the user a notice. Your comments seem like they'll make this a non-issue on boxes I haven't authenticated on yet, though, so that's good.

Reply on news.ycombinator.com