What? The way you would treat your dog is very different from how a farmer would treat his cattle. You give your dog a sentimental name, play with him often, and when he gets sick you take him to the vet and spend lots of time and money making him better. On the other hand, a cow is given a generic name, isn’t played with individually but is driven as part of the herd.
Servers for a long time in IT have been dogs, they’re occasionally even named dog names and thought of fondly (or hatefully). We’ve cared for them, gave them redundant networking, redundant power supplies, and many, many hard drives. When they fail, we restore them from backups or login and troubleshoot manually for as many hours as it takes to bring our server back online. Cattle servers, on the other hand are cheap, small, and can be replaced. So if one has issues at 3am, it’s much easier to bring up a fully-working replacement. Putting services into virtual machines hosted “in the cloud” turns our dog servers, which are expensive and time-consuming to cattle servers, which are cheap and low-individual-investment.
Why? Many reasons, mainly because infrastructure is cheaper than human time. You’ll nearly always have more servers than systems administrators, so why does a systems administrator spend many hours on a single broken server, when there are many that could require his attention?
Humans drive cattle as a herd and tend to interact with cattle only rarely one-on-one. As such, we’ll need tools to drive and manage our herd so we don’t need to login and duplicate the same work across all the servers. That’s where configuration management software comes into play. We store templates of servers, saved in configuration files using our configuration management software as a central repository; an archive of servers, if you will. From these templates, you can spin up any number of servers with exactly the same software on them. Because we can easily spin up copies, our configuration management software also becomes a backup of all of our servers. While we’ll still need to backup the data, the configurations (as long as they were pulled from the central repository) are safe. This also means that we can make changes to the central repository copies and then push out the changes to our herd, essentially driving them as a group.
How? The magic component here is “Configuration Management Software”. This can show up in many forms. Options for configuration management range from homemade BASH or Python scripts to open source and commercial products like Chef, Puppet, Salt, or even VMWare’s vFabric. In future articles we’ll talk about how SingleHop is making the transition of its own infrastructure from dog servers to cattle servers, what tools we’re using and how it’s coming along.
Next up, we’ll go deeper into why this is helpful for preventing cruft in application environments, easing code deployments, and improving flexibility.