Live data from Hacker News

Google Cloud Spanner is now half the cost of Amazon DynamoDB

cloud.google.com

71–80 of 371 posts

Re: Google Cloud Spanner is now half the cost of Amazon DynamoDB

#71
“ According to the Amazon Prime Day blog post, DynamoDB processes 126 million queries per second at peak. Spanner on the other hand processes 3 billion queries per second at peak, which is more than 20x higher, and has more than 12 exabytes of data under management.”

This comparison seems to be not exactly fair? Amazon’s 126 million queries per second was purely for Amazon-related services serving Prime Day generating this on DynamoDB, and not all of AWS is my read.

What would have perhaps been a more fair comparison is to share the peak load that Google services running Cloud Spanner, and not the sum of all Spanner services across all of GCP and all of Google (Spanner on non-GCP infra).

I will say that it would show a massive of confidence to say that Photos, Gmail and Ads heavily rely on GCP infra: which would be brand new information for me! It would add to confidence to learn more on how they use it, and if Cloud Spanner is on the critical path for those services.

What is confusing, however, is how in this article "Cloud Spanner" is consistently used... except for when talking about Gmail, Ads and Photos, where it's stated that "Spanner" is used by these products, not "Cloud Spanner!". Like if they were not using the Cloud Spanner infra, but their own. It would help to know what is the case, and what the load of Cloud Spanner is: and not Spanner running on internal Google infra that is not GCP.

At Amazon, practically every service is built on top of AWS - a proper vote of confidence! - and my impression was that GCP had historically been far less utilised by Google for their own services. Even in this post, I'm still confused and unable to tell if those Google products listed use Cloud Spanner or their own infra running Spanner.

Re: Google Cloud Spanner is now half the cost of Amazon DynamoDB

#72

Earlier quoted context omitted.

yeah but you run into other issues when you put all of your lambdas on the same VPC

Not to be that guy, but why lambdas? I'm genuinely curious. I've never found the "cost savings" (big air quotes) worth it in comparison to the increased configuration/permissions complexity. Especially when Fargate exists, where you can just throw a docker container at AWS, what do Lambdas add? The zero scaling?

With CDK, I can get an ECS service up and running in the same amount of time it'd take to create a lambda function behind API gateway or triggered by SQS/cron. Deploys are easier, cost savings are real, permissions/configuration are the same level of complexity unless you're cutting corners. I'd only use ECS for stuff I know would be high sustained throughput, long duration(>15m) tasks, or things that absolutely need more persistence between executions.

Re: Google Cloud Spanner is now half the cost of Amazon DynamoDB

#73
post #34

A problem for me building on this is that Google Cloud has no coherent strategy. So the price could easily be double or quadruple Amazon in 2 years. Google Maps is the key lesson here. 10 to 20 times price increase, just because someone had a meeting. No justification or coherent strategy, just "sorry here's a shiv to the gut". At least with Amazon, as chaotic as it is, you know that they just mark stuff up to the ma…

It's surprising how Google have shot themselves in the foot with their short term thinking. Nobody trust them for anything that involves long term support on any new services/products(and several already existing products).

Re: Google Cloud Spanner is now half the cost of Amazon DynamoDB

#74

If only someone could actually run and publish comparison benchmarks, but DeWitt clause by Spanner makes it impossible.

Capitalism at work yet again. Which requires informed consumers. Obvious response is to keep users in the dark.

Re: Google Cloud Spanner is now half the cost of Amazon DynamoDB

#75
post #44
post #23

Earlier quoted context omitted.

Curious: have they ever increased prices of existing Google Cloud services? As far as I know, AWS only ever decreases prices on services for example

"Coders howl over Google's App Engine price hike (natch)" https://www.theregister.com/2011/09/02/google_app_engine_use... I don't know if Google App Engine falls under Google Cloud services, but either way that's just a technicality; the sentiment remains the same. Edit: more information here: https://github.com/stickfigure/blog/wiki/The-Unofficial-Goog...

TWELVE YEARS AGO! find a new complaint.

Re: Google Cloud Spanner is now half the cost of Amazon DynamoDB

#76

But twice as complex to use, though. That GCP interface is cancer. You need a Google-to-English dictionary to understand it.

AWS is really no better. Both consoles are a mess in their own ways. CLIs are really what matters, though. In general, I have found the GCP command line (“gcloud”) easier to work with.

Re: Google Cloud Spanner is now half the cost of Amazon DynamoDB

#77
post #31

This thread is already a damning indictment of google cloud. Price cuts alone won't attract customers -- google has sustained significant reputational damage with their crappy customer service and support. That's hard to fix

I've been doing Android development since 1.0, many Android developers are unhappy with the abusive "relationship" they have with Google, because of their control over the Play Store, your developer account, and resolving things if they come up. I'd pick any non-Google tech if there was an alternative.

Re: Google Cloud Spanner is now half the cost of Amazon DynamoDB

#78
post #5

Without an on-demand version of spanner that doesn't charge per node but per operation makes it not comparable to dynamodb for many use cases.

Exactly: I have to provision for peak throughput on Spanner. Average throughput is much lower than the peak throughput, so I'm doubtful of seeing savings no Spanner. (But I bet that Spanner is much easier than DynamoDB to develop with...)

You can scale Spanner up/down based on demand although there is a lag time with it.

I built a system that relies on a high-performance database and tested with both AWS DynamoDB and Google Cloud Spanner (see disclaimer) and was able to scale Google Cloud Spanner much higher than AWS DynamoDB.

DynamoDB is limited to 1000 WRUs per node, and there isn't an obvious way to get more than 100 nodes per table, so you're limited to 100,000 WRUs per table (= 102400000 bytes/sec = 97 MiB/sec = 776 Mib/sec) -- even if you reserve more than 100,000 WRUs in capacity for the table. The obvious workaround would be to shard the data across multiple tables, but that would have made the software more difficult to use.

Google Cloud Spanner was able to do much more than 97 MiB/sec in traffic (though the exact amount isn't yet public), and also was capable of much larger transactions (100 MiB versus DynamoDB's 25 (now it is 100) items * 400KiB of ~10 MiB) which was a bonus.

Disclaimer: The work was funded by a former Google CEO and I worked with the Google Spanner team on setting it up, while I am a former AWS employee I didn't work with AWS on the DynamoDB part of it, though I did normal quota adjustments.

Re: Google Cloud Spanner is now half the cost of Amazon DynamoDB

#79

“ According to the Amazon Prime Day blog post, DynamoDB processes 126 million queries per second at peak. Spanner on the other hand processes 3 billion queries per second at peak, which is more than 20x higher, and has more than 12 exabytes of data under management.” This comparison seems to be not exactly fair? Amazon’s 126 million queries per second was purely for Amazon-related services serving Prime Day generatin…

We shared some details about Gmail's migration to Spanner in this year's developer keynote at Google Cloud Next [0] - to my knowledge, the first time that story has been publicly talked about.

[0] https://www.youtube.com/watch?v=268jdNwH6AM

Re: Google Cloud Spanner is now half the cost of Amazon DynamoDB

#80
post #8

Earlier quoted context omitted.

This definitely happened with Google Maps, where Google was clearly the dominant player. Has it happened to other services? It seems far less likely to happen for business cloud services where they are a distance 2nd (3rd?) to AWS. I know of some examples (admittedly ancient) where they have reduced costs: https://cloudplatform.googleblog.com/2015/05/Pay-Less-Comput...

Before they offered Google cloud, they offered Google App Engine. After they introduced Google Cloud they got bored of App Engine and 10x’d the price. This was particularly painful because App Engine was a batteries-included solution with heavy vendor lock-in.

> After they introduced Google Cloud they got bored of App Engine and 10x’d the price.

I don't know about "got bored of"; I'd say more "effectively deprecated, using increasing costs† as an implicit push toward rewriting your service for more modern parts of their platform."

Specifically, Google want you to rewrite your GAE apps for Cloud Run (https://cloud.google.com/appengine/migration-center/run/comp...):

> Cloud Run is the latest evolution of Google Cloud Serverless, building on the experience of running App Engine for more than a decade. Cloud Run runs on much of the same infrastructure as App Engine standard environment, so there are many similarities between these two platforms.

> Cloud Run is designed to improve upon the App Engine experience, incorporating many of the best features of both App Engine standard environment and App Engine flexible environment. Cloud Run services can handle the same workloads as App Engine services, but Cloud Run offers customers much more flexibility in implementing these services. This flexibility, along with improved integrations with both Google Cloud and third-party services, also enables Cloud Run to handle workloads that cannot run on App Engine.

Anyone who's still on GAE (rather than having moved over to Cloud Run) at this point is a "legacy enterprise customer"; and so Google have at this point moved GAE pricing beyond just a monetary disincentive to use, to being "fired-customer pricing" — i.e. the price you charge when you don't really want to work with a customer any more, a price that says "go away", but if they still want to pay you even at that price-point, then sure, why not?

Post reply on HN