Hacker News Reader

Comment by foxylad | Hacker News Reader

Can HN please add a filter for these increasingly lame "Google cancels all the stuff" posts?

Yes, Google has cancelled services, but they've all been free things that they had every right to decide would never increase revenue. Why should Google have to keep everything they ever built running for ever?

If you pay for services from Google, then it's a completely different story. We've used Appengine for 12 years now, and every time they've decided to deprecate services, there's always plenty of notice, a superior replacement, and usually lower costs.

View on HN

>If you pay for services from Google, then it's a completely different story. We've used Appengine for 12 years now, and every time they've decided to deprecate services, there's always plenty of notice, a superior replacement, and usually lower costs.

Really? I've had the complete opposite experience on AppEngine as a paying customer.

I was using Python2 AppEngine with ndb and the Users API. Cloud Datastore + ndb automagically cached your data and worked pretty nicely. When they moved to Firestore, they dropped that feature and recommended you buy your own Redis DB and manage caching yourself. They got rid of the Users API entirely and forced apps onto OAuth, which is much more complicated to integrate.

They old AppEngine emulator worked really nicely as well, in that you could emulate a pretty full AppEngine environment locally. When they moved from Python 2 to 3, they dropped most of the emulator's features. True, AppEngine apps require less AppEngine-specific code, so there's less need for an emulator, but it's still useful for testing certain scenarios. I checked recently and it seemed like they had improved their emulator, but I believe there was about a year where there was no Admin UI for their emulators like there had been for AppEngine Python2.

It's all caused me to move away from AppEngine and rely more on vendor-agnostic stacks.

This sounds like a mis-characterization of the situation. It is not Google who have moved from Python 2 to 3, it's you. Google still offers and supports the legacy Python 2.7 runtime for App Engine, and will continue to do so indefinitely. The same is true about ndb and Firestore. It may be that you moved from NDB to Cloud NDB (Firestore), but nobody forced you to do it.

That's a fair point.

But I think it's not such a "free choice" when Google announces a service is deprecated given that they're notorious for shutting off their deprecated services. Once Google announces a deprecation, I think it's fair to assume an EOL could come at any time, and I don't want to be caught on the back foot when that happens with not enough time to migrate.

I see that Google now has clear messaging that they will support Python 2.7 AppEngine indefinitely,[0] but I don't recall seeing that messaging in 2019. Internet Archive only has snapshots of that page[1] going back to April 2020, which makes me think they hadn't made it clear until then that this was their policy.

In 2019, I just remember seeing scary warnings everywhere in AppEngine docs of "we strongly recommend you get off of Python 2.7." I talked to Google DevRel folks at PyGotham 2019 and asked them what was going to happen to Python 2.7 AppEngine. They said it was going away but they hadn't picked an EOL date yet.

[0] https://cloud.google.com/python/docs/python2-sunset

[1] https://web.archive.org/web/*/https://cloud.google.com/pytho...

Woof, sorry. I worked on the Users API deprecation a while ago (2018-2019, prior to any announcement), and there were a few features that just couldn't be migrated reasonably to OAuth (e.g. the `admin` functionality). We did consider things like moving to Cloud IAM (e.g. what we did for GCF and Run) as well as Firebase Auth, but couldn't replicate everything :/

Hi-5 fellow "got caught across the boundary" traveller. This happened to me when I moved jobs to be devops lead on a new product for a company - the google recommended contractor implemented regular AppEngine with ndb, and about 6 months later we were staring down the barrel of everything being deprecated (and had to do the same: add a redis instance to the stack) and then hope that the new AppEngine was going to be ready when we actually went live.

It eventually came together but we ended up having to do a whole lot of refactoring while we were on a tight launch schedule.

The thing is they change/deprecate/retire paid-for services too (in a brutal contrast with the competiton).

Two quotes from one of the posts referenced in the submission (from Steve Yegge):

...I know I haven’t gone into a lot of specific details about GCP’s deprecations. 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, and they never automate it for you, and often there is no documented migration path at all. It’s just crickets. And every time, I look over at AWS, and I ask myself what the fuck I’m still doing on GCP. ...

... Update 3, Aug 31 2020: A Google engineer in Cloud Marketplace who happens to be an old friend of mine contacted me to find out why C2D didn’t work, and we eventually figured out that it was because I had committed the sin of creating my network a few years ago, and C2D was failing for legacy networks due to a missing subnet parameter in their templates. I guess my advice to prospective GCP users is to make sure you know a lot of people at Google… ...

On the first, I've worked as a PM on Firebase, App Engine, and Endpoints.

Nobody has been forced to migrate from the Firebase RTDB to Firestore (and AFAICT the Firestore API hasn't deprecated anything?), App Engine deprecations (https://cloud.google.com/appengine/docs/deprecations) are basically "you can't do new things using these old things, but the old ones will continue to run" (though other deprecations I've done have provided clear explanations of why we're deprecating and how someone can work around it), and Endpoints is still around despite being comically out of date (it's even getting a managed version!).

>We've used Appengine for 12 years now, and every time they've decided to deprecate services, there's always plenty of notice, a superior replacement, and usually lower costs.

That doesn't remove the cost and time of updating your code and migrating.

In most? cases it should make up for that in lowered cost savings moving forward.

That should be a decision for the customer to make and not one that is forced on them. Many larger companies tend to have legacy systems that are basically black boxes to them. The cost of updating one can be orders of magnitude more than any cloud costs for running it.

100% this. Deprecating things your customers use always sucks for your customers. No matter what. It doesn't matter how long the notice is. It doesn't matter how good the replacement is. You have made work for your customers that they wouldn't otherwise need to do.

>>but they've all been free things that they had every right to decide would never increase revenue

If my service provider were to hold this opinion, I would not be able to trust them, actually I would start to search for an alternative immediately. It sounds like a service provider who is okay with turning customers into lab-rats, to experiment on, and once done just discard them away.

> every time they've decided to deprecate services, there's always plenty of notice

Ah, but with AWS, if something is deprecated, generally they tell you you should use something else, but the old way will continue to work indefinitely. You can switch over on your own timeframe.

Just got kicked off of google music as a paying customer, so nope, got a shitty youtube music replacement.

As a paying google fi customer got transferred to hangouts then that got canceled and I apparently need to change my phone number if I want to make an outgoing voip call again because ??? google.

> Just got kicked off of google music as a paying customer, so nope, got a shitty youtube music replacement.

YouTube Music isn't available in my area. Got kicked off Google Play Music with a "download your content, we're deleting it" and couldn't pay even if I wanted to.

Announced discontinuation in August, full deletion of my Music Library in February.

> On 24 February 2021, we will delete all of your Google Play Music data. This includes your music library, with any uploads, purchases and anything you've added from Google Play Music. After this date, there will be no way to recover it.

Same here. I ended up on Spotify instead, which is still shitty although less than I remember (no music player should ever display the notice "can't play the current song", that is its core feature).

However I don't think the two can be compared: we don't need to launch a giant project to make serious infrastructure changes to switch provider.

Just responding to the OP "Yes, Google has cancelled services, but they've all been free things that they had every right to decide would never increase revenue. Why should Google have to keep everything they ever built running for ever?"

Which to be clear they are not responsible for running all their services forever, but it puts a lie to the idea that google is fine with stability in a service, they'll take something commercially successful enough and sacrifice it for something else in hope it attains "hypergrowth".

At the end of the day google doesnt give a flip about its customers, the structure of google will always incentive new services over fixing/maintaining existing stuff and anyone who has a pollyannish view of this needs to wake up.

Obviously google has no obligation to do anything for free. It's still annoying when they cancel services and we like dunking on them when they do.

What about all the data they gobble up for free from its users during the time its active? Google has never been free, its bread and butter is the data we give it. We were it's product.

Reply on news.ycombinator.com