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

261–270 of 417 posts

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

#261

Post by rblatz »

wutwutwutwut wrote: post #206
skohan wrote: post #172

Earlier quoted context omitted.

Unfortunately I understand that Azure is not exactly what one would call "mature software". I have a colleague who's been using it for a few months, and he complains about it constantly. He's had to submit a couple of pull requests for somewhat silly issues like string escaping not working properly.

I don't have the same issues as your colleague. I've been using Azure for 8 years and rarely run into any issues. Maybe his issues isn't with Azure.

Same, 8 year user. No real issues to complain about.

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

#262

Post by tomc1985 »

dmitriid wrote: post #76
tomc1985 wrote: post #21

I can hear cries from tenderfoot developers whining about supporting multiple options and backwards compatibility... "But that's sooooo muuuuch too teeessstt!! Whaaaaaaaaaaaaaaaa!!!!!!!!!!" But that's your job dude. So what if it costs more money and time. Fucking pay for it anyway. I feel like startup software dev needs a swift kick in the ass or three with that phrase.... "do it anyway!" Who fucking cares if these…

You didn't read the article, did you? Startup developers don't mind supporting multiple options and backwards compatibility. Often they have to because they don't have the time and the money to rewrite everything, so it's common in startups to run and support multiple versions of APIs, clients etc. It's Google who doesn't provide backwards compatibility, upgrade paths and migration options. > But that's your job dude…

I read the whole article. My reaction is such because I feel that much of software dev is plagued by the same bullshit that the article describes about Google

I've been on the web since the mid 90s. The last 15 years have had more cool things taken away from me because of sunset bullshit than the first half of that time period. Software (even web apps) should be eternal, there should never be "features removed" or "EOL" announcements. If they don't want to run something they should open source it and let the community take over. What the hell is the point of hoarding all this wonderful IP if it serves noone?

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

#263

Post by hn_check »

mauricio wrote: post #209
Wandfarbe wrote: post #207

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.

Deprecation is too kind of a word. Traditionally deprecated means that it is no longer a best practice/canonical. It's nice to see deprecated flags when building new code because you know you found an out of date bit of documentation and you should look at what may be a better approach.

Deprecated APIs, functions, etc, in many orgs hang around forever. They might not be ideal, but they still work for code written before (or even code written after that might have some perverse reason).

Google (outside of Android) doesn't deprecate, they rip it out. It makes things easier for them, as this post details at length, but it makes it harder for the rest of the universe.

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

#264

Post by gameswithgo »

skohan wrote: post #172
aaanotherhnfolk wrote: post #162

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…

Unfortunately I understand that Azure is not exactly what one would call "mature software". I have a colleague who's been using it for a few months, and he complains about it constantly. He's had to submit a couple of pull requests for somewhat silly issues like string escaping not working properly.

used azure to host an aspnet website, azure sql, and azure redis. everything worked pretty nicely, we made money and had a quality product reliably on the web with a small team. this was 2 years ago.

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

#266

Post by irrational »

This puts into words what I have suspected for a long time. When we were considering which cloud platform to move onto, we considered Google Cloud for about five seconds before someone said “How long until they kill it?”. And all of us knew exactly what they meant. It feels like Google’s main mode of operation is killing projects. We ended up going with AWS.

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

#268

Post by monadic2 »

MaxBarraclough wrote: post #184
aaanotherhnfolk wrote: post #162

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…

A library being dependably bad is not good. Sometimes changes really are good enough to break an api. It does take a significant amount of communication to do this without pissing people off, though.

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

#269

Post by manquer »

micimize wrote: post #252
manquer wrote: post #218

Earlier quoted context omitted.

Easier to get started ? Their UI , IAM architecture and firebase being kind of separate is so confusing . Aws used to be simpler , while they are screwing it up now, the recent route53 upgrade was terrible , a single click action has now become 4-5 clicks they are still better than GCP. Azure has the really the best interface (outside of DO) , it is easy to go to related and nested resource in one freaking app. Both…

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 once a month, reach their product teams, get preview access, get the MS account manager of my customer to help with a deal, put them in front of my customer, help with compliance, even get their sales guys to recommend my product. To a lesser extent I can do a lot of that with AWS too, with even sub $100k/year spends they will still put an account manager for you. I am not sure any of this was possible with GCP for most customers.

It is extremely hard to get a human from Google to talk to you even at $100k+/year GCP spends. Google has contracted a lot of partners to do all the heavy lifting in support for them so they don't have to do the hard work. It does not work, the partners can not do much beyond what is available on the portal or clarify beyond the documentation.

Azure serves enterprises really well, and has really made effort with developers and their support for startups in fantastic, AWS is not as good yet, however it feels like they are really trying and their tech popularity works in their favour and they care about backward compatibility a lot S3 API from 2006 still works. With Google and GCP it does not even look as though they are trying at all.

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

#270

Post by calcifer »

remus wrote: post #111
larrymcp wrote: post #54

Earlier quoted context omitted.

I saw that he mentioned a few of them in the article. He writes: I can tell you that virtually everything I’ve used, from networking (legacy to VPC) to storage (Cloud SQL v1 to v2) to Firebase (now Firestore with a totally different API) to App Engine (don’t even get me started) to Cloud Endpoints to... I dunno, _everything_, has forced me to rewrite it all after at most 2–3 years.

Thanks for taking the time to list them out, didn't spot those in the article. Personally, I think most of them seem quite sensible. Having a 'support everything forever' approach is obviously going to impose a huge burden on the teams who maintain this stuff which is then going to limit the ability to make anything better. The depreciation notices generally seem pretty good (12-15 months notice by the looks of it, s…

> Having a 'support everything forever' approach is obviously going to impose a huge burden on the teams who maintain this stuff which is then going to limit the ability to make anything better

And yet AWS is doing just that while innovating at the same time.

Post reply on HN