2

I have been working with many applications and had different approaches to storing application properties (configurations).

The problem is were to store different types of configs.

  1. Configs which require application restart and being changed rarely (some 3rd-party properties, DB or queue credentials)
  2. Configs which can be handled by application without restart and being changed often (specific business properties, performance tuning properties like number of cores, executors and memory size - specially in streaming applications)

Approaches I used:

1. Store all configurations in Git.

Pros: Simplicity and everything in one place.

Cons: Passwords should be hashed, each change should be committed, merged and deployed.

2. Store configs which are being changed rarely in Git, and those which are being changed often - in DB.

Pros: Easy to change DB configs without version control and without need to redeploy application.

Cons: Several places of configs, dependency on DB, still problem with passwords.

3. Configuration Service like Spring Cloud Config

Pros: Centralized, built in password hashing

Cons: Git dependency.

4. Environmental variables

Pros: Security

Cons: DevOps required

Do you have better alternatives or comments to described?

1 Answer 1

1

In terms of configuration, there's no one true answer. It's more a matter of what makes the most sense to you in your scenario, and a balance between effort and what features you get out of it.

  1. Configs which require application restart and being changed rarely (some 3rd-party properties, DB or queue credentials)

More often than not, requiring a restart is not a matter of technical necessity, it's a matter of not having bothered to develop a way to update your configuration mid-runtime. I don't mean that negatively. Sometimes, it's really not worth the effort.

However, if you already need other configuration which is reloaded mid-runtime, I see little reason to intentionally make a separate config for values which don't need to be reloaded at runtime.

  1. Store all configurations in Git.

The overall goal of a configuration is to separate it from the application itself, so that you can change the config without needing to touch the application files.

Tying your config to a deploy means that you haven't really added much compared to if you had hardcoded your config values into your code (as a config object, not using magic numbers all over the place).

Note that local configs are an exception to this. You'd like those to be available via the codebase for the purpose of development.

Cons: Passwords should be hashed

This is never not true, so it is irrelevant in terms of a comparison. NEVER store passwords plaintext, when it can be avoided (SQL connectionstrings are a thorn in my side).

  1. Store configs which are being changed rarely in Git, and those which are being changed often - in DB.

Using a database is not a light decision. It's a strong dependency and tends to come with an overhead cost both in hosting and maintenance. However, it is also incredibly feature-rich and allows you to do whatever you want (as opposed to a third party config framework which constrains you to its specific implementation).

Performance can be a bit of a bother, in cases where an extra network call (which generally can't be awaited for long as it contains essential config values) is undesirable.

  1. Configuration Service like Spring Cloud Config

Using third party tools can save you a lot of time, but it constrains you to the implementation of the tool. Whether this is desirable depends on the tool and your requirements.

Some development teams prefer depending on external libraries, and tend to end up having to spend some of the manhours they saved back on dealing with updates and version changes, or even bugs that the third party team may have introduced.

Other development teams avoid third party tools when one can be trivially developed in-house. This takes more time (unless you already have an in-house solution from an earlier project), but can help you avoid needing to respond to unexpected version changes or newly introduced bugs when you didn't touch the tool.
It may be inefficient to reinvent the wheel, but sometimes you'd rather have your own wheel instead of renting someone else's.

There is no one true solution to how a team's time is best invested.

  1. Environmental variables

Environmental variables are great for things that change in every environment (hence the name), but they're not great for storing large sets of nested information. If you have only a handful of non-environmental config settings, you can just stick the whole config in env variables, but if you have a sizeable collection of non-environmental variables, or if they are nested sets of config values, I suggest you don't.

Do you have better alternatives or comments to described?

You didn't really mention a tech stack so it's less than trivial to find an apt suggestion for your scenario.

In general, I would put off implementing the final configuration tooling as far to the end as possible. Of course, you should preemptively abstract your config and avoid magic numbers, but during development you can usually get by with your tech stack's vanilla config solution (e.g. app.config for .NET, some separate JS file/object for JS, ...), and only implement an additional config solution when the need for one presents itself.

Based on that need when it presents itself, you are able to more accurately home in on the solution that best fits your scenario.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.