Live data from Hacker News

Why I distrust Google Cloud more than than AWS or Azure

iasylum.net

151–160 of 251 posts

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

#151

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…

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.

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

#152
post #134

Earlier quoted context omitted.

I have also worked at Google (in an unrelated department) and completely disagree with this. Maintaining old code & services is a problem everywhere. Monorepo vs multirepo, monolith service vs microservices etc. all have nothing to do with it. There will always be a broken dependency, a service/API/library you rely on about to deprecate, new urgent security patches, an outage somewhere upstream or downstream which yo…

Concerning the promotion thing, I hear this a lot from Googlers but isn't it the same everywhere else? Most tech companies (big tech at least) will promote on product achievements, not maintenance.

The main difference was/is that at Google your immediate manager, director, PM, peers and everyone else in your product unit (who you work with every day) have almost zero say in whether you get promoted or not. You have to essentially summarize everything you did in bullet points and send it over to an anonymous committee who don't know who you are. They will base their decision on this piece of paper without any additional background or context.

This does help in various ways – the process is more objective, there is less bias, less departmental/managerial politics etc. The drawback is that a lot gets lost in translation. There is too much burden on you as an engineer to pick and choose what you spend your time on so it looks good to the committee.

In other companies I have worked at getting promoted was a byproduct of doing a good job. At Google getting promoted is the job.

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

#153
post #41

Can HN please add a filter for these increasingly lame "Google cancels all the stuff" posts? Yes, Google has cancelled services, but they've all been free things that they had every right to decide would never increase revenue. Why should Google have to keep everything they ever built running for ever? If you pay for services from Google, then it's a completely different story. We've used Appengine for 12 years now,…

What about all the data they gobble up for free from its users during the time its active? Google has never been free, its bread and butter is the data we give it. We were it's product.

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

#154

Earlier quoted context omitted.

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.

It's not as bad as you think, the PRs are written on their own and the engineer in question probably blanket approves all of them every morning while they're checking email (quickly scanning them looking for automated red flags).

Occasionally I'd get an escalation asking for product approval, but generally yep, it was an auto-approve if it's within the predefined range.

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

#155

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…

The thing that always gets me is when this is presented as some sort of huge commitment -- this is the bare minimum that enterprise support plans provide and have provided for decades.

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

#156
post #102

Earlier quoted context omitted.

What does a billing issue look like? Is it something trivial, like they charged you for $X+X, but you only used $X (e.g., they double billed you -- should be solvable with a phone call)? Or more complex, e.g, they charged for more egress than you actually used (kind of hard to prove or disprove after the fact)?

It's 100% our mistake(s). It's only AWS fault indirectly, in that AWS is complicated and requires a lot of non transferable knowledge. As a small example, we currently pay $750 for Route53. We don't know why (it isn't traffic). It has something to do with Route53 resolvers that our "lead sre" setup before leaving. AWS support doesn't understand how it's setup, and since $750 is relatively small, we've just left it.

Support is the wrong avenue to track this down -- I'd recommend reaching out to your account team!

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

#157

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…

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.

There is a lot of competing business interest here. I always look at a post like this as possibly having ulterior motives.

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

#158
post #134

[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 have also worked at Google (in an unrelated department) and completely disagree with this. Maintaining old code & services is a problem everywhere. Monorepo vs multirepo, monolith service vs microservices etc. all have nothing to do with it. There will always be a broken dependency, a service/API/library you rely on about to deprecate, new urgent security patches, an outage somewhere upstream or downstream which yo…

The "you must make something new to get promoted" was a common meme (literally) at Google, but I never saw that myself. I got promoted, and I sat on promotion committees, and it didn't seem that important. I did sort of start a new project to get from 4 to 5 (rather a prototype was handed to me by my more senior team members), but it was clear to me that the path to 6 was not starting a new project -- it was increasing the reach and value of my existing project. I left before that happened (Google Fiber got canceled, found a new team but it wasn't really my thing), so I'll never know for sure, but I didn't feel any pressure to make something new for the sake of making something new. There was, of course, pressure to make the thing that you did work on good, and nobody was really going to stop you from making something new.

Basically, that whole eng ladder thing is really important. I looked at that a lot for my own promotions and for evaluating candidates for promotions. Just dealing with churn isn't really on there, so it's probably not something you should focus too much on. I'd say that's true at any job; customers aren't going to purchase your SaaS because you upgraded from Postgres 12 to 13. They give zero fucks about things like that. You do upgrades like that because they're just something you have to do to make actual progress on your project. Maybe unfortunate, but also unavoidable. Finding a balance is the key, as with anything in engineering.

The biggest problem I found with promotions is that people wanted one because they thought they were doing their current job well. That isn't promotion, that's calibration, and doing well in calibration certainly opens up good raise / bonus options. Promotion is something different -- it's interviewing for a brand new job, by proving you're already doing that job. Whether or not that's fair is debatable, but the model does make a lot of sense to me.

Things could have changed; I haven't worked at Google for 4 years. But this was a common complaint back then, and it just wasn't my experience in actually evaluating candidates for promotion.

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

#159
post #7

I see the Google hate on HN is strong enough that an article that just regurgitates the contents of a few articles and blog posts can be upvoted to #1 in short order.

And the odd thing is that Google has been significantly better for consumers than other FAANG companies. Apple has historically been anti consumer and anti developer with a huge marketing budget to wash it. Facebook intentionally makes us sad. M$ and their anti competitive practices should be well known.

>Apple has historically been anti consumer

What? Apple has been pro-consumer to the detriment of everyone else. Developers are still screaming that they aren't allowed to install malware on my iphone.

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

#160

Earlier quoted context omitted.

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.

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 things theyve done is create a terraform repo anyone can contribute to. They will review PRs and manually apply changes for production accounts. Whats great is that these folks can take my PRs that are 80% right and they are able to help me achieve least privilege better than I could on my own. However, other devs really dont care about least privilege and they tend to go for large open policies.

AWS's IAM policy is far and away the most sophiscated and granular, and even has a nice UI now. Trying to achieve this in Azure is next to impossible because you must have extremely high permissions to even be able to make new roles/policies that are super granular.

Post reply on HN