Hacker News Reader

Comment by dangrossman | Hacker News Reader

On top of paying 8x what it cost before/after I moved from/back to Softlayer, AWS services just didn't work right. EBS failed often. RDS, which runs on top of EBS, would fail often too. When an entire AZ failed, despite paying double the hourly rate for "Multi-AZ" instances that were supposed to automatically fail over to another zone, nothing failed over, it just failed.

If I need on-demand instances these days, I'll do it at Linode. They bill to the day, so you don't need to commit to a month for temporary instances. It's not as scriptable, but it works and doesn't cost a fortune over renting hardware either. More often, I just get servers with more CPU cores and more RAM than I need so there's plenty of room to absorb spikes.

View on HN

We use Softlayer too for the same reasons. Have been with them for over 10 years now - since they were called The Planet. Just had one hardware failure during the entire time. They also now offer Cloud computing instances - which can be deployed either hourly or monthly. And you can mix and match your Cloud and dedicated servers - giving you all the flexibility to scale that you get with AWS / EC2.

You should probably not use softlayer cloud; a very bright ops guy at scribd had a horrific time doing so.

http://kovyrin.net/2011/05/02/cloudlayer-bad-story/

It's also 2 years old, so a lot might've changed.

I could write the same about Rackspace Cloud - in 2009/early 2010. I suspect (but cannot confirm) this isn't relevant any longer either.

Our own experience with their Cloud offering is more recent and a bit different. We have been using cloud computing instances running Haproxy as load balancers to route millions of requests to multiple physical web servers for over a year now. Can't generalize - but we have had no problems so far.

AWS does per-hour billing, so you definitely do not have to commit to a month for on-demand instances.

I was attempting to point out that you don't need to use EC2 to get shorter than month-to-month billing these days.

OK I see. But then why not EC2 with per-hour billing?

I would imagine for a lot of people, they don't need that type of granularity when spinning up and shutting down a server instance. Unless you have some automation to spin up new instances as load increases for short bursts, I could see people working on a schedule that is across a few days.

Scaling up/down is usually for CPU-bound jobs. EC2 has a bad cost/CPU workload ratio when compared to a provider like Linode. You really have to bank on the hourly billing (as the article touched on) to make the cost it worthwhile.

That's not necessarily true.

We use ELB (Elastic Load Balancer) with an auto-scaling group behind it. The instances get added or removed based on the latency reported by CloudWatch/ELB. During the course of a day, the number of EC2 instances running can vary from 8 to 25.

Usually 8 is enough, but when spikes happen or when the capacity of instances to process stuff drops (which does happen in cloud-computing, based on what neighbours you have and what they are doing), then new instances are started in a matter of minutes.

And this billing by hour does save us a lot of money. Because 8 instances is enough, until it isn't and the traffic is so huge that it can choke and freeze 8 instances.

Incidental, this ability is one reason we moved off Heroku.

Azure bills by the minute as of today.

Counter to your point, RDS, EBS, and all of our services have never failed even when we went under extreme load last month.

Its computing and hardware, absolutely everything fails eventually.

Hey Dan, interesting to hear your experiences with EC2, especially with RDS - Would you mind expanding on your comment:

  "EBS would fail often too"

How often is often, and in what way did it fail ?

I'm currently thinking about using RDS in a production environment and it would be interesting to know the limitations.

It's in the AWS docs -- basically, EBS (and RDS built on top of it) is more reliable than a standard hard drive, but nothing like S3 -- you need to expect RDS to fail eventually, just like you would with a server of your own.

But, that's why AWS gives you RDS backups, AZ failover, etc. -- the backups won't fail (they're stored on S3), and with AZ failover, you can make downtime vanishingly small. But you need to actually do that.

A lot of people seem to confuse S3's 99.9999...% reliability with the EBS-backed stuff, which you must plan for eventual failure with.

AWS best practices:

plan for EBS to fail

plan for RDS to fail

'snapshot early snapshot often', as snapshots will help you in case of a failure

there is no automatic snapshot functionality ( yet? )

plan how to snapshot an EBS RAID (Filesystem, uptime)

RDS and EBS both snapshot automatically.

How does Rackspace work? Do they work just like Linode or are they an AWS competitor? I heard some good reviews about them, but not sure...Anyone here on Rackspace who could give us some pluses and minuses of the service?

We had a 2/3 ec2 1/3 rackspace split, and ended up moving largely off rackspace for operational reasons. I found the interface much more usable at AWS, whereas the one at Rackspace was a 'five clicks to do anything' webif, though apparently they've improved in recent months.

I'm not heavily experienced in cloud offerings, but it's far easier to manage the AWS stuff than the rackspace - the DNS management is quite flexible yet couldn't be simpler with AWS's 'Route 53', but with the part of Rackspace we were using it wasn't 'all in one place', which made it hard to peruse or alter.

I found support at both places to be upbeat and knowledgable, though I don't know about timeliness since I've only really lodged low-priority tickets. AWS does need more domain knowledge in order to understand its flexibility, and I've gotten a good workout from my $50/mo support add-on.

Thank you for your feedback :)

We were on Rackspace before moving to AWS. Their sales person flat out told us on our contract renewal call that the only thing they could compete with AWS with was customer service.

I appreciated their honestly but they were lacking a few required services for us at the time.

If I may ask, how long ago was this? Thanks.

Reply on news.ycombinator.com