What is Configuration as Data?

I have written about many kinds of infrastructure and application configuration tools, including Infrastructure as Data. Infrastructure as Data tools and platforms, such as Kubernetes, represent configuration using data serialization formats, such as YAML. However, these data formats are typically generated using Infrastructure as Code tools and approaches, and the templates or other generation code are managed as code in version control. There are numerous such tools, particularly for Kubernetes.

What, then, is Configuration as Data?

Infrastructure as Code (IaC) implies representing infrastructure and application configuration as code or a code-like format and storing and managing it in source control like code. Configuration as Data (CaD) implies representing the configuration as data and storing and managing it like data.

It sounds simple and obvious, but apparently isn’t. The approach certainly isn’t mainstream among Kubernetes and cloud users, and the tooling hasn’t existed to adequately support it. I’ve been converging towards this approach for years, with kubectl apply, kustomize, Config Connector, and kpt, but focused only on the first half of the problem, the representation.

How is Configuration as Data different from just calling Kubernetes and/or cloud APIs? Isn’t that data? Kubernetes is certainly pretty close. Cloud APIs are more idiosyncratic.

The application of IaC provides one clue: a separate source of truth necessitates a reconciliation process. Additionally, the capabilities that motivate adoption of IaC, such as variant generation, are still desirable to provide, even if in a different form.

What are the potential benefits of Configuration as Data?

At a high level, it means that tools can read and write the data, instead of just making changes manually or, now, with AI. This has the potential to reduce a lot of the toil involved, and enables mass changes to configuration.

It also means you have the freedom to create resource specifications however you like: AI chatbots, UIs (e.g., https://k8syaml.com/), CLIs (e.g., kubectl, kompose, rbac-tool), cdk8s used in a tool as a library, importing live resources, etc. They don’t have to be crafted artisanally.

And, especially with Kubernetes, since the Kubernetes Resource Model used for configuration is the API representation, it’s possible to update the configuration from the live state, rather than just propagating changes in the other direction, providing another means of mitigating configuration drift. I still hear about ops needing to disable GitOps reconciliation in order to make changes to the live state, and then backporting changes into Helm charts and other configuration formats in git manually.

Managing configuration as data rather than as files spread across many git repositories provides an approach to mitigate configuration sprawl, as well.

All of the 12 anti-factors of IaC are either addressable or non-issues in the Configuration as Data paradigm.

Ok, so what is the catch?

It will take time to build up the ecosystem of tools that make Configuration as Data easy to use.

We’re near the start of that journey, but the destination will be a better place.

Do you manage any of your configuration, maybe application configuration or network configuration, as data? If so, what do you see as the benefits? What challenges have you encountered? If you use Config Connector, ACK, ASO, Crossplane, or other KRM-based infrastructure provisioning mechanism, do you store the resources in source control? If so, how do users create and make changes to them? If not, where do you store them, if anywhere?

Feel free to email us at hello@confighub.com, or send me a message on LinkedIn, X/Twitter, or Bluesky.

If you found this interesting, you may be interested in other posts in my Infrastructure as Code and Declarative Configuration series or in my Kubernetes series.