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 argument is that 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. It sits apart from the compiler that produced it and can be read and checked 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 holds up to reading and checking 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.