Skip to main content

Configuration Server

Context​

Microservices are being adopted. Configuration values are hard-coded. Configurations change at runtime very often.

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​

Configure deployed microservice instances via a configuration server.

A configuration server is a component, usually some kind of key-value store, that propagates the configuration to the microservice instances. This mechanism allows changing configurations at runtime without redeploying the microservice instances.

The configuration can be managed separately from the source code allowing for independent evolution of the configuration. Synchronization between source code and configuration is only required if configuration keys change, not their value.

Examples for configurations that change at runtime:

  • Switch to different monitoring modes to enable debugging
  • Locations of communication partners as other microservices. Potentially, a configuration server can serve as service instance discovery mechanism this way.

Maturity​

Proposed, to be evaluated.

Sources of Evidence​

L3:

  • Context: Backtory case
  • Technologies: Spring Cloud Context and Config Server
    • separate configuration from source code, as CD recommends

L9:

  • Context: Applying microservice-style design to OpenStack
  • Configuration State Manager
    • manages configurations of all services in the control plane
    • implemented as distributed key-value store based on etcd
    • each container has sidekick process
      • monitors status of service periodically
      • register or de-register the service in the CSM
    • collaborates with service proxy and service orchestrator to do service discovery and cluster management (redeployments)

L12:

  • Context: components to utilize for full benefits of microservices
  • Configuration Server = advocated by Continuous Delivery to decouple source code from configuration
    • change configuration with redeploying
    • many services => redeployment is costly
    • config server: let microservices fetch their corresponding configurations
    • contributes to automate deployment process and decouple build life cycle of each service from other services
  • Technologies:
    • Spring Cloud Context and Config Server

L31:

  • Context: Migration practices MP11: Introduce configuration server
    • Context
      • each service has numerous instances running in production
      • service registry lists availeble instances
    • Problem
      • how change running instances' configuration be changed without redeploying?
    • Solution
      • two separate repositories
        • one for source code
        • one for configuration
          • changes should be propagated to running instances => they should adapt accordingly
      • need to synchronize the repos when key change,
      • but can evolve independently
    • Challenges
      • mechanism implemented for all used programming languages
    • Technologies
      • Spring Configuration Server
      • Archaius
  • Use at Backtory
    • improved operational experience
    • changes were quite common in beta phase => fewer redeployments, fewer instances of downtime
  • Used in all three cases

L55:

  • Context: Maya platform based on microservices
  • Configuration server: store properties files in centralized way for all microservices
    • (+) change service runtime behavior
    • e.g. to perform debugging and monitoring

LN48:

  • Context: service discovery as microservice challenge
  • need to store runtime configuration and update deployment information so other microservices can see the communication info
  • also used for API proxy fir routing
  • required for zero downtime
  • Example technolgy: Consul

LM48:

  • Context: microservice migration describes an examples project (FX Core) and compares back to monolith
  • Foundational services for supportive functions (not business related)
    • among others: centralized service configuration (ConfigurationService)
    • active/active failover (active replicas)