Occasional connectivity works both ways

Amazon S3 went down this weekend. It isn’t alone… Twitter and other services have outages too. If you’re trying to build on the cloud, then sometimes the cloud just isn’t there.

Om Malik observed: “The S3 outage points to a bigger (and a larger) issue: the cloud has many points of failure – routers crashing, cable getting accidentally cut, load balancers getting misconfigured, or simply bad code.”

The 2002 definition of “Rich Internet Application” explicitly mentioned support for occasional connectivity. Most of us have assumed this means that the app works whether or not your pocket device can connect to the net. But it’s just as valid whether a remote service is down. The app should just work, regardless of whether its connectivity requests can be fulfilled.

Support for occasionally-connected applications is available in the Adobe Integrated Runtime (AIR). But it isn’t automatic. We still need well-accepted design patterns, interface conventions to handle varying freshness levels of remote data. We’ve got the basics down at the platform level, but there’s a lot of work left to do at the application level.

The cloud concept isn’t dead just because S3 went down. Arguing whether Amazon or Google or Microsoft or a startup has best connectivity is irrelevant — all services are occasionally unavailable. Simple always-live apps are vulnerable to surprises. Every application that relies on the network really needs to figure out how to still work, when it cannot connect across the cloud.