Lee talks about this evolution in an interesting interview on Software Engineering Daily: Scalable Architecture with Lee Atchison, about Lee’s new book: Architecting for Scale: High Availability for Your Growing Applications.
This is a topic Adrian Cockcroft has talked a lot about in relation to his work at Netflix, but it’s a powerful experience to hear Lee talk about how Amazon made the transition with us having the understanding of what Amazon would later become.
Amazon was running into the problems of success. Not so much from scaling to handle the perspective of the request, but they were suffering from the problem of scaling the number of engineers working in the same code base.
At the time their philosophy was based on the Two Pizza team. A small group owns a particular piece of functionality. The problem is it doesn’t work to have hundreds of pizza teams working on the same code base. It became very difficult to innovate and add new features. It even became hard to build the application, pass the test suites, and deploy the software.
The solution: move to a Service Oriented Architecture (not microservices).
Organizing around services allowed individual teams to truly own the code base, the support responsibility, and top to bottom responsibility for the functionality.
The result: a dramatic increase in innovation and the ability to grow. After a while, the Amazon retail site grew with a constant stream of new capabilities. Maybe too many 🙂
The process requires a culture shift, really more of an ownership shift, from being part of a larger group to be an entity of its own that has responsibilities outside of its group as well as responsibilities inside the group.
While the strategy of consciously exploiting team organization as a means of speeding up product development and encouraging innovation is not a new idea now, in the early 2000s it would have been one ballsy move.