Parts of the Amazon.com S3 (Simple Storage Service) cloud computing infrastructure were down for at least 6 hours, according to news reports and the company's own health dashboard.

The dashboard now shows that service is normal again, but as late as Monday at 10 a.m. Eastern time, the Twhirl Twitter service continued to display a message saying, "Currently, twitter avatar images cannot be displayed because the webservice twitter uses to host them (Amazon S3) is down."

So far, the company's customers have reacted with all the vengeance of a collective yawn.

The reaction is best encapsulated by this comment to a story on ReadWriteWeb:

People rankled about 5 hours of downtime should try providing the same level of service. In my experience, it's much easier to write-off your own mistakes (and most organizations do), than it is to understand someone else's—even when they're doing a better job than you would.

It does seem like most users have a high degree of tolerance for these kinds of outages, particularly since we've all gone through downtime thanks to the in-house IT department (and I'm talking about both planned service—Windows and unplanned crashes that go on for hours at the worst possible time).

This is a far cry from the early days of SAAS (software as a service). Remember when the Salesforce.com outage of December 2005 loomed as the potential death-knell of the entire business model?

That said, even the most reasonable customers are likely to reach their breaking point if the Web service providers fail to provide a more reasonable level of service. As another RRW commenter put it:

It's safe to presume that S3 and related services are going through a phase of rapid expansion—hitting walls as they push out further and introducing defects as their environment changes. All new systems go through a similar adolescent phase so I'm not extrapolating this into a trend, yet.

SLAs are not useful—they don't present accurate expectations (it's a sales tool), and the recourse is always insignificant in comparison to the lost incurred. "How good are you" is more useful than "how good do you promise you'll be". Think about that point if you're deciding to use S3 in the near future, is the contract or the service history more relevant to your decision?

Anyway, S3 et al better be scrambling to tweak their architecture or I'm switching off either to www.nirvanix.com or bringing it back in house where there are a few throats to choke.

We ran a piece on SLAs in the on-demand world back in 2006 that is more relevant than ever.

The most salient thought about this comes courtesy of a throwaway by Om Malik at the end of his recent post on the S3 outage:

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.

There's no doubt that cloud computing will survive this, and many other instances of outages and plain bad service. As more players come into the market, more of them will suck, allowing the better companies to differentiate themselves.

Om's statement about the many points of failure brings up two issues worth thinking about: Is your company equipped to survive an outage from your cloud computing service provider; and do these many points of failure represent an opportunity to step in and provide a new kind of service that helps mitigate one of these potential service gaps?

You don't have to be in the IT business to create a marketable service. Just look at how Credit Suisse took its home-grown virtualization application and spun it off into a business of its own.