Our great sponsors
-
izanami
Izanami is a centralized versatile feature flag solution, well suited for micro service architectures.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
You should have some kind of configuration service with an audit log to make sure configuration changes are tracked. We use Izanami.
At simultaneous points in time, "config" has become more risky (i.e. been used to outright change the behavior of the software, e.g. with... "feature flags," AKA "bugs not waiting to happen") while purely functional programming has made the behavior of the software more predictable (with managed effects, surfacing failures as values of types obeying some algebra like everything else in the system, etc.) This is one of the—usually unstated—reasons "config as code" has arisen. Another one is the realization that config files don't have types to speak of (yes, I know about Dhall), whereas your programming language does.
I don't think Knobs is maintained anymore, which is a shame—it'd be nice to see its dependencies brought up-to-date, and probably another module added supporting, e.g. etcd. But IMO it still serves as a useful counterpoint to the way too many people think about configuration and change.
You can project along these lines to find the intersection, at which a change in configuration is just another effect to manage, and realize that, if you use a configuration representation that supports some sort of publish-and-subscribe "watching" system—like, say, the filesystem in Java since Java 7, or pretty much every key/value store since the early 2000s—you can write a purely functional configuration system that supports multiple kinds of representations, including distributed ones like Zookeeper, and propagates configuration changes via streams without the need to even restart the system.