Skip to main content

Avoid Hardcoded Configurations

Context​

Microservices are being adopted. Configuration values are hard-coded.

Problem​

  • Reconfiguration of a microservice instance requires rebuilding the deployment artifact.
    • The rebuild of deployment artifacts to reconfigure a service instance takes time and resources
    • Managing different all the deployment environments becomes complex

Solution​

Avoid hardcoded configurations because reconfiguration requires changing code and rebuilding the deployment artifact. Rather move the configuration from compile time to deployment time or runtime.

Consider one of the following mechanisms:

Next to establishing a technical solution for the problem, hard-coding configuration may be tempting, e.g., to quickly test am implementation. We advice to apply quality measures, e.g., code reviews, to achieve consistency in the application of the technique.

How to configure a microservice instance should be subject to standardization, e.g., the mechanism and the configuration value format (JSON, YAML, plain text, ...).

Maturity​

More data required (only 2 sources).

Sources of Evidence​

L24:

  • configuration may vary considerably across different execution environments (development, staging, production)
  • changes to source code => very demanding and error-prone deployment
    • solution: environment dependent configs external to source code
    • used for automation tools

Interview A:

  • Challenges of conceptual nature: make containers configurable from outside
    • Examples:
      • test endpoints vs production endpoints
      • certificates
      • stage and customer-specific variables
    • should be handled in a standardized way
    • get rid of all hard-coded configurations in code
    • Problems: (1) technical challenge, (2) be consistent with it
    • Mindset: "Everything outside the values.yaml file does not exist"
    • Previously: Java, properties files, led to rebuild every time changing the configuration
  • Mindset was the real challenge.
    • Devs want to test fast => hardcode it somewhere
      • e.g. test DB localhost => crashes in production
  • Issue about configuration format
    • JSON, YAML, plain text, ...
    • Interpretation => need for standardization