Nuts and Bolts II: configuration

We're DevOps. We're committed to Software-Defined Everything, of course. All artifacts and assets must be configurable-declarative-manageable-comparable; we introduce features and corrections incrementally, by selective toggling.

What do all these concepts mean, though, that is, what working code makes them real? One of DevOps Deliveries' most important continuing themes is that DevOps isn't a commodity or line item to be bought and painted over an underlying reality; DevOps is more a body of techniques that experienced practitioners apply artfully and economically. When we talk about "configuration" here, it's crucial we go beyond abstract concepts and look at working code that makes manageability real.

DevOps from different organizations meet at conferences, start talking about their configuration models, nod their heads at each other, and often don't realize they're using entirely different technologies. That's not necessarily bad; it just means they see only partial pictures. "Configuration" in practice might act through a GUI (graphical user interface) or a declarative INI-like text or an executable fragment (think of Perl-based swatch(1), for instance) or a Web service or NOSQL endpoint or Windows Registry or various combinations of these.

It's OK that different organizations have different habits for configuration. It's OK for one organization to use a few different configuration methods: maybe a Web form for maintenance that support personnel can do, along with textual conf-s or PowerShell scripts for DevOps staffers to tend. Not so good, though: chasing after a new "best practice" with each project. Paramount qualities for configuration are simplicity, reliability, and comprehensibility; a "powerful" configuration method is not necessarily a good thing.

My own tool of choice for many years was Tcl, which was invented as an embedded configuration language. More recently, I've hailed PowerShell for playing a similar role specifically in the Windows ecosystem. In my own work, though, I've increasingly turned away from these powerful tools in favor of tiny little DSLs (domain-specific languages) whose syntaxes are so simple that it takes only a line or two of any convenient development language to parse them. In place of Turing-machine capabilities, I now like DSLs that look like this:

      # I make a point of allowing for comments.
      # Often configuration requires no more than a simple key:value
      #     association, like this:
      job-limit:20
      algorithm-B-weight:0.03
      algorithm-D-weight:0.78

      # Blank lines should also be treated as comments.

Advantages of such a simple syntax? Error-handling is straightforward, security analysis is a lot easier than with an "active" language, and I can use standard installations of run-times without having to hunt down even one additional parsing library.

Much of the point of software-defined everything is that "knowledge workers" can read and maintain texts. I want my configuration syntax to be so simple that co-workers immediately understand it. That's more important than subtleties of having computers understand the texts. I've worked with high-capability configuration definitions; as entertaining as they are, I see that organizations generally go farther with simple, robust configuration approaches.

The conclusion? Identify "configuration" as an explicit requirement of projects, define configuration as simply as possible, implement it reliably, and use the effort and attention you save on higher-value constructions.