I'm looking into using Azure app config (AAC) for an existing on-prem asp.net (.NET 6) app to allow for dynamic updates to the config. I am wondering if AAC will work for my situation though.
My main concern is that any config updates made in AAC are persisted somehow in case we lose connection to AAC. So the app needs to have an on-prem location to pull the most current config in case that connection is lost.
Basically, I do not want the app to revert to an older config if the connection is lost and the app pool is recycled, but that seems to be what would most likely happen based on my understanding of it.
So, I need a way to persist the config after any update, even if the app pool is recycled. Is this something that Microsoft addresses somehow?
The only thing I found that seemed like it had potential to be a solution was in the AAC Best Practices documentation, under "Client Applications in App Configuration".
https://learn.microsoft.com/en-us/azure/azure-app-configuration/howto-best-practices
They suggest a proxy server for security and traffic reasons there. I was thinking that an on-prem proxy server could potentially work for this as well if it could persist the latest config. I couldn't find any details in the documentation on how to set such a proxy up though.
Is there some solution to this that I'm missing, or is AAC just not suitable for my situation?
Unless you worry about the stability of your on-prem infrastructure, the availability of Azure App Configuration (AAC) is equally important to applications regardless of whether they run in the cloud or on-prem. AAC put huge effort into ensuring high availability. You may check out this FAQ for details.
Note that if you use the AAC configuration provider library in your application, it has built-in caching and refreshing functionalities. It will always serve configuration from the cache even if it fails to connect to AAC to refresh the data. It will keep trying to refresh the data (or failover to a different replica if you have geo-replication enabled).
The above should be good enough for most applications. You shouldn't need to build a proxy service that's to solve a different problem. Actually, a proxy service can also fail regardless of where you run it. If you really need an extra layer of protection, you can, for example, export data to a configuration file using AAC Azure CLI as part of your build or CI/CD process and deploy that configuration file as part of your application. This way, your application can use a "last known good" configuration if it can't connect to AAC at startup. Once it can connect to AAC, it can load the latest configuration.