Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dear Google Cloud: Your Deprecation Policy Is Killing You (2020)

steve-yegge.medium.com

Post reply on HN
Print view View original

101–110 of 126 posts

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You (2020)

#101

Post by [deleted] »

bradleyjg wrote: post #77
ksplicer wrote: post #49

Earlier quoted context omitted.

This has nothing to do with what Google engineers value and everything to do with what management above them values. At Google you don't get promotions or raises for maintaining products, you get them for launching new products. That's the full story of how you get all these deprecations. Google management has been trying it's harded to kill the company for a long time.

Sure, it’s almost always the case that a corporate culture is heavily influenced by the incentives put in place by management. But those incentives and that culture influences what engineers value. That’s how the mechanism works.

[deleted]

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You (2020)

#102

Post by znpy »

zdragnar wrote: post #72
adrr wrote: post #69

Earlier quoted context omitted.

That was a poor decision. Every other cloud provider has domain support. Just left my CTO role at a public company to do a another startup, GCP wasnt even in the running. It was between Azure and AWS. Also the first company i didnt pick GSuite or whatever they are calling it now because they fail to innovate on it. Office365 has been beating it in feature launches like adding an AI copilot and AI generated meeting su…

I don't want innovation in GSuite. I want email and calendar and video calls and maybe the occasional docs. Of the companies I've worked for, half had GSuite and half had office. Personally, I'll take GSuite any and every time.

had gsuite in a job, and office365 at another job.

I'd be okay with office365 if teams wasn't such a shitty piece of software.

slack so far has been the best corporate chat experience.

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You (2020)

#103

Post by JonChesterfield »

Pet_Ant wrote: post #62
renegade-otter wrote: post #47

Earlier quoted context omitted.

Google culture in general seems to be "this is not fun or a very profitable, so we are just going to, like, not do it anymore". Fundamentally it comes from the fact that they don't have to do any of it anyway . Anyone using AdWords knows that it's a money-printing machine. Google is thousands of fresh CS graduates who want to do "cool green-field stuff" but not really the day-to-day grind we are all part of and what…

I'm doing boring enterprise maintenance for a lot less than Google money, maybe I should just apply. "No, I'm not Ivy league or MIT, but I'm great at taking abuse and grinding away thanklessly". Any chance that buys me a pass on not being great at memorizing algorithims?

Nope, the whole point of the memorizing algorithms to gain access structure is to show that you're great at grinding away thanklessly. Just saying it isn't enough.

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You (2020)

#104

Post by [deleted] »

dielll wrote: post #53

recently Youtube shows you a pop up that says they banned adblockers and even suggest that you pay for Youtube Premium. However, in my country if you click the Youtube Premium link, it says YouTube Premium is not available in your country" I don't think Google takes their non ad products seriously. They only launch their products in few countries, the teams use them for promotion then abandon the products

[deleted]

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You (2020)

#105

Post by scetron »

miroljub wrote: post #54
garganzol wrote: post #46

Earlier quoted context omitted.

The TCP connection limits are in place only when a central HTTP/HTTPS routing/termination is used. But you can turn that off by a config parameter in fly.toml file and by allocating static IPv4/IPv6 addresses for your app. By doing so, your app will be then fully responsible for handling all HTTP/HTTPS traffic by itself without external caps.

It's funny how people spend a lot of time and, in the end, choose a worse (unfavourable?) product just because of their inability to find a config switch that would solve all their issues and enable them to use their tool of choice.

There's quite a few reasons why it happens though. Perhaps the feature was available, perhaps there was no documentation or poor documentation. Perhaps this is more complex in some way? We don't really know.

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You (2020)

#106

Post by hobs »

scarface_74 wrote: post #75
hobs wrote: post #73

Earlier quoted context omitted.

> I have never in 5 years heard any CTO of any company of any size worry about “lock in” when considering their cloud choices. The company I got laid off just decided they are going multi-cloud and that anything on their original cloud offering which is vendor specific is verboten in the middle of multiple in flight projects which now probably will never complete because they basically just did it by fiat in an unfun…

And how is that adding any business value? Are they constantly testing for cloud portability like Uber does? Is it giving your former company a competitive advantage?

No, its stupid and wrongheaded, but that doesn't mean people don't do it, just giving an example of my most recent experience but I have seen it multiple times. They believe they will be able to sell their SaaS product in different clouds using existing budget companies have invested in said clouds.

People are loss averse to decisions that they made about things that are completely unrealized, it makes no sense.

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You (2020)

#107

Post by ctvo »

djha-skin wrote: post #40
garganzol wrote: post #10

This story resonates with me so much. An avid cloud platforms user in the past, now I just use Dockerfile + fly.io combo. Dockerfile gives you a total freedom without vendor lock-ins and forceful deprecations. I have never been calmer and happier before that switch. Now, only I decide when to upgrade - and usually it is as easy as editing a text file pointing to a new package version. IMHO, the only thing cloud provi…

One of our engineering teams wanted to use fly.io instead of kubernetes that I was running in AWS for the company. They really liked its ease of use and they really wanted to use it. Unfortunately fly.io only allowed 5,000 concurrent TCP connections, and there's was a chat app that needed to maintain many more web sockets than that for each instance that was running (More like 50,000). So they ended up switching to k…

There's a another reason to avoid fly.io outside of platform capabilities: their outages caused by growing pains. If it were me, I'd circle back in a year or two.

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You (2020)

#108

Post by Havoc »

vrosas wrote: post #55
Havoc wrote: post #32

Yep. Been navigating the firestore / datastore maze and even though it mostly works I still can’t quite tell how the bits relate to each other. There is firestore on fire base side. And then on gcp side also firestore. Except it’s called datastore there. And comes in native flavour and datastore mode. And then there is firestore compatibility with native mode datastore. But also datastore in datastore mode. And they…

I can understand the confusion. A brief history lesson. Firebase: a paas that google bought that included a real-time nosql db (also casually called firebase) Datastore: googles OG serverless nosql db that was tightly baked into appengine as part of their own paas After buying firebase google decided the db implementation was shit and set out to write their own. In typical google fashion they picked the most confusin…

Thanks - that is indeed helpful!

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You (2020)

#110

Post by asah »

scarface_74 wrote: post #68
zmgsabst wrote: post #33

Earlier quoted context omitted.

No — changing your code makes every one of those aspects harder, more time consuming, and thus a worse option. (Again, except network topology.) And yes — I’ve helped migrate global systems on the peta-scale, for finance where compliance is legally mandated. The idea that changing your code at the same time is irrelevant is laughable: Changing your software significantly while migrating has caused major errors in pro…

Again, you’re looking at your little piece of work that is a speck in an entire organization. Your CTO is working with your CIO, compliance department, finance department, product owners, the PMO organization, etc. They are talking to the board about strategic decisions and what will give them a competitive advantage. He’s not losing sleep over whether you put a facade over your data access layer because in some dist…

OP here: aws_s3 is a nice example of a proprietary extension that makes it hard to leave AWS.
Post reply on HN