The Day the Cloud Died(elasticvapor.com)
elasticvapor.com
The Day the Cloud Died
http://www.elasticvapor.com/2009/06/day-cloud-died.html
6 comments
Don't bother with this waste of time. You're welcome.
Cloud computing actually is dying and the hype from the author of that blog is one of the reasons. It's a bunch of smoke and mirrors.
Why would TMZ or any other site want to pay for all the resources to satisfy acute demand when it produces no value for the content producers or the advertisers who support them. Those clicks have no value except to the consumers. Websites aren't charities. They have to make money somehow.
You're better off letting your site crash under that kind of load.
Why would TMZ or any other site want to pay for all the resources to satisfy acute demand when it produces no value for the content producers or the advertisers who support them. Those clicks have no value except to the consumers. Websites aren't charities. They have to make money somehow.
You're better off letting your site crash under that kind of load.
Over-sensationalist title. Unexciting (and somewhat wrong) article. Not all websites need or should deploy to EC2 and the like.
Useless article!
Purely a scaling issue.
It's a similar story to the days when sites would get D-DOSed by Slashdotters!
There isn't an ifinite amount of bandwidth out there, so this will ALWAYS happen occasionally - even in the Holy Cloud!
People who think going to the cloud will automatically solve all your scaling issues are severely misguided. It takes a lot of work to have a system where newly provisioned servers are even used in your server infrastructure. Do you think Perez Hilton setup his own dynamic load balancing and web serving strategy?
How much headroom do the 'cloud' providers allow?
Presumably any sudden, broad, increase in demand for servers is going to cause problems if there are no physical machines to support the instances - however many times you scribble the word 'Cloud' on your design in crayon.
Presumably any sudden, broad, increase in demand for servers is going to cause problems if there are no physical machines to support the instances - however many times you scribble the word 'Cloud' on your design in crayon.
One would hope that scalable architecture is one of the main selling points of cloud computing.
So how long does it take to power up amazon instances in the case of a news item like this? Or do you have to have them standing by already allocated? If so, isn't it cheaper to build you own?
Ways I've found that work for pretty quick scaling on EC2 (YMMV, and I'm not that smart or seasoned on it, so don't take this as canon.)
You need to have the elastic block storage (or some remotely mountable storage you trust to be up). On this storage, you put things like your database and other dynamic content that you expect to persist through a reboot of the box, which reverts back to its base image.
You need to configure a couple of boxes at least, one to act as a load balancer, and another to act as the content provider. For more laden sites than mine, you might also need a separate instance for just the DB.
You are going to eat the cost of static IPs for at least a few boxes, but that's pretty cheap. Configure those IPs to be in your load balancer always. They'll fail when they're down, but that shouldn't be an issue.
At this point, you can have basically as many boxes available as you have previously allocated, and bringing them online is as simple as turning them on. You could probably use CloudKick to dynamically bring them online, but I haven't really played with it to know.
If you need scaling past that allocation, you can bring up more instances (the bottleneck will of course be the DB), and register them with the load balancer as you need.
You need to have the elastic block storage (or some remotely mountable storage you trust to be up). On this storage, you put things like your database and other dynamic content that you expect to persist through a reboot of the box, which reverts back to its base image.
You need to configure a couple of boxes at least, one to act as a load balancer, and another to act as the content provider. For more laden sites than mine, you might also need a separate instance for just the DB.
You are going to eat the cost of static IPs for at least a few boxes, but that's pretty cheap. Configure those IPs to be in your load balancer always. They'll fail when they're down, but that shouldn't be an issue.
At this point, you can have basically as many boxes available as you have previously allocated, and bringing them online is as simple as turning them on. You could probably use CloudKick to dynamically bring them online, but I haven't really played with it to know.
If you need scaling past that allocation, you can bring up more instances (the bottleneck will of course be the DB), and register them with the load balancer as you need.
"Unexpedly Twitter had major scaling issusing dealing with the sudden influx"
I don't know whether I should point out the awful spelling, or poke fun at the idea that Twitter failing is ever "Unxpeded".
I don't know whether I should point out the awful spelling, or poke fun at the idea that Twitter failing is ever "Unxpeded".