Chapter 7. Managing Your Decoupled System

Something of a congratulation is in order. We’ve been hard at work, but step by step, we are building a very robust Internet-scale application. We have used a lot of services offered by AWS to make our application better.

The result is that we have several big application components, all managed by their own teams. These application components are in themselves applications, using all the features introduced in Chapters 2 and 3—EC2 instances, RDS databases, ELBs, and Auto Scaling. But they are all glued together by S3, SQS, SimpleDB, and SNS.

These services are very robust and highly scalable, but we still want to know what is going on with our system. Especially in a distributed app like this, with disparate teams, it is very important to know what is happening.

There is no CloudWatch for these services, so we have to figure out how to get to these numbers ourselves. For this, we can turn these services onto themselves.


We have been calling the AWS services infinitely scalable, but with the disclaimer “for all practical purposes.” The question is, when do we reach the end of our practical purposes? That is one of the things we want to measure: the limits of buckets, queues, domains, and groups. These limits say something about the containers themselves.

The other things we want to measure are a bit more vague, and have to do with performance. Queues, domains, and groups do have unique performance characteristics. We want to know how information ...

Get Programming Amazon EC2 now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.