Ok, so Amazon announced that you can now use your root domain to host static sites on S3, but should you?
Posts tagged with rackspace
Performance encompasses a lot of different metrics. In this example there are only a handfull that matter to me: CPU horsepower, Storage I/O, and Network Latency. In this post we’ll start with CPU.
Back in early December someone in #habari who knows that I’ve got an EC2 server asked me what I thought of them. When I told him I preferred my Rackspace Cloud Servers for a variety of reasons he asked me to enumerate them. The conversation that ensued covered a lot of ground and really made for a great blog post.
I’ve been playing with both the Amazon CloudFront and Rackspace Cloud Files CDNs over the past week with the eventual aim of offloading all the static files that make up this site (all like 4 of them) to a CDN, mainly for the fun of it.
Having used Amazon’s S3 storage service for quite a while now they were my first choice, but I didn’t want to totally discount the Rackspace offering - they’ve done some seriously cool things in a very short period of time and I swear by their Cloud Servers.
From casually playing around there have only been minor differences. First of all Cloud Files doesn’t seem to support “folders”, so you end up with a much flatter storage pool. For my 4 files that’s really only an issue for my OCD, but Amazon does support hierarchical directory structures, so that’s something to keep in mind.
Otherwise I found Amazon’s system only slightly more annoying in the way you ‘deploy’ an S3 bucket to the CloudFront CDN. It seemed to take slightly longer and emphasize the idea that there were two distinct systems and products being used, whereas Cloud Files seems much more unified - click a check box and you’ve got a CDN URL.
So with one minor annoyance on each side of the aisle I turned to hard quantifiable data, something every programmer loves. I loaded up my stylesheet on both CDNs and pointed a Pingdom check at each. The results were surprising.
1 - 4 of 4