To the man who only has a hammer, everything looks like a nail
With changing times, our tools change and the use of it as well.
In the last couple of years, a constant question has buzzed the internet what’s the difference between Infrastructure-as-Code (IaC) and Configuration Management (ConfigMgmt) and when to utilize one of them.
Are they not doing the same thing?
Why invest in something new when the same thing can be done using ConfigMgmt tools?
Not only is that question coming up for engineers, but it’s also coming up for the companies that have created the Infrastructure-as-Code and Configuration Management platforms.
What’s the right decision and which direction should you go in?
In this blog post, I will try to touch on the differences between IaC and ConfigMgmt, along with the platform and tool you should use in what type of environment.
Difference between IaC and Configuration Management
| Infrastructure as a Code | Configuration Management |
|---|---|
| IaC creates the System | ConfigMgmt configures the system |
| Clicking around UI is not a good way to spend engineer’s effort | Creating servers and systems is easier with virtualization, still everything is manual. |
| Infrastructure-as-Code is used to automatically create any service or system in the cloud or on-prem with code | Manually click around a GUI to provision servers and then you had to RDP or SSH into the servers to configure them |
| The code is typically a provisioning language, like JSON or YAML | Configuration Management is a way to configure servers. The configuration could be: Installing applications Ensuring services are stopped or started Installing updates Opening up ports |
| HashiCorp Configuration Language (HCL), is getting popular nowadays, which is a much easier and human-readable language compared to JSON and YAML to write infrastructure code | With servers growing, its not practical for a sysadmin to login to each server and configure them. Some identified this problem and build a tool to automate these tasks |
| IaC is also called Provisioning, as in a provisioning tool and is used interchangeably | The tool was Configuration Management |
| Some known IaC’s are: – Terraform – Plumi | Some known config management tools are: – Ansible – Puppet – Chef |
Why can’t ConfigMgmt be used for IaC?
It can. Technically, one can use ConfigMgmt for IaC. The biggest problem using Config Management as an IaC is configuration drift.
Configuration drift is when someone automates a deployment using ConfigMgmt, and after some time a person goes into the server and changes the config. No one will know and there isn’t an actual blocker to stop the person from doing that. That causes config drift.
With IaC tools like Terraform, it’s different because Terraform has State files that essentially tell the server this is how you’re supposed to look. Don’t change for anyone.
When and where to use IaC vs Config Management?
In a startup and you’re primarily using Serverless and Container technologies to deploy apps. In practice, you don’t require Configuration Management. You just need an automated way to create the Serverless service or the containers. For example, you can use an IaC tool to create a Lambda Function.
ConfigManagement is mainly still useful with enterprises where there still are bare metal and virtualized servers, consider the organization like AWS that has a pretty important job; i.e. provisioning and configuring servers. Behind the scenes under the AWS UI hood is a server running on a virtualized platform, and that server needs to be configured with the dependencies that are needed to run AWS, setting up those things are done using ConfigMgmt.