 So my name is Jimmy Campbell. I am a developer on the Azure App Configuration team. I'm excited to be here today to talk about our service and also to celebrate.NET Core 3.0. I've been a.NET Core developer since beta eight, and definitely a lot of change since then. I think that Azure App Configuration is a great tool for a.NET Core developer to add to their arsenal. Whether they're developing modern global cloud applications, microservices, or maybe just sticking in the DevOps pipeline. Whatever, configuration is all across the stack, so a centralized configuration service really makes a lot of sense. So what ended up happening was we saw a lot of problems with configuration, the way applications are moving today. Some examples of some of these problems might be, how do I centralize configuration when I'm running on an Azure function. I'm also running in Kubernetes. I'm running on some VMs that I own, and I kind of need to share settings between them. Or maybe something like I'm running apps in North America and I'm running in them in Europe. I need to share settings, but I also need them slightly nuanced because the application just needs to behave differently in North America or Europe. To more advanced use cases, wherever I'm getting my configuration from, how do I dynamically update it during runtime? And so configuration is a very fundamental piece and there are some common problems. We saw people trying to develop their own solutions that comes with the cost. We also saw things like people try to use things that weren't necessarily meant for configuration. And then they would eventually get to a point where they got stuck because the solution they were using just wasn't designed for that. So it really made sense to make the service Azure App Configuration, which is then in preview now since April, yes, April. And we got on this and now it exists, so a centralized configuration service. For .NET Core developers specifically, we offer things like a configuration provider, similar to the JSON file provider in .NET Core. Things, we have a SDK, a configuration client where you can write, read settings. But I think, first of all, what I should do is get started saying, what is Azure App Configuration? It's an Azure resource. What happens when I create it? What do I actually get when I start using it? And so we'll kind of do like a getting started right now. So I'm gonna go into my command line and get started with Azure App Configuration from the CLI. .NET Core has a pretty good CLI and we're all developers here. So I think we can kind of enjoy the automation opportunities that come with the CLI. So I'll go ahead and get started creating my first Azure App Configuration. So I'm using the Azure CLI now as denoted by AZ. And then App Configure is our command group. And I'm going to create an azureappconfiguration.net.com demo. My resource group is gonna be Jimmy CA config, one I already have configured. And I'm gonna have a location of Central US. So what am I getting when I create Azure App Configuration? So it's an Azure resource. And I'm gonna get a place where I can store settings. Settings in our model are stored as key value pairs. So you may have a message which is hello world or something like that, just a simple key value. And that's really what we store at the foundation. We do offer metadata on top of that. So you're storing your settings and they're available to you through a web endpoint. So if you look at configuration instance that I just created, my endpoint that has been allocated to me is hdps.net.confdemo.azconfig.io. So now I have a REST API listening on this endpoint that was allocated just for me where I can start creating settings in a central manner, start consuming them in all my applications, my DevOps. Anything that really speaks of REST API can start writing and reading settings from this app configuration instance. And of course, the CLI is one of the things that can do this. We can go ahead and create our first setting here. Now that I just booted this up, azappconfig kv for key value, set. I want to set a key value. So the name of my store is .net.confdemo. I have a key I want to create color, pretty typical setting name, and a value of blue. All right, so now we just use the CLI, the Azure CLI, to create an app configuration instance and create our first setting. All right, this kind of shows some of the automation with the service. So you can kind of run these things in a script or whatnot. But now we're going to go into the portal and we can show the UI for this thing and we can kind of get the best of both worlds. So I'm going to go into the portal here. Let me refresh the page. I'm going to see this .net.confdemo. Now, everything I've done in the CLI can be done through the portal and also the things that I do in the portal can be done through the CLI. We look for feature parity across both. And so if I wanted to create my app configuration through the portal, I could have created it through create a resource and I create settings through configuration explorer. All right, so here we see the setting that I created, color and then blue. Simple key value pair to represent a setting. And then we see some metadata on top of it, label, last modified, content type. The one I actually do want to mention before we get too deep here is label. So key value are definitely important because you need those to have a setting. But label is something important to our service because it can be used when you're querying settings and it gives you a way to add a new dimension to your configuration. For example, I may have an application that runs a premium and a standard SKU. And I might want the color to be green and standard. And I might want it to be red and premium or something like that. And so I can kind of model this with label. It's not just a metadata, it's not just like a tag that when you get it, it's actually used in queries. So when you query configuration, you can say give me all the settings for the standard label, or give me all the settings for the premium label. So this is kind of what I talked about before where I have nuanced configuration, maybe like a West US or North America and Europe, stuff like that. So label is something important for our service layer. So now we have the ability to create settings. We know what it kind of means to have an app configuration instance, how I can create settings for it. I want to go a little bit further into the portal here before we leave it. Just kind of get the coverage. We see some other things down here in operations such as feature manager. Feature manager is a value on top of just simple configuration. I can probably go into that into another time. But we also have some configuration utilities down here. We are storing configuration and we're a configuration service. So it makes sense for us to have utilities like for example, I need to restore my configuration to what it was yesterday because it worked yesterday but it doesn't work now. You can do that through the restore tab. So you can select a day of what I want my configuration to look like. For example, on September 11th, I didn't have any keys. So it's saying, hey, do you want to delete these keys? I can compare settings. I can compare across app configuration stores. I can compare across labels. So like I said, I have a premium and a standard app. I want to compare these things. I can see red and green. And I can also do import and export. Import and export is really valuable. It's actually my favorite thing because especially when you're bootstrapping app configuration from a .NET Core developer point of view, you probably have app settings.json, something along those lines. And we support the ability to come in from a configuration file, import settings, we also allow export of settings to a JSON file. And this can also be done through the CLI. That's that feature parody I talked about. All right, so that is kind of the background for app configuration, the portals, CLI interacting with it. And now that we know how the settings are represented and how we can kind of get started, it makes sense to move into a .NET Core app that's actually utilizing this. And so before I do that, let me go ahead and use to another app, move to another app configuration that I already allocated. This one doesn't have any settings yet, but I'm gonna show the import I talked about from a configuration file. I'm gonna import some settings, appconfigwebdemo.json. I'll actually show that file. It's just like app settings JSON file, if you will. And I imported it into my configuration store. And now you can see I have all these settings here. They all start with webdemo colon. That's kind of a prefixing practice. I may have multiple apps configuration set stored in my single app configuration and one way to separate them is by namespacing them. So all these are from my webdemo app and they all start with webdemo. And now I have these settings here. I can start consuming them in a .NET Core application. So let's move into an ASP.NET Core 3 application that I have. This is a ASP.NET Core 3 razor pages application. It's doing very little actually. The main point to get out of this app is that it's pulling the configuration from app configuration. And the way we're doing that is we're binding our configuration to a model called settings. And you can see there's kind of a one to one mapping here, refresh rate languages. These all map to settings here. And we're binding them to that model and we're using those properties in our razor view. So essentially we have like a one page app pulling configuration and just using those settings to show what we're seeing on the web page, the very simple way to demo the configuration. Now the typical practice and .NET Core for configuration is to use a configuration provider. .NET Core comes with a few very common ones like JSON file configuration provider, environment variable configuration provider, command line, etc. We offer a configuration provider. It's the Azure app configuration, configuration provider. And so that is what's gonna be showing right now on my program CS. On top of the environment variable and JSON file providers that come by default and default builder, I'm wiring up Azure app configuration. So it's these lines right here. This API add Azure app configuration is exposed by the NuGet package right here, Microsoft.azure.appconfiguration.asp.NET Core. So I just need to add a reference to this to my ASP.NET Core project. And then I can go ahead and start using this API. Okay, so I go in, I call add Azure app configuration. And then I need to do a little bit of configuring to actually set up the app to pull the settings from my app configuration instance. The most important thing is I need to connect. Now what I'm doing right here is called connect with managed identity. This is a feature that we utilize on Azure platforms that are running applications that support managed identity. These identities can be assigned to these Azure platforms. In this case, I'm running an app service. So I assigned an identity to my app service. And I granted that identity access to my app configuration instance. So I can actually go into my app configuration instance and I can look at the role assignments. And I say, I granted access to my app service. And so using this flow allows me to short circuit the other way of connecting that I'm gonna get to. It allows me to, well I can short circuit connection stream basically. And I can take advantage of the fact that I'm running an app service. I'm running my.NET Core out there. But if you don't wanna do that, that's perfectly fine. You can just use connect and you pass a connection string. The connection string comes from our portal or our CLI. You can list it there and then you would just provide it into Bootstrap your app. But since I am running this app for the demo in app services, I can utilize this way of connecting. And one of the great things about this is I don't need any configuration to bootstrap my configuration. Because as you can see, I'm not using a connection string. All I'm doing is specifying the end point of my app configuration instance. Okay, moving on to some other options used in this. We have a little bit of filtering here. This use is just specifying a key filter because I mentioned that I kind of wanted to segment my applications. And in this case, I have them all namespaced by a web demo column. All right, and so I'm selecting only those. Then finally, we have this configure refresh. And this links back to what I talked about before where we have a notion of wanting to dynamically update configuration during the run time of our application. Because some application designs depend on this behavior. And so before I go into configure refresh, I actually want to talk about where the refresh is triggered. And so I'm going to go into program or start up CS. And we see this use azure app configuration. This is the only other place where any Azure app configuration code is found in the application. And what this does is it wires up a middleware inside of your ASP.NET Core app that uses requests to actually trigger a refresh of the configuration. If you were using our configuration provider previously, you may have been aware that we were using a polling model before. And now we switch to a middleware model. And the reason for this is that when you're polling for configuration, especially in a microservice world, you end up maybe just using a little bit of unnecessary resources if you're doing that continuously even if the application is dormant. With a middleware based approach, we can be smart about when we want to refresh our configuration. If you have 10 apps, maybe not all of them are always getting requests. You're load balancing or something like that. Only the ones that are getting a request need to really be triggering configuration refreshes. When the other ones start getting a request, then it makes sense for them to start triggering refresh as well. And so that's what this does right here. Request based refreshes. Now we can go back to where we're actually configuring the refresh. Because we know that refreshes are being triggered, but what does it mean to trigger refresh? And that's what we're configuring right here. Essentially what we're saying is, what do we want to keep up to date? What settings do we want to refresh every setting? Maybe one or two settings that are really important that need to be dynamically updated during the app. That's what's configured right here. In this case, I'm watching a setting called WebDemoCentinel. And not only am I watching that setting, I'm specifying something called refresh all. Which means when that setting changes, when I notice a change in that setting, I want to refresh my entire configuration just like I did when the application started up. So I want to go back to app configuration and just get everything again. That's what's happening right here. And so with that, that's the full setup of app configuration in my .NET Core app. Now I can actually see it in action. So I have this application right here. It's blank right now because I didn't have any settings before, but I uploaded some JSON settings. And if I refresh the page, you'll actually see that I have some configuration from Azure App, or some settings, some data that came from the settings. It came from my Azure App configuration. This came because I uploaded that JSON file. But to kind of give a better view of that, we can go in and edit some more things right now. Let me show the values for these. Let's change the background color to green, maybe increase the font size. Just kind of do what we can to make the changes very apparent. And also make a better message. So now what actually happens, if I refresh the application now, nothing is going to change because we're only watching that sentinel value, like I mentioned. But as soon as I update the sentinel value, I just need to change it. I don't really, it doesn't matter what I change it to. The application can start picking up the changes to all the settings that I updated. So we're going to start seeing the change to the green color, high.netconf, bigger font. And so this kind of just shows dynamically updating settings during the run time of the application. So to get started, all you really need to do, pull in the NuGet package, Microsoft to Azure, the app configuration, the ASP.NET Core. That's if you want to build an ASP.NET Core app. If you're just building a .NET Core app, ASP.NET Core is involved, we also have another package called Microsoft.Extensions.Configuration.AzureConfiguration. It uses that common configuration provider namespace. That one doesn't pull any ASP.NET Core stuff into it. So if you're just building a console app or maybe a hosted service, it makes sense to use that. It's still going to give you the ability to do refreshes. It just doesn't give you the request-based refresh middleware, but you can refresh the configuration yourself on demand. All right. So that's the .NET Core scene, but for .NET Core developer, just developing applications isn't the whole picture. There's also you need to build and you need to be able to release your applications. So we've been seeing a lot of mention of Azure DevOps for these kind of needs, and we actually have a DevOps build and release task. It is on the DevOps marketplace. You can go look for Azure App Configuration, and you can add it right now to your organization or project to start using it. And what this does is it utilizes all the settings we put in our app configuration and it injects them as variables into our build and to our release. So I can actually go ahead and create a new build pipeline to kind of show off using this. So create a new build pipeline here. Delete all the steps just to add in Azure App Configuration, my subscription, my configuration instance name. So now with this task, every setting that's present in here is going to be available to my build pipeline. And if I use it in other builds, it's going to be available in those build pipelines. So I can share my settings across builds now very easily if I'm centralizing them in my app configuration. And I can also put my app settings there. And so it kind of makes it easy to manage them in one place and have one interface that you're working with for settings, one set of pools, one CLI, one form of automation. And now to demo this, I will add in a PowerShell task right here. And I'm just going to echo a setting from Azure App Configuration message. I don't have that yet, but I can create it. Message, hello devops, cool. And now when I save and run this build, I don't want to commit to master, but I'll save and run this build. And then what we'll see is it's going to very quickly pull the settings, put them in as build variables, and then say hello devops. And we'll kind of have that. And like I said, what this allows us is we can easily have one interface for managing our settings for the applications we're building. We can share these settings across all these builds, all these releases, just make sure to bring them in through this one build task. And then we can kind of keep with the semantics of how we want to add dimensions to our configuration with a label, things of that nature. And I even want to go a little bit deeper into the DevOps interoperability with App Configuration. I mean, configuration is really all across the stack. So applications using configuration, DevOps is using it. And there's even more room to talk about it here. Because Azure DevOps is very easy to interact with the Azure CLI. You can spin up very quickly an Azure CLI inline script to start doing something. And so this kind of ties in to a scenario where you may have an application and you can't afford to pull settings at the run time of your application. You can't make a HP request to pull settings. You can't talk to the service, possibly as a requirement. Well, if you still want to use Azure App Configuration, it's perfectly reasonable to have those settings pulled at build time or release time. Package them in an App Settings JSON file and deploy them with your application. So I can go ahead and show kind of what that might look like right here, and also show using the Azure CLI to talk to App Configuration. So let's hook up an Azure CLI task. Let's do a inline script. And we're going to use a functionality you saw import on the portal. But now let's do an export on the CLI. We're going to do an export all the settings in our App Configuration to a JSON file. So that's what we have in this right here. App Config, KV export. We're saying to a file. We give the file path, AppSettings.AzureAppConfiguration.JSON. It's a JSON file, the separator we want to use, and the config store it comes from. Finally, let me go ahead and publish these artifacts so that we can see them at the end of the build. And it demonstrates, as I mentioned, you want to pull settings during build. You don't want to pull them during the runtime of your application. You want to kind of have that very consistent, or it's just a requirement for when you're running our apps. So let me run this build. And then so this will take just a second for the Azure CLI to log in. That's probably the longest part of using the Azure CLI in this build. But it will produce the Azure AppSettings.AzureAppConfiguration.JSON file. And if you were doing this in a real scenario, you would just put that right next to your AppSettings.JSON. And then bam, you now have dynamic settings, but they came from during build time. So that's pretty much all I have right now for Azure App configuration, centralized configuration management solution. We have utilities for managing your configuration, a way to share your configuration across all kinds of different platforms. DevOps, it doesn't matter where in the stack you are. Azure AppConfiguration can help out provide the configuration there. And I guess real quick, I do just want to show the build artifacts of this. I did say published build artifacts. Well, there was supposed to be a JSON file there. I maybe typed something wrong in the build pipeline. But I think the idea is there. It basically produces the exact same file as this. And it would be present in the build artifacts. I must have just typed something. But yeah, that's pretty much it for me. All right, this has been a pretty amazing, Jimmy. Like, look, and I'm going to tell you this, because Matthäus, I think, has said, if I say it wrong, I'm so sorry. I thought this presentation was going to be about appsettings.json. Azure AppConfiguration is amazing. It's cool to have this other place to put that stuff and manage it. It was about appsettings.json, kind of. Kind of. And then the other one, which was interesting, which you answered there at the end, but I'd love for you to reiterate, what's the best way to do a fall back to offline settings? You kind of showed this a little bit in your demo. Why don't you see what, maybe he's going to tell me how to say his name. I'll say Matthew American nice. So how do you do a fallback to offline settings? That's a good point. So there are multiple different considerations when you're talking about fallback to offline settings. There's what I just talked about, about putting your settings there during build time and release time, so you don't have to make a query during runtime. So I just demoed that. That's exactly how you do it. I don't know. Like I said, I probably mistyped something in the build pipeline, but there would have been a JSON file there that could have been used as appsettings.json. Another aspect would be something that we have in our configuration provider, which is called an offline file cache, which if you're running on the same VM or something, and maybe one time when your app is starting out, it doesn't have network connection. You can use an offline file cache in our configuration provider library, and it will pull the last retrieved settings. They write them to a file and encrypt them, and it will pull them in case it doesn't have a network connection. So kind of two different practices for offline. So probably not the first one, but the second one is there as well. That's cool, because I thought maybe you just pull it and build, but then you also have a cache to fall back on as well. That's cool. Is Azure App Configuration recommended for secrets like connection strings? Another good question. All right. So Azure App Configuration is a completely secure way to store any key value, encrypting things. I mean, there's no worries there, authentication, authorization, all good. However, there is another service named Key Vault, which is better for management or management of secrets. They have things like, if you're managing things like certificates, auto renewal of certificates. Or if you have things like connection string, they'll expire connection string, and they have very granular access policies. So they are the best place to store a secret. So there's nothing wrong per se with storing a connection string in an app configuration, but ultimately for secrets, that's exactly what Key Vault was designed for. Whereas we were designed for just configuration, extensive querying mechanisms, things of that nature. And one of the things that we're actually going to be coming out with soon is a way to reference Key Vault secrets in the .NET Core Configuration Provider. So we'll go through to Key Vault for you in your app. It kind of abstracts Key Vault, but your secrets can still live there. And that's cool because Nick had the same sort of question. What's the difference between this new app config and Key Vault? So Key Vault is for secrets, app config is for, how would you finish that sentence? Yeah, Key Vault is 100% designed for secrets. Azure app configuration is designed for configuration. There's nothing limiting you from putting anything you want in app configuration. But ultimately, as we have configuration management utilities, Key Vault is going to have secret management utilities, the expiration, secret rotation, or certificate rotation, things like that. So those are values that we're not going to be able to give because that's not what we were designed for. That's awesome. Does this configuration service integrate directly into Azure Functions so I don't need to manage the config there? Okay, so two things. Our .NET Core Configuration Provider is net standard. You can use that in an app function and pull it right when your app function starts off. The second thing is I exported something to a JSON file in the last presentation. You can export it to an app service through the CLI or through the portal. And so other platforms within Azure, we want to integrate with to be able to push our stuff there. Azure Function, AKS, you name it. On our roadmap is the ability to do this automatically via sync tasks. And to just have your configuration live there, but you can still manage it centrally in app configuration. Amazing last question. Is there an app configuration Nougat package for the .NET framework? So there is, yes, there is net. The one I just mentioned is net standard. So you could use it in the .NET framework. Also, we do have a configuration builders Nougat package. The configuration builders was introduced, I believe, in 4.7 and it's kind of a net framework way to do configuration, well built into the framework there. And we do ship something for that. So it's an Azure configuration specific .NET framework configuration builder. Amazing. We have some feedback coming in on, may I say, they're Mika's jokes that I was asked to read. Okay, the jokes on .NET Conf, I told her that they may not work, but she was adamant. So maybe we should have a talk with her afterwards.