Programming Amazon Web Services

Thinking Like Amazon

Before you start building applications based on AWS, it is worthwhile to consider the thinking behind these services. What were the key goals that lead Amazon to build the services in the first place? And how did these goals influence the design and implementation of the services?

Initially, the AWS infrastructure services were not conceived as products to be sold to developers external to Amazon but were instead designed to meet specific needs within Amazon’s own internal systems. It was only later that these services were opened up to the public. The key implementation details of the services are therefore intended primarily to serve Amazon’s needs and will not necessarily use the methodologies or techniques common in the rest of the industry. Appreciating the reasoning behind the architectural decisions and their implementation details can help you to adjust your expectations for the services. This, in turn, will make it easier to design applications that work well with the services’ capabilities.

Amazon’s services are designed to power the Amazon.com web site and related partner applications. The services operate as small component cogs in a large service-oriented architecture (SOA). Each service performs a specific task as simply and efficiently as possible, while the strengths of many different services are combined as required to perform complex processes and build the rich Amazon.com web pages with which we are familiar. Amazon’s SOA has been developed over many years of hard-won experience to be highly scalable to meet growing demand and be highly reliable despite the inevitable hardware and network failures that will occur in such an environment.

The AWS infrastructure services we will examine in this book were designed to fulfill specific tasks in this SOA environment. You will gain the most from the services with the fewest headaches if you design your applications to work like Amazon’s. Instead of taking the traditional approach of building a system with the expectation that everything will work as expected all the time, and that problems will be so rare that you can deal with them as an afterthought, you need to accept from the start that failures will occur, and you should design your application to deal with them. For example, you should aim to build application components that can recover from temporary network glitches, gracefully handle error conditions, and restart quickly. Try to avoid creating architectural bottlenecks that are single points of failure. Instead, share the work burden between multiple components in a service pool that can be expanded or contracted in response to demand, and ensure that each component in the group can be easily replaced.

With the right mindset, you can take full advantage of the AWS infrastructure and build your own applications that, like Amazon’s, are scalable, reliable, and cheap to run. If you do not embrace this chaotic and contingency-based approach, or if your application simply does not fit this model, you may end up fighting the AWS infrastructure every step of the way.