Updated on February 4, 2016 by UpGuard
Two factors have resulted in a corresponding increase in the number of servers supported by today’s sys admin - virtualization and the massive growth of computing in the organization. Even in small and medium-sized companies, it is not unheard of to have a sys admin supporting 4 servers or so. And of course, this number only goes up as the size of the organization increases. Enter configuration management (CM) tools like Puppet, Chef and Salt. Make no mistake, any of these tools will truly simplify your life as a sysadmin, by automating and minimizing the drudgery of manual server setup and creation. But which one should you go for? As with IOS vs. Android vs. Windows Phone, X-Box vs. PlayStation vs. Wii, each has both diehard loyalists and vociferous critics. The answer, again as happens in many of these wars, is that you need to match and compare each contestant’s capabilities to your own needs, and judge for yourself.
Puppet is the elder statesman of CM tools. It has been around for the longest time, it has the largest user base and market share. It was developed in 2005 by Luke Kanies, and is an open-source product that also has a commercial version developed and supported by Puppetlabs. The product can brag having high-profile organizations on board as clients – these always lend useful credibility. Some of these clients are Google, Reddit, Dell, PayPal, Oracle, Los Alamos Labs, and Stanford University. The working language is Ruby, but Puppet also has a well-developed web-based UI for (admittedly limited) configuration and setup tasks. Most users will find that the GUI is more of a viewing and informational tool, and most fine-grained work will inevitably require learning how to use the CLI. Puppet’s CLI makes use of a customized DSL loosely based on Ruby. This is roughly akin to database vendors’ implementation of customized version of the standard SQL to manipulate their own relational databases (Microsoft’s T-SQL, Oracle’s SQL*Plus). Having a DSL is both good and bad; good because it allows Puppet commands and structures to be defined quickly with a minimal amount of coding, and bad because it of course requires one to first the DSL itself. According to Kanies: “One of the benefits of Puppet’s DSL—beyond the simplicity—is that it encourages the mental shift that Puppet requires. To use Puppet effectively, you need to think in resources, not files or commands. If you wrote your configurations in Ruby, you could easily just open files and run commands all the live-long day, but with the DSL, you have to learn to think in resources.” (link: http://puppetlabs.com/blog/why-puppet-has-its-own-configuration-language ). PuppetLabs has also developed an alternative DSL that allows users to use pure native Ruby code and statements, but this is being deprecated in favor of the Puppet DSL.
The creation of Salt, aka SaltStack, was largely the work of its co-founder, Tom Hatch. His street cred in CM development stems largely from his long-time use of both Puppet and Chef. He felt dissatisfied with both, particularly their slowness and over-reliance on Ruby. So he started work SaltStack, choosing the more widely used and arguably easier to use Python as Salt’s working language, as opposed to Puppet’s Ruby. Salt was open-sourced in early 2011 and boasts a growing fan-base, including at last count at least one famous, high-profile enterprise customer – LinkedIn. Salt now also contains an enterprise package for very large deployments. Salt leverages the ZeroMQ message bus, a lightweight library that serves as a concurrency framework. It establishes persistent TCP connections between the Salt master and the various clients, over which communication takes place.
Community, Platforms and Support
Having been around for longer, Puppet of course boasts a much larger community. It is also supported by a relatively well-established commercial parent company, PuppetLabs Inc. Large corporations are oftentimes jittery about taking risks on expending their resources and partnering up with small, somewhat unknown corporations (think Linux in the early days). To such clients, a tool like Puppet is a godsend. Puppet is available on all the major operating systems – Windows, Linux and MacOS X. However, Puppet’s maturity, commercialization and sheer size have also resulted in a somewhat disgruntled minority. The market can be a fickle mistress, and there have been increasingly vocal protests at Puppet’s lack of agility, slow responses, and pushing users aggressively towards the commercial package.
Salt is definitely the upstart in this field. It has a growing and very active and very helpful community and support group. Tom Hatch has a reputation of being one of the small breed of corporate execs who truly listens to user suggestions and criticisms. Among its user base and in the CM market, Salt is rapidly gaining a reputation as a “CM tool done right the first time”.
Product Performance, Ease of Use
Version 3.0 of Puppet, introduced in Q2 2013, introduced a significant speed boost, mainly due to a new orchestration engine. This allows finer-grained filtering to select subsets of systems to modify or directly control, as well as batching functions to permit a gradual rather than all-together rollout of changes. Another major change is the better support of Windows servers. Several earlier features such as Live Management (a browser-based UI for real-time node management) did not work with Windows. Version 3.0 now introduces Live Management and orchestration of Windows servers. Also, the Puppet interface’s duality - both GUI and CLI - means that many newer users and many non-developer sysadmins find it easier to learn than CLI-only tools. Some notable downsides are:
The SaltStack team, on the other hand, is reputed to be very receptive to feedback, both positive and negative. They also have a knack for quickly resolving problems as they arise. The user base is vibrant and always ready to assist. The caveat here is that Salt is still relatively new, so whether the goodwill, open-source camaraderie, the product-first profit-later mindset, and lack of egos and politics will persist, only time will tell. That said, Salt also suffers from its own niggles, many of which are simply due to its newness. For instance if you mess up a pillar (centrally located data set) in Salt, your deployed minions will not show any pillar data, and also won’t tell you why this error occurred. Salt also has a GUI tool called Halite under development, but as at November 2013, it is still very much a beta tool; buggy and bare-bones. So for now it is essentially a CLI-only product supporting the Python language, which even its ardent critics admit is a orders of magnitude faster than a Ruby-based product like Puppet. Salt's biggest advantage is its scalability and resiliency. You can configure multiple levels of masters, resulting in a tiered arrangement that both distributes load and increases redundancy.
So in the final analysis, Puppet or Salt? You may as well walk into a used-car lot and ask “Which car is best for me?” The answer is that it depends on several factors, the main one being “What do you need?” Do you require a mature tool for sys admins rather than developers, do you have a heterogeneous environment with multiple operating systems? Then Puppet may be better for you. Or are you attracted to a relatively new product with a stable base but some kinks still to be ironed out? One without a GUI for now, and limited to a homogeneous setup, but with a very active user community, a la Linux in the early 1990’s? Then Salt may be your preferred choice. Do your research and pick whichever tool suits your needs. But remember, you really cannot go wrong with either one. Even a used car that fulfills most but not all your needs still beats having to walk everywhere.
References and Further reading
Misconfigurations are an internal problem that emanate from within the IT infrastructure of any enterprise; no hacker is necessary for massive damage to occur to digital systems and stored data. And the problem is pervasive, with Gartner estimating anywhere from 70% to 99% of data breaches result not from external, concerted attacks, but from internal misconfiguration of the affected IT systems.