In a microservices architecture, the services are dynamic in nature. They will go down and come up based on traffic or any other configuration. Due to this dynamic nature, there should be a separate, highly available server that holds the essential configuration details that all the servers need to know.

For example, our pricing service will need to know where the registry service is and how it has to communicate with the registry service. The registry service, on the other hand, should be highly available. If, for any reason, the registry service has to go down, we will spin up a new server. The pricing service needs to communicate with the config service in order to find out about the registry service. On the other hand, when the registry service is changed, it has to communicate the changes to the config server, which will then cascade the information to all the necessary services.

Spring Cloud Config Server (https://github.com/spring-cloud/spring-cloud-config) provides the server- and client-side support for external configuration.

With the Spring Cloud Config Server, we have a central place to manage all our external properties across all environments. The concept is similar to Spring-based environment property source abstractions on both the client and server. They fit any application running in any language.

They are also helpful for carrying the configuration data between various (development/test/production) environments and can also help to migrate applications.

Spring Cloud Config Server has an HTTP, resource-based API for external configuration. They will encrypt and decrypt property values. They bind to the config server and initialize a Spring environment with remote property sources. The configuration can be stored in a Git repository or in a filesystem.