Ask HN: Why cloud computing?
For hosting your apps, why go on the cloud? Is scalability the only reason. It seems so much more expensive.
18 comments
A couple of reasons that are important to us:
1. The ability to scale easily. This is going to depend on your application's traffic pattern. Is it predictable? If not, how costly is a failure due to an unforeseen spike? For us, since we host other people's communities, it's very important that we be able to scale easily. I'm willing to pay a premium for this.
2. Amazon builds into their pricing the cost of handling the day to day routine failures and the bigger 'oh shit' failures. Again, I'd rather pay for this directly rather than having it as a liability by either (a) paying someone on my staff to worry about it, or (b) ignoring it all together turning it into a hidden liability.
3. The Amazon architecture allows us to do things that we can't do elsewhere easily. For example: easily moving IPs between instances with Elastic IPs. This makes doing certain types of upgrades much easier. We boot a new instance with new software, make sure it's working, then swap the IP over. Also, the combination of EBS and S3 are a lifesaver for doing backups. Again, we're managing other people's data so I'm happy to pay a premium to do hourly snapshots of my data and continuous backup rotation through S3, with occasional movement offsite using AWS Import/Export.
These are just some examples. Amazon makes many things easier, and only a few things harder, and on the surface appears to cost 'more'. However, I believe when you factor in the true cost of running a site, including all of the time involved in handling failures, designing architectures that have been designed before, performing monkey maintenance (swapping drives, power supplies, whatever), you'll find that the Amazon stack is probably on par or cheaper from a total cost of ownership point of view.
1. The ability to scale easily. This is going to depend on your application's traffic pattern. Is it predictable? If not, how costly is a failure due to an unforeseen spike? For us, since we host other people's communities, it's very important that we be able to scale easily. I'm willing to pay a premium for this.
2. Amazon builds into their pricing the cost of handling the day to day routine failures and the bigger 'oh shit' failures. Again, I'd rather pay for this directly rather than having it as a liability by either (a) paying someone on my staff to worry about it, or (b) ignoring it all together turning it into a hidden liability.
3. The Amazon architecture allows us to do things that we can't do elsewhere easily. For example: easily moving IPs between instances with Elastic IPs. This makes doing certain types of upgrades much easier. We boot a new instance with new software, make sure it's working, then swap the IP over. Also, the combination of EBS and S3 are a lifesaver for doing backups. Again, we're managing other people's data so I'm happy to pay a premium to do hourly snapshots of my data and continuous backup rotation through S3, with occasional movement offsite using AWS Import/Export.
These are just some examples. Amazon makes many things easier, and only a few things harder, and on the surface appears to cost 'more'. However, I believe when you factor in the true cost of running a site, including all of the time involved in handling failures, designing architectures that have been designed before, performing monkey maintenance (swapping drives, power supplies, whatever), you'll find that the Amazon stack is probably on par or cheaper from a total cost of ownership point of view.
Personally, because it reduces the skills base I need on board. I can ignore most issues below the app level and focus on what I do best.
I've used Google App Engine and Azure but am focusing on GAE because of costs and the ability to ignore instances. When I'm not there and the server falls down, the App Engine team will be seriously motivated to get it up. Over time, I expect them to hugely improve reliability without me having to upgrade anything. My VM at Slicehost has been fantastic but is probably less secure than a Google VM.
The crazy thing is that I won't have to pay Google a cent until I get serious traffic.
I've used Google App Engine and Azure but am focusing on GAE because of costs and the ability to ignore instances. When I'm not there and the server falls down, the App Engine team will be seriously motivated to get it up. Over time, I expect them to hugely improve reliability without me having to upgrade anything. My VM at Slicehost has been fantastic but is probably less secure than a Google VM.
The crazy thing is that I won't have to pay Google a cent until I get serious traffic.
There's actually an element that's way overlooked: peace of mind. Let's say AWS goes down. 1) You can't do anything about it, so while you're upset, you're not losing sleep driving to your colo and back at 3am. 2) Many, many other companies - some of whom are infinitely larger than you - are also down. No one is going to mock you in TechCrunch for being down. They're going to mock Amazon, Rackspace, or whomever.
OTOH getting Amazon to acknowledge a problem if it is isolated to your instance may keep you up all night as a recent post about a DOS attack highlighted, so I wouldn't say you're exactly off the hook when it comes to support of your site just because you don't control the hardware.
[EDIT] The post I was referring to: http://news.ycombinator.com/item?id=860414
[EDIT] The post I was referring to: http://news.ycombinator.com/item?id=860414
That seems such a dubious reason to do so, just because ignorance is bliss !
Depends on how you look at it. If you accept that your own abilities are also limited and that you might make costly mistakes, you might conclude that the total downtime will probably be the same. Say X hours per year. The difference is that if you use Amazon, you don't have to spend X hours (even if those hours are in the middle of the night) running around fixing it, someone else does this.
Then, when you need to explain why, you have an easier time too. There is the 'no one got fired for buying IBM' spect to it, but there is also genuine peace of mind.
Then, when you need to explain why, you have an easier time too. There is the 'no one got fired for buying IBM' spect to it, but there is also genuine peace of mind.
Moving from physical servers to EC2 (with reserved instances, that cut the hourly prices significantly) saved me $300 a month.
And I feel much less stress now that I'm "in the cloud". If a server breaks, one click starts a new instance with the apps and configuration already in place. If a virtual hard drive crashes, one click restores a snapshot.
And I feel much less stress now that I'm "in the cloud". If a server breaks, one click starts a new instance with the apps and configuration already in place. If a virtual hard drive crashes, one click restores a snapshot.
Let's look outside the USA:
Here in Germany, hosting is rediclious cheap. You get decent quad core boxes with 12GB RAM for about 70EUR (~100$) including 2-3TB of traffic.
Compared to ec2 it's reeeealy cheap and located in the middle of continental europe. The Dublin/Ireland location of EC2 has a much higher latency and is more expensive than the US instances.
So most startups [1] rent a lot of those cheap boxes in Germany, doing a loadbalancing/failover setup in front of it. done. If you need more hardware: It usually takes <24hrs to get a new box. So just order 1-2 more than you currently need as backup for scaling and faults.
[1] I analyzed that from the most popular hosting provider of http://IsItRails.com
Here in Germany, hosting is rediclious cheap. You get decent quad core boxes with 12GB RAM for about 70EUR (~100$) including 2-3TB of traffic.
Compared to ec2 it's reeeealy cheap and located in the middle of continental europe. The Dublin/Ireland location of EC2 has a much higher latency and is more expensive than the US instances.
So most startups [1] rent a lot of those cheap boxes in Germany, doing a loadbalancing/failover setup in front of it. done. If you need more hardware: It usually takes <24hrs to get a new box. So just order 1-2 more than you currently need as backup for scaling and faults.
[1] I analyzed that from the most popular hosting provider of http://IsItRails.com
Hey rmoriz,
could you tell me the name of that provider? Seems like a delicious option.
Thanks
could you tell me the name of that provider? Seems like a delicious option.
Thanks
Depends on what you mean with 'The Cloud' and 'apps'.
Hosting something 24/7 on for example Amazon's EC2 is barely cost effective. On the other hand doing regular hosting combined with EC2 for peaks is extremely cost effective.
Hosting something 24/7 on for example Amazon's EC2 is barely cost effective. On the other hand doing regular hosting combined with EC2 for peaks is extremely cost effective.
Hosting something 24/7 on for example Amazon's EC2 is barely cost effective
That myth keeps popping up but is simply not true in many situations. There is a wide corridor of use-cases in the mid-range where EC2 is indeed more cost effective than rented or owned servers. Sometimes dramatically so.
The number of factors involved is obviously quite large, but lets just consider the baseline cost of having a "large" instance running for 3 years straight: $10386 (or as low as $4510 if you commit by reservation).
You'll be hard-pressed to match that figure for a rented or bought server, simply because EC2 is a 50.000 server gig and likely yields slightly more economy-of-scale savings than your setup ever could.
That myth keeps popping up but is simply not true in many situations. There is a wide corridor of use-cases in the mid-range where EC2 is indeed more cost effective than rented or owned servers. Sometimes dramatically so.
The number of factors involved is obviously quite large, but lets just consider the baseline cost of having a "large" instance running for 3 years straight: $10386 (or as low as $4510 if you commit by reservation).
You'll be hard-pressed to match that figure for a rented or bought server, simply because EC2 is a 50.000 server gig and likely yields slightly more economy-of-scale savings than your setup ever could.
It seems people often gloss over the issue of redundancy when making these comparisons as well.
If the server hosting your EC2 instance fails, you just bring up a replacement and continue on your way. If you are on a traditional VPS, you either have to bring up a new instance from backup, or wait for the provider to get things running again, but at least they have some strong motivation to since multiple customers are down. If you have a rented or coloed server, you have to wait for someone to fix it, with shorter guaranteed turn-around times costing you more.
You might be able to make the case that you could deploy an app on a single EC2 instance because in the event of failure, your downtime probably runs much less than an hour. Downtime due to a hardware problem on a rented or coloed server is likely to be much more than that. Maybe that tradeoff is acceptable to keep the costs down, but it is a tradeoff. If you aren't willing to make that tradeoff, your cheaper rented or coloed server is actually two servers, with a rough doubling in costs.
If the server hosting your EC2 instance fails, you just bring up a replacement and continue on your way. If you are on a traditional VPS, you either have to bring up a new instance from backup, or wait for the provider to get things running again, but at least they have some strong motivation to since multiple customers are down. If you have a rented or coloed server, you have to wait for someone to fix it, with shorter guaranteed turn-around times costing you more.
You might be able to make the case that you could deploy an app on a single EC2 instance because in the event of failure, your downtime probably runs much less than an hour. Downtime due to a hardware problem on a rented or coloed server is likely to be much more than that. Maybe that tradeoff is acceptable to keep the costs down, but it is a tradeoff. If you aren't willing to make that tradeoff, your cheaper rented or coloed server is actually two servers, with a rough doubling in costs.
But to make a large instance comparable to a real server you would need to include some data transfer and persistent storage in with the price of the server. The EBS page estimates a 100 gig store for a DB would be about $26 a month. If you add to that a gigabyte of data out an hour(at $0.17) you would be up to almost 10 grand for three years of a reserved instance. $10,000 / 36 months is $277 a month, for a server.
If you add bandwidth and storage to one side of the equation you'll also have to add it on the other side.
Do you get the bandwidth cheaper elsewhere? Perhaps but probably not significantly.
Do you get storage with similar flexibility and scalability cheaper elsewhere? Highly unlikely.
Oh and housing, power and staff aren't free either. Neither are the premium support contracts with your various suppliers to get same-day replacements for failed hardware.
Once you factor everything in you'll realize that EC2 is not nearly as expensive as it may seem at a glance.
Do you get the bandwidth cheaper elsewhere? Perhaps but probably not significantly.
Do you get storage with similar flexibility and scalability cheaper elsewhere? Highly unlikely.
Oh and housing, power and staff aren't free either. Neither are the premium support contracts with your various suppliers to get same-day replacements for failed hardware.
Once you factor everything in you'll realize that EC2 is not nearly as expensive as it may seem at a glance.
How can you tell whether the answer is "Cloud" when you don't spell out what the requirements are? In some cases cloud is a good fit for hosting an app, in other cases you are better off using virtual servers, dedicated servers or even colo. Personally, I like using GAE to prototype apps. I can put up an app and get people using it and get feedback. Then using the metrics, I spreadsheet traffic, processor loads, etc and compare the various deployment options.
Recovery is also pretty useful - I posted about our recovery from a worst-case-total-server-death here:
http://unfeatureddocuments.com/content/disaster-and-recovery
For a small startup without a dedicated sysadmin I can't think of anything better than EC2 for handling this kind of thing.
http://unfeatureddocuments.com/content/disaster-and-recovery
For a small startup without a dedicated sysadmin I can't think of anything better than EC2 for handling this kind of thing.
The main drivers are cheaper startup costs and less of a need to manage hardware yourself (usually including backups).
And that you dont have to worry in case your site get a spike due to it being slashdotted.
The other advantage I can think of is to see if a better configuration would help scalability needs. For e.g. if I think a x-bit x-core box would work better for my app, there isnt a need to buy the whole thing before knowing it does no good. I could just pick one from the cloud and pay only for usage.
The other advantage I can think of is to see if a better configuration would help scalability needs. For e.g. if I think a x-bit x-core box would work better for my app, there isnt a need to buy the whole thing before knowing it does no good. I could just pick one from the cloud and pay only for usage.