Scaleability is a term near and dear to a CTO’s heart. It’s also the most important factor in growing a website. If you want to avoid the “fail whale” at right, you have to be able to scale your application to run on hundreds (and, if you’re really lucky, thousands) of servers. Let’s take a look at the typical scenario of ordering a new server.
Hopefully, you have some kind of measures in place that alert you to the fact that you need a new server. If you don’t even have this, that stinking whale just might be your job floating right out from underneath you. Stop! Do not pass “Go!” and proceed directly to Munin! Knowing the usual loads (and growth over time) is critical in being able to plan your infrastructure.
Ok, so you (and the marketing team) have noticed a nicely growing trend in traffic over the last few months. SEO and performance optimizations are working together to drive traffic to your site and keep it there. Grab a pen and continue the curve on this database queries per second graph below:
You better order some servers! Note: yes, I know you should first ensure your query caching parameters have been tweaked and your application isn’t making unnecessary requests…but that’s another blog post ;).
So, you contact your hosting provider and ask for a quote. A few days later, you get your quote and discuss with management on when/how many to order. A week later, you’ve filled out the order form and faxed it off. I’ll be generous here and say this whole process took a week (even though its closer to two). You’ll find out why in a bit.
Let’s make another assumption and say your servers are completely managed – this means you don’t have physical access to them and the new ones just sort of “pop” into existence in your network. If you took physical delivery, it probably means you’ll have to install even the OS yourself, configure RAID arrays, etc. adding up to a month in work (and lost time). But, again, let’s be a bit more 21st century here. Your hoster promised your new servers would be ready for use in two weeks, and, luckily you get them as promised. We’re now at 3 weeks and you’re staring at a couple of empty terminal shells now.
How long it takes to install your application on a new server depends on a lot of factors. How complex is it (how many moving parts does it have)? Trivial applications take about a day to fully configure, test & deploy. Bigger beasts might take up to a week.
Experience is another big factor in your setup time. How often have you done this before? Is it your first time? Probably means you don’t fully have a grasp on your application (and all its dependencies). You’ll need a week. Do you do this every month? Should be a breeze then: 1 day. Let’s go with the average and err this time on the conversative side: 1 week total installation, deployment & testing time.
Congratulations! 4 weeks after you’ve identified the need for additional capacity, you now have it. Unfortunately, neither your website nor your users have been patient during the last month. This is obviously not going to get you a promotion, but definitely cost you some traffic.
Enter the “Cloud” – that nebulous, silver-lined wonder of infinite scaleability. Amazon’s EC2 cloud cuts the requisition time of the order & delivery stages down from 3 weeks to just minutes. This is already a 75% savings in deployment time! But, without automated deployment, you’ll still need a week to get your application installed.
Ok, so I finally mentioned “automated deployment”. It’s basically about automating the entire install, test & deploy phase above. Over at NetDoktor we use Capistrano to accomplish this truly magical feat. What used to take me an entire day, now takes anyone a few minutes. And that 4 weeks timeframe above? Now less than 10 minutes. This gives your business an incredible flexibility to instantly meet the demands of your customers, traffic spikes, and overall growth.
5 thoughts on “Why your boss will love Capistrano”
The title talks about capistrano, but the word occurs only once at the end of the article…
Anyway, I have used capistrano in the past, sometimes it suddenly decided to stop updating the code due to some obscure reason.
I have moved on to using a remote mercurial repository to which I push && update && rake db:migrate, and it never failed me.
I’ll see if I can streamline it further by just using rsync.
After all, the hundreds (thousands?) of capistrano code simply generate a set of bash commands to run an scm and rsync doesn’t it?
Capistrano is putting your money where your mouth is (where “scaleability” is your mouth). I wanted to talk about my experiences implementing scaleability with Cap and how that impressed my boss.
I’m about hip-deep right now in Puppet and getting the first half of that whole deployment mess down from a couple weeks to a couple minutes.
Beware of using rsync for code deployment!
Thanks for finally writing about > Why your boss will love Capistrano < Loved it!