Is puppet dev-ops?

Is puppet a Dev-ops tool?

Contentious and controversial: I do not believe puppet is a dev-ops tool.

It is true it once had its place; and maybe it still does easing sysadmins into a configuration management type program. As a frontrunner to the new line of devops/sysadmin tooling also including chef, ansible and salt; puppet emerged prior and prominently cementing its place among organisations as “the” tool to filling the void of bash script automation or being the successor to cfengine. Sysadmins felt familiar with it and comfortable. Its DSL became accepted as many new adopters felt that they were not writing code, yet writing configuration files; a skill that kept them from being branded “programmers” or needing to adopt a coding mindset.

Yet the old sysadmin ways remained; you could not run puppet against a vanilla, untainted server; bash scripts and other orchestration frameworks had to be built or remain in place in order to get puppet to “be puppet”. Combining this with an archaic “sysadmin” vs “developer” division where sysadmins held the keys to the kingdom, madness ensured. Puppet, the exciting new tool, was being used for orchestration and releasing code to entire systems. The sysadmin culture excluded coding practises like version control and build pipelines to exist for the artefact being the puppet configuration.

Employees would mash in odd community modules of the same taint to their own configurations in a declarative fashion, bypassing inbuilt modules and functions to run shell commands remotely, all to run puppet and hope dependancies, modules and manifests ran in a correct order in order to produce some kind of outcome.

So when it comes to the idea of describing your infrastructure in code, the mark seems to be completely missed.

Chef seemed to gain popularity shortly after puppet; seemingly putting more power back into the developers hands. With its more true to heart ruby DSL, bootstrapping capabilities and an every increasing number of recipes/cookbooks. Allowing developers to provision their server directly in ruby code if need be, comfort was created to a new audience; developers, developing the operational/system aspects of the system, taking back control from sysadmins. Though it had questionable upgrade procedures, scaling issues in its monolithic server/client based design and more complex structure; I would suggest, due to its uptake, audience and users bringing in development practice into this area; presented itself as a “devops” tool.

With salt and not long ago ansible being the latest tooling craze; both sporting an easy to learn YAML config and lending into an imperative paradigm; It is commonplace to use version control, build, spec tests within our dev-ops tooling systems and workflow.

With devops teams now using agile methods, doing code reviews, using git while more and more teams are treating their infrastructure as an artefact of code; puppet seems has lost its place in our modern dev-ops world.

Note: This is all my pure opinion channelled into an amusing post :)

Puppet is actually a great tool that as PuppetLabs mentions builds a tool “anyone can use” and there are lots of great pros out there, using good business coding paradigms, who make just ace stuff.