Web service developers today have a relatively easy job to do if they so choose. Don’t want to spend a lot of time doing statistics for your site? Use Google Analytics. Need event listings or reviews? Pull them from an API. Storage space or bandwidth concerns? There’s Amazon Web Services for that.

One of the key tenets of the connected and shared Web world of today is to let best-in-breed service providers handle the complexities of your Web environment. How valid does that philosophy turn out to be when one of the specialized providers has service interruptions?

Services around the Web felt the pinch of service outsourcing this afternoon due to an internal communication problem with Amazon’s S3 and SQS services. The effects of the outage for some were purely cosmetic; Twitter failed to load user avatars for a period starting around noon Eastern time. For others like Basecamp and other 37signals products, the downtime caused features to be disabled temporarily.

The hardest hit this afternoon, though, were services whose entire system revolved around Amazon’s service. Users of SmugMug were greeted with a picture of the service logo watering a garden of servers and a brief message explaining the current situation. The company’s reaction? “We’re not happy about it, of course…”

Amazon does provide a service level agreement (SLA) for their AWS suite; any uptime of less than 99.9% of any given month results in either a 10% or 25% credit of that month’s service cost. (A 6-hour isolated outage on a 31-day month would result in a monthly uptime of 99.2%.) With the number of services that fundamentally depend on external providers for the entirety of their business, is a simple SLA valid?

As SmugMug CEO Don MacAskill wrote this afternoon on the SmugMug Status Updates blog:

Since problems in this industry are inevitable, and Amazon’s performance over the last two years has been so exceptional, we’ve been afraid an outage like this. I’m sure there will be more over the next few years, too.

While MacAskill’s point may sound pessimistic, it’s historically valid. While using best-of-breed services and APIs provides a service with a host of tangible benefits, it comes with the risk of multiple points of failure for a connected Web business.

(In 2006, MacAskill wrote a post detailing why S3 is a good choice for his business.)

As the major television news stations reported on the sudden death of one of modern times’ most respected journalists, similar coverage unfolded simultaneously online. The people participating in this new form of real-time reporting didn’t sit in anchor chairs in front of millions of viewers. Today’s online coverage was composed of 140-character messages from ordinary people in front of computers and mobile devices around the world.

Many users of Twitter found posts from their followers announcing the death of NBC political analyst Tim Russert this afternoon in their Twitterstreams. As the news spread, the Twitter crowd mentioned some of their memories of election nights, whiteboards, and episodes of “Meet the Press”. People from all over the globe put aside their political differences and remembered their favorite moments of a great reporter.

As the tweets came flowing in, a new type of memorial formed at conversational tracking sites like Summize. A search for “russert” revealed a broad compilation of announcements, emotions, and well wishes. A real-time anthology of reactions evolved as more Twitter users learned of Russert’s passing.

Maps of 100 recent Twitter users who posted about Tim Russert today. Images created with the Summize, Twittervision, and Google Maps APIs.

Now, just hours after the first announcement of Russert’s death, hundreds (if not thousands) of people around the world have joined an impromptu community and contributed to this new form of spontaneous memorial. It’s a fitting tribute for a journalist by those who watched and respected his insight.

There’s been quite a bit of discussion over Apple’s decision to ban iPhone SDK applications from running in the background.  I found a link to a great argument by Hank Williams in favor of background processes on a post (”The Flip Side of the Multitasking Argument“) over at John Gruber’s Daring Fireball.  In it, Williams mentions that “with location aware devices we can broadcast not just ‘presence’ but location.”

With a device so personal, would you want to allow background applications to broadcast your exact location or status? For me that’s an action I would want to explicitly allow, and that permission would most likely come in the form of actively running the application in the foreground.

I realize the argument may venture be on the borderline of Orwellian paranoia, but there are new considerations that have to be made for such smart mobile devices.