I can immediately off the top off my head think of no less than four examples of useful services Google has discontinued or EOL'ed: Google Reader, Google Code, Google Wave, and XMPP support for Google Voice.
So as well as potential future price hikes, you should be prepared for the possibility that this service might not be around for the long haul. Therefore you should skip using any Google-specific functionality, and instead implement a design that allows you to easily migrate to another VM vendor.
I never got the "google shuts everything down" mentality that has become so prevalent.
I could easily beat those 4 with a multitude of examples from both Apple and Microsoft, that doesn't mean that any of them are untrustworthy, just that they evolve and continue to grow.
At least when google shuts down a service, they give a good amount of "heads up" to those using it, provide examples of trustworthy equivalent services from competitors, and ALWAYS provide an export function if it makes sense to have one.
Apple and Microsoft may discontinue support/sales but the hardware/software they sold you continues to function. That is inherently not true of "cloud" services.
> I could easily beat those 4 with a multitude of examples from both Apple and Microsoft that doesn't mean that any of them are untrustworthy
No, that's pretty much what it means. To varying degrees when you build on top of Apple, Microsoft or Google offerings, you're sharecropping rather than farming. Sometimes, they'll just find that it's in their interest to no longer lease out the farm to you -- or to change the rates/terms.
"Untrustworthy" might be an over strong term, if for no other reason than that invoking "trust" as a relevant concept in this context is probably itself incorrect.
That thing that jumps out at me from that example data set is that they were all free services. That's not to say there aren't fee-based services that Google has discontinued, or that your point isn't valid, just that your provided data points don't seem entirely relevant to me, given the subject.
Amazon has discontinued Flexible Payment Services, Amazon Webstore Services, and others. Presumably your warning to not rely on proprietary implementations is vendor-agnostic?
Or at the very least: never rely on one vendor's proprietary implementation(s). Always have at least two in active use (though you can do something like using one vendor 95% of the time), and if/when one goes down make it your top priority to find another.
You're right, though I wouldn't compare App Engine to things like Google Reader.
When Google EOLs a highly-visible free service like Reader, it generates a lot of outrage, but consumers can find a replacement like Feedly at reasonably low cost.
The risk of writing apps on a platform like App Engine is far greater because people tend to spend years building software and a business tightly interwoven with the platform, only to be shut down by unpredictably massive rate hikes because you basically have to rewrite to get off the platform, not just the app itself but all your ops stuff too.
While it is possible to dig yourself into that hole using lots of Amazon services,
Amazon doesn't require you to use platform-specific APIs, many of their services like EBS are very easy to replace, and Amazon's services have not been subjected to the same project-ending rate hikes. In practice, people move on and off EC2 all the time. So if you are going to trust a vendor, it's more reasonable to trust Amazon.
So as well as potential future price hikes, you should be prepared for the possibility that this service might not be around for the long haul. Therefore you should skip using any Google-specific functionality, and instead implement a design that allows you to easily migrate to another VM vendor.