The config api is for single config across multiple service instances/environments and enabling immutable containers.
Frameworks like Archaius separate Dynamic properties etc into interfaces that start 'Dynamic...'.
This serves the model well as the config API is not a general place to hold app state and changeable core properties have unclear semantics that contradict good microservice practices for:
1 - Server restart
2 - High availability
3 - Scaleout
4 - Config as (change tracked) source
Only the app can call set or remove apis so what scope is any change visible to?
If there is a requirement to have dynamic properties then this should be supported without getting rid of the ability for some users to know that - with identical deploy artifacts - that servers are running with the same config. This can be done if applications have, by default, some way to reference config values that are known to be stable/common based on artifacts.
The config api is for single config across multiple service instances/environments and enabling immutable containers. Frameworks like Archaius separate Dynamic properties etc into interfaces that start 'Dynamic...'.
This serves the model well as the config API is not a general place to hold app state and changeable core properties have unclear semantics that contradict good microservice practices for:
1 - Server restart 2 - High availability 3 - Scaleout 4 - Config as (change tracked) source
Only the app can call set or remove apis so what scope is any change visible to?
If there is a requirement to have dynamic properties then this should be supported without getting rid of the ability for some users to know that - with identical deploy artifacts - that servers are running with the same config. This can be done if applications have, by default, some way to reference config values that are known to be stable/common based on artifacts.