2023-02-06, 15:15–15:40, B.3.037
Infrastructure as Code should really be Infrastructure as Configuration.
DevOps, SRE and other engineers dealing with infrastructure are mostly managing
pure configuration data by writing, editing and auditing JSON, YAML or similar
serialization formats.
Purely data-oriented languages like JSON might be fine for managing small and
simple infrastructure, but when the size and complexity of a configuration grows,
data languages don't seem to be the right tool anymore.
There is no way to reuse data and have a single source of truth, with all the
pain and inconsistencies that duplication inevitably brings with time. We can't
express data dependencies either. For example, the open
ports of a firewall may depend on which services are enabled on a server. In
JSON, everything must be hardcoded.
In the end, Configuration Management looks like the poor sibling of Software
Engineering. What about tests, types, LSP integration for real-time feedback,
completion and documentation? What about modularity, code reuse, abstraction?
In this talk, I will present Nickel, a configuration programming language I am
currently working on at Tweag, to help finally entering the era of Configuration
as Code. I'll discuss more specifically the approach of Nickel to modularity,
which is how to write small and reusable configuration snippets that can be
combined into a complex configuration, based on a merging operation.
I work at Tweag I/O on the design and implementation of Nickel, a configuration programming language in relation with the Nix package manager. I'm trying to bring programming language research to the field of DevOps, for reliable, sustainable and reproducible infrastructure.