Payne Points

A couple days ago, one of our long term clients (“Adrian”) came for a visit to our New York offices. He is the operations manager for one of the more successful deal aggregation sites. We were fascinated to hear how he was leveraging Amazon’s AWS “spot pricing” for their service. I had seen this option in the past, but didn’t really understand its benefit.

Defining AWS Spot Pricing

Since Amazon has such a large pool of resources available, there are times when many of these resources go unused. This is very similar to what happens in the hotel industry and electricity delivery. While electrical power usage patterns are fairly regular and your electric company can charge different day and night rates, the hotel (and AWS) usage patterns are less predictable (or “spotty”). Rather than have these resources go unused, Amazon offers greatly reduced rates to encourage people to use these available resources. For those who can take advantage of this, it is a huge financial benefit. (In some scenarios, the price difference is 90% off.)

The Right Price is the Right Time

At Adrian’s company, they use spiders to search the web for deals. It turns out that they don’t need to do this all day long. This is a process that can wait until the spot prices on AWS are advantageous.

When the prices are low, Adrian spools up a spider and lets it run.

If the price rises, he shuts down the spider and waits for a good price again.

Since the process of searching the web can be highly parallelized, he can spawn many machines when the price is right.

Once all of the deals are found, they send email alerts to their users. Again, there is no specific time that they must email users (although they seem to prefer the morning). Now Adrian monitors AWS for the best time to spawn his email servers. They come up, do their thing, and are returned to the pool once they complete their job. Very cool stuff. (I have heard of vendors selling this capability as a “future use case” for cloud computing, so it is exciting to see that some people are already doing it!)

Monitoring Elastic Resource Pools

While Adrian could use AppFirst for actually monitoring the AWS pricing and send an alert when the price is right, the real magic is in how he uses AppFirst to monitor his highly elastic resource pools.

AppFirst has a concept called “applications.”

An application is basically a fingerprint for a process (or group of processes) running in your environment. The definition could be as simple as “spider.exe” or include a complex combination of file paths, process names and command line parameters.

This pattern can then be applied to all of the servers in your environment (or a “server set” if you want to limit the scope). Once applied, users can then report on the aggregate performance of these processes across all of the servers. Metrics like “network in,” “network out,” and “total memory” are pretty interesting over time for troubleshooting and capacity planning.

The beauty of this is since we are only focused on the processes that match the pattern, the number of servers included can vary from measurement to measurement. This means that as the number of spider servers or email servers grow and contract, we can automatically keep track of the aggregate metrics.