Design Patterns for Microservice Architecture – Externalized Configuration

Every business Application has many configuration parameters for various Infrastructure (e.g., Database, Network, connected Service addresses, credentials, certificate path). Also, in an enterprise environment, the application is usually deployed in various runtimes (Local, Dev, Prod). One way to achieve this is via the Internal Configuration, which is a fatal bad practice. It can lead to severe security risk as production credentials can easily be compromised. Also, any change in configuration parameter needs to rebuild the Application. This is even more critical in Microservice Architecture as we potentially have hundreds of services.

The better approach is to externalize all the Configurations. As a result, the build process is separated from the runtime environment. Also, it minimizes the security risk as the Production configuration file is only used during runtime or via environment variables.

Pros

• Production configurations are not part of the Codebase and thus minimize security vulnerability.
• Configuration parameters can be changed without a new build.

Cons

• We need to choose a framework that supports the Externalized Configuration.

When to use Externalized Configuration

• Any serious production application must use Externalized Configuration.

When not to use Externalized Configuration

• In proof of concept development.

Enabling Technology

Almost all enterprise-grade, modern frameworks support Externalized Configuration.