I do most of my work on apps that are deployed to on-prem IIS servers rather than the cloud. We do use Azure SSO (Entra? whatever it's called now) for most of these apps though. Would you still suggest using Azure App Configuration/Key Vault in that scenario?
Hi shawn , great example. Got confused in one place where you have configured app config connection in app settings file this is fine for local but when we deploy application from where we read this connection string.
It's just a configuration setting, so as an Environment Variable is usually how it is done (this is the one bootstrapping config that you need to read the rest of the app configuration)
This seems great for a production setup. For local dev would you just wrap the .Add with #if RELEASE or would you recreate all the keys in the Azure App Configuration with a Dev label and dev values, but then how would other devs have different settings?
I would use appsettings.{buildtype}.json for dev-time configuration. I wouldn't even apply the App Configuration at dev time. For secrets, User Secrets. In .NET Core, I would never do #if RELEASE as Environment.IsDevelopment() is preferred.
is there a way to make these settings region independent? configuration is definitely one of issues when you have so many azure app services and function apps but the other issue I see is also creating one function app for each region. Ideally Microsoft should have setting when you create an app service or function app it should ask if you want regional redundancy (and then let you pick which region, ) just like zone redundancy and then it should automatically give you the new url which is created with front gate and application gateway preconfigured /predeployed vs us having to create one in say East region one in West region. Are there other cloud providers that offer this kind of region redundancy by default as part of code deployment? is this something planned for future or maybe its out there and I am not aware.
I don't know. But if it doesn't support it, you could use a prefix (e.g. ASIA:...) to have region specific. I think it only georeps the whole one. Also, these are cheap, so you could just have one for each region.
I do most of my work on apps that are deployed to on-prem IIS servers rather than the cloud. We do use Azure SSO (Entra? whatever it's called now) for most of these apps though. Would you still suggest using Azure App Configuration/Key Vault in that scenario?
Hi shawn , great example. Got confused in one place where you have configured app config connection in app settings file this is fine for local but when we deploy application from where we read this connection string.
It's just a configuration setting, so as an Environment Variable is usually how it is done (this is the one bootstrapping config that you need to read the rest of the app configuration)
This seems great for a production setup. For local dev would you just wrap the .Add with #if RELEASE or would you recreate all the keys in the Azure App Configuration with a Dev label and dev values, but then how would other devs have different settings?
I would use appsettings.{buildtype}.json for dev-time configuration. I wouldn't even apply the App Configuration at dev time. For secrets, User Secrets. In .NET Core, I would never do #if RELEASE as Environment.IsDevelopment() is preferred.
is there a way to make these settings region independent? configuration is definitely one of issues when you have so many azure app services and function apps but the other issue I see is also creating one function app for each region. Ideally Microsoft should have setting when you create an app service or function app it should ask if you want regional redundancy (and then let you pick which region, ) just like zone redundancy and then it should automatically give you the new url which is created with front gate and application gateway preconfigured /predeployed vs us having to create one in say East region one in West region. Are there other cloud providers that offer this kind of region redundancy by default as part of code deployment? is this something planned for future or maybe its out there and I am not aware.
I don't know. But if it doesn't support it, you could use a prefix (e.g. ASIA:...) to have region specific. I think it only georeps the whole one. Also, these are cheap, so you could just have one for each region.