Five Reasons You Need Enterprise Configuration Management
by Eric Olsson
Software is buggy. It’s a bold claim, I know. Sarcasm aside, the battle to keep your applications up and running is ongoing. Wouldn’t it be nice if you had a way to eliminate an entire class of bugs from your application? Enterprise configuration management can give you this benefit. Engineers shouldn’t have to spend their time chasing down a bug that ultimately is caused by a production system that isn’t correctly configured.
Even if you’re running a smaller business and roll your eyes at the term “enterprise,” the practices and tools are worth considering. When better to introduce the practice than when your application is relatively small and simple to configure? Perhaps you’re willing to find out a little bit more about it. Well, let’s define our terms and then dive into five reasons why you need enterprise configuration management.
Setting a Foundation
To start us all off at the same point, let’s take a look at enterprise configuration management. Wikipedia has an easily understood definition of configuration management: “[Configuration management] is the practice of handling changes systematically so that a system maintains its integrity over time.” Therefore, enterprise configuration management is the practice of handling changes systematically so that the systems within your enterprise maintain their integrity over time. To put it another way, you want changes made to your application and environments to be controlled and tracked rather than done adhoc.
Defining Good Configuration Management
With a definition in hand, let’s now turn our attention to why you need enterprise configuration management (ECM). To do this, we’re going to follow two people who are also learning about ECM, Katie and Bree. Bree has been around since the beginning of her company’s application. When the company was just in the founder’s garage, she was doing it all. She wrote some of the first lines of code for the application. When version 1 was ready for customers, she was configuring the web server on the box. So today, whenever someone goes spelunking into the older parts of the application, Bree is usually the first person they call.
Katie, on the other hand, is a relative newcomer to her company. It’s a larger company with multiple applications deployed across multiple environments. They have a pretty good process in place for deploying code to a test environment for QA to test. From there, the application gets deployed to a staging environment. In this environment, the product managers do some last-minute testing and check out the new features. Finally, the production environment is complete, and it has a backup environment in case of disaster.
Together with Bree and Katie, let’s dissect why we need ECM.
1. Configurations Must Be Genuine
This one resonates with Bree. When she was setting up her company’s first server, she did all she could just to get it running. She had to learn things like web server configuration and hardening on the fly. Over time, she updated the server and tweaked it as the application changed and new threats emerged. At some point, John, her manager, had asked for a set of instructions to be able to recreate the setup. Internally, Bree groaned because she knew there was no way to recapture all those steps.
A configuration that’s genuine means that whatever configuration steps exist are accurate. The configuration doesn’t exist merely for the sake of being able to say that you have “configuration management.” If you need to entirely recreate an environment, you should be able to do so just using the configuration. You shouldn’t need a Bree in your office to “finish up” after you think the server is set up.
Ideally, the set of instructions involves minimal-to-no human interaction. At the very least, you want a set of accurate instructions to follow that yield a fully configured server. And that server had better match the rest of your environment. If any of the following ring true, you may need this:
- Making some final manual changes to config files before deploying your application
- Running operating system patches before installing your application
- Changing an environment variable on the server before adding it to the production environment
2. Configurations Must Be Repeatable
Now let’s see why Katie wants repeatable ECM. During her first couple of weeks on the job, she needed to roll out an emergency patch to the production environment. Katie began to run the patch on the machines in the environment. When she began applying the patch to the third machine, it displayed an error. The patch complained about an invalid configuration value for the application. Now what? When she asked her colleagues, they all swore each machine was set up, configured, and deployed correctly. They each followed the steps in the work instructions. Did Katie find a bug in the patch? Or was there a mistake in configuring the production server? Can Katie be sure that provisioning, configuring, and installing the application on a new server would fix it?
ECM ensures that your machines, applications, and patch levels are repeatable. You need to know the catalog of Windows patches the server needs. Your application may rely upon a list of environment variables. You need to know these to be able to add new machines to the environment. Ideally, you’d want to eliminate the possibility for human error.
3. Configurations Should Be Automated
Both Bree and Katie benefit from this need. If your ECM automates provisioning, configuring, and deploying new servers, this is a game changer. For Bree, she no longer has to spend a work day installing and configuring a new server. Instead, she simply runs the automated tool and a new server is ready for her to deploy to an environment. She’s confident the machine is configured and patched correctly and the application installed correctly. She can focus on delivering more value to her customers, confident that she won’t be chasing environment-related bugs.
For Katie, this is table stakes for managing an application of any scale. Manually configuring new machines and installing new environments are probably forbidden somewhere in the later parts of the Geneva Convention. Tools such as Docker and Kubernetes have made great strides in automating the setup and configuration of software environments.
4. Configurations Should Be Consistent
Since we’ve already explored the need for repeatable configurations, we’re going to explore consistency in usage. Bree’s manager has asked her to bring up a new machine for a customer pilot. Bree may be tempted to just manually spin one up. She’s done this before. She tries to rationalize why ECM might get in the way of her getting the job done. While her desire to please the customer is commendable, Bree needs to use the ECM tools and procedures consistently. Otherwise she runs into the problem where a new version of the application is deployed and it fails on the customer pilot server. Now she has inconsistent configurations between production and the pseudo-production customer pilot system. Not good.
Katie also enjoys consistency but in a different way. She can’t do all the work herself. She wants to delegate the work to her team yet still be confident each deployment is correct. Having ECM in place ensures that the work is scalable across people. Multiple people can create the new machine instances. Katie can sleep easily at night knowing the environment is correct.
5. Configurations Should Be Easy
You saw a sense of this when Bree was considering how to bring up the customer pilot environment. That’s a sign that the ECM you have in place isn’t easy. If this ECM is a seven-page Microsoft Word document, then you should reconsider how easy your ECM is to use. For someone like Katie, she enjoys spending her evenings at home rather than doing off-hours deployments. If your ECM isn’t easy, your engineers will avoid it. Eliminate as much usage friction as you can.
Why Do You Need Enterprise Configuration Management?
Whether you’re like Bree in a smaller company or like Katie in a larger company, you’ll want to be able to gracefully handle your configuration management tasks. Investigate what ECM offerings are available. Manual ECM work is tedious. Save bug-bashing time. Enjoy more confident deployments of new features for your customers. Delight your customers and your workers. Make Bree and Katie happy.
This post was written by Eric Olsson. Eric was first introduced to programming in high school, and he’s been fascinated by it ever since. Most of his professional experience has been working with C# and other .NET technologies. After being introduced to agile methodologies and practices such as test-driven development, he’s had a particular interest in applying them to the code he writes.
12 DECEMBER, 2019 by Carlos Schults The software development process today is very different from what it used to be 15, 20, or even more years ago. One of the most dramatic of such differences is undoubtedly the number and frequency of releases. Agile practices have...
26 November, 2019 by Carlos Schults Your Essential TEM Checklist “Test Environment Management Checklist.” Yep, that sounds like a mouthful, but don’t let that discourage you. The idea here is quite simple—adopting a checklist to evaluate the soundness of your test...
18 NOVEMBER, 2019 by Carlos Schults Test data management is vital for achieving a healthy test automation strategy, yet many professionals are still not familiar with the term. They don’t know what the concept means, nor why it’s so important. But why would that be a...
03 NOVEMBER, 2019 by Arnab Roy Chowdhury DevOps, a word that combines “development” and “operations,” is a business process that shortens the time taken to gather customer feedback. Besides, it also enables progressive software delivery and helps clients grab market...
30 OCTOBER, 2019 by Erik Dietrich Measuring TEM Capability in Your Enterprise Once upon a time, testing your software was easy. Or, at least, relatively speaking, it was. Your team would write some code, tag an unreleased version of the software, build it, and hand it...
22 OCTOBER, 2019 by Eric Boersma If you're like a lot of developers, you might not think much about software security. Sure, you hash your users' passwords before they're stored in your database. You don't return sensitive information in error messages. Each time you...