5 ms·

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 E

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.

jd007 13y ago
AWS does per-hour billing, so you definitely do not have to commit to a month for on-demand instances.
- dangrossman 13y ago
  I was attempting to point out that you don't need to use EC2 to get shorter than month-to-month billing these days.
  - jd007 13y ago
    OK I see. But then why not EC2 with per-hour billing?
    - kyrra 13y ago
      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.
    - orthecreedence 13y ago
      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.
  - bad_user 13y ago
    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.
- JoshGlazebrook 13y ago
  Azure bills by the minute as of today.
pitchups 13y ago
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.
- x0x0 13y ago
  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/ http://kovyrin.net/2011/05/02/cloudlayer-bad-story/
  - sluukkonen 13y ago
    It's also 2 years old, so a lot might've changed.
  - porker 13y ago
    I could write the same about Rackspace Cloud - in 2009/early 2010. I suspect (but cannot confirm) this isn't relevant any longer either.
- pitchups 13y ago
  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.
neya 13y ago
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?
- vacri 13y ago
  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.
  - neya 13y ago
    Thank you for your feedback :)
- theg2 13y ago
  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.
  - neya 13y ago
    Thank you for your feedback :)
  - kc5tja 13y ago
    If I may ask, how long ago was this? Thanks.
whyleyc 13y ago
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.
- crazygringo 13y ago
  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.
weitzj 13y ago
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)
- theg2 13y ago
  RDS and EBS both snapshot automatically.
theg2 13y ago
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.

jd007 13y ago

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

dangrossman 13y ago
I was attempting to point out that you don't need to use EC2 to get shorter than month-to-month billing these days.
- jd007 13y ago
  OK I see. But then why not EC2 with per-hour billing?
  - kyrra 13y ago
    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.
  - orthecreedence 13y ago
    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.
- bad_user 13y ago
  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.
JoshGlazebrook 13y ago
Azure bills by the minute as of today.

pitchups 13y ago

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.

x0x0 13y ago
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/ http://kovyrin.net/2011/05/02/cloudlayer-bad-story/
- sluukkonen 13y ago
  It's also 2 years old, so a lot might've changed.
- porker 13y ago
  I could write the same about Rackspace Cloud - in 2009/early 2010. I suspect (but cannot confirm) this isn't relevant any longer either.
pitchups 13y ago
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.

neya 13y ago

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?

vacri 13y ago
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.
- neya 13y ago
  Thank you for your feedback :)
theg2 13y ago
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.
- neya 13y ago
  Thank you for your feedback :)
- kc5tja 13y ago
  If I may ask, how long ago was this? Thanks.

whyleyc 13y ago

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.

crazygringo 13y ago
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.

weitzj 13y ago

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)

theg2 13y ago
RDS and EBS both snapshot automatically.

theg2 13y ago

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.