Configuration as code, and as data
Brian Grant coined the Kubernetes Resource Model and argues that configuration should be data, not a program you run to find out what it is. chant agrees, and most of the industry is still catching up to him.
His case is simple: declarative configuration is data. It is separated from the code that transforms it. This is a huge part of what makes Kubernetes manageable.
chant is configuration as data
chant compiles a typed source to the platform’s own spec and hands that spec back untouched.
The output is declarative data, in the format the platform already speaks, separated from the compiler that produced it, readable and checkable before anything runs.
Brian’s definition has two halves. Represent configuration as data, and store and manage it like data.
chant takes the first half. The spec it emits is data, readable and checkable before anything runs. ConfigHub takes both, and keeps the data in a store. chant leaves it in git.
chant is configuration as code
You author chant in a real typed language, and a compiler turns it into the data. Code on the way in, data on the way out.
The compiler changes the format, not the config.
Accessible Ops
Being both is the better combination, for agents and for people
Configuration as code is what makes configuration as data comfortable for a person and reliable for an agent.
chant is both.
For the language side of this, and why TypeScript lets a tool be both at once, see TypeScript is the right choice for infra.