The Evolution of Configuration Management: IaC vs. GitOps

Misconfigurations are the leading cause behind security incidents in Kubernetes-orchestrated or otherwise containerized environments. Without proper configuration in place, applications would run into problems ranging from noncompliance and inconsistencies to performance bottlenecks, security vulnerabilities, and functionality failure. Therefore, configuration management is a critical component in a software development lifecycle for maintaining systems in a desired, consistent state.

According to Red Hat’s State of Kubernetes Security report, misconfigurations were the leading cause behind security incidents in Kubernetes-orchestrated or otherwise containerized environments. Without proper configuration in place, applications would run into problems ranging from noncompliance and inconsistencies to performance bottlenecks, security vulnerabilities, and functionality failure. This would make cloud-native systems unstable and cause them to become a liability to businesses. For this reason, configuration management is a critical component in a software development lifecycle for maintaining systems in a desired, consistent state. However, the way configuration management is done has been evolving over the years. This post traces the history of configuration management, focusing on how GitOps handles this critical aspect of running cloud-native applications today.

The Legacy of Configuration Management

Back in the day, when it came to managing changes in IT resources, the IT team’s focus was mainly at the server level to see if any change in the hardware would lead to problems in the rest of the stack. Each server was manually configured with the greatest of care and leisure. Virtual machines brought greater flexibility and efficiency to this process.

Infrastructure as Code (IaC) was a big step for configuration management where the entire hardware was defined as code. IaC tools such as Terraform, Chef, Puppet, and Ansible played a key role in simplifying and scaling infrastructure management. In addition, they helped speed up infrastructure provisioning and reduced costs by improving resource utilization.

Over the years, cloud-based platforms, and containers, in particular, have revolutionized the way infrastructure is provisioned. With mainstream cloud adoption and Git becoming the prevailing version control system, GitOps has emerged as the latest turn in the evolution of configuration management. GitOps goes even further than IaC when describing everything as code. ‘Everything’ here includes infrastructure, networking, data, and applications.

Kubernetes and the Declarative Approach to Infrastructure

Just as with programming, there are two approaches to provisioning infrastructure — declarative and imperative.

The imperative approach requires you to specify the exact steps to provision or modify infrastructure. It offers hands-on experience in deploying infrastructure. On the other hand, the declarative approach is more suitable for the modern cloud-native approach that Kubernetes defines. It requires that you only define the system's desired state and leave its execution to a platform like Kubernetes. Kubernetes makes both infrastructure automation and declarative configuration easier.

The Shift From DevOps to GitOps

Envisioned in 2017, GitOps is a modern operational framework to manage Kubernetes clusters and deliver applications focusing on Git. It inherits the best bits of DevOps such as CI/CD tooling, a collaboration between Dev and Ops, and automation of processes and applies them to the software delivery pipeline using Git as a single source of truth.

DevOps ensured collaboration between the development and operations teams and brought a cultural shift in the IT sector. But where it fell short of expectations is when organizations embraced continuous integration and aspects of continuous delivery but did not go all the way to continuous deployment.

This is where GitOps takes things to the next level. With the GitOps approach, teams define and manage deployments and changes to their infrastructure right from a Git repository. Making changes in infrastructure is now as easy as creating a pull request — you can catch typos, do regular reviews, or even revert a commit if you have to. Using Git, developers can now commit code, and platform engineers can automatically deploy this code into production.

Using Flux & Helm for GitOps-Driven Configuration Management

Kubernetes allows you to integrate various tools to automate the scheduling, deployment, and monitoring of containers. One such tool is Helm which has become wildly popular in the GitOps ecosystem.

Helm is a powerful package manager for Kubernetes that facilitates the definition, installation, and deployment of highly repeatable applications and services used in various scenarios. In addition, helm Charts add significant value to the continuous delivery environment by offering an organized packaging format for managing multiple YAML files with duplicated and hard-coded values.

In a nutshell, Helm helps you manage complex releases while keeping things simple when you scale. But it needs to be bridged to the essential Git repositories where the K8s cluster and app specifications are defined. Flux facilitates just that.

Flux is a set of open-source GitOps agents that act as a bridge between Git repositories and Kubernetes clusters. It is a declarative deployment automation tool that maintains code consistency by automating Helm Chart releases when code changes are introduced. Flux synchronizes these changes from Git to the Kubernetes clusters. It does so with custom resources called HelmReleases that trigger the Helm Operator, which then synchronizes the changes in the chart code. Not to mention, Flux comes with detailed drift detection functionality, among other interesting features, to enable declarative infrastructure management.

Configuration management was just about hardware and infrastructure for a long time, but we have come a long way since then. With the introduction of GitOps and tools facilitating it, developers and platform engineers have abundant choices to design infrastructure configurations as they please - in a declarative way.