jd/adobe

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.

Posted by John Dowdell at 08:57 AM | Permalink | Comments (0)

Infoworld has an article and editorial suggesting that the arrival of beyond-the-browser technologies like the Adobe Integrated Runtime "spell doom for the web browser". No way. We definitely need to be able to read the web -- to click from hyperlink to hyperlink, to search documents on strange sites -- we need to be able to browse the entire web safely. Having a generic shell application which can hold various HTML/CSS/JS presentations will remain a vital need far into the forseeable future. We'll always need a document browser, so that you can read documents without bothering to trust the document provider. We need to surf. But now we've also got technology for network experiences from providers you trust, whether it's an old-style native-code executable like Microsoft's WPF, or a separate browser process like Mozilla's Prism, or a cross-platform desktop application with easy development like Adobe AIR. Desktop applications started adding networking functions back when browsers started adding scripting... there's a long tradition of both types of client software serving different user needs. Desktop apps convey additional privileges to coding you trust; HTML browsers' restrictions let you engage with sources you don't know enough about to trust. It's not one or the other, it's both. As Adobe's Ed Rowe says at the end of the article: ""Adobe has no vested interest in saying all apps should be Web apps or that all apps should be desktop apps. In no way are we anti-browser. As far as the browser becoming more powerful, where that makes sense, that's great."

Posted by John Dowdell at 07:54 AM | Permalink | Comments (1)