Boost the flexibility of your Microservice architecture with Spring Cloud

Spring Framework

Inevitably when your application configuration is written directly into the code, every time you need to apply a change, the application must be recompiled or/and redeployed, for the client’s well-being or even for the folk that does that work, avoid it. Most engineers separate the configuration information from the original application source due to the lack of efficiency and flexibility.

Five usual solutions to this problem take place. In this article, I propose one of those solutions, mainly the most straightforward, Spring Cloud Configuration Server.

What is Spring Cloud Configuration Server

Looking at the official Spring.io documentation:

Spring Cloud Config provides server-side and client-side support for externalized configuration in a distributed system. With the Config Server, you have a central place to manage external properties for applications across all environments.

With this server, whenever you apply a simple configuration change, the microservice instances will automatically update themselves, with the new properties settled. Some of its features:

• It supports multiple backends for storing configuration data (Etcd, Eureka, Consul, ZooKeeper, and the one we are currently explaining);
• Can be integrated with GIT source control;
• With simple annotations, you can have the configuration server up and running;
• Multiple profiles environments for each microservice (usually dev/QA/Prod);

How microservices interact with this central repository

Every time one service instance starts, it will fetch all the properties data from the configuration server, through a service endpoint exposed by the repository. When some changes occur, the services are notified to refresh their copy of the application data.

Conceptual Architecture

Creating our Spring Cloud Configuration Server

1. Create a new spring project,(You can easily do it through the Spring Initializer).
2. Make sure the following dependencies are added:

• spring-cloud-starter-config
• spring-cloud-config-server

Spring Cloud is a massive collection of independent projects, many third-party libraries and dependencies are used, you need to specify the version number of the current spring cloud project you are currently depending on, in this case, Hoxton.SR8. All this code is pushed into a GIT repository, you can easily go there and check if all dependencies match with the ones inserted on your pom.xml or gradle.build.

3. Edit the application.yml, this file will tell your Spring cloud configuration service what port to listen to and where to locate the backend that will serve up the configuration data. To maintain the easy setup and understanding of the concepts/steps, I decided to store these configurations properties in the filesystem, however as you probably know, in a distributed environment, this may become a bit overwhelming and make the architecture unnecessarily complex, you should probably consider storing this data in a database.

Configuration Server (application.yml)

The search-locations property will have the location of your service configuration files (dev/QA/Prod), just by inserting the minus after the service name and then the file context, like:

• client1.yml -> default
• client1-dev.yml
• client1-qa.yml
• client1-prod.yml

Spring Cloud can easily map the services to each environment automatically if they follow this name convention.

4. About the service configuration itself, it’s pretty much the same content as you would insert on the original application.yml of the service, in this case, we set up an in-memory database like:

Client1 (client1.yml)

5. The only step missing is inserting the configuration annotation at the main application class, @EnableConfigServer, we place it so Spring can know which context should be running:

Configuration Server Main Class

6. Now the only thing missing is to build the project and start it:

• mvn clean install
• java -jar <project-path>target/configuration-0.0.1-SNAPSHOT.jar

Configuration Server Startup logs

And Boom, you got yourself a spring cloud configuration server, you can test it just by requesting the following endpoint:

Client configurations HTTP Request

Client Configuration

1. Edit the bootstrap.yml on the resources folder, if you don’t have it, you can create it and insert the following content.

Client1 Bootstrap Configuration (bootstrap.yml)

This file is used for boot configuration purposes, all other properties should be placed on the application.yml

And that’s it, on the client startup you should see something like:

Conclusion

Hope this tutorial helps you knowing one more tool of spring, it’s always a pleasure to share the simplicity and the power these tools have and some of us don’t know them yet! All the code posted will be available on GIT so you can have deeper look at the code presented as the client used for this interaction. Keep tuned for news.