5 ms·

Sometimes there is no problem to be solved, all these tools just complicate everything. Do this instead: 1. Use flat yaml files. No loops nor conditionals, no

• lugg 7y ago
  Or just use native data structures. If you're throwing it all into a docker container as a single artifact you don't need a separate language to patch into a complicated config parser. Just use hardcoded objects/maps in whatever language you use.
  • q3k 7y ago
    What if your language is compiled?
• q3k 7y ago
  What if you are using already existing tooling that takes very verbose yaml files? I've seen Concourse CI pipelines that push past 5k lines of YAML, where 50% internally is repeated 10-line blocks, and there is tons of repetition across different YAML files.
  • tuldia 7y ago
    Duplication is far cheaper than the wrong abstraction. I do prefer to have lots of dumb files than having to deal with the cognitive load of a tool that in the end will generate lots of files anyways.
    • combatentropy 7y ago
      > Duplication is far cheaper than the wrong abstraction. I'm going to chew on this. For me, Don't Repeat Yourself has been one of my highest values. My former colleagues would copy and paste code everywhere. It was a pain to make changes to, and I relished refactoring it. But I also regret some of the libraries I wrote in my early years. They aren't designed how I would today, but now several applications depend on them. One thing I will say is that it's okay for your first draft to be ugly. It helps to see all the duplication before you design the abstraction.
      • api 7y ago
        I would second the parent. DRY was a false God. I would say RCL: reduce cognitive load. Obviously if there is a manageable way to reduce repetition, take it, but I would not add a lot of complexity for the sake of brevity. That's turning your dev team into a data compression algorithm made of meat.
        • tome 7y ago
          Perhaps DRY was a good shortcut to RCL and SST (single source of truth). Those two are really important. DRY is an approximation to them (a good one in most cases).
          • dllthomas 7y ago
            Are you speaking about DRY on a syntactic basis, or the version from The Pragmatic Programmer ("Every piece of knowledge must have a single, unambiguous, authoritative representation within a system")?
            • tome 7y ago
              Ah, thanks, now I realise I've been taking DRY too literally and what I described as "single source of truth" is actually what DRY tends to mean: https://en.wikipedia.org/wiki/Don't_repeat_yourself https://en.wikipedia.org/wiki/Don't_repeat_yourself
              • dllthomas 7y ago
                I would say "was intended to mean.". The acronym is catchy and seems sufficiently self explanatory that I think your initial interpretation may be more common. I've been jokingly pushing for over-application of syntax-focused DRY to be called "Huffman coding"
        • q3k 7y ago
          Cognitive load is also present from vastly duplicated code and config: having to remember to update or take into consideration 20 other places in your codebase any time you make a change.
  • desert_boi 7y ago
    YAML has shorthand for objects. https://blog.daemonl.com/2016/02/yaml.html https://blog.daemonl.com/2016/02/yaml.html if you're repeating them, there's always this option.
• cwp 7y ago
  I work at a small company - maybe 40 engineers. Our app is still a monolith, but we have secondary systems for processing data and communicating with external systems. It's not the most elegant thing ever engineered, but it's not bad given our security and compliance requirements. I mention all this to illustrate that we are nowhere near NetAppAmaGooSoft scale. Nevertheless our deployment is complex. We can't just have a few hundred identical machines. There are many heterogenous parts, and they have to be hooked up to each other. We currently do this with ~20K lines of HCL applied with Terraform. It's mostly written by some hella-smart infra engineers, and is very well factored. Still, it's a BEAST. The Terraform Enterprise workflow is tedious, and writing configuration is a lot of work. We would love to replace it, with ...something better. There are alternatives out there, but nothing that's obviously much better. It wouldn't be worth the migration effort. As far as I can tell, this is the state of the art, and it sucks. My coworkers are sick of hearing me say "We are not Google", so I'm sympathetic to the YAGNI argument, but there really is a problem here. Flat YAML files would be a nightmare for us. I bet there are a lot of companies out there that have worse solutions than we do. The default of "each team rolls their own ad hoc deployment tools" masks it somewhat because it's not obvious that the company has 17 solutions to the same problem, with varying levels of effectiveness and reliability, all of which are expensive to write and maintain, and none of which will be reused when a new team gets organized. Terraform is a valiant attempt to solve the problem with middling results. We can do better, and we need more attempts! I'm excited that CUE exists. It's not ready for my use case yet, but it's very promising. The best thing about it is that it scales well, up and down. If you have simple needs, you can just write flat CUE to start. It's just JSON with some syntax sugar. The fancy stuff can come later, but it's there when you need it.