CODEWITHSUNDEEP
.netconfigurationazure-service-fabric
YMC
YMC

Reputation: 5452

Single centralized configuration settings storage for multiple distributed .net services

Goal: our application consists of micro-services architecture distributed across multiple servers (built with on-prem Service Fabric). We want to have a centralized place to store configuration settings like connection strings, entry points etc. This settings do not vary from one service instance to another which means we do not have to store it along with a service, but rather prefer to have a centralized storage where this settings could be updated on-the-fly, and picked up by all services without redeployment. User-friendly interface to edit this settings is nice to have, but not quite necessary, we can use simple notepad in a worst case scenario. Format to store the settings could be an xml, json or any other format supporting hierarchical data structure.

Question: does Service Fabric provides something out-of-the-box that helps us in that? If no, are there any third-party .net tools or we'll have to build "storage, repository and api" from scratch?

I tried to search for such frameworks for a little bit, but found nothing on market and nothing in SF, maybe I just do know how this sort of things named.

Upvotes: 1

Views: 2327

Answers (2)

Diego Mendes
Diego Mendes

Reputation: 11341

What you are looking for is a Configuration Service, there are plenty of solutions ready to use around the internet, you have a few options:

  • Use a cloud solution, like Azure KeyVault, in this case you would only have to add the authentication details to your services per environment, and all services pointing to the same KeyVault namespace.

  • Use a local solution, like HashiCorp Vault or Consul, in this case, you would deploy a it to your cluster and configure your services to communicate with it

  • Create your own, where you would create as a service fabric service, deployed along your services. I honestly don't recommend this approach unless the other services does not provide a feature required for your solution, that honestly think they are pretty complete.

There are other solutions as well, but they are pretty much based on these approaches.

Regarding Service Fabric Built-in solution, currently there is no out of the box secret management as part of service fabric, but there is an option in the Roadmap, but probably won't be released until Service Fabric Mesh gets release next year.

Upvotes: 4

Oleg Karasik
Oleg Karasik

Reputation: 969

As far as I know there is no out-of-the box solutions for this. What I can propose is to have a separate stateful service that would act as configuration store (let's call this service - configservice).

So all your configuration would be done within this service.

Then you can use this project in your services to subscribe on configuration change event that would be published by the configservice on configuration change.

The pros of this approach are that implementation of configservice gives you a possibility to implement any functionality you would need (scheduled config updates, validation, etc). The downside is quite obvious - you need to implement it by hand.

Hope this helps.

Upvotes: 0

Related Questions