One of the most studied architecture
transformations occurred at Amazon. In an interview with ACM
Turing Award-winner and Microsoft Technical Fellow Jim Gray,
Amazon CTO Werner Vogels explains that Amazon.com
started in 1996 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.”
As time went by,
Obidos grew too tangled, with complex sharing relationships
meaning individual pieces could not be scaled as needed. Vogels tells Gray
that this meant “many things that you would like to see
happening in a good software environment couldn’t be done
anymore; there were many complex pieces of software combined
into a single system. It couldn’t evolve anymore.”
Describing the thought process
behind the new desired architecture, he tells Gray, “We went
through a period of serious introspection and concluded that a
service-oriented architecture would give us the level of
isolation that would allow us to build many software
components rapidly and independently.”
Vogels notes, “The big
architectural change that Amazon went through in the past five
years [from 2001–2005] was to move from a two-tier monolith to
a fully-distributed, decentralized, services platform serving
many different applications. A lot of innovation was necessary
to make this happen, as we were one of the first to take this
approach.” The lessons from Vogel’s experience at Amazon that
are important to our understanding of architecture shifts
include the following:
- Lesson 1: When applied rigorously, strict
service orientation is an excellent technique to achieve
isolation; you achieve a level of ownership and control
that was not seen before.
- Lesson 2: Prohibiting direct database
access by clients makes performing scaling and reliability
improvements to your service state possible without
involving your clients.
- Lesson 3: Development and operational
process greatly benefits from switching to
service-orientation. 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, building, and operating it.
The extent to
which applying these lessons enhances developer productivity
and reliability is breathtaking. In 2011, Amazon was performing
approximately fifteen thousands deployments per day. By 2015, they
were performing nearly 136,000 deployments per day.
Although not stated here, I think the progression
went from monolith to services as we speak about in the SOA
sense to microservices/DevOps. If that is accurate, then
there would have been a reuse period, and it would be
interesting to see what changes in thinking and implementation
they went through now that they are fully embracing DevOps.
Anyone have any insight or contacts we can trace
down?
Ken
------------------------------------------------------------------------------
Dr.
Kenneth Laskey
MITRE
Corporation, M/S H330
phone: 703-983-7934
7515
Colshire Drive fax: 703-983-7996
McLean VA
22102-7508