Comment by obulpathi | Hacker News Reader

Comment by obulpathi | Hacker News Reader

Parent Full thread

Let's look at Google vs AWS from people's time:

* Ease of use: Google Wins(Cloud Shell, SSH into instance from browser). Its far easier to spin up an instance and manage it on Google Cloud than AWS with VPC mess.

* Platform Cohesivity: Google Wins (See the comparisio below)

* AWS has 2 storage solutions with different APIS: S3 and Glacier; Compare that to Google. Just one storage solution to serve all needs. You get a backed in CDN for free!

* AWS has two queuing systems (SQS and Kinesis) and still require the developer / admin to adjust the scaling of infrastructure. Google has just one Pub/Sub. You get push notifications on top. No need to tune knobs to get extra scale. It just works.

* AWS load balancers and persistent disks need warming up before high usage. If you are running a website on global scale, you need to use DNS geo load balancing on top. Google load balancers are global (as opposed AWS regional load balancers), no need of DNS tricks. No need of prewarming. Google persistent disks need no prewarming. You can mount a single persistent disk on multiple instance and share data easily.

* Security: Google encrypts data at rest and at wire by default. Try doing that on AWS. Google takes care of SSH key provisioning and management. AWS: You have to do it by yourself.

* AWS NATs and micro instance are known to be unreliable. Google has live migration. If something goes wrong with instance they work their magic behind the scenes so that you don't have to worry about migrating the instance to another physical host.

* Automation: Instance id are not global on AWS. Have fun creating maps and stuff inside CloudFormation templates. Google Cloud resources are global. All resources (images ids) have a global identifier. No more messing with zonal vs regional vs global resources.

Google Cloud can save money by saving your time too!

I don't actually have much of an opinion specifically about Google Cloud vs AWS. I will say for your argument to make sense you have to first prove that 1) these differences make for cost savings that aren't a rounding error when it comes to employee costs and 2) these differences aren't overwhelmed by the smaller ecosystem (tooling, availability of talent, etc) of aws vs google cloud.

Also as a nitpick:

>AWS has two queuing systems (SQS and Kinesis)

This is a feature, they offer different promises/behaviors. In fact, Pub/Sub does not offer one of the important ones that Kinesis does (strictly ordered delivery).

The latter use case is easily handled by Dataflow (something that AWS lacks. See https://cloud.google.com/blog/big-data/2016/02/comparing-the...).

One may also say that Google has a single Global seamlessly scalable durable message delivery service and Amazon has two that are neither global nor seamlessly scalable. Firehose is AWS itself admitting to this argument... And then there's firebase :)

I think dataflow is rad! But can you show me any bit of documentation that shows strictly ordered at least once delivery?

I don't think it actually does that.

I'm not certain, but I'm reasonably confident that strictly ordered durable, globally replicated delivery would have to make extreme latency & availability comprimises.

Dataflow is a fault-tolerant deterministic processing framework, engine, and service, not a messaging queue, so it doesn't "do that" by definition.. wrong product :)

That said, one may order and dedupe the message stream with Dataflow using message metadata, time windows, watermarks and triggers.

PubSub offers at least once delivery semantics.

And I agree with your last statement.

Sure. I think it is fair to say that AWS does not offer a "Global seamlessly scalable durable message delivery service". What doesn't seem fair to me is to complain that AWS offers too many products, or to ding Kinesis for making normal/understandable engineering trade-offs.

It turns out that while AWS doesn't offer a single "Global seamlessly scalable durable message delivery service", Google doesn't offer a single strictly ordered, at least once delivery message delivery service.

Personally, I think thats ok, as a variety of solutions is great for all of us, but its hard to say one decision is better than the other when they are solving different problems.

I agree with you, but re-reading the original commenter's argument, he was saying that with AWS services you don't get seamless scalability, even though there's SQS, Kinesis, Firehose. I don't think he was complaining about the number of products, I think he was making a point that most AWS services don't seamlessly scale the way Google Services do.

There's an interesting blog in the works by one of our customers, who "surprised" PubSub with 4.5 million messages per second, and kept on this test for about a week. One hell of a load test :)

And this is especially true when looking at the product I work on, BigQuery.

Google cloud is missing RDS though, and DBA tasks are a giant headache.

Google Cloud SQL 2.0 is pretty neat

Google Cloud has MySQL for RDS. Agree that its lacks Oracle, MSSQL and Postgres. You can use managed Postgres by Enterprise if you like. If you are startup and running Oracle in AWS / Google Cloud, that's probably not a wise choice (You don't get the benefits Oracle, which is performance in AWS / Google Cloud). A startup using MSSQL in cloud? May for a niche purpose. If you are a big company with lots of legacy apps built with Oracle / Postgres / MSSQL, AWS makes more sense in short run.

Reply on news.ycombinator.com