3 ms·
Configuration management systems are nothing new and do not obsolete 12-factor. Consul is one lower-level solution popularly leveraged for this, for one. You ca
by 3np 2y ago
Configuration management systems are nothing new and do not obsolete 12-factor. Consul is one lower-level solution popularly leveraged for this, for one. You can get all the upsides mentioned in the OP and still expose the configuration to the application itself as environment variables (or templated files, which is fine for more complex configuration, as long as your apps recognize env vars to determine the path they should be read from. Process signals can used to trigger selective live config reloading without restarts).
You can have whatever fancy synamic system or kv-stores you want to manage and provision your configuration - the point is that the application itself should not be concerned with such technicalities. You abstract it away before it reaches the app.
Feature-flagging is a great example of something where yes, you may want some form of more purposeful management UI. But that does not mean that you should need to integrate with such services inside the service or app itself. The appropriate env vars should be derived and injected by the infrastructure.
Having in-app service-API integration with language-specific SDKs for wiring up configuration is an recognized as an antipattern for reasons and a motivation behind 12-factor.
I think you really want to consider this and afford and promote a way to use Lekko in such a cleanly separated way, without having to reach in and have it become new tech-debt itself by forcing API integration in services. All the things you are promoting should be possible without changing a single line in any of our apps. Otherwhise I think Lekko may become obsolete before 12-factor actually does...
- passichenko 2y agoJust want to make it clear that I'm not saying that 12-factor as a whole is obsolete, I'm only talking about 3rd factor (Config). Yes, it's possible to implement dynamic configuration on top of environment variables using templates and signals, but you'd have to implement a lot of non-trivial logic yourself (how to have different values based on the context, how to deliver new versions of templates, caching, thread safety, logging, etc). And you would have to use a wrapper to access it. At this point, you essentially building a custom configuration management system and environment variables become an implementation detail. And you are stepping away from using the benefits of environment variables: clear separation by deployments and language-agnostic nature. The main point of Lekko is not fancy UI and API (in fact Lekko doesn't really have an API, it just requires you to express your configs as pure functions). The main point of Lekko is that you should treat your configs as code (but with a different deployment pipeline) and Lekko helps you with it. > Having in-app service-API integration with language-specific SDKs for wiring up configuration is an recognized as an antipattern for reasons and a motivation behind 12-factor. Can you elaborate on this? 12 factor talks about changing configs independently from code on a per-deployment basis. Lekko supports that among other things. It feels like you are projecting an experience of using a specific solution (like Consul or something) to all configuration management tools.