Simplifying configuration management with Configuration as Code

With the surging speed of development and deployments, tracking the release pipeline and changes made is becoming difficult. Configuration is no exception to this. Configuration management was never a luxury but has become a necessity now with all the rapid changes. Everyone has a defined process to test every change in environments before finally moving toward production. In this scenario, establishing and maintaining consistency of performance, functional & physical attributes, and operational information is vital. This is where Configuration as Code has a significant role to play. Backed by the version control system, it assists with the formal migration of configuration between several environments. So, to make a choice when you have an enormous amount of configuration files, Configuration as Code (CaC) can be one of the best practical choices.

Configuration is anything that can be tweaked to change application behavior. Configuration does not affect the overall application behavior, but it empowers an application for better performance, extendibility, launching its replica service, and selecting several available options. From this, CaC may sound to you like a config file that is written once and is ready-made to use everywhere. However, it is not that simple. The best Configuration as Code can have its source control repo, a build & deploy process like code & code pipeline configuration, and test environments for the deployment cycles.

What is Configuration as Code?

Configuration as Code works on a simple principle - "treating configuration just like code." For people who handle configuration "out of band," it is crucial to check the configuration into version control. Simply put, it is a configuration that can be migrated from one environment to another. The only condition is version control. While setting up configuration files into code, teams need to figure out ways to store them in your version control system. Let's see them one by one.

How to store configuration in a version control system?

Now there are multiple ways to do that, which include:

Storing code and configuration into the same repo (Monorepo): Monorepo strategy could simplify your pipeline by keeping all your files in the same repo. However, if you are treating configuration files like source code, it could trigger a new build after every change to a setting. This could slow down your team and can be avoided.
Storing code and configuration files together (component/microservices): In microservices, development teams usually split their code into several repos. It would be wise to bundle your code and config files together along with the particular microservice. However, it would help if you made sure that any changes made to the config are propagated.
Storing code and configuration in different repos (Separation): Instead of storing code and configuration in the same repo, some teams prefer to have their configuration code in a repo all by itself. Although, it is not practical for most applications. This model can be helpful for rollbacks, audits, and reviews.

With CaC, you migrate configurations in your release pipeline alongside your application code. Like any other code change, you can change a setting that you can branch based on your system. Make sure to test it in each environment before merging it back into the pipeline for production.

Now the interesting part is, depending on what tools you use and how you manage the infrastructure, there is a possibility that some of us might get confused between IaC and CaC. In one of my previous blogs, "What is Infrastructure as Code and why should you go for it?", as the name suggests, I talked about what IaC is. Now, let me explain the difference between Configuration as Code and Infrastructure as Code.

Difference between Configuration as Code (CAC) and Infrastructure as Code (IAC):

Many people tend to get confused between the terms CaC and IaC and assume that both are similar. But the reality is that they aren't the same. Infrastructure as Code is used to manage and provision your infrastructure with the help of a code instead of the usual manual process of configuring devices or systems. And to assist with this, there are some great tools like Puppet, Chef, Terraform, and Amazon's Cloud Formation. On the other hand, if you want to manage your application configuration data in a defined manner, then Configuration as Code should be your choice. I would specifically like to mention that both IaC and CaC come under configuration management, and both of these are extensively related to defining or scripting application environments. If you look at the requirements, then IaC needs to define environments that include the networks, servers, and other compute resources in a text file that is utilized as the base source for creating and updating the environments. Whereas in CaC, you are responsible for defining the configuration of your servers, code, and other resources in a text file and can be utilized as the base source for creating and updating the configurations. So, it would be correct to say that both manage two different sides of your IT environment.

Now that it is clear when to use IaC and when to use CaC let's see why you should use CaC and when you should avoid it.

Merits and Demerits of Configuration as Code:

Before you adopt configuration as code, I feel you must know its pros and cons. To make it a little simple for you, I am listing down some of the significant pros along with the cons of CaC.

Pros of CaC:

The configuration is standardized, and you can check the standardized config in the version control.
It doesn't require every operation or DevOps engineer to develop their own scripts to get the work done.
It is pretty easy to configure & reconfigure an environment as everything in the configuration is tested in advance.
It is a big time-saver for a project or a team, and it is also capable of limiting the number of human errors that can be introduced in our systems.
CaC works as a good option for recovery purposes. You can quickly restore your environment in case of a disaster if you have the configuration along with the scripts to install.
CaC increases your reliability and improves the system's uptime as well.

Cons of CaC:

It is pretty tough to maintain the scripts and configuration.
Transferring CaC to cross teams or to an enterprise level has limitations due to the complexity of environments.
There is very high chance that many of your configurations won't be in use any longer during the restoration because the products running in production at the time of disaster couldn't be purchased for rebuilding it. So, it is essential to replace your infrastructure with the newest products constantly.

Any technology requires a certain period to mature and to gain the adoption pace. I believe that now is the right time to embrace Configuration as Code in a controlled manner. Like any other adoption process, the best way to approach CaC would be to start with a plan and then make iterations to adopt it and improve. Get in touch with us to know how you can start with your CaC initiatives.