Live data from Hacker News

Why I distrust Google Cloud more than than AWS or Azure

iasylum.net

121–130 of 251 posts

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

#121

[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…

How does multi-repo codebase solve that problem? You would still need to keep up with your infra at minimum unless you run everything yourself too. Now you have another problem...

Imo mono repo has little to do with it and it’s more just an eng culture of shipping above all else (heavily influenced by their promo process)

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

#122

[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…

Why isn't the failing tests the problem of the person who changed that line? What you describe is very strange. If someone changes a shared module, and some tests fail in result, his changes simply should not be merged. > you will get a ticket to understand what has changed, make changes and fire up every tests Do you fire tests manually?

If you make changes to a large shared module, is it your responsibility to chase down each and every usage of it? For example if you are upgrading a dependency due to a somewhat breaking security issue such as Jackson 2.8->2.12

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

#123

Earlier quoted context omitted.

I used to think the problem with AWS was pricing and hidden costs etc. But in reality it’s because companies just let developers run wild without restriction on AWS and end up over provisioning or pulling in expensive services to solve dead simple problems. The issue is definitely not AWS. It’s always the developers. You really need a gate keeper to AWS to question why you need a service and ask for a price estimate…

Funny, since AWS has much more granular control over IAM roles and users than GCP does, 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.

> 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.

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

#124
post #107

Earlier quoted context omitted.

I'm shocked that any cloud provider lets you use prepaid cards... all of the major providers have problems with crypto mining and abuse, so it's crazy that AWS would allow prepaid cards that might be laundered, etc. And IMO, if you're a real customer, all the providers are fairly forgiving, provided you can get in touch with a real human who works there.

Google is infamous for making it impossible to reach a real human. Their DNA is all about automating all the things.

While I agree with the automation piece, guessing first.last@google.com is going to get someone a large % of the time. You can reach an engineer or a PM with about 10 minutes of stalking LinkedIn.

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

#125

Earlier quoted context omitted.

Why isn't the failing tests the problem of the person who changed that line? What you describe is very strange. If someone changes a shared module, and some tests fail in result, his changes simply should not be merged. > you will get a ticket to understand what has changed, make changes and fire up every tests Do you fire tests manually?

If you make changes to a large shared module, is it your responsibility to chase down each and every usage of it? For example if you are upgrading a dependency due to a somewhat breaking security issue such as Jackson 2.8->2.12

You do not chase down, the buld system detects all affected modules and runs their tests. That's the advantage of monorepo - contineous integration that includes all dependent modules.

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

#126

Earlier quoted context omitted.

That's because Google's quota increases are binary: - either they're automatically approved because you fill in a form requesting more and it just becomes a PR for an engineer to approve, OR - it can't move because you've hit an internal service limit

Wait, really? Quota are recorded by code that must be changed by pull request, not an entry in a db? That sounds like an insane waste of engineer time.

A not uncommon flow was:

- google form submission

- creates a PR with the project ID and the requested value as an exception in a file (this requires OWNERS approval, so at a min one eng/pm to approve)

- file would update a DB the next time it's picked up

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

#127

While I'm not arguing the general point of the article, I will counter point one thing. > Will Google Cloud even exist a decade from now? This seems wildly speculative, and the likelihood of GCP, or its core offerings, not existing any time so soon is next to zero. Google has to royally fuck up for this to be the case, but even if it ends up being case, there will be a string of lawsuits lined up that will likely cos…

There were multiple companies forced off Google Maps because of a pricing change. This could absolutely happen and has happened before.

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

#128

[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…

I think this is a little inaccurate. Google's monorepo does have branching but it is a second class citizen with minimal support that most engineers aren't aware of unless you've carried a product through many releases.

That being said, every release can stand on its own and be iteratively changed without taking on changes from the rest of the company.

The highest possibilities for breakages to be introduced are at boundaries where your long running services depend on an another team's service(s), but this problem is not unique to Google.

Google can choose to maintain a long running maintenance project or deprecate it, and I won't claim to know what plays the biggest factor in that decision (it's likely unique to every team), but having a monorepo definitely is not part of the equation.

(Also worked at Google for some time)

Edit: typos

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

#129

Earlier quoted context omitted.

I don't know why all the cloud companies make you jump through so many hoops to get more quota - but Google has consistently been the fastest for me. Fill out some random Google Docs form (why does it have to be so dodgy?), receive quota within 24 hours. Contrast: Microsoft - flat out refused me more quota despite spending 10k/mo with them. Required me to convert to invoice billing, and then wanted a bunch of proof o…

That's because Google's quota increases are binary: - either they're automatically approved because you fill in a form requesting more and it just becomes a PR for an engineer to approve, OR - it can't move because you've hit an internal service limit

Heaviside step function https://en.wikipedia.org/wiki/Heaviside_step_function

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

#130

While I'm not arguing the general point of the article, I will counter point one thing. > Will Google Cloud even exist a decade from now? This seems wildly speculative, and the likelihood of GCP, or its core offerings, not existing any time so soon is next to zero. Google has to royally fuck up for this to be the case, but even if it ends up being case, there will be a string of lawsuits lined up that will likely cos…

Cloud computing hasn't existed for all that long though - eventually a cloud provider is going to fold for one reason or another, and that'll change the industry pretty thoroughly when it does happen.

Lots of stuff "won't happen" until it does and the big speculation at the moment is that Google might eventually convince itself that the adtech business is the only business worth being in.

Post reply on HN