Live data from Hacker News

Why I distrust Google Cloud more than than AWS or Azure

iasylum.net

231–240 of 251 posts

Re: Why I distrust Google Cloud more than than AWS or Azure

#231
> Most business can't rationally avoid picking a cloud provider option - and that often means choosing between AWS, Azure or Google Cloud.

It looks like this lie has been repeated long enough it became a reality for some people. Yes, you can perfectly avoid using a "cloud provider", as millions of businesses worldwide already do, from small companies to largest tech businesses (for drastically different reasons though).

Re: Why I distrust Google Cloud more than than AWS or Azure

#232

[DISCLAMER: I used to work at Google in general, but not at Google Cloud] I'm not sure whether this has been discussed here before, but I'd love to take this forum to share an angle from the tech side of things: IMO, Google is _cursed_ to keep deprecating its products and services. It's cursed by Google's famous choice of mono-repo tech stack. It makes all the sense and has all the benefits. But at a cost: we had to…

> Yeah, the "Fuck You. Drop whatever you are doing because it’s not important. What is important is OUR time. It’s costing us time and money to support our shit, and we’re tired of it, so we’re not going to support it anymore." is kind of true story for internal engineers.

Oh man that explains everything, I can totally relate to that.

Re: Why I distrust Google Cloud more than than AWS or Azure

#234

Earlier quoted context omitted.

> so that the infrastructure/security group should be able to provision devs with the ability to roll their own IAM in a scoped way to prevent issues. This requires money and time that often only large corporations have the luxury of.

In my experience trying to configure AAD policies, AWS IAM and (to a very limited extent GCP IAM), it does not generally require a large investment in time. It does require a development account in which the developer has full access to IAM/AAD. At my employer, we have a gatekeeper team who is terribly overworked and hardpressed to push back too much when business outcomes are at stake. One of the more successful thi…

Also, permissions boundaries are specifically made for the use case of "IAM teams delegating some control to devs".

IAM team creates a "developer admin" role/user that can only create users/roles that have a permissions boundary on it. That way, no matter what policy the dev admin grants, the dev user can only do what the permission boundary allows.

Re: Why I distrust Google Cloud more than than AWS or Azure

#235
post #143

I've been in GCP support for over 4 years. My opinions are my own. I try to stay as impartial as I can about my employer. I know there are a lot of valid criticisms to be made about GCP. As one of the people often bearing the brunt of the fallout whenever there is a painful outage or deprecation, I share some of them. But it never gets easy to read posts like this. This one appears to be a collection of old hacker ne…

Hey, thanks for all that you’ve done. My experience with GCP has been an incredibly positive one. GCP documentation has always seemed fantastic. Our TAMs were very responsive. GCP support has by far been the best support experience. I have to say that the initial days it seemed to suck. The UI was some 90s google group clone which wasn’t even accessible through the GCP console, it was its own separate site which I al…

Can we get some details about this exchange? I've never heard of this type of firewall discussion.

Re: Why I distrust Google Cloud more than than AWS or Azure

#236

[DISCLAMER: I used to work at Google in general, but not at Google Cloud] I'm not sure whether this has been discussed here before, but I'd love to take this forum to share an angle from the tech side of things: IMO, Google is _cursed_ to keep deprecating its products and services. It's cursed by Google's famous choice of mono-repo tech stack. It makes all the sense and has all the benefits. But at a cost: we had to…

piper supports branching (just like perforce) but it's not commonly done (some teams used it) because it's worse than qualifying at head.

Re: Why I distrust Google Cloud more than than AWS or Azure

#237

I've been in GCP support for over 4 years. My opinions are my own. I try to stay as impartial as I can about my employer. I know there are a lot of valid criticisms to be made about GCP. As one of the people often bearing the brunt of the fallout whenever there is a painful outage or deprecation, I share some of them. But it never gets easy to read posts like this. This one appears to be a collection of old hacker ne…

Idk sample size of 1, I’ve seen Cloud SQL almost bring a startup to death with issues. We wanted to move to AWS but migrating the data was too cost/time/risk prohibitive. The support engineer was helpful but ultimately the issues faced were not prioritized because we weren’t Google. Being not too specific for privacy.

Re: Why I distrust Google Cloud more than than AWS or Azure

#238

[DISCLAMER: I used to work at Google in general, but not at Google Cloud] I'm not sure whether this has been discussed here before, but I'd love to take this forum to share an angle from the tech side of things: IMO, Google is _cursed_ to keep deprecating its products and services. It's cursed by Google's famous choice of mono-repo tech stack. It makes all the sense and has all the benefits. But at a cost: we had to…

the monorepo makes everything worse but it’s only part of the problem, i believe.

the big problem is forcing everyone to keep everything “updated”.

What is really needed is a way, given a certain state (branch, etc) to find a way to reliably reproduce the build artifacts AND to have a way for your software to depend on these packages at specific versions.

This way you can make an informed decision about when or if yo upgrade something and you know for a fact that (setting security issues aside) you will not have to touch the code and you can keep running it forever.

Look at virtually any modern programming language. The way the packages work makes of breaks the language. I never understood why Google seems to believe they are special and basic stuff does not apply to them, but it does.

Also, IMHO huge difference between how thing are run and work inside Google and how things work “in the wild”.

Re: Why I distrust Google Cloud more than than AWS or Azure

#239
post #203

Earlier quoted context omitted.

This crowd also harshly criticized the Coinbase founder / Bitcoin when we he was looking for a co-founder, and now his share of Coinbase is worth $10 billion or so.

We also harshly criticized 642 other "I just need a programmer"-posts here that month, and all of those companies are bankrupt and long forgotten

But the Coinbase founder was a technical one.

Re: Why I distrust Google Cloud more than than AWS or Azure

#240
The only advantage of Google Cloud is the TPUs--if you're not running massive machine learning workloads, AWS is almost always the better choice on features, service, and reliability.

The *link between compute and storage* is not even officially a production product:

"Please treat gcsfuse as beta-quality software. Use it for whatever you like, but be aware that bugs may lurk, and that we reserve the right to make small backwards-incompatible changes." https://github.com/GoogleCloudPlatform/gcsfuse/

If a supposed cloud platform can't even produce a reliable way to access your data, then they have no basis being used in any halfway serious setting.

Post reply on HN