 | |||
|
|
||
| |||
| |||
| |||
|
||||||||||||||||||||
| |
|
Home > SOA All-in-One Guides > SOA Implementation > SOA Runtime > Lessons learned > SOA creates order out of chaos @ Amazon |
| |
|
|
|
||||||||
| All-in-One Guides: SOA Implementation: |
|
|||||||||
|
||||||||||
|
||||||||||
|
||
|
SOA Runtime
 Lessons learned
|
|
| |
|
|
| |
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
San Diego – For architects who believe detailed advanced planning will be the key to a successful SOA implementation, an alternative approach is offered by Werner Vogels, vice president, world-wide architecture and CTO at Amazon.com.
"Amazon does a lot of research, but we don't call it research, we call it development," Vogels said in a keynote at the opening the Gartner Inc. Enterprise Architecture Summit this week. He offered an almost anti-model for SOA development that includes hard work, failures, more hard work, successes and more hard work. He laced his presentation with tongue-in-cheek humor starting with the title: "Order in the Chaos: Building the Amazon.com Platform." Vogels pointed out that in 1995 when Amazon started with a simple Web ordering application running on a single server, the architecture was so simple it was literally drawn on a cocktail napkin. There was no grand plan to build an SOA platform that today features as many as 150 Web services on its home page alone. The massive online retail Web site evolved from a modest attempt to sell books on the Web, into this year's version that hosts 1 million merchant partners ranging from small used book stores to Target Inc., which in virtual retailing is now bigger than Wal-Mart, Vogels said. "We more or less naturally became a platform," Vogels said of the technological evolution. In a brief history of Amazon's technology, he showed how one server for databases of customer information and inventory grew to two servers, one for customer info and one for inventory. As the business got bigger with more customers and more products, more and more database servers were added. When database performance became an problem, a fast talking salesman told Amazon to buy a mainframe. Big iron did not prove to be the answer, a technology misstep that still leaves Vogels chagrined. "This is an Internet company in 1999 and we bought a mainframe," he said. When it failed to meet the scalability, reliability and performance needs after a year, Amazon pulled the plug on that hardware. Vogels said there is a lot of talk about what is the "secret sauce" that makes Amazon so popular. In his opinion, "The secret sauce is operating reliably at scale." To serve its 60 million customers and keeping them all happy requires scalability and reliability, that may go beyond what most SOA developers and architects need to factor into their platforms, Vogels said. For example, while most customers may feel they're buying a lot of stuff if they have 20 books and gadgets in their online shopping cart, he said Amazon has to be prepared for the one customer in 60 million with 20,000 items in their shopping cart. After the mainframe debacle in 1999, Amazon reached the point around 2001 where the only way to achieve the reliability and scalability it needed was to use Web services to insulate the databases from being overwhelmed by direct interaction with online applications. "We were doing SOA before it was a buzz word," the Amazon CTO said. Unlike most speakers at analyst conferences, Vogels doesn't mince words as to whether SOA is a good strategy or a workable theory. Upfront, he told his audience "Service orientation works." For all the talk of how Amazon is succeeding with blade servers running Linux, the CTO says, "We never could have built that platform without service orientation." Giving a glimpse into how the developers at Amazon are organized, Vogels said it involves teamwork. Each Web service has one team of developers responsible for it. And they are not just responsible for writing the service and then tossing it over the wall for testing and eventual entry into production where some poor maintenance geek has to look after it. The Amazon CTO tells his Web services team members: "You build it. You own it." That means the team is responsible for its Web service's on-going operation. If a Web service stops working in the middle of the night, team members are called to fix it. This policy that there is "no wall at the end of development" encourages developers to make their Web services as bulletproof as possible.
Since complexity is notoriously the enemy of reliability, Vogels encourages developers to keep their Web services simple. "Simplicity is the hardest design criteria," Vogels said. "Designing a service we ask constantly: Is this the simplest service we can build?" Another design criterion the chief technology officer emphasizes is not getting attached to any one technology or standard. Amazon developers start with what the customer needs and then work back to what technology will work for them, Vogels said. This includes the implementation of Web services standards. If one retail partner wants to use SOAP and another wants to use Representational State Transfer (REST), they each get the standard they request. "Our developers don't care if it's REST or SOAP," Vogels said. "It's all about customers."
|
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
About Us | Contact Us | For Advertisers | For Business Partners | Site Index | RSS |
|
|
||
|
|||||||
