This article is a short summary on the interview with Werner Vogels, who is the CTO of Amazon.com.Please refer to http://queue.acm.org/detail.cfm?id=1142065
how has Amazon’s technology evolved over the past five years?
Growth is core to Amazon.com’s business
strategy, and that has had a significant impact on the way we use technology. The impact has been on many
areas: larger data sets, faster update rates, more requests, more services,
tighter SLAs (service-level agreements), more failures, more latency challenges,
more service interdependencies, more developers, more documentation, more programs,
more servers, more networks, more data centers. A large part of Amazon.com’s
technology evolution has been driven to
enable this continuing growth, to be
ultra-scalable while maintaining availability and performance.
From a two-tier monolith to A fully-distributed, decentralized,
services platform
Amazon.com started 10 years ago as
a monolithic application, running on a Web
server, talking to a database on the back end. This application, dubbed Obidos,
evolved to hold all the business logic, all the display logic, and all the
functionality that Amazon eventually became famous for: similarities, recommendations,
Listmania, reviews, etc.
There were many complex pieces
of software combined into a single system. It couldn’t evolve anymore.
The parts that needed to scale independently were tied into sharing resources
with other unknown code paths. There was no isolation and, as a result, no
clear ownership.
At the same time, there was continued difficulty in the back-end database scaling
effort. Databases—and by that time we were using several databases—were
a shared resource, which made it very hard to scale-out the overall business.
For us service orientation means
encapsulating
the data with the business logic that operates on the data, with the only access
through a published service interface. No direct database access is allowed
from outside the service, and there’s no data sharing among the services. Over time, this grew into hundreds of services and a number of application
servers that aggregate the information from the services.
The big architectural change that Amazon went through in the past five years
was to move from a two-tier monolith to a fully-distributed, decentralized,
services platform serving many different applications.
what you’ve learned from this?
- strict service
orientation is an excellent technique to achieve isolation; you come to a level
of ownership and control that was not seen before
- by prohibiting direct database access by clients, you can make scaling
and reliability improvements to your service state without involving your clients
- If you want to be able
to aggregate services easily, if you want to insert advanced infrastructure
techniques such as decentralized request routing or distributed request tracking,
you need a single unified service-access mechanism.
- The services model has been a key enabler
in creating teams that can innovate quickly with a strong customer focus. Each
service has a team associated with it, and that team is completely responsible
for the service—from scoping out the functionality, to architecting it,
to building it, and operating it.
- Giving developers operational responsibilities
has greatly enhanced the quality of the services, both from a customer and
a technology point of view. The traditional model is that you take your software
to the wall that separates development and operations, and throw it over and
then forget about it. Not at Amazon. You build it, you run it. This brings
developers into contact with the day-to-day operation of their software. It
also brings them into day-to-day contact with the customer. This customer feedback
loop is essential for improving the quality of the service.
How many of the current buzzwords, such as SOA, WSDL, SOAP, WS-security,
are relevant to you?
-
The first
category is the services that make up the Amazon platform. There we use interface
specifications such as WSDL, but we use optimized transport and marshalling
technology to ensure efficient use of CPU and network resources.
- The second category is the interface with our retail partners, which has strict
descriptions for XML feed processing, service interfaces, etc., and where we
leverage as many standard technologies as possible.
- The third category is our public Amazon Web Services, which builds on the platform
services and provides REST-like as well as SOAP interfaces. If we look at how
developers use these interfaces, in general the REST version is used by small
libraries in Perl or PHP as part of a LAMP stack, and the SOAP calls are mainly
done by applications that have been built on Java or .NET platforms by consuming
our WSDL files and generating proxy objects.
What about tools? Are you using Eclipse and Visual Studio
as your dev environments?
Developers of our services can use any tools they see fit to build
their services. Developers themselves know best which tools make them most
productive and which tools are right for the job.
posted on 2009-04-11 21:27
Justin Chen 阅读(838)
评论(0) 编辑 收藏 所属分类:
Web Architecture