They thankfully decided to just go commercial-ish with Translate, but the same can't be said about Charts (which had a long deprecation window and a replacement, but the replacement is a fundamentally different kind of API that has different browser requirements and even different charting capabilities). They also happily will just shut down things like Google Checkout and offer no replacement at all for key use cases like "sell a physical product" (if you sell digital goods, you might be able to switch to Google Wallet Objects, an "exciting new API" released a couple weeks before Checkout was deprecated).
Google Checkout was certainly also targetted at enterprises, had a clear business model behind it, and had existed since 2006: everyone who built on that one (again, not me: I avoided Checkout like the plague) got only six months to migrate to a different provider (and figure out how they are going to handle any refund requests from recent customers, which will surely be horribly irritating as they won't be able to just tell Checkout to refund the transaction anymore). There is simply a patterned lack of care for people who may have built things on their stacks.
(Yes, some services have deprecation policies, but let's not forget that those guarantees were themselves attempts to regain faith due to a previous round of services that had been axed with little warning ;P. After the anger died down from that they started reversing course, shortening or removing the policy entirely after the previous guarantees expire. I can only imagine the people who keep citing these deprecation policies don't have much memory of how this has all been going down over the past few years ;P.)
http://googledevelopers.blogspot.com/2012/04/changes-to-depr...
Yes: you might be able to find alternatives to migrate towards... but if, by just acknowledging this pattern, you could avoid that bullet--which could easily come at the "least convenient moment" (such as when you now have some competition out of nowhere while attempting to launch a new product and raise finding), requiring you to suddenly drop everything for a couple weeks coming up with a new implementation of key infrastructure before the clock runs out--why wouldn't you?
That said, I acknowledge that Google shutting down enterprise products is less likely than shutting down niche consumer products. Another point I want to make, however, is that shutting down a product is not the only thing that can go wrong with something from Google. For example, there are App Engine bugs affecting production that have been left open for years. There's also poor documentation of some of the interactions between Google products. For example, the best documentation of Google Apps secondary domains not being supported by App Engine is a bug report. (https://code.google.com/p/googleappengine/issues/detail?id=6...)
I seem to run into an issue with App Engine every few months only to find that people have been encountering it for years and that despite being acknowledged by Google, it's just been sitting idle in the GAE issue tracker. My point is that a shutdown of GAE isn't the only thing that could go wrong with it, and who knows what GAE bugs might be encountered if one actually made a serious attempt to migrate an app away from GAE.
On balance, I don't regret picking GAE because I think the effort saved outweighs the problems.
(a) App Engine specifically (and Google Cloud Platform in general) is being sold to enterprise as well, with SLA and deprecation policies.
(b) App Engine has been around since 2008 and is growing VERY strongly.
(c) Even if worst case happens, fine, move your app to somewhere else. Deprecation is officially a year, plenty of time to move. Any company can deprecate any products. GAE has huge usage (over 3 million applications), and we have two (and counting) compatibility partners (CapeDwarf and AppScale) that you can move.
(d) GAE does not lock you in. Won't rehash arguments here, see: https://plus.sandbox.google.com/u/0/110401818717224273095/po...
cheers,
P.