Smugmug says Amazon EC2 is not Slower than they Advertise - it just Depends on How you Define a GHz

All GHz aren’t created equal.

Who knew? Here's a good read backed by real numbers by one of the most notable Amazon customers Smugmug, not by people complaining in the forums. 

The Future Just Called...

I had a written a post back in November about how the New York Times converted 11 million old articles to pdf in under 24 hours using Amazon EC2, S3 and Hadoop and then I came across a post today that had this to say about it:

The future just called and wanted to explain how "supercomputing" was actually going to work.

Amazon S3 Goes Down for 3 Hours

Amazon's Simple Storage Service (S3) had it's first major outage in years going down for 3+ hours and taking down 1000's of web 2.0 sites with it. Many new companies rely on Amazon's services to run their business so when Amazon goes down, they go down (myself included).

There is a big thread that you can read about it on the AWS forums and see Amazon's Post Mortem response:

Here’s some additional detail about the problem we experienced earlier today.
Early this morning, at 3:30am PST, we started seeing elevated levels of authenticated requests from multiple users in one of our locations.  While we carefully monitor our overall request volumes and these remained within normal ranges, we had not been monitoring the proportion of authenticated requests.  Importantly, these cryptographic requests consume more resources per call than other request types.
Shortly before 4:00am PST, we began to see several other users significantly increase their volume of authenticated calls.  The last of these pushed the authentication service over its maximum capacity before we could complete putting new capacity in place.  In addition to processing authenticated requests, the authentication service also performs account validation on every request Amazon S3 handles.  This caused Amazon S3 to be unable to process any requests in that location, beginning at 4:31am PST.  By 6:48am PST, we had moved enough capacity online to resolve the issue.
As we said earlier today, though we're proud of our uptime track record over the past two years with this service, any amount of downtime is unacceptable.  As part of the post mortem for this event, we have identified a set of short-term actions as well as longer term improvements.  We are taking immediate action on the following:  (a) improving our monitoring of the proportion of authenticated requests; (b) further increasing our authentication service capacity; and (c) adding additional defensive measures around the authenticated calls.  Additionally, we’ve begun work on a service health dashboard, and expect to release that shortly.
Sincerely,
The Amazon Web Services Team

Of course it's bad that this happened, but really not so bad when you think about it. How fast could you recover your own database and servers when they go down? And we all know, things go down at some point or another. And since Amazon puts out the fires, you get to keep more of your hair.

via: InfoWorld

Amazon Drops the Price for Simple Queue Service (SQS), but there are some Caveats

Amazon announced a new pricing model for their Simple Queue Service (SQS) today which looks much more reasonable than the old system.

Here are the pricing changes:

Previous Price (prior to February 6, 2008)

Messages

$0.10 per 1,000 messages sent ($0.0001 per message sent)

Data Transfer

$0.10 per GB—all data transfer in
$0.18 per GB—first 10 TB / month data transfer out
$0.16 per GB—next 40 TB / month data transfer out
$0.13 per GB—data transfer out / month over 50 TB

New Price (effective February 6, 2008)

Requests

$0.01 per 10,000 Amazon SQS requests ($0.000001 per request)

Data Transfer

Data transfer rates are unchanged. However, because many customers want to use Amazon SQS in conjunction with Amazon EC2, all data transferred between Amazon EC2 and Amazon SQS is free of charge.

So to get the benefits, you should use EC2 to get the free data transfer and second, poll the queue as little as possible (throttle back if the queue is empty and pick it up when there's stuff in it again).

Message Retention Time Changes

The message retention time has DECREASED from 15 days to 4 days. This is not a good thing.

Message Size Changes

The maximum message size has DECREASED from 256 KB to 8 KB for both Query and SOAP requests. Seriously?

Number of Messages Received

They've DECREASED the maximum number of messages you can receive in one request from 256 to 10. So now you have to make 25 requests (which cost money) to get what you could have got out of 1 request.

Conclusion

I've always had a problem with how SQS was priced. I had planned to use it for a service that uses high volume queues locally, but the pricing is just off the hook and didn't make any sense. I'm not sure if the new pricing will make that better or worse, but they've also decreased the functionality quite a bit.

It almost sounds like they are trying to sunset this service.

In any case, you have 180 days to switch to the new API folks, so get on it. For the Java folks out there, Typica is your best bet.

Why Tier Based Architectures Don't Scale

Nati Shalom from GigaSpaces wrote an interesting piece on his blog about why tier based architecture's don't scale. Think "weakest link" and your half way there.

Read it here.

While it sounds like he has a good point, some real world examples would have been nice.