Carlos Sanchez has a good blog post over at DZone about Puppet and Chef. I've covered using Vagrant and the Opscode platform in a video tutorial, because I (and the rest of Cloudspace) prefer Chef over Puppet, but the important thing is that there's some tool being used for this purpose -- even if it's just a Bash script.

The big thing that I think is missing from Carlos's post is context. Techies tend to see the value quickly, but it's good for business-types to know why a new tool is helpful to the business, instead of just a passing fad. Virtual machines (VMs) and automated configuration (Chef) are very useful, and like Voltron, they're even more powerful when combined.</80s-reference>

Starting from scratch

Here's a story I heard about another development company who had a laptop stolen (full disclosure: I didn't steal it). Computers can get stolen, or they can break in any number of ways... c'est la vie. My issue isn't that they had something bad happen, my issue is their backup plan, or rather, a lack of one.

They ended up spending a week where they couldn't do any work because they were rebuilding their development environment after buying a new machine. Imagine if that had happened only a day or two before a big release!

Contrast this against something that happened recently at Cloudspace -- one of our engineers had his laptop die on him. After a quick trip to the store, and copying over the VM onto the new machine, he was ready to work again. Total time: 2 hours.

It's the difference between "oh no!" and "OH YEAH!"

Not to mention that if you're a growing team, it's a lot nicer to have a simple setup so that people don't spend time configuring their machines when you hire them.

So VMs and automated configuration can help as an insurance policy in case things go wrong. They can also help prevent things from going wrong...

What's the difference between me and you?

Software is complex. We know this. A full development stack (even for a simple app) has many moving parts:

1. Operating System
2. Filesystem
3. Web server
4. Application code
5. Libraries
6. Databases
7. Queues
8. Information Retrieval/Search engine
9. Monitoring

Anyone who has been developing long enough has run into some weird bug that only occurred on a specific configuration, or a specific version of software.

When you're developing locally (testing code on the computer in front of you), it's rare to have the exact same setup that you do in production. Compounding the problem is that many companies will have applications with slightly different components. It would be nice if every application in a company used the exact same stack -- in the real world we know this is not the case. Developers have to be able to work on different applications, or you end up with massive team bloat, and your operations budget goes up.

So developers have a single machine, with one configuration, but they've got to work on several applications that have different configurations -- this means that developers run code on their machines in a different stack than the production server. Even a minor build difference -- let's say 5.0.1 versus 5.0.2 -- can produce the dreaded "well it runs on my machine!" followed by hours or days of wasted time to track down a mysterious bug (costing you money, as well as the loss of forward progress). This is supposed to be one of the advantages of SaaS -- you don't have to worry as much about the configuration of different machines for your customers. But you do have to be aware about the configuration for your developers.

By developing in a virtual machine, you can replicate a production environment. Note that I didn't say a production server -- I said environment. Any complex application is going to have several servers: web heads; database servers (masters and slaves); queues; cache servers; the list goes on. You can run an entire architecture from a single laptop, which means that mystery bugs get discovered and fixed sooner. Time saved, money saved, reputation saved.

One other way around this issue is having a staging environment that is a copy of production, also hosted in the cloud. I'm not anti-staging environments, but there are limits. I've seen other teams where people have to wait because someone else is using a staging server. It's like these teams are trying to slow themselves down.

By taking advantage of virtualization and automated configuration, everyone gets their own staging environment without the added cost. Imagine multiplying your hosting cost by the number of developers!

Not to mention that if you had all these different machines running the same setup, you'd need something like Chef to manage the configuration of them all (or your Ops team will waste time and money doing it all by hand). Just another way that VMs and automation play well together.

Bonus Employee Happiness Factor: because you can run a production environment contained within another computer, it doesn't matter what that outer computer is. So if one developer has to run OSX, but another developer couldn't imagine life without Ubuntu, it doesn't matter. They can each use whatever OS they want and whatever text editor they want. They'll still be building software under the same conditions.

Automated configuration: the multiplier effect

The list of ways that automated configuration has a multiplier effect is significant.

1. Development servers
2. Staging servers
3. Production servers
4. Continuous Integration & Continuous Delivery servers
5. Hot copies. Large architectures have servers that are running production code, but not handling production traffic, that can be switched to if a live production server dies.
6. Crash recovery. If a production server dies, rebuilding by hand takes time. Automating this makes things quicker, and removes the risk that a step might be skipped.
7. Software upgrades. What happens when you need to update the OS on 100 servers?

All of these situations are going to benefit from having automated configuration -- it's faster to set them up, and it keeps things consistent, which we engineering types love!

If you're interested more information about how Cloudspace can increase your pace and quality of development, get in touch with me: tim@cloudspace.com