Evolving Amazon's services into products

The announcements from Amazon Web Services LLC just keep on coming. The latest news flash is FBA (Fulfillment by Amazon), which will make Amazon’s warehouse, its customer service, and its pick, pack, and ship machinery available to sellers.

Free IT resource Hear how top CIOs turn change into a competitive advantage. Sponsored by HP Free IT resource Attend the SOA Executive Forum: Breaking SOA Bottlenecks SOAExecForum.com/may2007 Sponsored by InfoWorld

The million-plus merchants on Amazon’s platform are the obvious first customers for this new service, but as Amazon CTO Werner Vogels noted on his blog, it isn’t limited to products sold on Amazon.com. Anyone for whom the price is right will be able to outsource fulfillment to Amazon.

The blogosophere, already wowed by Amazon’s other services, tipped its collective hat when it heard about the new fulfillment program. And it wondered aloud, “What are they putting in the water up in Seattle?”

Amazon CEO Jeff Bezos addressed that question in a keynote at the MIT Technology Review’s Emerging Technologies Conference. Fully 70 percent of the effort required to do business online involves doing the heavy lifting that supports Web-scale applications, he said. After a decade of training, Amazon got really good at pumping iron, and now you can hire its muscle to do some heavy lifting for you.

Back when the Web services stack was starting to come together, and before SOA (service-oriented architecture) had emerged as a buzz phrase, the notion of services-as-products was a popular bull-session topic. First, you’d wrap service interfaces around your business processes to achieve internal consolidation and reuse. Then you’d find customers who would want to rent those services from you.

That’s no longer a hypothetical scenario for Amazon; it’s a real experiment. As we watch it unfold, we’ll all deepen our understanding of what SOA can mean and how services can evolve into products.

It’s interesting to note that while the term Web services is enshrined in the name of Amazon’s new subsidiary, the so-called WS-* stack is not really central to the developer’s experience. EC2 machine images, S3 objects, and MTurk tasks are all controllable using SOAP APIs, it’s true. But in the latter two cases you can as easily control things REST-style, by firing off HTTP GET requests.

These services aren’t defined narrowly according to their use of XML, HTTP, REST, SOAP, or WSDL; instead, they represent a broad set of network-based capabilities: storage, computation, intellectual piecework, and fulfillment. Some (S3, EC2) live entirely in the machine world. But others (MTurk, FBA) ascend into the realms of knowledge work and supply chains. At this level, the long-sought marriage of IT infrastructure and business process can finally be consummated. It’s not hard to grasp the business value of these kinds of infrastructure services. They’re just well-understood pieces of the existing business.

As they also become new businesses in their own right, though, new requirements will emerge. MTurk, for example, was invented to solve Amazon’s own data-cleansing problems. Now that third parties are building MTurk-enabled businesses, they’re facing different problems that spawn new requirements. 

In an interview following his talk, I asked Jeff Bezos about the tension between satisfying internal and external requirements. That’s a good problem to have, Bezos said. And he’s right. Anyone can repackage internal services and try to sell them. Evolving those services into broadly useful products is both a harder challenge and a greater opportunity.