5 ms·

This brings up a question I've also wondered when looking at moving to EC2: it simply costs more to run when you have a few servers that use up a lot of bandwid

by marquis 15y ago

This brings up a question I've also wondered when looking at moving to EC2: it simply costs more to run when you have a few servers that use up a lot of bandwidth. At what scale does it become more efficient?

ericHosick 15y ago
EC2 instances are not reliable: they degrade all the time. The solution, recommended by Amazon, is to have redundancy. So, plan on having at least two of every type of server or using their services like RDS. Really, it is a rabbit hole that can lead to thousands of dollars each month very quickly. EC2 becomes efficient when talking about hundreds of thousands of customers if not more. You can end up with an impressively robust system but at a large of upfront cost: for startups probably not worth the ROI.
- bretthoerner 15y ago
  > for startups probably not worth the ROI. I definitely agree. That said, I think people seem to forget something. Amazon says: "your instance may go down and if it does we may just terminate it, reclaiming your ephemeral disk. All data not on EBS will be lost." Every other host (at least implicitly) says: "your instance/machine may go down, we will attempt to recover your data. The ability and speed depends largely on why the machine went down and whether we run RAID/etc on the machine." I've waited weeks for a disk repair from very well known/regarded non-Amazon hosts. Redundancy is needed everywhere, not just on Amazon. Bare metal still dies, controllers flake out, networks go down.
  - sunsu 15y ago
    This is why I'm sticking with EC2 for now as well. Though one of my instances might go down or become unreliable, all I have to do to fix it is Stop and Start it! No messing with support tickets or waiting (sometimes hours) on someone to talk out to the data center to troubleshoot it. Its just fixed.
- bermanoid 15y ago
  EC2 instances are not reliable: they degrade all the time. The solution, recommended by Amazon, is to have redundancy. So, plan on having at least two of every type of server or using their services like RDS. With EC2 my approach has always been that if you've got enough traffic to justify it, you should move rather quickly to a load-balanced solution. This really forces you to stop relying on what's stored on any particular server, and focus your energy on making sure you can boot new ones and get them seamlessly into the rotation. Obviously this doesn't work for stuff like databases (for which I definitely recommend RDS or SimpleDB if they suit your needs), but even there, if you're hosting your own and make sure that the data goes on to EBS volumes instead of the instance stores, you can set things up so that you snapshot those volumes regularly and can boot up new database servers without trouble. Services like Rightscale can help manage stuff like this pretty easily, too, though they're probably a bit expensive for startups (and you've got to be willing to put in a little setup time, I've always found that their templates needed pretty substantial customization to suit my needs); in any case, Amazon is starting to pull more of that type of functionality into AWS itself, with stuff like CloudFormation and Elastic Beanstalk, so if I was starting now, I'd probably give those a closer look.
- cperciva 15y ago
  EC2 instances are not reliable: they degrade all the time You have an interesting definition of "all the time". In my experience, EC2 instances fail less often than dedicated servers.
  - ericHosick 15y ago
    I didn't define it. You could have asked for clarification. We have had three instances degrade within a week. So far, we have had five instance degrade. At current degradation rate, nearly 100% of our production servers would degrade every year. It took a lot of work to try and get, from Amazon support, the expected degradation rates of their servers. Their response was as I described: implement redundancy. They never did let me know their expected degradation rate. Admittedly, we have not seen any degradation in a few months. However, this doesn't make me feel any better.
rhizome 15y ago
From a user's perspective, what can EC2 do that a PC in a closet hanging off a T1 can't do?
- dasil003 15y ago
  More than 1.5Mbps for starters... appearing at the drop of an API call is another... you can fill in the blanks from here.
- bermanoid 15y ago
  Allow for an easy path to recovery, with near-zero downtime, when that PC-in-a-closet inevitably has some sort of failure. The nice thing about the fact that EC2 instances are at least to some degree ephemeral is that it forces you, from the start, to have a solid backup/restore plan. And when an EC2 instance goes down, you can have another one booted within minutes, compared to the days/weeks that it might take to get another physical machine set up. That's not even to mention scaling issues; right now I'm managing a stack of over 50 EC2 instances, and it's easily manageable by a single person (most of those are in a load balanced array, and they'll come up and go down automatically as load dictates). I have no idea what I would do if I had to physically set up servers to handle this type of shifting load...
  - rhizome 15y ago
    compared to the days/weeks that it might take to get another physical machine set up. Whaaaa? What does 50 EC2 instances correspond to in the hardware world, appwise (not environment)? Each of my Rails/Apache processes are about 75M (unoptimized, natch), which means 50 will sit OK in 4G RAM. Since that is laptop-caliber hardware capacity, I'm still not seeing the benefit in the server world (or even an 8G PC). From where I sit it seems to involve a lot of domain knowledge that is not relevant once you stop using EC2. Naturally, EC2 is totally great for spinning up and prototyping, but from my research its most compelling benefit is geographic dispersal, which can also be accomplished otherwise.
- gtaylor 15y ago
  I'll see your PC in a closet on a T1, and raise you an API-spawned, auto-scaling cluster of VMs that can be imaged, re-sized, and restored with the tiniest of delays.

by marquis 15y ago

ericHosick 15y ago

EC2 instances are not reliable: they degrade all the time. The solution, recommended by Amazon, is to have redundancy. So, plan on having at least two of every type of server or using their services like RDS. Really, it is a rabbit hole that can lead to thousands of dollars each month very quickly. EC2 becomes efficient when talking about hundreds of thousands of customers if not more. You can end up with an impressively robust system but at a large of upfront cost: for startups probably not worth the ROI.

bretthoerner 15y ago
> for startups probably not worth the ROI. I definitely agree. That said, I think people seem to forget something. Amazon says: "your instance may go down and if it does we may just terminate it, reclaiming your ephemeral disk. All data not on EBS will be lost." Every other host (at least implicitly) says: "your instance/machine may go down, we will attempt to recover your data. The ability and speed depends largely on why the machine went down and whether we run RAID/etc on the machine." I've waited weeks for a disk repair from very well known/regarded non-Amazon hosts. Redundancy is needed everywhere, not just on Amazon. Bare metal still dies, controllers flake out, networks go down.
- sunsu 15y ago
  This is why I'm sticking with EC2 for now as well. Though one of my instances might go down or become unreliable, all I have to do to fix it is Stop and Start it! No messing with support tickets or waiting (sometimes hours) on someone to talk out to the data center to troubleshoot it. Its just fixed.
bermanoid 15y ago
EC2 instances are not reliable: they degrade all the time. The solution, recommended by Amazon, is to have redundancy. So, plan on having at least two of every type of server or using their services like RDS. With EC2 my approach has always been that if you've got enough traffic to justify it, you should move rather quickly to a load-balanced solution. This really forces you to stop relying on what's stored on any particular server, and focus your energy on making sure you can boot new ones and get them seamlessly into the rotation. Obviously this doesn't work for stuff like databases (for which I definitely recommend RDS or SimpleDB if they suit your needs), but even there, if you're hosting your own and make sure that the data goes on to EBS volumes instead of the instance stores, you can set things up so that you snapshot those volumes regularly and can boot up new database servers without trouble. Services like Rightscale can help manage stuff like this pretty easily, too, though they're probably a bit expensive for startups (and you've got to be willing to put in a little setup time, I've always found that their templates needed pretty substantial customization to suit my needs); in any case, Amazon is starting to pull more of that type of functionality into AWS itself, with stuff like CloudFormation and Elastic Beanstalk, so if I was starting now, I'd probably give those a closer look.
cperciva 15y ago
EC2 instances are not reliable: they degrade all the time You have an interesting definition of "all the time". In my experience, EC2 instances fail less often than dedicated servers.
- ericHosick 15y ago
  I didn't define it. You could have asked for clarification. We have had three instances degrade within a week. So far, we have had five instance degrade. At current degradation rate, nearly 100% of our production servers would degrade every year. It took a lot of work to try and get, from Amazon support, the expected degradation rates of their servers. Their response was as I described: implement redundancy. They never did let me know their expected degradation rate. Admittedly, we have not seen any degradation in a few months. However, this doesn't make me feel any better.

rhizome 15y ago

From a user's perspective, what can EC2 do that a PC in a closet hanging off a T1 can't do?

dasil003 15y ago
More than 1.5Mbps for starters... appearing at the drop of an API call is another... you can fill in the blanks from here.
bermanoid 15y ago
Allow for an easy path to recovery, with near-zero downtime, when that PC-in-a-closet inevitably has some sort of failure. The nice thing about the fact that EC2 instances are at least to some degree ephemeral is that it forces you, from the start, to have a solid backup/restore plan. And when an EC2 instance goes down, you can have another one booted within minutes, compared to the days/weeks that it might take to get another physical machine set up. That's not even to mention scaling issues; right now I'm managing a stack of over 50 EC2 instances, and it's easily manageable by a single person (most of those are in a load balanced array, and they'll come up and go down automatically as load dictates). I have no idea what I would do if I had to physically set up servers to handle this type of shifting load...
- rhizome 15y ago
  compared to the days/weeks that it might take to get another physical machine set up. Whaaaa? What does 50 EC2 instances correspond to in the hardware world, appwise (not environment)? Each of my Rails/Apache processes are about 75M (unoptimized, natch), which means 50 will sit OK in 4G RAM. Since that is laptop-caliber hardware capacity, I'm still not seeing the benefit in the server world (or even an 8G PC). From where I sit it seems to involve a lot of domain knowledge that is not relevant once you stop using EC2. Naturally, EC2 is totally great for spinning up and prototyping, but from my research its most compelling benefit is geographic dispersal, which can also be accomplished otherwise.
gtaylor 15y ago
I'll see your PC in a closet on a T1, and raise you an API-spawned, auto-scaling cluster of VMs that can be imaged, re-sized, and restored with the tiniest of delays.