Simpler Spring Cloud Config approach about spring-cloud-config

[szpak]

I'm not the author of spring-cloud-config, but for me the primary reason could be a situation when you would like to separate the infrastructure (Git repository) using another (micro)service to provide configuration. That facade just could be possibly replaced when (for some reasons) Git is not welcome anymore. Probably Dave will have more interesting arguments for that architecture.

Nevertheless for our projects we had similar concerns and in the end we created micro-infra-spring-config solution which under the hood uses spring-cloud-config, but simplifies it to keep configuration stored in the local directory - usually Git repository which is updated/pulled with cron (or any other external tool) - what seems to be something what you described in your question.

If you interested @Vad1mo, it is a part of micro-infra-spring stack which provides many common things needed to write custom microservice(s) (like dependencies between microservices), but micro-infra-spring-config can be used separately.

[Vad1mo]

I am trying to challenge if having a dedicated config server has any benefit over declaring Git as the config server and merging spring-config-server and sprint-config-client together.
Having an config-server with no added custom code is very suspicious to me for its existence.

[spencergibb]

Encryption is one thing that comes to mind. Right now only config server needs to know about the keys, otherwise, every service would need to know about the keys.

[dsyer]

The server separates concerns of application and configuration. You could do that with your build and deploy toolchain for sure (by storing the configuration in a different repository and checking it out during deployment), but that's not the only choice, and it's not available to everyone. I would say, though, to keep the separation clean, it needs to be done at deployment time, not at build time.