Actually this is even more specific, which is building your product on a webservice provided by someone else is risky. Unlike a library you download, a webservice ends the day they cut access to it.

With a library you can continue to use it, and slowly rebuild your product to use a different library (or even use that library forever if it works for you), but with a web service it works 100% today and tomorrow it doesn't work at all.

This shit still happens?? and people fall for it?!

http://raganwald.posterous.com/this-shit-still-happens-and-p...

You mean like .NET? Or Cocoa Touch? Or DOM? Or Node? Or POSIX?

At some point, we're all relying on APIs provided by somebody else. I think that's why it's so easy for people to ignore the pitfalls of just a little bit more.

The difference is that those APIs are "non-cloud". The code necessary to run those APIs is spread far and wide and no one can just centrally "turn off" .NET or POSIX. Perhaps over time the programs written for unmaintained APIs will fail on newer platforms, but you will always have the means to go back to the old system and run your dependent programs there. In Google's web-based system, Google is the only one with the keys necessary to keep that engine running, and if they take their ball and go home, all of that API's users are screwed.

If Microsoft stopped all .NET support today, my .NET apps will still keep running. Big difference.

In this case, people are using "API" to refer to the service. The google translate service is being shut down for non-human users.

I think you can state this in a different way, "Why would I invest in a company which will be killed by Google changing its mind about an API?" I imagine (but it's pure speculation) that folks like YC, other Angels, or early stage VC's should as their due diligence point out this risk and without a reasonable mitigation option pass on funding.

This would 'self correct' folks who weren't doing the extra work.

However for things where there isn't really a credible way to come up with an alternative you are kind of screwed. But then it would become a Google problem if they didn't get API adoption without offering some sort of indemnification in the event they need to take it back.

I presume the 'translation abuse' is people using it to send spam in 141 different languages.

If the abuse is translating spam, then that's even more surprising - because that's exactly the kind of abuse that Gmail already prevents all the time. It even seems like a great opportunity for Google to gather spam data in all sorts of languages.

I think relying on a free API is the problem, not any API.

When you pay per request for access to an API, at a level that can make the provider as well as you profitable, you can have some comfort in the fact that if your provider goes down there will likely be a competitor to spring up in its place.

It depends on how much of your revenue is based off access to the API. Every moment without access is lost revenue; that can break a startup.

If your startup could survive if you switched off the API, then you're fine.

As long as you are willing to wait 5 or 10 years for someone to replicate Google's R&D.

There are billion dollar companies like NetFlix completely reliant on AWS APIs.

I would be willing to bet that most of them have mitigation strategies in place that they can, at least in part, switch to. They don't use them because they are less cost effective than AWS (or other current providers) but they should be able to switch with relatively little notice.

I believe you, but I would be willing to bet those mitigation strategies are a few unmaintained word documents that would be grossly insufficient if it actually came that far.

I don't see why NetFlix would have to be more paranoid about AWS, then say Apple about Foxconn. Business is business, except at Google.

Netflix is actually pretty well known for its resiliency to AWS outages.