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).
Why I distrust Google Cloud more than than AWS or Azure
231–240 of 251 posts
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…
Oh man that explains everything, I can totally relate to that.
Re: Why I distrust Google Cloud more than than AWS or Azure
#233Re: Why I distrust Google Cloud more than than AWS or Azure
#234Earlier 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…
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
#235I'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…
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…
Re: Why I distrust Google Cloud more than than AWS or Azure
#237I'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…
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 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
#239Earlier 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
Re: Why I distrust Google Cloud more than than AWS or Azure
#240The *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.