Return to Question

I have a series of .NET kubernetes services that all need to retrieve dynamically a series of configurations from a database, since the deployment of this infrastructure is going to be on-prem for multiple clients each with a different configuration.

This means that configuration-as-code and all the could-based solutions are out of question.

I initially developed a ConfigurationProvider that given a database connection retrieves and joins a series of jsonb from PostreSQL by a "topic" key: this works ok because the query is done only at startup and there is a single instance of each service (and also allows subscription to the key updated event postgre generates, enabling hot-reloading)

An hard requirement i have is that the configuration must be stored in a database. I would love to know about more optimal solutions, but the operations team only knows how to deal in SQL because they have been using only that for the past 20 years.

Ideally the configuration database is unique and common for each service, that should have a different dedicated database for data.

I was wondering if this solution could actually work long term and scale, or if someone has already had experience with something similar and has suggestions.

Would a single "configuration provider" service work better than a "eveyone queries their own"? And if so... are there any ready-to-use solutions (open source or at a price) that work well with being virtualized in a on-prem kubernetes cluster? Maybe even offering an UI for the Operations people?

I have a series of .NET kubernetes services that all need to retrieve dynamically a series of configurations from a database, since the deployment of this infrastructure is going to be on-prem for multiple clients each with a different configuration.

This means that configuration-as-code and all the cloud-based solutions are out of question.

I initially developed a ConfigurationProvider that given a database connection retrieves and joins a series of jsonb from PostreSQL by a "topic" key: this works ok because the query is done only at startup and there is a single instance of each service (and also allows subscription to the key updated event postgre generates, enabling hot-reloading)

An hard requirement i have is that the configuration must be stored in a database. I would love to know about more optimal solutions, but the operations team only knows how to deal in SQL because they have been using only that for the past 20 years.

Ideally the configuration database is unique and common for each service, that should have a different dedicated database for data.

I was wondering if this solution could actually work long term and scale, or if someone has already had experience with something similar and has suggestions.

Would a single "configuration provider" service work better than a "eveyone queries their own"? And if so... are there any ready-to-use solutions (open source or at a price) that work well with being virtualized in a on-prem kubernetes cluster? Maybe even offering an UI for the Operations people?

I have a series of .NET kubernetes services that all need to retrieve dynamically a series of configurations from a database, since the deployment of this infrastructure is going to be on-prem for multiple clients each with a different configuration.

This means that configuration-as-code and all the could-based solutions are out of question.

I initially developed a ConfigurationProvider that given a database connection retrieves and joins a series of jsonb from PostreSQL by a "topic" key: this works ok because the query is done only at startup and there is a single instance of each service (and also allows subscription to the key updated event postgre generates, enabling hot-reloading)

Ideally the configuration database is unique and common for each service, that should have a different dedicated database for data.

I was wondering if this solution could actually work long term and scale, or if someone has already had experience with something similar and has suggestions.

Would a single "configuration provider" service work better than a "eveyone queries their own"? And if so... are there any ready-to-use solutions (open source or at a price) that work well with being virtualized in a on-prem kubernetes cluster? Maybe even offering an UI for the Operations people?

I have a series of .NET kubernetes services that all need to retrieve dynamically a series of configurations from a database, since the deployment of this infrastructure is going to be on-prem for multiple clients each with a different configuration.

This means that configuration-as-code and all the could-based solutions are out of question.

I initially developed a ConfigurationProvider that given a database connection retrieves and joins a series of jsonb from PostreSQL by a "topic" key: this works ok because the query is done only at startup and there is a single instance of each service (and also allows subscription to the key updated event postgre generates, enabling hot-reloading)

An hard requirement i have is that the configuration must be stored in a database. I would love to know about more optimal solutions, but the operations team only knows how to deal in SQL because they have been using only that for the past 20 years.

Ideally the configuration database is unique and common for each service, that should have a different dedicated database for data.

I was wondering if this solution could actually work long term and scale, or if someone has already had experience with something similar and has suggestions.

Would a single "configuration provider" service work better than a "eveyone queries their own"? And if so... are there any ready-to-use solutions (open source or at a price) that work well with being virtualized in a on-prem kubernetes cluster? Maybe even offering an UI for the Operations people?

I have a series of .NET kubernetes services that all need to retrieve dynamically a series of configurations from a database, since the deployment of this infrastructure is going to be on-prem for multiple clients each with a different configuration.

This means that configuration-as-code and all the could-based solutions are out of question.

I initially developed a ConfigurationProvider that given a database connection retrieves and joins a series of jsonb from PostreSQL by a "topic" key, and this works ok because the query is done only at startup and there is a single instance of each service (and also allows subscription to the key updated event postgre generates, enabling hot-reloading)

Ideally the configuration database is unique and common for each service, that also should have a different dedicated database within postgre

I was wondering if this solution could actually work long term and scale, or if someone has already had experience with something similar and has suggestions.

Would a single "configuration provider" service work better than a "eveyone queries their own"? And if so... are there any ready-to-use solutions on the market (open source or at a price. altough i thing it's gonna be real hard to convince management to spend) that work well with being virtualized in a on-prem kubernetes cluster?

I have a series of .NET kubernetes services that all need to retrieve dynamically a series of configurations from a database, since the deployment of this infrastructure is going to be on-prem for multiple clients each with a different configuration.

This means that configuration-as-code and all the could-based solutions are out of question.

I initially developed a ConfigurationProvider that given a database connection retrieves and joins a series of jsonb from PostreSQL by a "topic" key: this works ok because the query is done only at startup and there is a single instance of each service (and also allows subscription to the key updated event postgre generates, enabling hot-reloading)

Ideally the configuration database is unique and common for each service, that should have a different dedicated database for data.

I was wondering if this solution could actually work long term and scale, or if someone has already had experience with something similar and has suggestions.

Would a single "configuration provider" service work better than a "eveyone queries their own"? And if so... are there any ready-to-use solutions (open source or at a price) that work well with being virtualized in a on-prem kubernetes cluster? Maybe even offering an UI for the Operations people?