Metered Web services

Amazon’s new simple storage service, S3, burst on the scene a few hours before I had to hop on a plane. There was enough time to sign up for an account, download and run some sample programs, snag the documentation, and take the pulse of the blogosphere. But now, Wi-Fi-less at 35,000 feet, I can’t connect my laptop to the S3 data cloud in order to try out some of the ideas it has sparked. Frustrating!

By now you’ve heard the pitch: Amazon is offering metered storage for blobs of data in quantities ranging from 1 byte to 5 GB. S3 provides a simple key/value store, like the ever-popular Berkeley DB, but it operates purely as a service and at Internet scale — albeit without locking or transactional features. Objects can be world-readable or governed by a range of access controls. REST (Representational State Transfer) and SOAP APIs are provided, along with wrappers in a variety of popular languages. Pricing is aggressive for storage, somewhat less so for data transfer. Amazon’s commerce engine handles the billing.

An especially nice touch is the capability to hook those objects directly into the BitTorrent network, in order to lower the cost of distributing popular content.

Another handy feature is time-limited access. As a developer you can provide access to an object using a signed URL that expires at a time of your choosing. Anyone can access it until then. Afterward, it’s gone.

Initially S3 seems to be a Rorschach inkblot onto which developers are projecting their own interests and inclinations. Is it a remote hard drive for personal or corporate backups? A scalable, reliable, and maintenance-free platform for hosted content? A way to share data among cooperating services? A decentralized object database?

S3 could well live up to any or all of these possibilities, but one thing’s for sure: It most emphatically isn’t yet another advertising-supported Web application. There’s no customer face at all; it’s just storage for Web developers to use. And that’s incredibly refreshing. If I’m going to be using more and more Web applications, as I surely will, I don’t want to pay providers to suppress ads. To me that feels like paying farmers not to grow corn. Nor do I want to see ads popping up in every document and spreadsheet. I’d rather invest directly in QoS.

More generally, I’d like to find out whether metering infrastructure services in this way will prove technically and economically viable. When we talk about a grid of Web services, we like to compare it to the power grid, but the analogy is deeply flawed in at least one way. My electric bill isn’t itemized. I don’t know what it costs me to run each of my appliances, or how long it will take to amortize the cost of replacements. Lacking this feedback, we make poor individual decisions that, collectively, add up to a tragic misallocation of resources.

Creating what’s called the “energy web” — a marketplace where smart producers and consumers of power exchange price signals in real time — will require a massive overhaul of our legacy power grid. There’s just no way for us to start from scratch. But in the realm of Web services, we’re just now building the grid. Given a clean slate, perhaps we can figure out how to aggregate demand, meter usage, and value services for what they do rather than just for the eyeballs they attract.