SLA's for Web Services?

On Friday, Amazon's S3 online storage service went down for awhile. Many different online services now use S3 as a way to distribute content and store media online, and everywhere S3 is used - things didn't work for awhile this morning.

Is this an unacceptable failure of an automated business process? Or should we just accept it as the normal behavior for the web? Clearly a service like 37s Basecamp can't ensure that S3 stays up, because they have no control over any of Amazon's services. But their paying customers were nonetheless compromised when Amazon's service went down.

Wikipedia defines a Service Level Agreement as an agreement between parties that defines a "level of service" in terms such as percentage of uptime, power uptime etc. It has its roots in agreements between telecom companies and their corporate customers.

As more and more mission critical business is moved over to online services that themselves may outsource functionality to other parties, the question of reliability comes up. Where is the assurance that the third party will be there when you really need them? It was these kinds of questions that led to SLAs in the first place.

SLA-backed web services could be viewed as premium - something that you pay an additional amount, in order to ensure that the vendor is investing in the infrastructure to ensure the required level of service. Vendor's could look at SLA-backed service as a potential profit center.

Its the Integration, Stupid

For awhile now I've talked about WAX - web application exchange. A number of people took this to mean thick-client, or desktop, apps that integrate with an Internet-based service.

That's not exactly it - I recently signed up for a service called Sandy. This fairly amazing online service allows you to send yourself reminders to do things - to keep yourself organized. It's pretty slick.

But the thing that really makes it go is the integration. Sandy speaks SMS, email, Twitter, Jott. There's so many different ways to get those reminders in and out. Reminders to do things at specific times come with .ics (iCalendar) files so I can add them to my calendar.

Set up is a breeze - each means of communication is verified by Sandy sending a message containing a special code that you enter back at the Sandy application. Successful entry of the code activates that means of communication.

(Honestly I probably have too many channels turned on at once. A single reminder is now going to come at me as an email, an SMS message, and a Tweet. Its going to drive me crazy.)

All of this integration allows me to leverage all of the other tools that I already use. This is extremely powerful. Now instead of relying on one application to do it all (badly), application developers can concentrate on the things they do best, and work with each other to deliver a value to the user that is greater than the some of its parts. Because of the Web Application Exchange. WAX.

This is something to pay very close attention to, and to understand how it follows a well-established pattern in technology. As a technology matures, it moves from tightly integrated proprietary generalists (building, for example, yet another social network from scratch) to focussed application developers that add their own core value to an already existing infrastructure.

WAX in the Wild: Flickr Export

Connected Flow makes a Flickr Export plug-in that allows you to export directly from your photo application to your Flickr account. This let's Flickr be the provider of photo sharing services, and allows you to access it directly from your photo management application. They build plugins for both iPhoto and Aperture.

The New Application Developers

The dirty secret of social networking website development so far - how do you actually get people on the site? In the past the path has been treacherous at best, consisting of a fair amount of traditional-style promotion and PR.

Now, major social networking sites such as FaceBook are presenting APIs. More than just surface integration, these APIs allow you to treat the social networking sites as platforms, meaning you can become a third-party application developer. Suddenly a lot of opportunity appears.

As is detailed here, anyone can write an application for Facebook that pulls information from a user's profile, including preferences, his network, friends etc. Users are, by default, encouraged to spread applications virally, and the better applications take advantage of the user's network.

Suddenly there is a viable alternative strategy to bootstrapping your own social network. You can simply build applications for Facebook, or other established social networks, and use their critical mass to hook into whatever you offer as a unique value. Of course the more of a purple cow you are, the more traction you'll gain.

Its amazing how full-circle this is. Suddenly web developers become like desktop application developers in the 80s and 90s, looking at their apps and deciding which platforms they want to target. Should we make a version for Facebook, LinkedIn and MySpace? Well, which is our target market? Hm....

WAX in the Wild: Ebay Desktop

The new Ebay Desktop is built with Adobe Air and presumably communicates with Ebay via web services or some similar mechanism.

Wax in the Wild: PackRat

This is a classic WAX app - its a front end for 37 Signals BackPack, it has an offline mode, and to enable that it has sync. You can find it here.

It points down to the basic elements of WAX.

• A rich client front end.
• A web service with an API.
• State synchronization between the client and the server.

PackRat is a great example of that.

WAX in the Wild: Jing

A little while ago I talked about WAX - a new kind of application that combined the best parts of desktop and web applications. Well, via MacBreak Weekly I discovered a great little WAX app called Jing, made by TechSmith.
In a nutshell, Jing lets you take screenshots and desktop video and then easily and automatically share it on ScreenCast. The whole thing is currently designated a pilot project, meaning that its totally free.
There are really a number of options open to them for a business model, if they decide to go forward with Jing as a product. They could charge for the software. Images and video posted to ScreenCast could be associated with an advertising payload, making it a Google-type media initiative.