Configuration Approach for New Microservices
Change Type:
-
Feature -
Bugfix -
Refactoring
Context and Scope
Currently used (legacy) microservices configuration approach is error-pron, not flexible and poorly scalable:
- The @Value annotation is commonly used. It is redundant, hard to find and change, not type-safe (error-pron);
- Configuration properties (in .property files and @Value) are almost always mapped on capitalized names of environment variables, which reduces the set of possible means of parameter passing and possibility of hierarchic properties definition;
- The unsuitable @Component annotation is commonly used for ostensibly "configuration properties set" classes;
It does not take advantage of the modern configuration methods offered by Spring Boot.
This makes it difficult to transition to a "configuration server/clients" approach usage.
Decision
1. Stop using obsolete/legacy approach:
- @Value annotations;
- @Component annotation for "configuration properties set" classes;
- Stop mapping application properties on environment variables names;
2. Start using recommended Spring Boot configuration/externalization approach:
Start following Spring Boot 2 Externalized Configuration guide tightly;
-
Type-safe @ConfigurationProperties annotated configuration properties beans should be used:
- each service modules (root, core and providers') introducing at least one configuration property SHOULD have at least one such class in
org.opengroup.osdu.<service>.<module>.config
package, eg.org.opengroup.osdu.backup.provider.gcp.BackupGcpProperties
. - More when one can be used where convenient;
- each service modules (root, core and providers') introducing at least one configuration property SHOULD have at least one such class in
-
to simplify properties beans definition, Lombok @Getter and @Setter annotations should be used;
-
properties beans should be enabled with @ConfigurationPropertiesScan
-
properties beans should be injected into interested classes (using constructor injection)
- certain properties should be consumed by getters, eg.
propertiesBeanVariable.getSomeProperty()
- certain properties should be consumed by getters, eg.
Rational
Current configuration approach is obsolete, error-prone, and hard for understanding maintaining. By establishing a better configuration standard we improve, simplify and speed-up our own development process and make it easier for all new community contributors to join and become involved faster. Plus, we wish to make our services potentially configurable with MSA "configuration server/client" model.
Consequences
- Providers should plan refactoring their code as soon as they slots;
- No urgent activity required. Providers shouldn't sync their changes with others;
- When properties re-defined properly, nothing should break in currently defined CI/CD etc