As times change, tools change. As tools change, the purpose of the tools change.
There's a constant question that comes up about when to incorporate Infrastructure-as-Code (IaC) and when to utilize Configuration Management (ConfigMgmt). 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, you'll learn the differences between IaC and ConfigMgmt, along with what platform and tool you should use in your environment.
When you think about IaC, think about it like this - IaC creates the thing.
When you need to create a service in the cloud, a virtualized server, or even a scalable orchestration solution like Kubernetes, you need to think about how to automate it. No one wants to create anything manually anymore and for good reason. There's no way to make manual efforts repeatable and clicking around a UI isn't an efficient way to spend an engineer's time. Because of that, everyone is thinking about how to automate the creation of services, platforms, and systems.
Infrastructure-as-Code is used to automatically create any service or system in the cloud or on-prem with code. The code is typically a provisioning language, like JSON or YAML. However, that's changing rapidly with HashiCorp Configuration Language (HCL), which is a much easier and human-readable language compared to JSON and YAML to write infrastructure code. Another huge concept becoming popular is Infrastructure-as-Software, which is defining your infrastructure with a general-purpose programming language like Python or Go.
The key differentiator with Infrastructure-as-Code and the manual way of creating systems and services is that it's done by writing code. If you're not a developer, that's perfectly fine. A lot of the IaC tools are geared towards non-developers to help them get up to speed. That's why HCL is so human-readable compared to standard programming languages.
You may also hear IaC called Provisioning, as in a provisioning tool. The two phrases are both valid and you'll hear one or the other used depending on who you're talking to.
When you think about ConfigMgmt, think about it like this - ConfigMgmt configures the thing.
Several years back, virtualization hit the world. A lot of folks didn't think it would end up being as big as it was, but it ended up sweeping the tech nation. Everyone was trying to get on board with VMWare and Hyper-V to get a bigger bang for their buck when it came to servers. Even though creating servers and systems was easier with virtualization, there was still one problem; everything was manual. You had to click around a GUI to provision servers and then you had to RDP or SSH into the servers to configure them. Configuration could consist of starting services, installing dependencies, installing applications, running updates, and much more, so it was a lot of manual effort.
A few companies saw this problem and decided to make a type of tool to automate these tasks. The tool was Configuration Management.
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
And much, much more.
You may be thinking to yourself well why can't ConfigMgmt be used for IaC?
The answer is - it can. Realistically and technically, you can use ConfigMgmt for IaC. The biggest problem is configuration drift.
Configuration drift is when someone automates a deployment with say, ConfigMgmt, and 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.
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.
There is definitely debate around if Infrastructure-as-Code or Configuration Management is most used in today's world. The answer boils down to what your current environment looks like.
Let's say you're a startup and you're primarily using Serverless and Container technologies to deploy apps. Realistically, you don't need Configuration Management. You just need an automated way to create the Serverless service or the containers. Maybe you use an IaC tool to create a Lambda Function, for example.
On the flip side, maybe you're an organization like AWS that has a pretty important job; provisioning and configuring servers. Behind the AWS UI is a server running on a virtualized platform, and that server needs to be configured with the dependencies that are needed to run AWS. If you're at a company where bare metal or virtualized servers are still very much the way business is done, ConfigMgmt makes sense.
As for which is most used today, it all depends on your environment. There is no clear-cut answer.