Live data from Hacker News

Dear Google Cloud: Your Deprecation Policy Is Killing You

medium.com

191–200 of 417 posts

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

#191

> I’m not actively developing on AWS, so I don’t have as much of a sense for how often they sunset APIs that they have previously dangled alluringly before unwitting developers. SimpleDB still works, it's not even deprecated or grandfathered to not accept new users. There is really nothing else you need to know about how AWS treats deprecation than that single example. Deprecation is practically unheard of in AWS. If…

Another example: There was a change to how objects within S3 could be addressed by http(s): https://aws.amazon.com/blogs/aws/amazon-s3-path-deprecation-...

Initially the (justified) change gave you ~18 months to implement necessary changes. Seems feedback was negative regardless, so they modified it in a way so current usage remains unaffected.

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

#192
post #80

> [Google] contracted with a company called Bitnami to create a bunch of “click to deploy” solutions, or perhaps I should write “solutions”, because they don’t solve a fucking thing. They’re just there as checkboxes, as marketing filler, and Google never gave a shit whether any of them worked from Day One. I've had similar experiences with broken Bitnami images that makes it seem like they aren't even tested before b…

Bitnami broke their MongoDB Helm chart. We're careful to pin versions, and hadn't anticipated someone would re-write history and break published code. Can't get too upset, we don't pay them anything. Not in a rush to use them again though.

Have you reached out to (community) support? My colleagues there tend to do their best to help the community.

EDIT Disclaimer: I work for Bitnami; not in that team though. I reached out internally to see if this is a known issue, but it's Saturday...

EDIT 2: does the downvote mean bitnami community support is so bad or did my wording offend anybody?

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

#193

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…

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

Isn't that inherent to their interview process?

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

#194
post #146

Earlier quoted context omitted.

> we all know someone that lost someone to the Python2/3 transition This feels like a very strange perspective. Why is it a problem to "lose" someone from a language? You're an engineer (a presumption on my side); casting yourself into a subsection of a "Python engineer" seems like a move with all the downsides and no upsides.

You don't lose, you're still an engineer. Platform loses a user. And that's bad for everyone as explained in the essay.

[deleted]

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

#195

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…

> you're just going to lose a tonne of people because they don't want to do what you're telling them and you won't be able to hire good people with your priorities because no one is going to believe they can have a good career at Google by prioritizing stability and long term support

I don't follow. Wouldn't ridding Google of its reputation for inadequate maintenance, make it a more prestigious employer? Its reputation for paying well wouldn't change. How would this lead to an exodus?

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

#196

Earlier quoted context omitted.

> “[...] 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 n…

Same for Java.

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

#197

It is a total hassle to keep up with Googlers changing everything constantly. It's not just GCP it's every platform they control. Try keeping a website on the right side of Chrome policies, a G Suite app up, a Chrome extension running. Thousands of engineers chasing promotions by dropping support for live code. If it was their code they wouldn't do it. The org is broken. If you want to see what mature software suppor…

Try to keep up with Android development and Play Store policies...

I stopped publishing own apps on the Play Store, and unpublished all the one that I had, because of the stress and the time used just to follow the damn policies.

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

#198
post #47

It's odd to see an article emphasising backwards compatibility, but not a single mention of Microsoft (I even ctrl+F'd the page source to check!) They've regressed a bit in the recent years but I'd still consider MS the gold standard for back-compat. I have Win32 binaries I last modified over 15 years ago, small (or perhaps tiny - size measured in KBs) utilities that I use daily. They worked perfectly on Win95, and s…

You missed this: > I’ll also give a shout-out to our friends in the Operating Systems business: Windows, Linux, NOT APPLE FUCK YOU APPLE, FreeBSD, and so on, for doing such a great job of backwards compatibility on their successful platforms. I share your desire for stability. I don't necessarily mind frequent updates for security reasons, but I'm getting to the point where if things are changing in big ways often, I…

"completable software". that's the ticket. the maturity to say no more features will be accepted; it is done. for the past 20 years we have been teaching the agile way, that points to the constant churn of requirements, the pivots, and the idea there is always another sprint

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

#199
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.

Is it true though?

Keeping your stuff up and running, patched with the latest security updates takes time. And opensource systems also break compatibility at times. Sometimes the installation/upgrade process changes over time and you need to learn how to do proper upgrades even if the software technically can be made to work with the rest of the system.

It's hard to quantify, but I don't think it's so clear-cut as Yegge makes it look.

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

#200

It is a total hassle to keep up with Googlers changing everything constantly. It's not just GCP it's every platform they control. Try keeping a website on the right side of Chrome policies, a G Suite app up, a Chrome extension running. Thousands of engineers chasing promotions by dropping support for live code. If it was their code they wouldn't do it. The org is broken. If you want to see what mature software suppor…

I'm reminded of a blog post I once read, which annoyingly I now cannot find, on how the job of a library maintainer is to not break the API. If you break the API, you've failed at your job. This mindset makes more sense than treating API breakages as a routine case-by-case decision. As the article puts it, breaking changes are breaking the library's commitments. (The library/service distinction doesn't matter much he…

sounds kind of like this famous linus rant: https://lkml.org/lkml/2012/12/23/75
Post reply on HN