Earlier quoted context omitted.
Like, I don't want to fanboy, but it's _hard_ to find a use case that postgres can't handle at small to medium (i.e. 90% of projects) scale.
It's hard to find a use case that a plain old filesystem can't handle at small to medium scale. But there are perhaps more important considerations than just "can it handle it"
Google Cloud Spanner is now half the cost of Amazon DynamoDB
291–300 of 371 posts
Re: Google Cloud Spanner is now half the cost of Amazon DynamoDB
#292Just moved our infra from GCP to AWS. Kubernetes clusters, LB, storage, lambdas, KMS and all of it. Google runs their tech stack as if it's a startup that builds their CV. Everything is immature, tons of hacks, undocumented features. If you are on their k8s there are tons of upcoming new versions and features that force you to revisit key hacks you put in your infra because of their misgivings. Our infra team keeps t…
> AWS support is so nice, you can't believe it. It's actually sort of ridiculous. AWS has the best support I have ever interacted with. I mean, our org certainly pays enough for it but it's so completely unusual in tech, or really any sector to get great support even when you're paying for it.
Every time, I am also proven wrong as someone competent on their side both actually understands my issue and finds a resolution.
Re: Google Cloud Spanner is now half the cost of Amazon DynamoDB
#293Earlier quoted context omitted.
Interesting, if you swap GCP and AWS in your post then thats exactly my experience. I wonder what makes us different, I work in europe on video games; AWS’s handling of me when I was at Ubisoft left a really sour taste - when I moved into Tencent/Sharkmob I tried really hard to love AWS as it was the defacto industry standard and instead I was left with a feeling that most of it is inconsistent garbage papered over w…
> I was left with a feeling that most of it is inconsistent garbage papered over with lambda functions This sounds more like an indictment of the system design than the cloud provider. What are some of these “3am” topics that made GCP a better choice?
1) having the project/account your in visible at the top at all times.
We used SSO for “accounts” which is AWS’s way of completely separating resources; the long string that is returned is not unique in the start and the remainder is cut off: so all accounts/projects looked the same, was impossible to tell at a glance if you were in dev, staging or prod.
2) Autoscaling groups with that had human readable incrementing “names”, in AWS instances have hex slugs as instance names and you can give an instance a special “Name” label: but any new machines created with an ASG will just reuse the same name label making them hard or impossible to tell apart.
The AWS official solution for this is to have a lambda function hook on the scale event and give your new node an incremented name label. Given that AWS is pricy to save me time: I do not personally consider this an elegant solution.
3) having all regions on one page.
We spent €6,000~ on a database we didn't know about until we started digging into the bill. Not knowing what resources are available at a glance feels pretty basic to me tbh.
4) the network implementation overall; in Google you can just make a network and it will work without having to mess with zone routing and configuration of that which is put on the user.
If it’s on the user, it’s a variable that has to be checked during an outage; it is terraform code that has to be grokked and so-on.
Re: Google Cloud Spanner is now half the cost of Amazon DynamoDB
#294Earlier quoted context omitted.
We have an old "quiet part out loud" corporate story. It's about how one arm of Google using our service and wondering why it had so much downtime, only for us to point at their GAE arm and say "when they're down, we're down". They went and talked to GAE and - funny enough - were able to correlate the downtime they observed with GAE downtime. GAE uptime improved, for a little while. Yeah, we're on AWS now too.
Does Google run on GCP?
Re: Google Cloud Spanner is now half the cost of Amazon DynamoDB
#295Earlier quoted context omitted.
In the timestamped video link shared downthread, the speaker does seem to strongly imply that gWorkspace doesn’t manage the infra, when he finishes explaining the migration he declares (around 55:18)“[…]we can focus on the business of gmail and spanner can choose to improve and deliver performance gains automagically[sic]” which would imply, to me at least, that it’s on GCP.
That's not what it implied to me. To me, it meant that they adopted an internal managed Spanner with its own SRE team, instead of running their own Spanner. In the past, Gmail ran their own [[redacted]]s and [[redacted]] even though there were company-wide managed services for those things.
Source: I was on the last team running our own [[redacted]].
Re: Google Cloud Spanner is now half the cost of Amazon DynamoDB
#296Earlier quoted context omitted.
It's way WAY more than just Infra Spanner vs Cloud Spanner. Cloud spanner doesn't support protobuf, which is annoying, but that's not a dealbreaker; it's still just a DB. The issue is really all the various internal frameworks (such as Apps Framework for Java), deployment systems (Server Platform, AKA Boq/Pod/Urfin), and so forth.
Of course, I was simplifying. It's always more complicated doing a migration. :)
My old team was building a system that was half-GCP and half-Borg, and we had to write our own (extremely bad) Cloud Spanner fake for use in tests. In contrast, Infra Spanner is extremely well supported for tests. Same with BigQuery vs Dremel and many other systems.
Re: Google Cloud Spanner is now half the cost of Amazon DynamoDB
#297Earlier quoted context omitted.
No need to guess when you can measure. I am running https://cloud-canary.com a service where I monitor AWS primary services for latency and availability. It comes with a lot of data. For instance this is the latency I see doing operations against Dynamo. https://cloudcanary.grafana.net/public-dashboards/c53e2092d6...
What a cool lil side project/company! Going to circulate this among friends... Little bit of well meaning advice: This needs copy editing -- inconsistent use of periods, typos, grammar. Little crap that doesn't matter in the big picture, but will block some from opening their wallets. :) ("OpenTeletry", "performances", etc.) All in all this is quite cool, and I hope you get some customers and gather more data! (a 4k…
Any feedback is appreciated!
I pick 4k as a no-op against S3, something that very little time but still does some work.
I will definitely consider to increase it!
Re: Google Cloud Spanner is now half the cost of Amazon DynamoDB
#298Earlier quoted context omitted.
Frankly it's a bit weird to see this kind of dick measuring in a product blog post from the "Director of Engineering" :/
s/the "Director of Engineering"/a "Director of Engineering"/ There are many engineering directors at Google.
swish
Re: Google Cloud Spanner is now half the cost of Amazon DynamoDB
#299And for many projects, Postgres is still cheaper than both. Having used both, I would much, much rather do the work to fit my project in Postgres/CockroachDB than use either Spanner or DynamoDB, which have WAY more footguns. Not to mention sudden cost spikes, vendor lock in, and god knows what else. AWS and GCP (and Azure, and Oracle cloud, and bare Kubernetes via an operator, and...) support Postgres really well. Ju…
Is there any company that hosts Postgres in the cloud (and does nothing else) and has great customer service?
Re: Google Cloud Spanner is now half the cost of Amazon DynamoDB
#300And for many projects, Postgres is still cheaper than both. Having used both, I would much, much rather do the work to fit my project in Postgres/CockroachDB than use either Spanner or DynamoDB, which have WAY more footguns. Not to mention sudden cost spikes, vendor lock in, and god knows what else. AWS and GCP (and Azure, and Oracle cloud, and bare Kubernetes via an operator, and...) support Postgres really well. Ju…
Except for projects for which NoSQL is a better fit than a RDBMS, no? If I'm writing a chat app with millions of messages and very little in the way of "relationships", should I use Postgres or some flavor of NoSQL? Honest question.
My advise to you is to use Postgresql or, heck, don't over think it, sqlite if it helps you get a MVP done sooner. Do NOT prematurely optimize your architecture. Whatever choice results in you spending less time thinking about this now is the right choice.
In the unlikely event you someday have to deal with billions of messages and scaling problems, a great problem to have, there are people like me who are eager to help in exchange for money.
Lots of people like to throw around the term "big data" just like lots of people incorrectly think that just because google or amazon need XYZ solution that they too need XYZ solution. Lots of people are wrong.
If there exists a motherboard that money can buy, where your entire dataset fits in RAM, it's not "big data".