3 Pitfalls of Internally Developed Configuration Management Tools
The needs and benefits of configuration management software (CMS) to manage environments have long been recognized, even before the explosion of system growth due to virtualization and cloud computing. “Towards a High-Level Machine Configuration System” was not the first paper written about configuration management, but it underlines the need for configuration management software existed as far back as early 90s. Due to the lack of viable solutions, early adapters in this field had to create various homegrown solutions ranging from make, bash, and perl scripts tied with version control software such as CVS to manage complex environments. Rolling your own configuration management tool may have made sense back when Linux fit on floppy disks and open source was a new vocabulary where there were no viable options. But today, there are compelling reasons to adapt and convert to a tool like Puppet rather than writing and maintaining an in-house configuration management tool. Why should you make the effort to migrate to Puppet from an existing solution? 1. The cost to develop and maintain the entire tool chain. It’s cost-prohibitive for organizations to write and maintain a custom configuration management tool due to the time and cost to develop and maintain the software as well as training users on the custom solution. The initial developer/admin is often the only expert on the internally developed software, and this creates a vicious cycle of difficulty for hiring people who can understand and extend the home grown tool, which is often neglected and no longer maintainable. This often leads to new staff rewriting the same solution in a new language to replace the existing tool. 2. The complexity to support multiple platforms and large environments. Scripts developed internally were rarely flexible enough to handle multiple platforms. The internally developed solution is often targeted for one platform, so it needs to be ported and rewritten for another operating system, or even a newer version of the existing OS. And as the number of systems grows, the homegrown tool (which is usually several tools chained together) will stress and often break as the environment scales. Puppet, which is supported on most Unix platforms, has been tested and proven in several large-scale infrastructures. Now with Puppet Enterprise, Puppet is scalable out of the box with full stack including Ruby along with Apache and Passenger. 3. Lack of user community and open source ecosystem. Very few of the tools developed internally have adapted a clear licensing policy, so it’s rare for them to be published, documented, and reused/adapted outside the organization. This severely limits the scope of the users, and the number of minds that can work on any problems that may come up within the system. Puppet is open source, and users have published modules to deploy applications and extend functionality at forge.puppetlabs.com. There are thousands of users on the puppet user mailing list and hundreds of active participant on freenode #puppet—which means countless resources to help anyone writing Puppet manifest or extending Puppet on their own. If these reasons convinced you to check out Puppet, see our intro to Puppet documentation, and download Puppet Enterprise.