Live data from Hacker News

Dear Google Cloud: Your Deprecation Policy Is Killing You

medium.com

271–280 of 417 posts

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

#271

Earlier quoted context omitted.

That's just been my experience – I remember having much more pains trying to get AWS IAMs and permissions to work, and I really like that they give you suggestions like "this machine could be smaller" or "this role never actually uses all these permissions." Also I haven't worked _that_ much with firebase, but it seems like a great example of the benefit of using GCP. Firebase is a cohesive and accessible solution to…

Google are not competing with DO for developer mindspace, for large enterprises stability matters a lot more than new features and enterprise support matters too, for startups serving enterprises they don't do much either, what's left is consumer focused companies like SnapChat who can thrive on just innovative new tech. I can get Microsoft on a call anytime, I have account managers responsible who talk to me atleast…

>S3 API from 2006 still works

An interesting note is that Amazon actually planned to EOL part of this vis-a-vis what path to address objects at, and then walked it back (for buckets created before a certain date): https://aws.amazon.com/blogs/aws/amazon-s3-path-deprecation-... I think the behavior is still considered "old style" if not explicitly "deprecated", but is "supported".

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

#272

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…

That's because product management at Google is non-existent. Yeah there's a lot of people called "product manager" but what they do ain't it.

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

#273

Earlier quoted context omitted.

People have to realize, that software is not done when written. Software makes the fabric between everything in our lifes. It brought us tones of innovation; It is one of the biggest enabler, innovation drivers and tool we have. It is one of the complexest and cheapest tools we have. You know what happens with software which is stoped being worked on? Very old, unflexible Cobolt Software on Mainframe systems in banki…

People realize this, especially on HN. The post is referring to deprecations. You can patch security vulnerabilities and move a product forward without deprecations. Google does it well with Go.

Until Go is deprecated in favor of Kotlin (as Kotlin is experimenting with server-side)

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

#274

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…

Culture changes real quickly with the right leadership at the top. Bezos and his "everything as a service" mandate, it didn't take long to implement and worked just fine. What you need is empowered leadership and the willingness to take a short term pain for a long term gain, that thing that Yahoo couldn't do and ended up dying of.

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

#275
post #13

The answer to why this is, I’m beginning to realize after talking to dozens of Googlers working at Google as acquaintances, friends, former coworkers, HN comments and twitter personalities is - Google has an active disrespect if you’re not part of their in group . If you haven’t passed their tests, you’re basically an object of derision - a mark, an object just used for incrementing a CPM metric, or an incompetent, l…

(warning rambling rant) I feel like this was super true in the pre Facebook days but they were humbled A LOT by the massive flop of Google plus. I honestly don't feel like I get the my s * doesn't stink vibe from them anymore. Especially because everyone knows their Achilles heel now. But for their ad revenue what would they be? Everything else material from came from an acquisition or is infra stuff. It's cool but t…

> Yeah they built big table... But the rest of the industry standardized on Hadoop (at the time) because they never released an implementation and so they started losing out on good hires because they didn't want to get locked into proprietary Google infra.

Hadoop and Bigtable are not the same thing. Bigtable is a noSQL database. Hadoop is a big data processing framework. Hadoop is actually an open source implementation of MapReduce, which was developed at Google and which has since been replaced by Flume

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

#276

This very long article doesn't describe even a single instance of anything GCP has deprecated. It's a long rant with a bunch of f-words, and the claim that he gets deprecation e-mails "about once a month". Can someone who is informed point to actual GCP services that have been, or are being, deprecated? From the article, I have no idea whatsoever if this is some huge actual problem with core services... or pulling su…

Python2 on AppEngine is a huge, painful Google GCP deprecation. I have a friend who built an AppEngine app within the first year of the platform's release, and he's spent the better part of the past 9 months doing almost nothing but managing his company's migration to Python3 AppEngine. It wasn't just migrating from Python2 to Python3 syntax. Google used it as an opportunity to also turn down tons of APIs and service…

But Python 2 on App Engine is not officially deprecated yet (e.g. not listed here: https://cloud.google.com/appengine/docs/deprecations) and they have not sent the "[Action Required]" email (of which OP talks about) for that yet, so I'm not sure it counts. They are "just" recommending migration.

I have a ~60 KLOC AppEngine Python 2 app (started in 2011), but I'll probably migrate that over only when the deprecation actually occurs, as:

- that gives the python-ndb library more time to mature (performance and bugs),

- easier migration paths for some of the non-py3 services I use (e.g. Images, Users, Memcache) might appear when deprecation actually occurs, either from Google or 3rd parties,

- I'm in no hurry,

- I will be surprised if Google gives less than 1 year of deprecation notice (Python 2.5 got 4 years from deprecation to termination).

(If the APIs I use were available for py3, I would've probably already migrated.)

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

#277

Earlier quoted context omitted.

I strongly feel that you must have end to end tests while using node because of the dependency hell. Not even knowing if a upgrade of a dependency breaks your system is just hard. Also testing it by hand is just not maintainable.

> Not even knowing if a upgrade of a dependency breaks your system is just hard. This is true for any language/platform.

There are massive differences in how much of a problem this is across different platforms.

With Clojure, I can think of 2 times ever when a dependency caused an issue. It was extremely obvious since the issue was "won't compile", and the fixes were simple.

With PHP, I expect any change to potentially break something. Bump your AWS SDK which uses a different minor version of guzzle? Fatal error.

There's a world of difference between breakage being an everyday thing and a true rarity.

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

#278

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…

Microsoft is definitely treating their developers well.

I was exposed to this firsthand yesterday when I cloned the [ShareX](https://github.com/ShareX/ShareX) project to take a look at a problem I was encountering.

Literally all I had to do was install Visual Studio Community, click the “Open in Visual Studio” button on Github, wait a few minutes to install the C# runtime that Visual Studio automatically prompted me to install, and click “Run”.

5 minutes was all it took to be writing code for that project and it makes me want to get into the .Net ecosystem more.

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

#279

And then there is AWS, which has depreciated exactly one service, SDB, but only after they created a much better replacement (DynamoDB) and offered to help migrate all of their large customers, so they could get the usage percent so low that almost no one was affected by the shutdown.

Disclaimer: AWS SDE The focus on consistent behavior and once launch, never deprecate practice has caused many headaches, I personally know of control planes specifically written to accommodate old behaviors that a few customers had years ago even when the entire service has been updated. But IMO this is still much better than deprecating production services and behaviors on the fly.

But by making in Amazon's problem, the customer never experiences breakage, and that's a huge win.

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

#280
post #169

I've been hiring dev ops engineers lately, and the consensus seems to be in the candidates I've talked to that all of the cloud providers are somewhat painful to work with. I've worked the most with AWS so I'll use it as an example, but it seems like they sell on "new services", so they are incentivized to release quickly, which leads to services with a lot of holes and poor documentation, making it almost essential…

It’s a true difference of kind with Google though. Yes they are annoying, but other providers try much harder to have customer service, planned deprecation.

Google flagrantly, with absolutely the “fuuuck you” vibe Yegge writes about, does not care. It fundamentally doesn’t support you. It promises X, delivers incompatible Y, deprecates Y for Z, doesn’t document anything along the way, has no useful support docs, crams upselling ads into all its docs, it’s bonkers.

AWS can be hard to use and confusing. That’s just not the same thing. Poor ergonomics I can forgive, especially if there’s docs and support.

Post reply on HN