Fotolia
Standardize configuration management software for smoother DevOps
If your organization uses different configuration management software for development and operations, you're not alone. Even better, it's no engineering feat to migrate to one main tool.
Innovation and standardization always stand at odds: Standardization encourages mediocrity, but a lack thereof opens the gates to chaos and mayhem.
With the advent of software-defined infrastructure, the battle in many IT organizations has shifted from equipment and end-user application standardization to DevOps toolchains and infrastructure automation, as in configuration management software.
Configuration management and related automation software often enter an organization thanks to a creative individual's attempts to increase efficiency. Organizations commonly have a plethora of configuration management tools, often with overlapping functionality, installed in different departments. Personal preference, the idiosyncrasies of a particular job or workgroup and the persuasiveness of early adopters create this bevy of unstandardized tool sets. The question for IT managers is if it's possible to herd these cats and if the benefits of standardization on one tool -- such as efficient code sharing, reduced training, repeatable processes and lower management overhead -- are worth the effort to change, the disgruntled employees and the reworking of existing code and processes.
When it comes to infrastructure configuration management software tools, the disruption caused by tool consolidation is often minimal, as popular products, such as Ansible, Chef and Puppet, mostly cover the same workflow, just differently. Of course, each has its unique strengths and weaknesses: Chef integrates and packages modules into a complete installation package, and Ansible uses distributed, agentless, cloud-optimized architecture, for example. Each automates standard system and application configuration installations well, which means the team can pick just one tool for everyone.
Nuanced feature differences are seldom the deciding factor in this configuration management software choice. For example, one software engineer found that a company he joined used both Chef and Puppet but, soon thereafter, consolidated on the latter. More of the company's infrastructure was already automated in Puppet, so there wasn't much code that the staff had to replace from the Chef systems. Experience and a built-up code base in a given configuration management software tool create an unwillingness to learn something else -- that inertia is often the best reason to choose among two or more substantially identical tools. In the fast-moving world of DevOps and cloud infrastructure, IT teams don't have the time for exhaustive comparisons and software bake-offs.
There are legitimate technical reasons to choose one tool over another. The decision ultimately comes down to the desired results, process workflow and user's job responsibility. To categorize configuration management software tools, separate the two halves of DevOps -- development and operations -- and look at software designed for developers versus that tailored for operations.
Application and service assembly in dev tools
Configuration management software originated to automate application development. Version control systems, such as Concurrent Versions System and Apache Subversion, and build automation tools, such as Make, transform configurations and process steps into repeatable scripts. These have been staples of software development for decades. As more of the runtime infrastructure became virtualized, the ability to automate the software lifecycle expanded to include system and application configuration and provisioning.
Ansible, Chef, Puppet and Salt occupy this configuration management software space. According to an annual survey of cloud users by cloud management provider RightScale (see the figure), almost half of the respondents use or to use Chef and Puppet in their organization, with Ansible third. Each of these configuration management software vendors cites major online services and large enterprises among its customer base.
Each of these configuration management software tools use popular scripting or configuration languages, like Erlang, Python, Ruby, YAML or a custom domain-specific language -- such as used by Puppet -- to describe a system's desired state or how to procedurally achieve it in reusable documentation. Although these tools were initially built for application configurations, they have incorporated features to automate virtual infrastructure deployment. For example, Amazon Web Services (AWS) adopted Chef for its OpsWorks configuration management software platform for Elastic Compute Cloud instances. Although OpsWorks can deploy instances and other services, many operations teams on AWS prefer to use an infrastructure templating service, such as CloudFormation, to manage actual resource deployment and scaling. The dichotomy between application and instance configuration and infrastructure templates is significant as it's the reason many organizations end up with multiple configuration management tools.
Infrastructure provisioning, management for ops
IT operations teams are less concerned, if at all, about the internal configuration of a VM, aside from its underlying OS, than instance details, such as the number of virtual CPUs, , network interfaces and any attached storage volumes. Tools that standardize cloud or virtual service configurations and automate deployments with resource templates are more valuable than software that automates the internal state of application images.
Infrastructure orchestration software -- AWS CloudFormation, Google Cloud Deployment Manager, HashiCorp Terraform, Tryolabs' Metamon project -- aims primarily to deploy new cloud infrastructure, not manage the configuration of machines that already exist. Microsoft partnered with HashiCorp to use Terraform to provision Azure services, for example. Orchestration and configuration management software aren't always sufficient to automate an entire workflow -- HashiCorp offers the Atlas suite to address this, with tools for the entire application delivery lifecycle from code check-in and image to infrastructure instantiation and image deployment.
That complex DevOps toolchain
Automation is the key that unlocks efficient, repeatable, agile DevOps processes, but software is only the vehicle. Start with a clearly defined and detailed manual process that's been tested and refined. Gates wisely stated that automation in efficient operation increases that efficiency, and the same goes for the opposite.
Although standardization within process categories is valuable and necessary, a complex, multistage DevOps toolchain likely requires more than one tool to automate the entire lifecycle. An increasingly popular option to simplify the deployment process and improve repeatability is immutable infrastructure, which integrates server configuration with application code into an image that is the atomic unit used for deployments. Organizations using the model have less need for configuration management software tools, instead focusing on source code control, image packaging and infrastructure deployment.
If overhauling DevOps and application lifecycle processes is too unwieldy of a proposition, the best of action is to standardize on the fewest number of tools to create an automated workflow.
The right configuration management and automation tools depend on an organization's larger strategy, including cloud agnosticism; support for multi- or hybrid cloud; choice of cloud platform, both public and on premises; any legacy code; and the language expertise and preferences of its DevOps personnel.
