Computing delivered across the wire at the flick of the switch, just as predictably and effortlessly as we already receive electricity, telecoms and water. Ever since computer science academic Martin Greenberger first posited the notion of an 'Information Utility' in a May 1964 article for Atlantic Monthly, computing goliaths and telecoms giants alike have dreamt of fulfilling this alluring vision, and yet none have come anywhere close to making it a reality. Is it conceivable that in the end a dot-com retailer will beat them to the punch?
I described yesterday how Amazon Web Services (AWS) delivers computing infrastructure servicesAWS has to appeal to developers working for real companies, large and small including storage and message queuing on a commercial basis, and bills customers in direct proportion to usage. There's no minimum usage level and no barrier to entry: anyone can open a developer account and begin using the services, which are accessed using a simple programming call to a web services interface. This is the IT utility brought to life.
The crucial difference from the original vision is that the utility isn't delivering the final application, it merely offers slices of infrastructure that developers incorporate into their own applications. Some technology visionaries believe that's what makes it so significant. Here's what John Musser at programmableweb wrote in response to the release of Simple Queue Service (SQS) last month:
"With 'simple' but useful and reliable services like Simple Queue Service and the Simple Storage Service Amazon is building genuine foundational components for the internet operating system."
"Like S3, SQS is an extremely general-purpose service offering that will undoubtedly be used in ways nobody can predict ... Amazon's S3/SQS duo is a green field that invites entrepreneurs to think way outside the box."
These IT utility services are perfectly pitched to appeal to developers engaged in all the creative experimentation of Web 2.0, with one tiny rider: unlike most Web 2.0 APIs, these are ones you have to pay to use (see yesterday's companion post, Amazon: monetizing Web 2.0 with ... money). They're not for mashup hobbyists. Anyone depending on them without having their own monetization mechanism in place from the get-go runs the risk of being bankrupted the moment their mashup gets the attention of the crowd.
Put it another way: these services are targeted squarely at businesses. So if AWS is going to fulfil its mission of earning substantial revenue and income for Amazon, it has to appeal to developers working for real companies, large and small. That's certainly the way Amazon has designed its services, as Adam Selipsky, VP product management and developer relations for AWS explained to me when we spoke last week:
"We've built our services to be very horizontal and flexible enough to be used in many different ways. [SQS] is certainly flexible enough and stable enough and scaleable enough to be used in enterprise applications. It's also applicable to a whole swathe of small businesses and entrepreneurs."
So can it appeal to the enterprise? One stumbling block that I've noticed is the lack of any kind of service guarantees. Amazon doesn't publish an SLA. The line is that these services are part of Amazon's own infrastructure, and if they're good enough for Amazon, they ought to be good enough for other customers. Amazon is itself a consumer of both the S3 and the SQS services and, according to Selipsky, it doesn't get preferential treatment — AWS provides the same level of service across the board. "Amazon does use these services internally. They have to meet Amazon's highly aggressive performance expectations."
Indeed, part of the marketing pitch for these services is that they allow AWS customers to punch with Amazon's infrastructure weight: "We absolutely want to help developers of all sizes to look and feel like they are Amazon," Selipsky told me.
That remark suggests that the core target market is smaller companies, with Amazon presenting itself as giving a helping hand to the little guys. Certainly the use cases for SQS that Selipsky cited were relatively simple: receiving the results of filling in a form on a web page and passing them to a server to process, or acting as an intermediary between clients and servers in an AJAX application. But as I mentioned last month when I wrote about Amazon and Microsoft in mashup pact, there's also an add-in that will link SQS into applications written to Windows Communication Foundation (WCF), the web services plumbing in Windows Vista.
The truth is that Amazon doesn't really know what uses people will find for its services and therefore it can't say what its market will be until it sees what people come up with. I can see parallels with a 128k hobbyist microcomputer that a large computer company introduced twenty-five years ago called the IBM Personal Computer. It was targeted at small businesses and hobbyists and was expected to sell just a hundred thousand units or so. Instead, it sold millions and spawned an industry. Sometimes the stuff you build for the little guys turns out to be just as useful for all the big guys too.