Effective Configuration Management

Problem statement

Before the advent of Microservices, we used to create a properties files in which we maintained our configurable parameters/properties. If we have a need to change any parameter values/adding/deleting a parameter, we generally needed to restart the application container. This is the same case in all environments like development, staging, and production.

Microservices architecture will be having a number of Microservices implemented, they may be talking to each other or independent services. Each microservice can connect to different sources to pull/push the data and serve the requests. We will be having the information of the respective source available in the configuration file. If there is any change in a property value like URL change, then we need to rebuild and deploy the Microservice, which is time-consuming in the age of Microservices.

Microservices strongly advocates the principle of “Build just once and deploy anywhere”. But for trivial configuration changes, we end up rebuilding the codebase and deploy again. I see a strong need for automating this and if an independent application can manage all the configurations then it will be an interesting and useful solution.
Configuration server exactly fits the bill here.

What is the configuration server?

Configuration server follows the client-server approach for storing and retrieving all configurations across multiple applications in all environments.

The configuration source can be Git or SVN or we can store in the local file or we can customize in the database and can be modified at the application runtime.

With Microservices, we create a central configuration server where all our configurable parameters of Microservices are written and version controlled. The benefit of a central config server is that if we change a property of a microservice, it will reflect that change on the fly without redeploying the respective client Microservice.

In this blog, I will focus on an example of config server with Git backend, use it in a simple Microservice application (ConfigClient)

Implement a config server:

1. Create ConfigServer using spring boot and update your pom.xml with the required dependencies


2. Create main class


3. Create a file called ../src/main/resources/application.properties with the below content in it.


4. Create a project config, add a file called a-bootiful-client.properties to the project and commit it, with below content to GIT


5. Confirm the config server data:
Start the ConfigServer application and access below URL to confirm the properties you configured


Implement a config client:

1. Create Config Client using spring boot and update your pom.xml with the required dependencies



2. Create a file called ../src/main/resources/application.properties for client with the below content in it.



When we start the client application, the configuration values are read on the application startup, and not again. We can pull the updated values from the Config Server with a forced bean refresh. Annotate the Controller (MessageRestController) with the Spring Cloud Config @RefreshScope and then by triggering a refresh event (http://localhost:8080/actuator/refresh)

3. Create Client main class (ConfigClientApplication.java)


4. Create a Controller (MessageRestController.java)


Test the Config Server – Config Client applications:

1. Start the Config Server
2. Start the Config Client
3. Access the client message in the browser: http://localhost:8080/message
4. There you can see “Hello folk”, which we added in a-bootiful-client.properties file.

Test the updates in the properties file:

1. Change the message content in a-bootiful-client.properties file to “Hello Folks, how are you ?”
2. Commit the file
3. Refresh the config data with a POST request to

4. Access the client message in the browser: http://localhost:8080/message


Now, you are able to create a configuration server with GIT backend and use it in your Microservices. You can use GIT/SVN/database as a source to your configurable data.
With this, you can avoid re-build & re-deploying your applications on each change.

Related Posts

Leave a comment

Translate »
Privacy Preferences
When you visit our website, it may store information through your browser from specific services, usually in form of cookies. Here you can change your privacy preferences. Please note that blocking some types of cookies may impact your experience on our website and the services we offer.