6 Comments

Summary:

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 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.

chain

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, Android and BlackBerry. 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 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?

Photo courtesy Flickr user ciccioetneo

Related content from GigaOM Pro (sub. req.):

  1. Hmmm.. a very interesting and important issue !

    We considered integrating PpcSoft iKnow directly with Dropbox, but came to the same realization that you have in this article – depending on external cloud services make you vulnerable.

    We’re taking a step back and will be more flexible so that the user can choose *which* 3rd party synchronization service they want to use (instead of building our own, proprietary system).

    However, Dropbox is depending on Amazon S3, and if you choose a different provider than Dropbox that *also* uses Amazon S3 for their backend, then you’re really back to square one and haven’t really reduced your risk ?!

    The cloud *is* getting better, though :-)

    Share
    1. Providing users with choice is a good point, Atle (it’s something I discuss in my Pro post, too). Not only does it reduce risk, but users will appreciate the flexibility (why should I have to sign up for Dropbox if I’m already using something else?)

      Share
  2. As a task list provider, we’ve been wondering about this ourselves. The truth is, though, customers are demanding integration. They want tools that sync with other tools they already have like Google Calendars. And sometimes it’s easy for the start-up provider to integrate another solution so they don’t have to “re-invent the wheel.”

    For now, we’ve decided to go the holistic approach and not integrate for the very reasons you mention in the article. That’s not to say we’ll stay there, though. It will depend on where market demand takes us.

    Share
    1. Oh, integration is a very good thing, in my view, particularly as, on the web, moving data from one app into another can be a royal pain. But I’m concerned by some apps almost becoming the de facto choice for integration; it means there are then a huge number of apps relying on a single provider, which is a risky prospect.

      Share
    2. I agree about the reinventing the wheel. I would like to see standardised api’s for certain services. For example storage services such as dropbox could have there own api’s including advanced features specific to there service, however, also support and share a simple standardised storage api with other services. That way a developer could change supported services really easily without having to rewrite code or leave it open for the end users to decide which service they would like to use.

      Share
  3. Been reliant on another web app service is no different than relying on the provider of your infrastructure, hosting or internet connection. If those examples were causing issues you would change provider. You could do everything in-house, however, development, management and procurement costs would jump significantly. For smaller software companies having everything in-house just isn’t an option unless they manage to get investment. What I would like to see is more standardised apis between web services giving such apps a greater choice of integrating with other providers.

    Share

Comments have been disabled for this post