Live data from Hacker News

Why I distrust Google Cloud more than than AWS or Azure

iasylum.net

171–180 of 251 posts

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

#171

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

At Google it mostly _is_ your responsibility to do that, yes.

There is substantial tooling assistance to assist with this, and it's common to make changes by adding new functionality, writing an automated transform to shift usage from old to new, sharding out the reviews to the suitable OWNERS, and finally removing the old functionality.

Very heavily used common code tends to be owned by teams that are used to this burden. That said, it does complicate upgrades to third party components.

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

#172

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

[deleted]

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

#173

Earlier quoted context omitted.

I don't know exactly what's going on at Google, but the key feature request seems to be that one chunk of code be able to depend on a consistent version of the library interfaces. If it wasn't a mono-repo, you could specify a dependency as a particular version of the other repository. But if everything is in the same repository, and one directory of code depends on a past version of library code, then everything fall…

Maybe in java world it was different but when i wrote c++ and go code there breaking existing apis was extremely frowned upon and if they had to do it people usually sent you automated code edit PRs for this

I can attest. I work at a similar megacorp with a very large megarepo. If you commit a change that breaks any kind of test, anywhere, that shit is getting reverted very rapidly. If you MUST make a breaking change, congradulations, you get to update all of your users code too.

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

#174

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.

(A) Not necessarily, and (B) if so, okay so what? The whole point of the parent comment was about keeping devs in check, and I submitted an anecdote that AWS in fact has better tooling to keep people from doing things they aren't supposed to. Not related to billing oversight, but permissions.

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

#176
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…

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

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

Thanks for articulating this distinction so clearly; it's a simple enough idea, but it seems to elude so many.

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

#177
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…

Ahh I actually love those conversations, when they express the knowledge in a way that actually helps build your own understanding about the product and use it better.

Dear HN reader, if you ever did that to really help a costumer, you are a truly MVP :P

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

#178
post #107

Earlier quoted context omitted.

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

Also, if you're paying GCP any reasonable amount of money, you have an account manager who will respond in < 24 hours to connect you with the right PM to deal with the issue. Google deals with lots of random humans, GCP mostly deals with actual businesses. As much as I hated the support offshoring Google (and sometimes GCP) did, most actual businesses could get a human fairly quickly.

But you need to be logged into the cloud to start the support request. If they disable your account you can‘t start the process.

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

#179

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…

It's not that one-sided. On AWS, you have to go hunt to find the pricing for everything. On GCP, it's right next to the instance that you're starting. The GCP dashboard also provides recommendations to down-size VMs if they are too large. On AWS it's also super easy to spin up a VM and never see it because it's in a different region. These little things add up.

I do really hate this pattern done by AWS, and their docs seems more made to hide information than actually make easier.

I've learned much more with 5 minutes posts (which I truly dislike) in other sites than going to AWS docs.

Comparing to Digital Ocean docs and Q&A which is so much easier

Edit reason: Added DO as example of simplicity and really helpful price model.

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

#180

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…

I am on GCP, the greatest fear is not they increasing prices or disabling a product it‘s getting flagged and not being able to do anything. The support has been helpfull, that‘s true.

I guess having this fear is mostly people on hn reading these stories so often and how it is resolved: knowing someone at google. I don‘t know anyone and i should not have to. There should be some contact for disabled accounts you can reach. I am all the time looking at aws which does not have this problem but gcp is so much easier to use.

Post reply on HN