Hacker News Reader

Comment by jbyers | Hacker News Reader

"The numbers given in this article do not account for any AWS reservation."

While I agree that Google's pricing model is superior, the author's position on reserved instances accounts for ~40% of the cost difference.

In a drag race between instances AWS tends to lose. If you value the enormous feature and service surface-area that AWS provides it's a different story. Either way we win; both companies will engage in a brutal price and feature war for many years to come.

View on HN

> While I agree that Google's pricing model is superior, the author's position on reserved instances accounts for ~40% of the cost difference.

Author here :D

Gotta take a stance to draw graphs, right? Comparing no reserved instance with the automatic discount is simple and realistic in my experience.

I could make pricing graphs accounting for 25% of AWS reservations and 75% of automatic google discount. In my experience, that's the proportions we _may_ have in practise. It would still be the same conclusion. Google is massively cheaper.

I could make TCO pricing graphs, accounting for the thing from the last paragraph, plus the human time (500$/day) required to understand, pick and manage reservations. I didn't do all the computations but so far it points towards a negative ROI (compared to not reserving), unless the infrastructure is big enough to have the economy of scale (hundreds thousands dollar per year). (Note: I really don't want to go against all the HN/reddit crowd who drank the reservations marketing koolaid, so purposefully avoid to talk about the TCO pricing model publicly ^^).

Thus, in all scenarios, google instances are massively cheaper. YMMV.

You really should have noted you were using on-demand pricing at the beginning of the article.

No one doing over $100k per month is matching utilization perfectly with RIs. Either you are not utilizing some percent of RIs in which case you are overpaying through breakage, or else you are paying on-demand rates for the instances which are not under RI.

The calculus involved with matching RIs to forecSted demand in a dynamic growing workload is NP complete. And any inefficiency delta pays AWS. There's a small part of the curve where your savings is minimal if you don't match perfectly, it it easily goes to negative on the RI change.

Otoh, nobody spending $100k a month is paying full sticker price.

If you define sticker as published rates - I know of many companies that are paying list sticker price (published on web sites).

You have to get pretty big to get discounts from published prices, far bigger than $1M/year, more like $1M/month.

That is not my experience with AWS. You will get face time with a rep and discounts to published rates if you're spending $100k a month.

Is that only if you make large dollar commits with additional terms and requirements?

I seem to recall that there is something like a 5% discount after a few hundreds k per months.

To get a rep (that's unrelated), you have to pay full support which is about 10% per month (with a high minimum fee).

As a real life user of AWS I agree with this decision. RIs are not only a headache from a time perspective but we pay a non-trivial amount for a separate tool to manage purchasing them since AWS's built in tools aren't great.

Even with this tool we frequently make planning mistakes due to shifting business priorities or other reasons. Like - oh hay we have to upgrade our database instance but that needs a newer version because only the newer versions support something we need (i.e more than X GB ram). So engineering needs to modify the app to support the newer version.(Oh by the way AWS has a boatload of subtle restrictions like that.)

In this case we were sitting on a RI till EOY and for some reason you can't resell RDS RIs like normal ones (another subtle restriction) so we couldn't even partially recoup costs. Sometimes if you haggle with AWS Enterprise Support you can get them to help out if you're spending the money elsewhere but it's a pain. Good luck if you don't pay for that though (which itself is 15k a year or more).

What's the tool's name?

Probably CloudHealth

http://cloudcheckr.com/

https://www.cloudability.com/

And there is a 3rd competing tool that I can't seem to remember the name.

Wait, $500/day to manage RIs? As someone who manages RIs for my org, that's way overblown. At most it'd be four figures per year. And once you get big enough, you leverage tools to help you figure out what RIs to get, which more than pay for themselves.

I would like to hear what platform bits of AWS that you find lacking in Google Cloud. Google's ecosystem of fully managed services is very rich broad and compelling, and in many ways far ahead of competition. (work on Google Cloud but don't get paid to post here)

> I would like to hear what platform bits of AWS that you find lacking in Google Cloud.

RDS instances with Postgresql.

This is the one that comes up. Hit me up offline. Also, you can always use any number of partners that provide this functionality.

Let me know if there are any others.

> Also, you can always use any number of partners that provide this functionality.

Like AWS?

Yup, both leverage partners where their offerings are not present.

> Google's ecosystem of fully managed services is very rich broad and compelling, and in many ways far ahead of competition.

I see.

I'm not sure where I'm being inconsistent. Both AWS and Google have broad spectrum of fully managed services. There are places where Google lacks and AWS doesn't, and there are places where Google is superior, or where AWS lacks.

In both cases, there are partners that enrich these ecosystems.

You asked for a gap and when one was clearly identified, you went into a weird defensive sales mode. "partner" solutions are often garbage compared to a real native solution, so AWS is much better in this regard.

Sorry if I came off defense. I said that it's a valid concern in this thread, should have been more clear I suppose.

Python support needs improvement. The standard environment is limited, and the flexible environment is still in beta.

Py3k would be nice.

The 'flexible environment' supports 2.7 and 3.4, and any Python package that works on Debian Linux.

https://cloud.google.com/python/quickstarts

Yea. Even on gsutil 4.22 you gotta switch off your virtualenv before you can list your files. https://pypi.python.org/pypi/gsutil

From the top of my head, a managed Elasticsearch a-la-elastic-cloud would be very interesting. Their offering is expensive and very frustrating if you don't have a paid support contract. AWS has something similar, but lacking features (kopf, kibana, marvel, etc)

Thanks!

AWS Elasticsearch has kibana built in when you spin up your ES instances.

THis is in alpha on google

Where? They list all of their alphas here: https://cloud.google.com/sdk/gcloud/reference/alpha/

That's the list of alpha CLI commands, and is only related to an alpha service in that it won't outpace it.

Most alpha services do not yet have gcloud support.

Thanks for the feedback!

I'm PM for another Google Cloud database (not Cloud SQL), but will share this with the team.

Elasticache (redis/memcache)

Postgres

Integrated domains (a la R53)

S-N/E/Q-S

For me, the most compelling attribute of AWS is familiarity. Google Cloud has traditionally been more forward with bespoke services that need to be adopted in order to use the platform effectively.

Familiarity with one way of doing things is a reasonable point. To assist here a little our SA's put together this:

https://cloud.google.com/docs/compare/aws/

Thank you - that's helpful. However I was referring more to familiarity with systems and software used when administering one's own infrastructure.

I'm generally comparing AWS to colocation, not other IaaS offerings.

That makes sense. Please feel free to engage me here or offline - happy to introduce you to the right folks for this discussion.

Does Google have an equivalent for DynamoDB and Lambda? If so, I might consider switching.

Google has Bigtable and Datastore. Bigtable can be thought of as an events database, and Datastore is entities. Both very very compelling for DynamoDB users.

Google's Lambda equivalent is currently in Alpha. That said, there are bits like Cloud Logging and AppEngine that offer unique-to-Google functionality that's somewhat comparable.

(Work on Google Cloud)

With little research I've done, it looks like DynamoDB offers a great deal more than cloud datastore.

http://db-engines.com/en/system/Amazon+DynamoDB%3BGoogle+Clo...

Both technologies are clearly very compelling to users.

This is a bit outside of my expertise, but that page mainly points out that DynamoDB supports 3 more language-specific SDKs, while lacking ACID and what appears to be native cross-region replication (through Lambda). Until recently, Datastore was coupled with AppEngine that might explain it.

Would love to hear more thoughts from you.

(work at Google Cloud)

Datastore and BigTable looks pretty interesting, and I am having a hard time figuring out when to use which (apart from Datastore's ACID support) as both seem a good enough fit for most workloads.

Is Datastore Spanner?

I don't think there's an equivalent to Bigtable anywhere. It's so badass it's not even funny - take a look at [0] - a small team of engineers took O(weeks) to build a system that clocks 56 million qps (and these aren't simple bits - 56 million FIX protocol trades and orders).

You can think of Hbase as a clone of Bigtable, if that helps. Bigtable is actually exposed through the Hbase API. /u/mbrukman here is the PM for Bigtable.

[0] https://cloudplatform.googleblog.com/2016/03/financial-servi...

Last I checked the pricing was very different; nodes for BigTable, reads/writes for Datastore. BigTable is more cost effective for large workloads, but it requires buying a minimum of three nodes, which is ~$1,500/mo total. If you're small potatoes it seems infeasible. Happy to be corrected if I misread.

You're correct in that Datastore does provide more general transactions (Bigtable only provides single-row transactions); Datastore also provides indexing and search (Bigtable, like HBase, has a single index: the row key), and Datastore is synchronously replicated cross-zone and cross-region.

Datastore and Bigtable have different characteristics and use cases; see https://cloud.google.com/storage-options/ for an overview.

Datastore is a document database (compare it to MongoDB), while Bigtable is a wide-column store (compare it to HBase or Cassandra).

> Is Datastore Spanner?

Datastore is built on Megastore, which builds on Bigtable. :-)

I am the PM for Google Cloud Bigtable.

DynamoDB and Datastore are mostly equivalent in terms of utility and pricing. GCloud also has Big Table if you're dealing with really large data sets/qps.

Lambda and Cloud Functions are competitors, though there are some things you could do with Lambda + API Gateway that you can't quite do with Cloud Functions just yet (pretty narrow scope, though). I prefer the environment for Cloud Functions, subjectively.

"is very rich broad and compelling"

But does it support commas?

lol!

PAAS offerings for queue (SQS), notifications (SNS), email(SES) etc

Thanks - GCP doesn't match 1:1 on any of those. However, there are alternative (and for many use cases much better) ways on Google.

There's PubSub, Cloud Logging, Firebase (including Firebase Messaging), and all 3 don't really have a great direct AWS equivalent.

Take a look at the AWS/GCP equivalents at [1]. Mostly full coverage, although, again, some services work differently (usually better I hope!).

Email is indeed handled through either SendGrid or Google Apps [0]. Spam reasons I believe.

[0] https://cloud.google.com/compute/docs/tutorials/sending-mail...

[1] https://cloud.google.com/docs/compare/aws/

I have no idea how much a dataflow will cost to run. It tells me it's running on x vCPUs, but what will the bill actually be?

I am a Google Cloud PM, but not on Dataflow specifically.

Do you know how long the Dataflow processing will take? You may be able to estimate the length of the full-size process (assuming it's batch rather than streaming) by running on a small data sample to see how many vCPU hours it takes and estimate from there, assuming your data takes a uniform amount of time to process.

Since Dataflow is running code that you wrote, it doesn't know how complex your processing will be for any given value, so it's hard to give any reasonable estimate. In general, automatically predicting how long an arbitrary piece of code will take to run on a given input is even harder than the Halting problem (https://en.wikipedia.org/wiki/Halting_problem), which is already undecidable.

Details on Dataflow pricing: https://cloud.google.com/dataflow/pricing

Pricing calculator to estimate cost for Dataflow and other products: https://cloud.google.com/products/calculator/

Hope this helps!

Great comments!

Another way to look at Dataflow pricing as it related to this type of technology. Let's just assume for a second Dataflow and other similar technologies execute your pipeline on your data within the same resource-time amount.

Dataflow lets you set an upper bound on these resources, and lets you auto-scale, with essentially per-minute granularity. Alternatively, you can create a cluster of fixed resource amount. Cost of Dataflow is $0.01 per hour per CPU, in addition to those resources.

Dataflow's model hence either guarantees 100% resource efficiency, or you specifically opt into the upper bound of spend. A deployment model that lets you "spin up a cluster and pay for it" is intrinsically less efficient.

I wrote a blog on this WRT BigQuery, but Dataflow is right there [0].

[0] https://cloud.google.com/blog/big-data/2016/02/understanding...

(Work on Google Cloud)

Thanks. I know it's tricky due to scaling, etc, but I guess in the same way dataflow works out when data should arrive by (this is a streaming task btw), an estimate of the daily cost could be calculated and would be useful.

For me, the beta tag on things like App Engine Flexible instances is the biggest concern. We've had "fun" with Microsoft Azure services being less than fully baked, or Microsoft totally replacing services with different ones. In contrast, AWS has been very stable in this regard.

Yeah that's reasonable. At Google Cloud "Beta" means very far down the line of maturity. But YMMV and buyer beware when using "Beta" for production at any provider.

Try using https://www.cloudorado.com/ . It will calculate price for specific configuration for AWS, GCE, Azure and more. And you can choose if you want long-term commitment or not.

A nice attempt, but the comparison seems way off for anything beyond the lowest setting on the CPU slider. Choosing "1x" compares an EC2 c4.large instance type to others with a single vCPU (like a $6 DreamHost instance).

"large" is the smallest instance with fixed CPU allocation that AWS is providing these days.

Reply on news.ycombinator.com