Google making AppEngine in the first place always felt weird to me. It was great for some web developers, but outside that use case, really not so much. But it came with a great collection of side technologies, which got unbundled (Datastore, etc) because there were folks (like me) who wanted to use the side tech but not AE itself (for many, many years you couldn't "import numpy" but people would still say "see? We have a cloud, it's called AppEngine").
Once enough things were unbundled from AE, and containers became popular, it wasn't really clear what AE provided that wasn't better solved by more standard tech.
Often times, Google leadership simply didn't understand what its own engineers and product managers knew. People told me for years "we can't do cloud because the profit margins are too small", and now look: Google is a perenially third-place in Cloud but has committed itself so much they can't even shut it down if they want to.
No, we all just migrated the decision of using GAE to using Cloud Functions / Run / Tasks, which is fine. Those are easier for Google to scale over time, than AppEngine.
The problem with AppEngine was that they had to heavily modify the runtimes for isolation... the JVM needed to be secured and that meant maintaining a separate fork, which also meant being perpetually always behind in versions. It also meant any upgrade had to go through a huge security evaluation.
So, moving to another process model, containers, worked much better.
Once enough things were unbundled from AE, and containers became popular, it wasn't really clear what AE provided that wasn't better solved by more standard tech.
Often times, Google leadership simply didn't understand what its own engineers and product managers knew. People told me for years "we can't do cloud because the profit margins are too small", and now look: Google is a perenially third-place in Cloud but has committed itself so much they can't even shut it down if they want to.