...
One idea was proposed that all modules have a system multiple interface which can be implement (or not), which presents a common interface for accessing configuration specific to various modules. This means the clients (the UI for instance) are presented a common interface for getting configuration instead of each module doing it their own way.
The "Configuration"
...
Multiple Interface
Modules can choose to implement this multiple interface "configuration"
...
UPDATE This part probably doesn't make much sense from a security standpoint - it put's us right back to where we started. See comments section.
TBD... Just because the configuration APIs are distributed doesn't mean the configuration information must be. In the case of storage modules, they may choose to just store their configuration in postgres as doing so would probably require little effort. For business logic modules, or modules which have specific needs (e.g. the configuration is sensitive and should be encrypted, etc.) could choose to use a central configuration module for storage.
Here's where it might make sense to pull in additional technologies that are better suited to these requirements. See the Technologies section below. Having a module that presents a common interface in front of these technologies which is used internally (i.e. intended to be called only by other modules, not directly by clients) is an option that provides flexibility and opens the door to many potential benefits.
...
JIRA
Jira Legacy server System JiraJIRA serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key FOLIO-2583
Drawbacks
The "Externalized configuration" microservice pattern applies to deployment configuration (infrastructure and 3rd party services) only, not to business logic configuration. The business login configuration is completely independent of the deployment – it depends on the tenant or other properties.
Using mod-configuration for per-tenant business logic configuration violates the single responsibility principle (separation of concerns) where each service should be loosely coupled with other services and independently deployable. There is no benefit in moving them into a centralized configurations module.
Moving the per-tenant business logic configuration from mod-configuration into mod-*-storage but keeping a unified configuration interface has these drawbacks:
- Client needs to pass a parameter with the module name, this adds complexity.
- The configuration must fit into the 8 fields (mod-configuration API):
"module", "configName", "code", "description", "default", "enabled", "value", "userId" - The API documentation cannot explain the configuration options: mod-configuration API
These drawbacks can be avoided by using module specific configuration APIs. Example: https://s3.amazonaws.com/foliodocs/api/mod-orders-storage/configuration.html
Only those configuration options (deployment configuration) should be unified/centralized that really require it (some advanced features of redis/vault/...).