Jeff Barr, Amazon's web services evangelist, explained to XML 2003 attendees the decisions facing Amazon in opening up their systems for public use via web services. Barr's case study, delivered to a full room, formed part of the product presentations track on the first day of the conference.
Barr set the scene by outlining the various groups that Amazon's customers fall into: buyers, sellers (merchants who sell on Amazon's platform), web site owners (associates), and developers (people who use Amazon's web services.) Amazon's associates scheme has been very successful: founded in 1996, it now has over a million registered associates. This success augured well for the uptake of Amazon web services.
As Amazon's systems developed, they developed in the direction of interoperating feature components inside the firewall; e.g., the catalog, shopping cart, and personalization engine. Through their web services platform, Amazon is beginning to open these features up to public use, and Barr said they have ambitious plans to expose much more functionality.
So how did Amazon arrive at the decision to provide web services? One of the main drivers was that its partners needed better data access -- some major ones had XML data feeds, others simply scraped Amazon's web pages -- so the process of collaboration was both expensive and brittle. A move to defined and reusable web services was thus a logical solution.
|
Related Reading 
Amazon Hacks |
Amazon's aims in providing web services were, according to Barr, to support industry standards, provide remote access to data and functionality, decouple their data from its presentation, create a software development platform, unlock creativity from collaborators, and realize more benefit from their internal development investment. Particularly key for Barr, previously employed in Microsoft's developer tools division, is the aspect of creating a development platform, in much the same way as traditional software vendors do.
Considerations for Providing Web Services
Barr then outlined the various issues Amazon considered in the web service deployment, as well as their resolution. The first of these was revenue -- should Amazon pursue web services as an experiment or with the intention of generating revenue? Building on the success of their associates and sellers, Amazon decided to pursue revenue, building on the relationships with these two groups in the first instance. It seems that the choice to do this was key, as it provided a real-world customer base driving their design decisions.
The second issue to consider was that of licensing. In order to create conditions for success, the terms needed to protect the rights of both the developers and of Amazon itself. While providing a degree of openness in order to foster creativity and adoption, the license needed also to sustain Amazon's business model. Practical issues include ensuring data freshness and preventing excessive server load. These needs were met with licensing constraints including one API call per second, a ban on reselling data, storing non-price relevant data for 24 hours maximum and pricing data for 1 hour maximum, and a mandatory link to amazon.com.
The next issue was that of protocols. Should they support SOAP or XML over HTTP (that is, REST)? In the end Amazon provided both and let developers make the choice. Despite it being the "standard", only about 15% of Amazon web services calls are made with SOAP, the remainder with REST.
The fourth issue was to consider how to create a software platform for developers. This was addressed by borrowing best practices from the regular software world: document the APIs, commit to API stability, and provide backward compatibility across API revisions.
The final consideration for Amazon in deploying its web services was developer support -- how to help developers to succeed with the API. Amazon use a combination of a discussion board, weekly developer chats, a regular newsletter, frequent releases of the software development kit, and an online FAQ. Being responsive and open to their developer community has worked well for Amazon.
Barr's talk provided many good pointers for large businesses considering opening themselves to greater programmatic interaction with developers. Amazon's decisions certainly seem to have set them on a course for success. Perhaps the best mark of this success and future promise is that Amazon is increasing the size of its internal team by five times for 2004.
Did you attend this XML 2003 session? Post your comments on the talk in our forum.
(* You must be a member of XML.com to use this feature.)
Comment on this Article
| Titles Only | Full Threads | Newest First |
- SOAP Bloat and poor uptime
2003-12-11 07:48:17 Rich Z [Reply]
I've mainly used the Amazon merchant platform and I can honestly say that it's the biggest piece of junk I've ever seen. I will admit that the thought and design that went into the merchant side is really amazing, but it just doesn't work.
The merchant platform allows me as a merchant to post my products/prices/inventory/images etc., to the amazon site on a daily basis via XML/SOAP. It also enables me to get orders on their system that are placed for my product. But the system is set up to facillitate both very large and very small businesses, which means the system doesn't do a very good job at servicing either. For instance, they don't want or care about UPC info for products, they only want to know the SKU. Well, that's great unless you're talking about something with both sizes and widths (like shoes, pants, etc.) because then the SKU might not be a unique identifier. The UPC always is unique for a product. So, then what happens if another merchant selling completely different product has the same SKU as you? You guessed it, both of your products wind up being garbage on the site.
And since about black friday on this year, their uptime for receiving SOAP requests has been about 50%. Not very stable. SOAP works great except when one side is down. I recognize that all shopping sites experience load at the holidays but how many years have they been doing this? Did they just forget that traffic would be high now?
It drives me nuts that they spend so much time and effort talking about how great their associates program is working, meanwhile all of us high profile merchants that have signed on with them are just blowing in the wind. The whole web services concept seems to be just a toy to them and not a legitimate business process, because they certainly don't treat it as such.
In case you're wondering, I work for a major department store chain that's been featured on the amazon site for about a year now.
