3 ms·
The “code” rot creeps in over the years. Especially so if you work with a lot of people on the team. If they view the infrastructure-as-“code” parts of the p
by gorgoiler 4y ago
The “code” rot creeps in over the years. Especially so if you work with a lot of people on the team. If they view the infrastructure-as-“code” parts of the project as somehow lesser in stature than the rest of the actual code, then they more than likely see the YAML as a legitimate place to make drive-by tweaks without much care for “code” quality.
Because they are programmers though, they might actually try to make the “code” better:
First they refactor everything using ‘extends:’ to use inheritance for infrastructure “code” sharing.
Then they started sharing “code” between blocks by using YAML references. This removes duplication, except for the edge cases that need to be different. Hmmm.
Then the YAML file became a Jinja / Jsonnet / M4 / C-preprocessed template. That means there’s now another programming language involved so on the upside there’s some hope of finally being able to express computation, but with the downside that it somehow plays second fiddle to the YAML despite the latter having nothing to do with computation.
The downsides of trying to prematurely capture your ideas as config are real. If you don’t focus on all of the key variation points you’re going to see people start hacking and templating at some point. It’s inevitable. I like how Ansible didn’t even try to avoid templating and ran with it straight off the bat.
Config DSLs are hard. OpenSMTPD’s is beautiful but they didn’t get it right until version 6. Even then I bet some people are generating the config. Caddy’s dual approach of letting you use their DSL or give it generated JSON is nice. They have a config DSL for the use cases they could think of, but recognise that there will probably be other cases they didn’t think of, and so support you calling their API with machine built configs instead.
Configuring a system with a programming language is difficult too. If you had a Python module to set up Apache, and your config was particularly lengthy, you can guarantee someone on your team is going to come up with a “clever” abstraction at some point via a pull request that links to the DRY Wikipedia page.
It’s just that with Python etc — vs YAML “programming” in “code” — they are more likely to actually get it right.
- TobTobXX 4y agoVimL carries its scars from this process. At first just a configuration DSL for settings, nowadays the language truly sophisticated plugins are written in. I'm not decided whether I'd want something vim-like for infra as code. On one hand, in VimL, simple things remain simple and complex things are possible, alas you could say perfect design. On the other hand, everyone who has programmed something non-trivial with vim knows the pain.
- codethief 4y agoI agree with pretty much everything you wrote but: > It’s just that with Python etc — vs YAML “programming” in “code” — they are more likely to actually get it right. Are they, though? My impression from various projects involving a good amount of YAML files (for CI pipelines, k8s deployment and such) has been that countless things that take me seconds in python (declare and pass around a variable, find out what a line of code does, find out where else a variable is used) take me orders of magnitude longer in declarative DSLs (like anything YAML-based) than in imperative languages like Python. In 99 of 100 cases I have to either consult the docs (because I don't understand what a given declaration means) or resort to string search (yes, string search) across one or – god forbid – multiple repositories. Meanwhile, imperative code at least tells me what it does and tooling support (usage search etc.) also tends to be very good. YAML hell is real.