Hacker News Reader

Comment by 6gvONxR4sf7o | Hacker News Reader

Honest question: Do they kill off GCP services/features? Often? More or less than AWS?

As a user of GCP, this really feels like a HackerNews meme that doesn't have any substance. I have never had a GCP feature killed, but I've had many AWS features mothballed. I am not really sure how to change the perception here since it's easy to say: "Google kills products-- therefore I will never use any Google product†"

† Except search, email and phone.

They kill all kinds of stuff. I still remember dealing with this one:

https://cloud.google.com/network-connectivity/docs/vpn/depre...

Here's a take from an ex-googler:

https://medium.com/@steve.yegge/dear-google-cloud-your-depre...

> I've had many AWS features mothballed.

What, exactly? AWS is legendary for maintaining compatibility. Steve Yegge's article gives a good break down on how infamous GCP's deprecation practices are.

I was lucky in that GCP killed off the feature I wanted before I ever used it, so I didn't have to get burned in production. AWS has never burned me. (GCP used to have a service to do transformations on images in object storage, which I learned about in an App Engine book. It took me a few hours of searching to even find the deprecation notice. Now I just use https://github.com/awslabs/serverless-image-handler because I don't trust GCP).

For me, AWS Opsworks. It felt like once containers came into vogue, they stopped working on the product and it was nigh impossible to switch back to vanilla Chef.

Oh, I misunderstood what you meant by mothballed. Still, that is honestly a good example of why AWS is so much more reliable than GCP. AWS will keep the service running as-is even if they don't make any changes to it. GCP would just deprecate it instead and kill it off completely. Maybe that hasn't affected you yet, but the available evidence says that it has burnt plenty of people.

We can't even be sure whether GCP itself will be around in 3 years:

> In early 2018, top executives at Alphabet debated whether the company should leave the public cloud business, but eventually set a goal of becoming a top-two player by 2023, according to a report from The Information on Tuesday. If the company fails to achieve this goal, some staffers reportedly believe that Alphabet could withdraw from the market completely. [1]

That's disputed and is not hard data, but there's not any positive reason to believe that GCP will exist after 2023 either.

[1] https://www.cnbc.com/2019/12/17/google-reportedly-wants-to-b...

> Maybe that hasn't affected you yet, but the available evidence says that it has burnt plenty of people.

What evidence are you referring to here?

The best one is the Googler article linked in a sibling: https://medium.com/@steve.yegge/dear-google-cloud-your-depre...

That alone is more than enough to substantiate what I'm saying, but if you need more examples than just search or read HN a bit, due diligence, etc. I was personally lucky in that I got burned in the planning stages and didn't have to get burned in production, but I still wasted all that planning time and ended up having to use AWS instead.

I understand the problem you’re talking about, but the way you said “available evidence” made me think you had something more data-oriented than Steve Yegge’s blog post and HN comments.

Since you work at Google, you should be well aware of the deprecations. You don't need evidence of their existence, you just don't see it as a problem. Which you are free to do, since it's not a problem for you, it's just a problem for GCP clients, many of whose complaints you seem to be dismissing as not being "data".

GCP doesn't seem to provide a full list of deprecations, but the list for just one service[1] is pretty terrifying when you consider that your app might depend on two or three dozen services, and a deprecation in just one of them forces you to rewrite perfectly good code. A cursory search reveals a number of reports of being repeatedly bitten by deprecations[2][3][4], so no one should be mislead by the dismissals here. [2] has a good cautionary tale of a forced "upgrade" leading to potentially much greater cost.

[1] https://cloud.google.com/appengine/docs/deprecations [2] https://nilsnh.no/2019/11/09/managing-the-google-cloud-platf... [3] https://www.slideshare.net/async_io/lessons-learned-from-bui... [4] https://www.lastweekinaws.com/podcast/aws-morning-brief/whit...

I do work at Google: I’m not trying to dismiss the concerns and I understand that deprecations are a legitimate concern and carry a significant business cost. It sucks that you got burned a few years ago, and I totally get the why you lost trust in GCP.

I do think Google Cloud is trying to do better and the few deprecations I’ve seen personally have been heavily scrutinized and considered, with a clear migration path for users. I was only asking for data to objectively understand the problem as it stands today, and not to minimize your own experience. I know there are experiences similar to yours, but hopefully there are far fewer in recent years (but its always hard to tell without data).

That is encouraging, but it will take years to regain trust. Perhaps GCP will eventually exceed expectations and turn out to be a great platform.

We've had to deal with a few. They removed a gcs api a couple years ago and told you to update to the newest version of the sdks. obviously they didnt tell you which version it was actually fixed in, figuring that out was an adventure in itself. everyone's runs off master right? Worse, they hadnt even updated all of them by that point.

We updated to working versions, but support kept telling us we were using the old one. Turns out they didnt update the dataflow runtime, which they own and we cant inspect or update, and they were reporting it to us for us to fix...

Reply on news.ycombinator.com