Puppet’s history and relationship to DevOps
Puppet was started by creator and founder Luke Kanies, who was working as a sysadmin and consultant. He was unable to find the tooling he wanted to use and that his customers could rely on, so he created Puppet as a Ruby-based open source configuration management language in 2005. The success of this open source project resulted in the release of a commercial offering, Puppet Enterprise, in February 2011. But as the demands increased and Puppet needed to reform and expand as both a company and an open source project, Luke stood down, stating that the challenges of growing Puppet to enterprise-scale were far from what I love to do most, and far from my core skills. We need to scale, and we need to execute.
The new leadership that followed took a direction that saw the company develop its professional services, and focus more effort on developer tooling and education while expanding its product range both organically and via acquisitions, striking a difficult balance between the open source community and its enterprise customer demands. Puppet was acquired by Perforce Software on May 17, 2022, following the Chef (2020) and Ansible (2015) acquisitions, as the last of the standalone configuration management start-ups. Luke summed up the change that has taken place in the industry: DevOps teams are different now. Companies are looking for a complete solution, rather than wanting to integrate individual best-of-breed vendors.
This history has seen Puppet move from a tool that left it to the developer to decided how best to use it to solve problems to, today, a tool with patterns and solutions that users can just consume to standardize their automation and deployment. This has allowed users to focus on their solutions and not the underlying technology.
DevOps itself has become a frustrating term in the IT industry; the definition given by formal sources differs hugely from how companies actually use it, and references to it can be used as a cynical buzzword or sales gimmick. The focus of this book is on DevOps engineering, as used particularly by large companies and has been well researched and discussed in studies such as the Puppet-run State of DevOps Report. DevOps engineering is normally delivered as part of projects such as digital transformations, cloud-first migrations, and various other modernization projects. What is typically seen in these projects is a desire to automate self-service deployment, compliance, and remove toil. This approach follows the DevOps goal of breaking down the silos between developers and ops teams by allowing better communication and establishing shared goals. What is noticeable is that the system administrator role in which Luke worked originally has effectively been replaced by roles such as DevOps engineers.
Puppet will be used as part of a DevOps toolchain, and Figure 1.1 shows an example set of tools and their relative functions. It is typical for Puppet to start its role at the end of a provisioning pipeline, as infrastructure is stood up in a platform and needs to be configured and enforced:
Figure 1.1 – A DevOps toolset
This book will focus not just on a technological understanding but also on how to use the maturity of the Puppet language, tooling, and platform with opinionated patterns. These approaches have been developed through years of customer engagements for Puppet and the communities’ own implementations to allow users to reduce their effort in finding the right approach, focus on their solutions, and deliver immediate benefit and return to their customers.