As we’re coming to rely on various web apps to an ever-greater extent in our day-to-day work lives, the impact on both our data and our productivity of these apps failing increases. Recently, I’ve been thinking about how interconnected some of the web apps we use are becoming, too. Thanks to open and documented APIs, developers can integrate functionality from other apps into their own software, making the apps more useful. In general, this is a very good thing, but it nonetheless, introduces dependencies between these apps. That’s significant, because it means that an outage of one popular app could affect (or even take down) a raft of others.
For example, online file storage service Dropbox has an open API and works across some of the leading mobile platforms, including iPhone (s aapl), Android (s goog) and BlackBerry (s rimm). Among developers, it seems to be an increasingly popular choice for providing cloud storage functionality in their apps; there is now a whole ecosystem of apps that are built on it or rely on it in some way. But Dropbox recently went down. A situation like that is little more than an inconvenience if the outage lasts only an hour or two, but what happens if the problem takes longer to fix? And it’s not just start-ups like Dropbox that suffer from outages — even the mighty Google’s (s goog) apps have been known to go down.
It’s up to developers to be aware of and minimize these risks. In my latest post for GigaOM Pro (sub.req.), I detail some of the points that developers should be considering before integrating third-party functionality into their apps.
Note that I’m not suggesting that integration between web apps is bad or undesirable — far from it — but, as an industry, we need to consider and mitigate our risks by making sure that we don’t become over-reliant on certain services.
Are you concerned about web apps becoming increasingly reliant on each other?
Related content from GigaOM Pro (sub. req.):