[mtlynch]

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

[jeffbee]

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.

[mtlynch]

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

[asciimike]

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 :/

[XorNot]

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.