Externalized configuration Store pattern

Need(s)

Service typically uses one or more infrastructures and 3rd party services. They comes with key-value configurations that change from one environment to an other or in the same environment over time. Continuous delivery best practice say Build Binaries Once and Deploy the Same Way Every Time. How to enable a service to run in multiple environments without modification ?

• We need different configuration properties for different environnement.
• We need to share some configuration properties between different services.
• We need pushing configuration properties changes at live.
• We need to authorize user that can manage the configuration.
• We need to log configuration properties changes.

Externalized Configuration Store pattern definition

This pattern is about moving configuration information out of the application deployment package to a centralized location. It can provide opportunities for easier management and control of configuration data, and for sharing configuration data across applications and application instances.

Standalone Configuration Server

In microservice architecture we have several instances of different services. We can choose to embed the read and reload features from the Externalized Configuration Store in the services, or to dedicate these features to a Standalone Configuration Server.

There is some advantages of using a Standalone Configuration Server:

• less flow of exchange between the services and the Externalized Configuration Store,
• our system become independent of the implementation of the Externalized Configuration Store,
• the Standalone Configuration Server can use the Service discovery pattern¹ and Service registry pattern² to scale horizontally.

¹. “Service discovery pattern”, This content ↩

². “Service registry pattern”, This content ↩