Before virtualization became popular the number of servers at most companies were fairly manageable manually. Even large corporations who had a few thousand servers were managed manually. Usually the sysadmin team who was responsible for managing the environment knew the server farm pretty well, usually they built them one by one, naming them one by one. It was typical to find a cool naming convention which helped to remember which server is doing what. Gods, celestial objects, flowers,  mythical figures, whatever the sysadmin was interested in as a hobby.

Configuration files were manually edited, best case the sysadmin made a copy of the original file in the same directory named appending _SAVE or _COPY, or maybe the current date. It was the wild west, and we all had our experience based best practices. Software packages were not installed from the repository but compiled with the custom settings best fit your case and environment.


Fast forward to the mass adoption of virtualization, and dynamic resource management. The number of servers grew exponentially, and in order to scale companies had two options:

  • scale the operational team in proportion to the server size growth
  • find a more efficient way to manage the environment

The first option was more of a theoretical option, not a realistic one. It was too expensive. That’s when companies started to embrace the configuration management tools, which helped to ease this pain point.  It’s also good to know that we had configuration management tools way before this, CFEngine was released in 1993. It just never reached mass popularity. The first real popular CM engine was Puppet, but the real change came with a few years later, with Chef.

Puppet was already fairly useful, but Chef brought an even easier approach which is usually a key for broad acceptance.


Most CM tools are similar in core principles in how they operate. There are some differences, but the key components are typically the same.

  • have a language to describe a desired configuration
  • reach out and make changes on the managed nodes
  • have a remote repository to store popular configurations
  • try to support code reusability

Agent or Agentless

Some CM tools will require you to install an agent on the host you want to manage. Some won’t, in which case will use for example ssh to log in and complete its job. Which one is better? I prefer agentless, the less component we have the less we have to worry about. Still, there are some outstanding products that require agents installed. In general, I don’t think that purely this should be a deal breaker.

Imperative or Declarative

Imperative, or procedural CMs are executing commands/modules one after the other, so it expects you to write the configuration in a way that you’ll know what outcome you expect. You say how, and not what you want. One example is, Ansible.

Declarative CMs are about defining the end goal you want to see on your machines you manage. How it’s done? That’s handled completely by the CM itself. You say what, and not how you want. One example is Puppet.

Which one is better? If you are a control freak who is very sensitive about the details how things are processed, then imperative  is your thing. If you don’t care, or even you don’t want to care, then declarative  may suit you better.


My choice is usually based around simplicity. That gives me the chance to design the task at a low level, exactly the way I want, and execute it the quickest, easiest way possible. That’s why I prefer Ansible whenever I have a choice. Still, I have to admit that SaltStack’s diligent nature is impressive, and even though it’s a bit more complicated than Ansible, it’s a joy to work with.

Most of the CMs today are doing a good job, and you can’t go wrong with any of them. Unless you have a very specific, extreme use case, just go through my reviews and pick one that works for your taste.

Configuration Managent ToolGH stars (k)LanguageReleasedCompany
Puppet5.1C++, Ruby2005Puppet
Chef5.4Erlang, Ruby2008Chef
Rudder0.2Scala, C2011Open Source