Service dependency on the new web
Reading this post on the O’Reilly Mac Developer Center got me thinking about something we’re slowly falling into: web-service dependencies. Most new web applications are, in one way or the other, dependant on third parties, and the funny thing is noone seems to worry much.
Looking at the plethora of apps that use Google maps (and this is an example), is cause for concern. If google decided to drop support for Google maps, what would all the developers do? What would happen if Flickr decided to stop allowing people to use their photo database? What if?
Fact of the matter is, after service outsourcing and personal outsourcing, we’re seeing a new age of web-service outsourcing. One with no regulations - only expectations and hopes. Everything is based on trust, and trust sometimes fails. And the problem here is that even with web-services as a liability, there’s no fallback mechanisms, no alternative routes, no “competitor service” that can be plugged into an app in the timely manner live web 2.0 applications require.
This proves that purely mash-up based applications have small foundations, and like a house, with no foundations they may fail to resist should the unexpected happen. What will we do when services turn (if they do turn) greedy? How will we change if outsourced services change or close, since we’re seemingly so dependant?
A question for developers: Does your app depend on a third party service? Do you have an escape route or alternative? Should someone go crazy on a board meeting and decided to close a webservice you depend on, would you close doors? I would definitely love to hear some opinions on this subject.

So Mike just