The paper begins with a problem that Amazon is facing with its current client-server architecture: applications access the database directly and are tightly coupled with the data model. This makes the application sensitive to changes in the underlying data layer – where and how data is stored.
It proposes two solutions: one, a move towards a service-oriented architecture, and two, to model processes as a workflow.
- Service-oriented architectures (SOA) might not seem groundbreaking, but it was a significant departure from thinking about applications in the two-tier client-server model.
- In retrospect, it's easier to see how microservices would evolve from the proposed three-tier architecture. Moreover, that thinking of data domains as services set the stage for thinking about infrastructure as shared services a decade later (AWS).
- Another interesting thread is the emphasis on workflows. While not as prevalent as SOA, thinking of distributed systems through the lens of a long-running workflow is still common today.
- Both workflows are services that emphasize the customer-centricity of Amazon – systems that existed to (1) deliver services to customers and (2) make it as easy as possible for internal developers to add new features and work together.
- The proposal anticipated the drawbacks to distributed state synchronization and solved them in ways that would generally resemble how we might architecture it today.