Hacker News Reader

Comment by conesus | Hacker News Reader

Micro instances are great if you want to spend the least amount possible and don't mind sacrificing raw speed. You are paying a penalty of having a quarter of the processing power of a Medium instance. Oddly, though, the CPU in a Micro is about 15-20% faster than the Medium instance, but when looking at the CPU time versus Real elapsed times, you can see how Amazon is holding back the power.

View on HN

Micros are great if you want a very large EBS volume mounted on a 64-bit machine. The next cheapest 64-bit is $350/mo, and a TB of EBS is $100/mo.

Which begs the question, why doesn't Amazon offer 64-bit at an intermediate price point?

My coworkers and I have often wondered this.

My own best guess is that it's that classic bugaboo: Historical reasons. They've got a big installed base of hardware, software, and ops procedures to support 32-bit small and medium instances, and thus the marginal cost of continuing to run that hardware is lower. Given the choice between (a) a big program to compel all their existing 32-bit customers to migrate to 64-bit infrastructure, and then writing off all the racks full of 32-bit equipment; or (b) maintaining and building out the datacenters and infrastructure that they've already got established, they tend to choose option (b).

Of course, given that the price of compute hardware continues its inexorable fall, in three years Amazon will offer 64-bit at an intermediate price point: The expensive 64-bit large instance of today will be the cheap 64-bit large instance of tomorrow, and people who want real power will be paying for 32xlarge instances.

64-bit hardware is perfectly capable of running a 32-bit OS, though. There's really no obvious reason that Amazon would be trying to phase out 32-bit guests.

Keep in mind that 32-bit instances are highly advantageous for many web applications that use interpreted dynamic languages (Ruby, Python, JavaScript). Almost everything in those languages is an object, and every object is a pointer to a value, and pointers on 32-bit machines are half the size of pointers on 64-bit boxes.

In a Rails app (for instance), the overall performance of an application is often constrained by how many instances you are able to run in parallel. If a 32-bit box can run 50% (or 100%) more instances of your application than the equivalent 64-bit box with the same RAM, that's great.

Is there any benefit to using ec2 Micro instances over the smaller Rackspace Cloud offerings (http://www.rackspacecloud.com/cloud_hosting_products/servers...), unless you need to scale the Amazon way? I'm deciding between both currently to replace a dedicated server for a few of my low traffic sites.

Storage. AWS gives you EBS volumes, of practically unlimited size. With Rackspace, you get the size you get, 40GB, 80GB, etc, and have to pay for a bigger instance if you want more storage. There's cloudfiles, but its not as useful as mounted disks.

EBS is bounded at 1TB / volume. Then you have to stripe.

But the point is that you can do that. With Rackspace, you get X amount of storage, and that's the end of it. If you're getting full, your only option is to get a server with twice the RAM and disk at twice the price.

With EC2, I can have a server half the price of Rackspace's cheapest instance, but with theoretically unlimited storage space. I could use that e.g. for backing up server data, or as an NFS share.

The one major limitation of Rackspace's service is disk space. It's severely limited, and there's not much you can do about it.

Small correction: there's a fairly low limit to how many volumes you can attach to an EC2 instance. Available storage is very high, but not "theoretically unlimited".

Thats why I said "practically unlimited".

You get /dev/sd[b-p][1-15] as mountable EBS volumes. Thats (15 * 15) * 1TB, or about 225TB. You may even be able to go higher than "p", but I haven't tried. I'm also not sure, you may even be able to attach somewhere other than /dev/sd* .

Either way, after that, your EBS bill is $22,500/mo, just for storage, so you might be able to figure something else out for that cost.

But you CAN attach that to a $14/mo EC2 instance, which was my original point.

Edited to add:

Note that the default limit is 20 EBS volumes per EC2 account. You can request an increase from Amazon if you need more. http://groups.google.com/group/ec2ubuntu/web/raid-0-on-ec2-e...

Still, 20TB is "practically unlimited", for most applications.

In my experience a volume can only be attached to /dev/sd[b-p], so it's a 15TB limit per instance. If what you say is true, that would be great news. I'm testing it right now.

Also, in response to your question: I can confirm that EC2 complains if you try going above sdp, or anywhere else.

I know that the Centos and Ubuntu AMIs don't know anything above /dev/sdp, but I haven't tried any others. I have tried /dev/sd1 through /dev/sdd15 and /dev/sde1-4, and that works fine on Canonical's official 10.04 AMI.

You can't yet snapshot the disk images in all (most?) of the Rackspace data centers to their storage cloud. You can with the ec2 micro instances. Suppose to be coming real-soon-now though.

Reply on news.ycombinator.com