Live data from Hacker News

Fixing holes in EC2 reliability

mytechgossips.com

1–10 of 17 posts

Re: Fixing holes in EC2 reliability

#3
Given my experience, you are advocating way to much reliance on EBS. The nature of block storage makes it a poor choice for cloud attached storage.

Apps should be designed for redeployment quickly via configuraiton management. Persistent data should be stored to S3 or RDS, only use EBS as a last resort.

Moving from a VPS to EC2 is more than a fork lift migration, but should be viewed as an application redesign.

Re: Fixing holes in EC2 reliability

#4

tl;dr no one told him Amazon EC2 is not a VPS provider. Lots of people seem to assume it is. Instances are supposed to die, thats a feature not a bug.

This is the most important lesson here. I've heard too many stories that end badly and I've learned this the hard way myself.

Re: Fixing holes in EC2 reliability

#5
post #4

tl;dr no one told him Amazon EC2 is not a VPS provider. Lots of people seem to assume it is. Instances are supposed to die, thats a feature not a bug.

This is the most important lesson here. I've heard too many stories that end badly and I've learned this the hard way myself.

Ooops sorry, downvoted by accident.

I have a question though: how do people get bitten by this lack of instance persistence?

Re: Fixing holes in EC2 reliability

#6
post #5
post #4

Earlier quoted context omitted.

This is the most important lesson here. I've heard too many stories that end badly and I've learned this the hard way myself.

Ooops sorry, downvoted by accident. I have a question though: how do people get bitten by this lack of instance persistence?

In many cases, there are people who don't do their homework and set up regular, VPS-like web servers on EC2. What happens then, is that they have a real, established website that, weeks, months or years down the road, eventually gets rebooted, and disappears.

The EC2 instances boot to 'boot images', basically. Most of the images are like CDs, and contain just enough to get you ready to install your webserver, database, yadda yadda.

You can configure your image how you like, and then create a new 'image', which will be what your machine looks like after a reboot, but unless you use a persistent data store or external storage of some sort, you can't add new blog posts and expect them to be there after a reboot.

There are easy ways around it, and in fact, are best practices for application design, but compared to the normal shared hosting or VPS configurations that most people know, it is completely different.

Re: Fixing holes in EC2 reliability

#7
post #4

tl;dr no one told him Amazon EC2 is not a VPS provider. Lots of people seem to assume it is. Instances are supposed to die, thats a feature not a bug.

This is the most important lesson here. I've heard too many stories that end badly and I've learned this the hard way myself.

The other lesson I'd add is that if an instance dies and can't be rebooted, you'll need to stop/start it, which will result in an IP address change.

Best to have elastic IPs at the ready for that instance, or be prepared to deal with the IP changes.

Re: Fixing holes in EC2 reliability

#8

Given my experience, you are advocating way to much reliance on EBS. The nature of block storage makes it a poor choice for cloud attached storage. Apps should be designed for redeployment quickly via configuraiton management. Persistent data should be stored to S3 or RDS, only use EBS as a last resort. Moving from a VPS to EC2 is more than a fork lift migration, but should be viewed as an application redesign.

Can you elaborate on what's so wrong with EBS? Are you thinking more about performance, or reliability?

I'm wondering in particular what you'd suggest in cases where RDS is not an option, if you're running your own MongoDB server or something like that. I don't think S3 is really an option there, is it?

Or would you tend to do everything on the instance store and periodically do a manual snapshot to S3?

Re: Fixing holes in EC2 reliability

#9

Given my experience, you are advocating way to much reliance on EBS. The nature of block storage makes it a poor choice for cloud attached storage. Apps should be designed for redeployment quickly via configuraiton management. Persistent data should be stored to S3 or RDS, only use EBS as a last resort. Moving from a VPS to EC2 is more than a fork lift migration, but should be viewed as an application redesign.

Can you elaborate on what's so wrong with EBS? Are you thinking more about performance, or reliability? I'm wondering in particular what you'd suggest in cases where RDS is not an option, if you're running your own MongoDB server or something like that. I don't think S3 is really an option there, is it? Or would you tend to do everything on the instance store and periodically do a manual snapshot to S3?

EBS volumes are analogous to hard drives. They're reliable... until they fail. So keep backups. This is easily done with EBS snapshots, (which are persisted to S3).
Post reply on HN