Hacker News Reader

Comment by mr_luc | Hacker News Reader

$0.02/hr == approximately $14/mo if you leave it on.

Is this really $6/mo cheaper than a linode 512? That might be nice for personal projects.

I'm trying to teach myself some things that really need more than my local dev machine (puppet, backup strategies/more resilient code, learning cassandra). I've been running a bunch of VM's on my laptop, but my dev machine is a weakling and can't hardly handle it.

It almost seems like I could just spin up a dozen of these little instances for $2.88 per waking day and teach myself under substantially more "real" conditions on the cheap. That's something I'd love to have as an option on linode, given that teaching myself is a large part of what I use it for.

Is there any reason that wouldn't work? Is this too complicated in practice?

View on HN

One thing to note is that even EC2's "small" instance pales in comparison CPU-wise to even the low end Linodes. When playing with EC2, it blew me away how ridiculously slow they are until you get to the high levels (oddly it seemed the memory speed was also very poor - I had to wonder if even memory was networked somehow).

some corroboration: http://journal.uggedal.com/vps-performance-comparison

These instances are different though, they are able to burst CPU usage, just like Linode. AFAIK, none of the other EC2 instance sizes are able to do this.

Linode doesn't "burst" CPU usage. Processor time is shared fairly among Linodes on a host, and you can use any time that isn't used by others. It's worth noting that each Linode has access to four cores, so you can go up to 400% CPU utilization. For a good idea of how Linode's CPU performance routinely exceeds that of competitors, try this review: http://journal.uggedal.com/vps-performance-comparison

Semantics. The end result is the same: there is almost always a large amount of spare CPU cycles on each physical box, which can be utilized by instances to "burst" above their allocated capacity.

It's more than semantics. The term "burst" carries the implication that you only get something for a short time. That's really not a good reflection of reality in this situation.

Who cares what term they use or what implication it has? In reality, it is the same concept. That's why it is SEMANTICS.

Words have meanings and carry implications. By your logic, we might as well use the term "banana" instead. The point is that the concept doesn't reflect reality, and thus your point has no merit.

You fuck goats. Way to take this way the fuck off topic.

You've been here a year and a half and should know better than to post comments like this one.

I took a few minutes to google a few terms, like "cassandra EC2" and so forth.

I get the general impression that doing anything architecture-y or deployment-y requires amazon-specific steps, steps that I don't have to take on a barebones ubuntu install. (of the 'Do this to get Thrift working on EC2' variety)

That sucks some activation energy away.

The ease/hurdles of VMs on my dev machine, even if performance is a bit of a bear, is still more attractive to me than doing anything Amazon-specific, because it's still all just unix.

I don't want to learn "Amazon", I want to learn [puppet, Cassandra, et al].

hmm. I do cassandra on EC2 and I can't think of any ec2 specific setup that I need to do. Its just plain ubuntu. I do install my own custom cassandra to stay on top, but I would do that on any ubuntu install.

I think he's talking about making an AMI for his particular packages.

This is an issue for me to. It looks like a hassle and the instructions look vague and all I want to do is just setup a VM on my machine and then run it on amazon.

Turnkey Linux seems to make this better.

I'm guessing you're just using an off the shelf Ubuntu AMI, right?

I haven't seen anyone mention the cost of IO requests associated with EBS. Quoted from http://aws.amazon.com/ebs/ :

As an example, a medium sized website database might be 100 GB in size and expect to average 100 I/Os per second over the course of a month. This would translate to $10 per month in storage costs (100 GB x $0.10/month), and approximately $26 per month in request costs (~2.6 million seconds/month x 100 I/O per second $0.10 per million I/O).

I'm running 4 m1.small EBS-backed LAMP servers in all 4 regions. I pay about $1/mo for EBS IO (8-11 million IO requests per instance per month). The servers get a few thousand hits per day. The cost of EBS IO should be minimal in most cases. The benefit of EBS versus the local storage you'll get with Rackspace or Linode is greater durability because it is off instance and AWS automatically duplicates the data. If the VM host system fails (i.e. power supply goes bad), you can bring your instance back online within a very short period of time on another host at the exact state it was at the time of failure.

One word of caution: sometimes when an instance becomes unavailable (think network partitioning), all its EBS volumes will become unavailable as well. You can't snapshot, you can't detach. My most frustrating experience on EC2 yet.

You can force detach using the console tools. I had this problem too

I can remember at least one case where force-detach didn't work either. In that case there is absolutely nothing you can do to access your data.

If you use a 1-year reserved instance, it'll cost you about $115/year, which is substantially cheaper than the lowest-priced Linode. I'll be switching http://mbusreloaded.com/ after its Linode subscription runs out, as there's absolutely no way I use more than 10 GB of bandwidth per year.

It quoted me at $54/year.

That's the one-time fee. You still have to pay $0.007 per hour.

Oh, I didn't catch that part. Thanks for the heads up!

Yup - you could - this is a fantastic move by Amazon - this is the one thing that's been missing from my experimentation world - Linode is fantastic for the servers I run permanently there - I have no plans to remove them, but the commitment to an instance for a certain period of time is what keeps me from using it to work on deployment scenarious and whatnot. Amazon is fantastic for this (and has differnet constraints, of course)
This just brought AWS down into the realm of competition with the likes of Linode and others, and we can now figure out how to spin up a dozen nodes and work with all the innards of aws without worring about getting accidentally hosed on forgotten instances... works for me.

Remember, though, you still need to pay for EBS and bandwidth seperately.

Which should be pretty low if I'm the only user.
Linode doesn't charge you for bandwidth between nodes in the same datacenter -- is there something comparable in the EC2 world?

Yes, but only if the nodes are in the same region and availability zone. From amazon's pricing page [http://aws.amazon.com/ec2/pricing/]:
There is no Data Transfer charge between Amazon EC2 and other Amazon Web Services within the same region (i.e. between Amazon EC2 US West and Amazon S3 in US West). Data transferred between Amazon EC2 instances located in different Availability Zones in the same Region will be charged Regional Data Transfer. Data transferred between AWS services in different regions will be charged as Internet Data Transfer on both sides of the transfer.

None that I can see. I'm going to buy one reserved one, even though I have 7 hardware servers. I need to get better with the platform and for $54/year, the price is right

One thing that is useful: if you like to keep several instances configured and 'ready to go' for your learning experiments, when you are done, don't terminate them, just stop them. You don't pay for stopped instances (but then you do pay 24 cents a day per unattached Elastic IP address).

I'm in the exact same situation with Riak + node.js developement. Micro instances seems like a good fit.

Can Linode instances occasionally randomly be killed like EC2 instances, or do they offer stronger guarantees about uptime?

Linode is a VPS provider, not a cloud provider like EC2. Instances are always on, not on-demand. If they are ever killed it would be because of some kind of outage but I've found that to be extremely rare in my experience. Slicehost has also been good for VPS.

AWS instances don't have persistent storage...if your server crashes you loose your data, the changes to your OS and even your IP.
AWS is great, but you can't compare the AWS instances with other VPS or Dedicated offerings.

Micro instances don't have any local storage -- EBS only.

Reply on news.ycombinator.com