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

medium.com

Post reply on HN
Print view View original

131–140 of 417 posts

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You

#131

Post by murgindrag »

foepys wrote: post #39
nmfisher wrote: post #9

Earlier quoted context omitted.

Including the most critical group of all - customers. It’s astonishing how little Google cares about its paying customers, at least when it comes to AdWords and GSuite, and GCP. I think the Pixel division is the only exception, though I don’t own one so I can’t comment personally.

After 3 years of updates, Google drops Pixel support like a hot potato. As far as I'm informed every Pixel version so far had battery degradation issues. After year or so the battery seems to have only a fraction of the previous capacity.

So does every cell phone maker. I have a pile of old-but-working cell phones without security updates anymore in a drawer somewhere.

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You

#132

Post by murgindrag »

speedgoose wrote: post #115
merb wrote: post #101

Earlier quoted context omitted.

that was sily because they only asked for a company name but you could've entered "Individual" inside the box and they would not care!

That's a bit risky. Google is well known to close accounts and have no humans you can contact.

This is one of the many things which prevents me from building to Google.

1) I don't want them closing my account. Doing development is the sort of thing which looks A LOT like suspicious activity, for Google's buggy anomalous behavior detectors.

2) They close accounts on working businesses all the time.

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You

#133

Post by disgruntledphd2 »

em-bee wrote: post #53

i think this is the key point of the article: it actually winds up being less DevOps work, on average, to support open-source systems running on bare VMs, than to try to keep up with Google’s deprecation treadmill.

I honestly feel like this is a better idea in general, at least in data science stuff.

For context, I tend to get dumped with undocumented poorly written untested DS code bases every time I move to a new job.

The difference between setups where there's a bare VM/server and it runs using standard tools (command line scripts) or at least some open-source orchestration and any kind of proprietary technology tied to infrastructure is massive.

Additionally, the server stuff can be maintained and debugged by a far larger number of people, thus reducing bus factor.

Like, maybe in the web dev world there are things that everyone knows that are AWS services (maybe S3 counts, I guess) but in the DS world, I just know that I'm in for a whole lot more pain if they haven't just used bare servers.

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You

#134

Post by murgindrag »

sidkshatriya wrote: post #84
KingOfCoders wrote: post #41

"Fuck yooooouuuuuuuu. Fuck you, fuck you, Fuck You. Drop whatever you are doing because it’s not important. What is important is OUR time." Most NPM packages.

> “[...] Drop whatever you are doing because it’s not important. What is important is OUR time” > Most NPM packages NPM packages tend to be free and open source so morally they don’t owe us anything. So yes what is important is the time of the authors of the packages. I am grateful someone took the trouble to release them and many popular ones are actually well maintained. But cloud services that you are paying for a…

I don't care about moral debts or obligations. I care about whether stuff works and I can get shit done.

Other ecosystems (like Python) don't have the same culture as NPM. There are clean, well-documented, maintained packages.

Google doesn't have a moral obligation to support GCE customers either. It's just that everyone I know who has used GCE would never use it in production, and loudly advises everyone they know not to do so either. They'll be bleeding money at some point, not to mention they're already bleeding reputation. Google went from smartest-people-in-the-room to smug-incompetent-arrogant-douchebags. That's hard to get over. That's about good business, not some kind of moral obligation.

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You

#135

Post by zimbatm »

Traster wrote: post #102
mamurphy wrote: post #82

Earlier quoted context omitted.

My armchair thought: what if the CEO said "wow, Yegge is right, we've gotten really off trail here. you need to show leadership in maintaining a 3+ year old system at Google for promotions?" Could that happen and would it work?

The promotion system isn't the issue, the promotion system was the issue 10 years ago. For the last 10 years Google has been hiring and promoting and keeping people who prioritize shiny new things more than maintaining old things. If you start rewarding maintaining old things you aren't going to suddenly get what you want, you're just going to lose a tonne of people because they don't want to do what you're telling t…

It might be even deeper than that. I don't know if it's representative, the few Googlers I talked to were there only for the money. Their view of the company was actually quite negative.

Keeping backward-compatibility requires people that care. That have enough pride in their work to counter-balance the grind.

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You

#136

Post by murgindrag »

te_chris wrote: post #112
blickentwapft wrote: post #104

A perfect, spot on analysis. The only thing that’s weird about this is that it’s about 3 years late. If this had been written 3 years ago it would have been topical. But really it’s old news that google deprecates everything and leaves it’s developers in the lurch and that as a result no one wants to use their stuff. It’s not surprising to hear this from Steve Yegge cause he’s a super switched on guy, but it’s surpri…

I mean maybe I’m not their dream customer or whatever, but we’re happy with google cloud for our purposes - GKE, CloudSQL, Redis. I really enjoyed the essay and surely is some truth, but these products have all been pretty good for us.

With 3 services, and Google randomly disabling accounts perhaps 5% of the time for running customers, you have a 15% chance of having your business taken out by a buggy Google algorithm each year. That gives your business a half-life of 4.25 years, approximately, before you get the Google hammer-of-death.

Of course, those might count as one product, in which case, it's 13 years. I'm not sure how Google's algorithms work. Does it detect suspicious behavior per-service or per-cloud-account?

Ironically, so few people use Google in production that successful production use IS anomalous behavior.

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You

#137

Post by cpcallen »

gostsamo wrote: post #52
9nGQluzmnq3M wrote: post #43

So much ranting, yet not a single example of a GCP product that Google has actually killed. Got examples? I mean, there's stuff like Python 2 support being sunset on managed services, but as Yegge himself points out that's on Guido, not GCP.

No, the difference between python2 and python3 in the managed services goes much beyond unicode in the Google universe. The most obvious example is that in app engine standard python 2 you can send and receive emails while you need a third party service in python 3. In my other comment I've mentioned some other issues when Google start neglecting stuff.

Yes; exactly this. I'm contracted to Google, and so much of my Googler colleagues' time has been wasted in the last year porting projects off of the Python 2 APIs which are about to be shut down.

Are they porting to the AppEngine Python 3 APIs? Hell no: those are totally useless (no BigTable, no user authentication, etc.). If you have to rewrite everything to replace all the functionality that used to be "batteries included", you might as well build something can run on any old bare VM instead, and so—like any sensible external developer—my colleagues are doing everything they can to avoid depending on any Google-specific APIs, libraries or platforms.

I really though AppEngine and PaaS were the future, but evidently that future will not be written at Google.

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You

#138

Post by cpcallen »

1024core wrote: post #68

I have heard that at Google, you get promoted/rewarded for launches. To me, that seems like an obvious perverse incentive to continuously deprecate things, so new things can be "launched" to replace them. There are no "launches" if you're just maintaining backwards compatibility! Maybe GCP should take a hard look at their internal incentives?

Indeed; I suspect it's easier to get promoted for a "successful" deprecation than doing maintenance.

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You

#139

Post by rgblambda »

disgruntledphd2 wrote: post #124
logicslave wrote: post #63

Earlier quoted context omitted.

I think this is really common. I've met quite a few Google engineers whose whole identity is defined by their employer. Its striking, and a testament to the malleability of the human mind, even if the individual is "smart".

The joke that I always used to have when I worked near their Dublin office was How do you know someone is a Googler? Don't worry, they'll tell you :) This was prompted by me noticing that most of the people who still had their badges visible after work appeared to have Google badges.

From a brief look at job openings at Google Dublin, this mentality would be particularly mind boggling as it looks like the Dublin office houses the support staff (not that there's anything wrong with working support).

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You

#140

Post by nicoffeine »

sidkshatriya wrote: post #84
KingOfCoders wrote: post #41

"Fuck yooooouuuuuuuu. Fuck you, fuck you, Fuck You. Drop whatever you are doing because it’s not important. What is important is OUR time." Most NPM packages.

> “[...] Drop whatever you are doing because it’s not important. What is important is OUR time” > Most NPM packages NPM packages tend to be free and open source so morally they don’t owe us anything. So yes what is important is the time of the authors of the packages. I am grateful someone took the trouble to release them and many popular ones are actually well maintained. But cloud services that you are paying for a…

I recently returned to dev work after years in a niche of systems administration in banking and healthcare. The existing product is built on npm, and after a month in, I'm simply disappointed that such a fragile set of software is this popular.

Almost every day there is an automated PR to bump one of the thousands of dependencies. LTS is ending for Angular 8, but one of the main component dependencies doesn't support 9 yet. I had to put typescript in an unsupported state so one of the dependency upgrades wouldn't break something -- the solution is an ugly hack not supported by anyone. Another required a bump to lodash, which suddenly started failing. This led me to the following comment in a github thread:

> The recursive implementation of cloneDeep was by design with the shortcoming that in some rare cases it could run into stack size exceeded issues. I'm not how cloneDeep is being used but chances are a more specialized clone tailored to their scenario will be a better option.

So, I agree with the OP: the messaging for support in the npm world can be distilled to "fuck you".

If I had ever proposed to a customer that we would build infrastructure for them written by thousands of pseudo-anonymous entities who may or may not break everything because they felt like it, I would have correctly been fired.

This leads me to believe that supportability, reliability, and security aren't important to the npm ecosystem because ultimately the products built with npm don't matter. A bank or a utility company may use them to build a customer facing application, but for the stuff that's important, a competent technology manager would never let npm through the door.

(edit: I replaced "tools" with "software" in the first paragraph, because tools don't change interfaces and effects on a whim).

Post reply on HN