Configuration Management: What Is It and Why Is It Important?

Reading time 13 minutes

Configuration management is an increasingly important foundation for a successful tech platform. Good leaders in the tech space will want to know what it takes to implement it. If that’s you, you’re in luck! In this post, we’ll discuss a few key things:

• What configuration management is and where it originated from.
• The benefits of configuration management.
• How configuration management fits with concepts like DevOps and agile.
• How you can get started with configuration management.

Sound good? Let’s get going.

What Is Configuration Management?

Here’s my definition of configuration management: it’s the discipline of ensuring that all software and hardware assets which a company owns are known and tracked at all times—any future changes to these assets are known and tracked. You can think of configuration management like an always up-to-date inventory for your technology assets, a single source of truth.

New for Test Environment Managers

Solve the Achilles’ Heel of Software Delivery. End test environment headaches in just 4 weeks. Starting at $25K.

Learn MoreConfiguration Management & Planning

With that defined, let’s talk about how it works in practice. Configuration management usually spans a few areas. It often relates to different ideas, like creating “software pipelines” to build and test our software artifacts. Or it might relate to writing “infrastructure-as-code” to capture in code the current state of our infrastructure. And it could mean incorporating configuration management tools such as Chef, Puppet, and Ansible to store the current state of our servers.

Where Did Configuration Management Originate?

When I first started learning about configuration management, I found the concept super confusing. However, it turns out that there are reasons for the confusion. But to understand why, we need to look at some history.

We (the Software Industry) Stole the Idea of “Configuration Management”

The idea of configuration management comes from other institutions, such as the military. We took those ideas and retrofitted them into a software context.

How We Make Software Has Changed Over Time

Configuration management was traditionally a purely manual task, completed by a systems administrator. The role was a lot of manual work involving carefully documenting the state of the system. But the industry has changed completely. These changes came from the popularity of DevOps, increases in cloud computing, and new automation tooling.

Now that we’ve set the scene, we can dive into the details of configuration management. So let’s get to it!

What the World Looks Like With Configuration Management

Before we explore different tools for configuration management, we need to know what end results we’ll receive for our efforts.

What are the outcomes of well-implemented configuration management?

Let’s cover the benefits.

Benefit 1: Disaster Recovery

If the worst does happen, configuration management ensures that our assets are easily recoverable. The same applies to rollbacks. Configuration management makes it so that when we’ve put out bad code, we can go back to the state of our software before the change.

Benefit 2: Uptime and Site Reliability

The term “site reliability” refers to how often your service is up. I’ve worked at companies where each second of downtime would cost thousands—often tens or even hundreds of thousands. Eek!

A frequent cause of downtime is bad deployments, which can be caused by differences in running production servers to test servers. With our configuration managed properly, our test environments can mimic production, so there’s less chance of a nasty surprise.

Benefit 3: Easier Scaling

Provisioning is the act of adding more resources (usually servers) to our running application. Configuration management ensures that we know what a good state of our service is. That way, when we want to increase the number of servers that we run, it’s simply a case of clicking a button or running a script. The goal is really to make provisioning a non-event.

These are just some of the benefits of configuration management. But there are some other ones, too. You’ll experience faster onboarding of new team members, easier collaboration between teams, and extended software lifecycle of products/assets, among other benefits.

The World Without Configuration Management

Sometimes it’s easier to grasp a concept by understanding its antithesis. What does trouble look like for configuration management, and what are we trying to avoid? Let’s take a look.

A developer implementing a feature will commonly install a few bits of software and deploy code. If things are sloppy, this developer probably makes the team and manager aware of the intention to come back later to clean it all up—that it’s simply a demonstration and will be rewritten soon.

But then the deadline starts pressing, and the task of going back through and rewriting the installation steps as a script gets pushed lower and lower in priority. Before we know it, several years have passed, and a new developer gets put on the project. That developer is now left to pick up the pieces, trying to understand what happened. It’s quite likely they aren’t even going to touch the configuration of the server. Who knows what it would do!

The above situation is precisely what configuration management helps you avoid. We don’t want to be left in the dark as a result of developers setting up software without proper documentation/traceability. Rather, we want to know the answers to questions like

• What services are we running?
• What state are those services in?
• How did they get to their current state?
• What was the purpose for the changes?

Configuration management can tell us these answers.

That hopefully paints a clearer picture of the problems that configuration management is trying to solve.

How Configuration Management Fits in With DevOps, Continuous Delivery, and More…

Hopefully by now you’re starting to get the hang of what configuration management is and what it aims to do. Before we go on to discuss tooling, I’d like to take a moment to address how configuration management fits in with other software development concepts like agile, DevOps, continuous integration, continuous delivery, and Docker so that you can understand how these concepts fit in with the ideas of configuration management.

Is Configuration Management Compatible With Agile?

Yes. Agile software, by definition, reflects the desire to make changes to our software faster so that we can respond to market demands. Configuration management helps us to safely manage our changes and keep velocity high.

How Does Configuration Management Fit With DevOps?

DevOps is the extension of agile practices across both the development and operations departments. In fact, DevOps seeks to unify the goals of both departments. At some companies, the development department seeks change while the operations department seeks stability. But companies that embrace DevOps want both stability of their deployed assets and frequency of change. However, achieving this outcome requires cultural change.

Like agile, configuration management gives teams the confidence to move quickly with their changes. Under agile practices, the company gives configuration management responsibilities to the development teams, empowering them to provision, configure, and manage their own infrastructure. You build it, you run it.

Where Do Pipelines Fit Into Configuration Management”?

Software pipelines are the steps (or “value stream,” which we can create with tools like Plutora) that we usually automate, taking code from commit to production. Pipelines usually involve steps such as linting code, unit testing code, integration testing code, and creating artifacts. A software pipeline therefore is a form of configuration management. When we build software with tools like Docker, we codify our build instructions into our Dockerfile. This allows us to better understand the dependencies of our artifacts.

Is Infrastructure-as-Code Configuration Management?

Infrastructure-as-code (or IaC for short) is the practice of ensuring all provisioned infrastructure is done so through code. The purpose of IaC is to have a written record of which services exist, where they are located, and under what circumstance. Configuration management might choose to leverage aspects of IaC in order to achieve the full understanding of all the technology assets a company owns.

Is Continuous Integration/Delivery Configuration Management?

Continuous delivery is the process of ensuring that software is always in a releasable state. You can achieve this through heavy automation and testing. Continuous integration is the process of bringing separate software artifacts together into a single location on a frequent basis, for the purposes of verifying that the code integrates properly. Continuous integration tools, which are typically servers that run automation-testing suites, act as a form of configuration management by providing visibility into the steps required to set up and configure a given software artifact.

That should clear up some of your lingering questions about how configuration management fits with some practices or ideas that you might be using or are familiar with. Any discussion of configuration management would be incomplete, however, without a discussion about tooling. So, let’s take a peek at the different tools we have at our disposal for implementing configuration management.

The Importance of Declarative Style in Configuration Management Tools

Next up, we’re going to discuss configuration management tools. But before we get to that, I need to quickly discuss a concept to consider when comparing tools. And the concept is declarative style. You’ll hear about this terminology a lot if you go out and start looking into different configuration management tools. So, it makes sense to have a firm grasp of what declarative style is, why it’s important, and why so many people are talking about it.

So, what do we mean by declarative style?

And why is declarative style so important for configuration management?

What Do We Mean by Declarative Style?

When it comes to software, having a declarative style means telling your software the end result you want and then letting the software do the work in figuring out the way to get there. The opposite of the declarative style would be a procedural style, where instead of giving an end state, you give instructions on how to get there. The problem with instructions is that they’re dependent on the starting state.

You can think of it like this: declarative versus procedural is the difference between giving a friend your home address and giving them step-by-step instructions to get to your house from where they are. The problem with giving step-by-step instructions is that it assumes you know where the friend is starting, and it doesn’t allow for things to go wrong. It’s hard to replay steps when you’re in a bad state (i.e., lost!).

Why Is Declarative Style Important for Configuration Management?

By now, you’re probably thinking that declarative style sounds interesting. But why is it important?

Declarative style is important because configuration management is all about knowing the current state of your applications. So when we use configuration management tools, it’s desirable to use a declarative style and specify the end result that we want, not the steps to get there. This means we always know what end state we’re trying to achieve and how that’s changed over time. That’s instead of trying to work out when instructions were run and dealing with the complexities that may arise if certain instructions have failed.

What Are Configuration Management Tools?

There are many different tools for configuration management. In fact, it can get confusing, as there are tools that support configuration management without explicitly being configuration management tools.

For instance, Docker neatly packages up steps needed to set up and run an application (in a Dockerfile). However, people don’t often consider Docker a configuration management tool.

To make things clearer, let’s divide up the common tools that might fall under or relate to configuration management:

Configuration Management Tools

These are the tools you see typically associated with configuration management. Tools like Chef, Ansible, and Puppet provide ways to codify steps that we require in order to bring an asset in line with a current definition of how that asset should look. For instance, you might create an Ansible playbook that ensures that all of our X servers have Y installed within them.

Infrastructure-as-Code Tools

Often also called provisioning tools, IaC tools include CloudFormation and Terraform. If our configuration management tools include the setup we need on our assets, our provisioning tools are how we get those assets. It’s this blurred line that explains why we need to bring these tools into our discussion of configuration management. And many consider it an anti-pattern to use configuration management tools for provisioning.

Pipeline Tools

We talked briefly about software delivery pipelines, but implementing them requires tooling. Popular technologies include Jenkins, CircleCI, and GitLab CI. By using tools to codify our build process, we make it easy for other developers to understand how our artifacts are modified and created, which is a form of configuration management.

Source Control Tools

Source control tools include GitHub, SVN, GitLab, and Bitbucket. While we need to codify our automation in scripts, if we don’t appropriately track the history of our changes, then we aren’t really achieving configuration management.

We’re now nearing the end of our introduction to configuration management. We’ve covered what configuration management is, we know the benefits, and we’re now up to date on the latest tools. However, all of this information can be a little overwhelming if you’re asking the simple question of “Where should I start?”

Let’s break it all down so that you can start your journey into configuration management.

How Can I Get Started With Configuration Management?

Where to start? Do you begin by researching tools? Implementing some automation? Auditing your existing servers? Talking to others in your company?

Where you start with anything always depends on where you currently are. That said, only you are aware of your current situation and the limitations and resources available. Below are three different places you can begin your journey to effective configuration management:

1. Audit your software/hardware—What software do you currently have? What’s the state of it? Is it well documented? Are the setup and run instructions known for the software?
2. Perform a tools assessment—Do an assessment of what tools exist on the market for configuration management. The ones I listed above are a good start. Identify which tools could help you solve some of your configuration management problems.
3. Learn about best practices—Successfully implementing configuration management isn’t a one-and-done task. It takes time and work to continually ensure that all new software is appropriately audited and tracked. So you might want to look into some different key concepts, such as IaC and build and release pipelines.

It’s Time For Everything-as-Code!

And that’s all! Hopefully that helps to clear things up for you about configuration management. It’s all about keeping track of the current state of your software and infrastructure.

There are many ways to implement configuration management, and there are lots of different tools and processes. So when it comes to strategy, be sure to take your time assessing options and understanding how you want your configuration management processes to work.

It will all be worth it in the end, though. Get your configuration management right and your teams will be safer, more productive, and faster to make changes!

Good luck—and from now on, audit, track, and write everything-as-code!

Lou Bichard

Lou is a JavaScript full stack engineer with a passion for culture, approach, and delivery. He believes the best products emerge from high performing teams and practices. Lou is a fan and advocate of old-school lean and systems thinking, XP, continuous delivery, and DevOps.