[john-shaffer]

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

[ghayes]

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.

[john-shaffer]

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

[amscanne]

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

[john-shaffer]

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.

[amscanne]

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.

[john-shaffer]

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