summary Case Study Evolutionary Architecture at Amazon $(2002)$

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 $20012005]$ 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.

USE THE STRANGLER APPLICATION PATTERN TO SAFELY EVOLVE OUR ENTERPRISE ARCHITECTURE

The term strangler application was coined by Martin Fowler in $2004$ after he was inspired by seeing massive strangler vines during a trip to Australia, writing, $$They seed in the upper branches of a fig tree and gradually work their way down the tree until they root in the soil. Over many years they grow into fantastic and beautiful shapes, meanwhile strangling and killing the tree that was their host.$$

If we have determined that our current architecture is too tightly$-$coupled, we can start safely decoupling parts of the functionality from our existing architecture. By doing this, we enable teams supporting the decoupled functionality to independently develop, test, and deploy their code into production with autonomy and safety, and reduce architectural entropy

As described earlier, the strangler application pattern involves placing existing functionality behind an API, where it remains unchanged, and implementing new functionality using our desired architecture, making calls to the old system when necessary. When we implement strangler applications, we seek to access all services through versioned APIs, also called versioned services or immutable services.

Versioned APIs enable us to modify the service without impacting the callers, which allows the system to be more loosely$-$coupled$$if we need to modify the arguments, we create a new API version and migrate teams who depend on our service to the new version. After all, we are not achieving our re$-$architecting goals if we allow our new strangler application to get tightly$-$coupled into other services $($e$.$g$.,$ connecting directly to another service$$s database$).$

If the services we call do not have cleanly$-$defined APIs, we should build them or at least hide the complexity of communicating with such systems within a client library that has a cleanly defined API.

By repeatedly decoupling functionality from our existing tightly$-$coupled system, we move our work into a safe and vibrant ecosystem where developers can be far more productive resulting in the legacy application shrinking in functionality. It might even disappear enti