Microservices is the latest architectural approach to scaling applications. Their smaller, more atomic size, allows for greater agility as the impact of each iteration is more contained. This makes continuous integration and development easier as the burden of testing is less and deployment iterations are more limited in scope.
As we look to utilize Mule, and other systems, in this environment, we need to make sure that their configurations can automatically reflect their environment. As we build applications at scale and move out of the development lab, this becomes a real need. Luckily, the Spring Cloud Configuration server lets us do exactly that.
Adding Spring Cloud Configuration
When microservices start their run, the lifecycle startup process reads properties and uses them to configure process flows and endpoints. In small well contained environments, managing a limited set of properties in files is usually adequate. As your business begins to grow and extend into multiple Cloud Availability Zones, your configuration strategy will need to change. Some of the problems you’ll inevitably encounter in your running environments will necessitate microservice property files being extended with a more flexible approach.
Resilience is paramount in microservice environments. To be more adaptable to application faults and changing conditions, our experience has guided us to solutions like the Spring Cloud Configuration server. The configuration server has support for environment profiles and several ways of securing property data. It does this by using a Git repository (by default) to version and serve application properties.
When we need to update property values, we change and commit them in Git. The next microservice which starts will derive the latest properties from Git using the Spring Cloud Configuration server, without having to redeploy the application.
I’ve published Spring Cloud Config With the Mule ESB showing the details of this reference model on DZone. It shows how a MuleSoft microservice application would use the Spring Cloud Configuration server at startup to fetch properties and configure endpoints.
The next logical step will be to tie in a Discovery service, like Netflix Eureka, to this model. It allows for dynamically finding a Configuration server to connect with and derive our runtime properties.
If you are interested in the more technical aspects of Mule, you can check out all my articles on DZone.