 Right over here to my two good buddies, this is Paul and Andrew. Hey guys, how are ya? Hey, how's it going? Good to see you, Beth. Thanks for joining. Hey, we saved the best for last, right? Okay, last session of the day. What are we talking about today? We're ready to roll. We've got five Azure services. How many services are we gonna talk about? Oh, five is seven. That's five. Seven? Wow, I'm excited. I'm gonna do five, I don't know. I'm gonna do five. All right, let me start off with the best one. Most favorite. Yeah, I feel certain. Close to home. We'll lead with, I think, the two that are kind of universally applicable and have a thread through them. I think one of the goals for today, for our talk, is we hear from a lot of people, there's a lot of Azure services, we don't know where to start. So we tried to pick five services that we think apply to most.NET developers looking to move stuff to the cloud. Yeah, certainly we're not. Super piginated. Like, if you don't know, start here. Yeah, okay. So we're gonna tackle some very common scenarios that.NET developers are building today and what services you could really take advantage of right off the bat. Absolutely. Okay, so what's the first one we're gonna talk about? The first thing we're gonna talk about is Azure App Service. So we're going to have a sample application that we're gonna walk through. We'll go to Paul's machine first while we're doing this. And so it's relatively simple. Web application has a SQL server associated that stores login and some basic interaction data with. And then it's gonna let users upload images to the machine, or sorry, to the site. And then people can see images that they've uploaded. So this is an ASP.NET application. ASP.NET application. It's core to be precise, but nothing about it that's. Not fancy. Yeah, could be written in either. It's not that quarry. No, not that quarry. Okay. Not that quarry. Not that quarry. That's a different quarry. Right. And so the first service we wanna talk about is App Service because when we're thinking about moving web applications into the cloud, your first question is where am I gonna host this thing? What is the backbone of the application? So App Service is great for hosting ASP.NET apps. Absolutely, yes. Yeah, especially stateless front-end applications, web APIs, no brainer, start there. Cecil actually had a good demo in Scott Hanselman's session today. Keynote, yeah. Yeah, it's cool. Very cool. I think the way we talk about App Service is if you're looking to start hosting application Azure, App Service is where you should start. You may find in some cases that you grow out of App Service or you have, if you're migrating an existing application, you may have special requirements that it doesn't need, but it would definitely be the place that we'd say look there first and only if it doesn't meet your needs then go somewhere else. Yeah, I love as a dev, it really lets you focus on your app. Microsoft takes care of the infrastructure, like the OS, OS patching, IS, scaling it, all these kinds of operational things. So you just get to focus on your app. So we should also clarify, it doesn't have to be a core app, it can be .NET framework-based app as well. It can be .NET framework app. In fact, there's even a number of languages for those of you watching. There's all kinds of languages that are supported. Java, Node, and also Linux and Windows. So it's just like expanding, it's the easy way to start with these web applications. We're going to show .NET today. Okay. We have a bias. I have a bias. Okay. I'm in the right place. Never guess, Beth. Never guess. All right, cool, let's dig in. All right, so do you want to speak to your app, your beautiful image gallery app? Yeah, I mentioned it a little bit, but as Paul said, so if you look at Paul's machine here, you upload images, you can see images you uploaded, and then there's a SQL server associated that holds his login data. It's out of big transactions. Because it's all nature. Love it. Got it? All right, so looking from the Azure perspective, so I'm going to switch over to the Azure portal. And the first thing I'm just looking at, just kind of like a lap around, we'll look at the resource group where we created this. I just think of a resource group, like a namespace for those of you who work in Azure, you know what that is. And we're going to pick this app service. And just to Andrew's point, so many things are just built in. Like I can see that Azure is handling the health and the status. I can see it's running. I can see which location in the world it's running. It's in East US right now. Get to the public URL, right? But I want to show you some of the cooler things. So as a cloud developer, I care a lot about moving between different environments and making sure that the configuration for each environment remains intact, but I don't have to make changes as a developer to my source code. I really don't want to have connection strings and secrets and things like that in my code. So what app service does that I really love, you just go down to the application settings and that's basically your set of environment variables. And for each instance of an app service you have, you would keep the same name, but you could of course change the values or an operator who has the privileges can save those values. We'll talk about slots in a second, but even if you use slots for DevOps, the settings are aware of slots. Cool. Yeah. And then a couple other goodies, you know these days, HTTPS, SSL, TLS, super important. We, I think in the tooling, we turn it on by default now, right? We do, yep. Help people get through that. Nice. You can set up your own custom domain names, your CNames, so there's just a number of things that you actually, and turns out, had to do to have a real web app and it's just built in. That's cool. Here. Then thing about, you know, it's the cloud, so of course you expect a lot of scale. So the first thing I'd look at is, you know, when you need more resources, you can just simply, either through the portal or using a command line CLI, you can just add more virtual resources I was trying to make a new word today, you didn't buy it. I talked about virtual virtual machines, it's kind of like you did. Yeah, okay. More virtual virtual machines, you didn't buy it. But you can do that manually, you can also set up auto scale, so there could be a metric, whether it's like request per second, or whether it's CPU, memory, you can scale based on those metrics. So you can control it, or you can have it decide. You can have it decide. And so basically I'm just getting more and more instances that can handle the traffic. That's what we call scale out, there's also scale up, which I just think about as kind of improving your hardware, improving your virtual hardware. Okay. So in this case, what did we pick, Andrew? We think it was an S2. S2, yep. Right, so we got 3.5 gigs in memory, a few CPUs, you know. I know, that's cool. But, you know, our guidance is always start with the minimum app service plan, or basically scale that you need, and then try to scale out first, try to use more instances, and then as you need to then scale up, and then you'll get the best economics from doing it that way. Gotcha, okay. What I miss, I miss anything super cool about this. So can you think about it like, okay, there's scalability and there's performance, and if you're maybe hitting a performance problem, then you would probably scale up? That's a good way of saying it. Like if you, another way, you know, people talk about solving things through DevOps, so if you just need more capacity, you need more capability to run the workload, then you would scale out. But if the minimum requirements of just the service that you built as a developer itself, you might actually need to scale up just because you need, you know, even initially, you need that overhead of better hardware, more memory, let's say. Like if you have a memory intensive app, I would go for a higher memory skew. Okay. A different way to look at that is, depending on the resources of a single request, so if you're doing very computationally intensive stuff or high memory stuff, as Paul was saying, so any given request that comes into your application needs a lot of resources, that's when you'd scale up. If the issue is simply handling a lots of requests concurrently, then scaling out is gonna give you the better economics. Like we were just talking to a customer, just truly just yesterday, and they're kind of saying, hey, even with four users, I'm actually hitting some problems. I'm hitting some contention. And that's already a sign that either like the hardware needs to change or the app needs to kind of be refactored. So you're looking for those kind of signals versus is it more like, hey, when I have a lot of requests at scale, that many requests start to bog it down. Gotcha. And you're probably gonna tell me later how we could actually troubleshoot those types of issues too. Yeah, it's almost like a softball lead into. No. Maybe. Good happen. Okay, cool. And of course this works really well with our tools. So we just made sure that you just have an express lane to build your ASP.NET apps, your APIs and just push them into App Service. Cool. Yeah. Yeah, so I think it's a perfect segue into, and one of the other great things about App Service is just the first class integration with our diagnostic tools. Nice. That's cool. I would expect that. Yeah, so should I take a little run through of that? Please do. So everyone has it on. You need to know this, Beth, that Andrew actually wrote this application, and he's been trying to tell me all week that it's perfect. Okay? Okay, so. Tom Paul, he's been a manager far too long to be allowed to write code any longer. And as the manager, that's why I use the data to actually balance what you're telling me with what's going on. So let's actually, let's take a look. Yeah. Let's see what the data says. All right, so let's look at the overview. So there's a lot of ways that you can get into Azure monitoring, and think of Azure monitoring as the best way to turn the lights on to get metrics, logs, alerting, even deeper application insights. And it's really easy to turn that on from a web app. So a web app is intrinsically more of a developer application thing. So we're gonna go straight for the application insights. So I'm gonna pick that. That's again, part of Azure monitoring, just built in. We just did this in the last couple of months. We made it easier to turn on what I think of as the best default diagnostics plan. So it collects all the goodies that you probably want by default, but not too much. What types of things does it collect? Yeah, that's a great question. So first thing, we collect metrics and logs that's standard, but also we collect some APM or application performance monitoring data, really meaning things like we look at requests, which is a big part of a web app. We understand request times. We understand requests per second. And there's some really cool things with application insights. It actually knows inbound and outbound dependencies. And there's a correlation that gets added all the way through. So what that all lets you do is it lets you understand the end-to-end distributed trace of an entire application, which you can understand from logs. Logs are incredibly powerful. I think everyone uses them, but the tracing goes that one step beyond to help you understand full transactions. Also things that we worked on that we turned on. So we have a profiler, helps you get into real low level detail about am I spending too much time in CPU? Am I spending it waiting? Waiting for some dependency call. And we have a debugger that lets you collect dumps automatically at low overheads safely and we'll show some of that too. That's pretty cool. So also there's SQL, like you can do SQL level instrumentation. Everyone, especially he likes to blame SQL. So we get to figure out was it really SQL or was it your code? Okay, so let's take a look. So we'll look at the data. Again, that was easy to turn on. All right, so we're getting some metrics by default. We're seeing some failures. That could be user error Andrew. Don't worry about it. And then there's response times and things like that. Some different users using it. So let's just look at the most basic things we get out of the box. We have search. All right, so let's just look at all the data, all the logs, all the telemetry coming in. And here we go. We're getting all kinds of things like we're seeing requests, we're seeing trace messages. It even understands there's some outbound dependency calls into blobs. That's some of that APM tracing I was kind of talking about. So this is really cool. It's powerful. You can search like I could search just on exceptions. Also everything you see here, this is kind of the easy view, but you can open it up into analytics. We have this really powerful analytics platform that can search across all of the monitoring, all of the application, even the security data. And you can query and make very specific insights. Really custom queries. Yeah, really custom queries. And then that's the kind of thing, I think in our team rooms we do this, we make the queries that make sense for our teams. And we put them literally up on the screen and something we watch all day to kind of see how we're doing. That's cool. Right, so it's our metrics or our goals for the team to keep those things working well. So whatever's important to you, you can create a query and monitor it. Now I have to say, I still have no evidence yet that there's any actual issues with the app. So far, I think Andrew's winning. He's winning the argument. So let's go to the actual failures. Okay, so we have some errors that have been happening over the last 24 hours, change the filters. We have 21, 500 errors in the last day. That just, I think 500 is what, internal server error? Yeah, it is. That could be anything. It could be anything. Could be totally anything. Infrastructure probably crashed. And he had all day, by the way, to make sure this thing had no bugs. Just remember that. All right, so what we're doing, we're looking at this exception here and we're seeing there's an unhandled exception at the controller or the page that does a right watermark. So that was the part, like you took images in, you put that, your nice little watermark below. Now does IES do that or does your code do that? That would be my code. Okay. Double check. All right, so we have a null reference exception. There is no object reference. Any ideas what this could be? I'll go with the code. I could use a little more information. What else can you tell me? Okay. Well, we could actually open up a full debug trace. Like there's actually a dump of this that was set aside. I would love to see a dump of this. Okay. You might convince him. He's grasping right now. So basically you're saying that app insights will take an automatic debug snapshot when an exception occurs? And it's not, it's a little bit less aggressive than every exception because that would be wild. If you think about a mini dump, even a mini dump is kind of like taking all the memory on your machine and just very quickly, like 10 milliseconds, setting it aside, which is safe, right? It's even safe in production, but you don't want to be wasteful about that. It's chewing up storage and CPU. So we have like a collection plan, a collection strategy that looks at a certain number of exceptions that we've seen. Let's say we see over five of the same type. I see. Then we would go and take an exception or sorry, a dump. And then after we collect that dump, we're kind of like, well, we've seen that one. So maybe we shouldn't try to keep collecting the same one over and over again. So there's some things like that in the collection plan and that's all configurable. We have a default plan that, we try to make sure that law of averages over 24 hours, you're gonna see a good distribution of exceptions and you're gonna see representative dumps from that. So let me ask you a question. Is it better just to turn this on by default and let it do its thing? Or you should you only turn it on if you're starting to notice problems? You have both options. I like to put it on, because it's one of those things it's, hindsight 2020, you start getting exceptions. Who knows what the context was? Like there's easy things to debug, like logic errors that just were always there, or like a configure or a missing dependencies. Like those are gonna break fast and you might have a good idea from the logs. And I would never try to debug those things. But it's more like, hey at 2 a.m., something weird's happening and it goes down. Or some of my users maybe who are in another country, they're reporting issues and I have no idea how to reproduce that. And that's when a debugger is incredibly useful, because you get, this guy by the way worked on designing the debugger. But you get the context of everything coming in, like the local variables, the parameters. And that actually helps you understand, oh, it was this data point. So it's not just what broke, it's why it broke. So you're saying you can open these right up in the Visual Studio, right from here? Yes, you can. So here, like you get this web view that everyone has, it's lightweight, you don't need a dev environment. You can just download the snapshot and it's basically what the mini dump plus symbols and what am I missing? Yep, yeah, it's mini dump and symbols really. So it's gonna be big just to warn you. It's the full copy of the process memory, which gives you the full ability to inspect and see what's going on as Paul was saying, but what we had a 3.5 gig server, so that mini dump's probably gonna be two gigs at least, depending on what the application is doing at the time. So the web portal's definitely the place to start. You experiment around, you look, and when you're like, I really need to really drill in, that's when you wanna kinda do that next step of leaving the browser and bringing that down to Visual Studio. Cool, and just to kinda cut to the chase. So I could open in Visual Studio, but actually I think I have enough to go on here to ask you a question. So the username is null, and then we're sorta croaking on the right watermark, so. Any more ideas? Yeah, so I looked at the code while you were drilling into that. As part of the watermark to make sure that we know who things came from, I'm actually stamping a hash of the username into the watermark, and it looks like I had a slight logic mistake. It's actually a really- I wasn't at the day the intern worked on the code, it wasn't you? No, it's actually really, it's a security feature. Okay, it's a security feature. So what happened was I'm accidentally letting people who aren't logged in upload images, and you shouldn't be able to upload if you aren't logged in, so I'm really just saving the service. Oh, and you're saving the company money? I am. Thank you. That's a good guy. Although I will fix the application to not let people who are not logged in upload upload, and then we should be safe and try to fix that image. So that gives you a taste of what it takes. We use logs, we use metrics to investigate failures, and then when you really need to, when you're in trouble, there are things like the snapshot debugger for dumps, where you can just do that deep analysis. The other thing that we can do is we can analyze the performance. And so one thing I like to do is I open up this perf blade, I like to sort by account. So you can kind of sort from most frequently used APIs and controllers and pages to least, just to understand what's representative of your usage. Also average, it's good, it's bad, it's savage together, it's eh. So I'd rather use percentiles, I should patent that. So it's like, we'll take the median, just being like the middle one from the distribution. And now we can look again, we're saying okay, so people just viewing the homepage, 44 milliseconds, it's decent. Ooh, like this uploads taking 12 seconds. That's something we're gonna wanna look at. And the cool thing is we debate all the time about the app, I bet there's people seeing things slower than what we see. But you never really know and now with this data, you actually know, it's pretty cool. Like you see the full distribution of what's going on, then you can pick one. That's really cool, that's pretty deep. Actually there's a question out there that's sort of related here. So is there any way for app insights to detect a new recurring issue with a build and send a signal to Azure DevOps to roll back the previous build? So would that be something like, could you detect a problem and maybe switch back to the other slot or something like that? You can do that. So just in Azure monitoring all up, there's metrics and then there's basically actions that you would take. So one action would be an alert. That's probably the most common. You could send things to your instant management system or to emails or pages or things like that. But also it provides a hook where, let's say in your DevOps pipeline to take that person's question. That would be the signal of, hey, I'm throttling my rollout at this point, I'm seeing the event that things aren't looking good, so therefore I'm gonna branch off and I'm going to roll forward is probably what you would do. Roll back, roll forward to a version that worked. And so that scenario isn't completely automatic, but what is automatic is the metrics and the alerting and the events and then just in your DevOps pipeline you'd wanna hook that event. Got it. And I'm sure we'll be looking to add a fully automatic scenario like that as soon as we can. That's very cool. Yeah, that's a great question. So just to keep noodling on this, so the get is like viewing the homepage, the post is the upload, is that how I think about it? Yeah, post is upload. Okay, cool. And if we look at that, we see this distribution, we had kind of agreed, let's focus on what the mainstream customers are seeing and see all these triangles. This says that not only did we measure those requests, but we actually got profiles. And the profile gives us that deep level analysis. And I feel like performance engineering is tough. So we wanna just make it a bit easier. So the profile, we've been automatically collecting samples with full profiles. And you can see we have some that are 17 seconds, that's the worst one, all the way down to this median. We saw the median was around five seconds. So let's go here, let's sort by timeline and then Andrew, I'm gonna need your help to analyze this. So it looks like we're spending on a lot of time awaiting, kind of like awaiting for the CPU. And then the code you're actually running, your code looks like it happens in the very end. So like, how do I think about this one? Yeah, so I think what's going on here and I took a look at it to kind of drill it in, clicked around the traces a little bit more while you were looking at this on my machine, is while when the user uploads image, we do some processing on it before we put it up. And so when we get multiple users uploading, they kind of those requests are stacking up. And so that block time is they're waiting to get their term with the CPU to process that image. Okay, now, do you have an idea of why this method might be blocking, right? Like leaving us in a block mode, so there's a contention? Well, the issue is to process the image, we need the CPU. Okay. And, you know, there's, I think our plan, we have two cores on our CPU, which means that if we get two, more than two concurrent requests or two requests before it takes time to process that image, then we just have to wait until the CPU frees up before we can actually. Are we trying to do too much in this web app post? That is probably the right way to fix this. I don't know that I can make the code any faster that actually processes the image. Okay. So probably like rearranging, refactoring. Yeah, so I think the right way to fix this from a performance perspective would be to tweak the architecture of our application a little bit and offload the processing outside of the web app. Do we have time to try this? Could he try to refactor it a bit? Yeah, let's do it. What are you gonna do, use another Azure service to do this one? I am gonna use another Azure service, thank you, Beth. Nice. So yeah, we'll come over to my machine now. Okay. So real quick, what I have up here is just a small architecture diagram of the application as we have it so far, which is an ASP.NET core web application that's using a SQL Azure database to store user information and when users upload images, things like that, and we're storing the images that users upload in Azure Blob Storage. So we promised you five Azure services. We've talked about four so far, right? App service, application insights, Azure monitoring, SQL Azure, and Azure Blob Storage. And we just flew by storage and SQL. We flew by, everyone knows SQL, it's like it's- We flew by storage- We have a database. Yeah, we flew by storage and SQL. They're incredibly hard, but you can take it for Greg, it's SQL. Talk about them like air and water. They're, you know, you need to store files and that's what storage is there for. SQL Azure is built from the same source code that the SQL you would run on premises is, so if you're familiar with those things, not like me to spend a lot of time touring them but be aware that they're available. It's your relational database in the cloud. It's your relational database in the cloud. And they run at scale and they're backed up for you and like really good things like that. Cool. All right, so just scroll down. And so what we're looking at now is a architecture diagram of what we want the application to be. And so what we're gonna do here is we're gonna introduce Azure Functions as our fifth service. And so Azure Functions are event-driven code that are gonna dynamically scale outside the contact of my application. And so in this case, the event that we're gonna use is uploading the image. And so when the user uploads that image, we're just gonna pass it directly through my application. I'm not gonna process it all. I'm gonna stick it in a new container that's like a queue for waiting to be processed. I'll actually move the code that does the processing of the image we call it watermarking into a function that will then run independently application. When it's done, it's gonna move that over into the blob store that my application actually reads and serves the images from when a user looks at it. Gotcha. Okay. I need to admit, I've been around for a while and I've seen this kind of queue pattern where you have workers and web. Is that basically what you're doing? Is the modern way to do web worker with queues? Exactly. Oh, let's go there. Yeah. Can you explain it? To use a kind of very buzzy term, some people might debate this is exactly what we're doing, but we're trying to more microserviceize the app. We're taking the idea of watermarking and we're moving that out of sort of being instead of being this one big application that does everything into a process. Exactly, we're gonna put it in a queue. We're gonna let the worker pick it up. And the end user doesn't wanna wait around for the upload and the processing of the image. They just wanna, boom, send it going. So that feels very asynchronous, very fast. Now he's got a beefier service that can scale infinitely, right? That's cool. To go chunk on those images and do his watermarking. That's the theory, yeah. All right, so I wanna start off by just talking about how we would add an Azure Function project here. I have one created, so we'll, I don't know, we'll wait for a second. But in the new project dialogue, we have a cloud node under the visual C sharp node. And so Azure Functions is the second project in there. And so when I select that, it would pop up. It would let, give me options for the various trigger types available. I mentioned it's event driven. So there's a lot of good logic built into the Azure Functions runtime that lets me automatically wire up and trigger. And the runtime does all the heavy lifting for me about creating the objects and things like that. So we'll show that here in a second. I'm gonna go ahead and cancel out of this and hop back over to my, our application in Visual Studio that's ready to go here. What's that? Bit to no. So I have an Azure Function project here. And so what I'm gonna do is I'm gonna introduce two images. So one is gonna be an image or a function that's gonna trigger when the image is uploaded. Let me unpin this real quick into my queue. So what the application will do is the application said, we'll put it in a holding blob container. That's the word I couldn't think of right there. And you can see functions. This is the only- Okay, a holding pin. A holding pin, there you go. Okay, perfect. And so- It's the Azure Jail. Storage, Jail. The code that we're looking at right here, it's all attribute-driven. So I can see that I have an attribute here that's blob trigger and it's mapping to the container named images. And then my out container, which is indicated by this file access dot write or my out stream is just also than the images hyphen watermarks. I mean, it sounds like a lot of machinery, but what I kind of see is there's a couple attributes that just say, this is the storage queue I care about and it's doing all that pipeline in just output for me, right? Exactly, and that's what I wanted to point out. I don't have to do any, there's no code in my application at all about reading or writing from storage. The function's runtime's gonna take care of that on my behalf. That's cool. So I'm gonna go ahead and hit F5 to start debugging this particular application. So I'm running this on my local machine because in Visual Studio, we have a full local copy of the Azure Functions runtime. Same thing that's gonna run up in the cloud if I wanna develop it locally, right? You get rich debugging, just the tight inner loop that you've come to expect from Visual Studio and .NET. And just to prove that it's gonna work like we expect, I have storage explorer here. And so what I wanna do is I wanna copy, drop an image into my queue that I'm listening to and we're gonna watch the break point get hit in Visual Studio. So that's your trigger. That's my trigger. So I have my blob containers here. It's the drag and drop trigger. Drag and drop trigger, exactly. And then we'll test this working out in the cloud. So let's go to my pictures folder. Let's take this nice little green picture. I'm so creative. Drop that onto my queue. It's gonna upload that. And then when I come back to Visual Studio. Yep, I can see that my break point's been hit here in Visual Studio. I can see that it's gonna give me the name of it's green.png. And so as I hit F5, it's gonna go ahead and process that. And then if I go back to my storage explorer here and I refresh, I'm gonna expect that my sec, so I had a second function that when I finished processing I actually took care of deleting the old copy. Oh, and there we go. My delete one just got hit. So I had left a break point in there originally. So I hit F5 and that's gonna finish. And then we go back to storage explorer. We refresh the holding queue and it should be clean. It's been deleted. And we go to our images watermarked container. We're gonna see that we have green.png. It's been uploaded. So I've been able to, I have that wired up. And so now on my application, let's go ahead and test this in the cloud, Paul. Yeah, love to see it. We don't need to run it locally. But what I wanna do is I'm a little worried about messing up our production site. Obviously you and I are banking our retirement on this photo gallery app. We are. Succeeding. We nearly broke everything before this too, it was awesome. And so what I wanna do is I wanna create a deployment slot. So we've talked about slots a little bit. I think this is one of the really killer things in app service. And so what a deployment slot lets me do is let me create another place to push a copy of my code in app service. And then I can publish my application to that without affecting the regular site. And then I can go run tests against that. And then if I want, I can even then start routing a certain amount of traffic to that. So I've already created a, so I would create a slot here. So I'm gonna call this one blue because I've already created a slot for this one. So we don't have to watch it copy the deployment. That's like the deployment strategy. It's like blue, green. You're saying I could have, I could swap back and forth. Blue, green, test, prod, you know, kind of whatever you want. And then as you were showing the app service settings a little bit ago, I can choose what I wanna do from configuration. Do I wanna clone my configuration? Do I wanna share my connection strings? Or do I wanna have my own copy and potentially use different storage in a different SQL server here? For the purpose of this, I'm pretty confident in the quality here. So let's go ahead and clone just our regular environment. We'll run against the same storage and the same SQL. That's not a problem. And then from visuals. There's a question too. Yeah, I just wanted to let Andrew finish his sentence. But if you wanna be the host, that's totally cool. I'll just leave right now. Sorry about that, Beth. What's our question, Paul? All right. Let me turn. Go ahead, Paul. Read the question. Practice. Sorry. Okay, that's it. Go ahead. So, Andrew, Beth and I would both like to know. Do you know with function apps, what is their roadmap for development slots? Yeah, do we have deployment slots with function? Deployment slots are already supported in functions. Sweet. Even better than the roadmap. So it's like GA and ready to go. It's like GA and ready to go. There you go. You can do it. Iki Biked. I love the handle, by the way. You are ready to go. We've got deployment slots. So Iki Biked, Yuki, Yuki. You are Yuki. Yeah, Iki Yuki. Iki Yuki, cool. Thanks, Iki Biked. So the first thing I just wanna show is how to publish to a deployment slot from a developer perspective. And then obviously you can wire all of this up through a CI CD pipeline as well. But when I right click publish on my application and I choose, I'm gonna pick a new target, I'm gonna choose select existing. And then in the group, once it loads my subscriptions, I'll be able to browse and you'll see deployment slots. So this is Azure AI 2018. This is the resource group Paul and I have been using and I have deployment slots and I can see blue and function here. I'd already published a copy of this to the function. So let's go. You guys might have just updated that too because I remember I used to have to download a publish profile or something. Right. Yeah, you used to have to download a publish profile from the portal. You can always, if you do that, that's still a supported thing. So we have the import profile button right here. But yeah, you can just target a slot via that browsing as well. The VS knows slots now. VS knows slots. That's cool. You have to create it from the portal but once it's created, you can pick it and browse to it. And then once I, so let's click on this. This is blue. This is function. And so this is gonna be the function-based implementation we just stood up. And so what we'll see here is once it loads, I'm gonna click on my, I have another URL and it's gonna be exactly the same URL that we had before except I have the hyphen slot name on the end of it. And so this is our function-based implementation and it looks like it loaded and worked correctly as I would expect. Application Insights is already picking up the data from it because we have it on the site. So Paul could go look at those metrics and check it out. And then we were just clarifying this, like the monitoring and app insights works across all slots by default, right? That is correct. That's cool. And it lets you know what's slot? There is metadata so you can filter. Very cool. Yeah. Well, I'm not sure. So the last thing I wanna show is if we go over to the application insights, did you show the app map earlier? I forgot. I was on my roll then. So there's something called an application map and because we put our function app and our app service in the same application insights resource, it's gonna automatically be picking up and monitoring that function as well. And so on my application map, which is gonna load right here, once it eventually loads. So the map is sort of like your architecture of all the services? Yeah, the map is gonna look very, sorry, I'm kind of in a weird zoom state here. Well, we're at first building just a quick story. We had talked about that. And a lot of times when you diagnose something or when you onboard a new team member, I think a lot of us, we go to the board. Yeah, right. We draw a picture, maybe someone's done a Vizio or something like that. And we thought it would be cool for developers to have that as a way to conceptualize what's going on. And then overlay the telemetry that's live over it. That's cool. Other cool things, you really, and keep me honest here, I don't think you had to change your app at all to get that. I didn't, it just worked. It just worked, right? So basically including application insights, it's tracking these inbound, outbound requests that rebuilds the topology for it. Wow, smart. Yeah, so it's actually, it's truly the truth. Like sometimes we even draw the picture and then you look at the data, it's like, oh, we didn't quite do what we intended to do originally. Gotcha. Yeah. But you can see the function. It validates your architecture real time. It validates, yeah. And you can see, I mean, you can see the, it looks kind of like the, I'm doing it again, okay, a little bit. That's all right. This is so excited. This is Paul's bread and butter. Paul designed the app map. I'll give him the call out there. But you forgot to talk about it. They don't always let me out of Redmond, you know what I'm gonna say. Especially to Vegas. But we can see the slot here. One, two, three, four, five. We can see the original instance that we have stood up here. All my fingers. We can see our function down here. So it's picking up everything and automatically building it. We can see our SQL server. We can see our blob storage. And so just by turning on application insights on the resources that we wanted, it's automatically building an architecture diagram. And we can see performance data overlaid. We can see that 19% of the calls are failing. Like all of this information is overlaid. So to Paul's point talking earlier about why it's a good idea to just turn it on by default, it puts you in a world where instead of being reactive of oh, people are complaining about a problem, you can go be proactive and watch. Are there particular connections that were a problem? Are there times that are problematic? Things like that. Once you have that data to it, yes, it helps with troubleshooting. It helps with keeping your customers happy. But also you learn a lot. Like, okay, I had an idea about how people were using my service or my app, but I really know. Right. Like I really know for sure and I know in detail. So it's... That's actually really cool. So there's a question here if I wanna ask you. No content has a question. Can you use application insights outside of Azure hosting services that you only maybe write logs and dumps to Azure? So that's a great question. Can you use app insights outside of Azure? Yes, you can. So an application can just include the app insights instrumentation engine or SDK in the application. In fact, for a number of years we did that in Visual Studio Desktop itself. So it's totally possible. And then at that point you're using the Azure service as your data and analytics store. And your app still resides on-prem. What does not work today is having the whole entire thing beyond premises. So like having the data storage and the analytics on-premises too. I see. So that's not yet. Okay. So you want the cloud to do the deep analysis of those dump spaces. Right. Which is actually a pretty good usage of the cloud. Yeah. Exactly. Okay. That's a great thing to mention. That's a really good question. Because yeah, if you can't move the production app with deployment you can still take advantage of these Azure services to do some monitoring. Yeah, absolutely. Another thing, I think we both have come to encourage this a lot too. Like always in addition to app insights still pay attention to your logs. Make sure you're meeting really good logs. And I can think about for those on-premises scenarios you always at least have co-located logs with you. And then there's further analysis that you have on the cloud and I think that's just a great combo. Right. That's actually a great combo. So we've been talking a lot about analytics and Azure app service and functions and storage. So those are sort of like write some very common scenarios that you would use like architecture on-premises to move to the cloud. What are some like, like we don't have to demo them but what are some additional services that you can only get in Azure that you just wouldn't be feasible on-premises at all. So I think one of the really killer ones in Azure which we didn't talk about but is Cosmos DB. So Cosmos DB is a database that Microsoft's designed. They built from the ground up designed to run in the cloud. It has incredible performance. It's a non-relational database. So it lets you really just work with objects in your code. Objects, documents. Yeah. And from a performance perspective there's things that you would have had to work really hard to break it up to get it in a relational model to help SQL perform well. But Cosmos... Was that called like nth degree normal where you have to know all that stuff? And didn't they release like a .NET SDK or something like that? Yeah, it's really easy to work read and write to Cosmos. Okay, cool. Since you're on the topic too, I think the work they've done around consistency and replication of the data is truly incredible. Like you can have eventual consistency, guaranteed consistency across a lot of locations. It's pretty amazing. I can't even imagine trying to build that myself. It truly, like you said, it would be just not feasible. Right. Right. Well, these are some fantastic services, honestly. So I think that we've kind of hopefully gave you guys good show here of some common services. You should definitely check out at least and take advantage of. We didn't really talk, like Ed talked a little bit more on the dev ops side. That's another way to go to is if you're not ready to deploy to the cloud, you can at least try some dev test scenarios you can do in the cloud. We had these cool lab scenarios, did it? Yeah. Did that get shown? Yeah, I don't know if that got shown but that's, I wanted to mention that. You can even have your dev environment or your test environment just in Azure and that's a safe step into the cloud kind of decide if that's a good working model. We also have a website, you know, AKMS, migrate to the cloud, whack, migrate to the cloud. I think it's been in the chat room actually. So that has a lot of great resources on just like, hey, how do I move? And it talks a lot about app service there. My front end, my data, yeah, app service is really what we recommend but also containers are really helpful too. If you need to preserve those dependencies, it's really helpful as well. And if you use your favorite search engine in search for .NET Azure, the top result, and I think all the major search engines is what we call the .NET Azure Developer Center that will have quick starts to all the things we showed and talked about as well as extra resources. Very cool. I think that we're building some learning kind of plans that you can actually like work right with Azure right through the browser and do different things, right? So that's a good way to actually check out without, you know, try before you buy. And I want to hear, you know, are these the five services we arm wrestle about all the time and I always lose? Yeah, yeah, let us know. He's right. But if, you know, if you want to hear something else, please tell us. Absolutely. We want to make it better. All right guys, this is the rap of the show. I mean, you guys hit the finale. It was awesome. Thank you so much. Nice, we made it. Thank you, Beth. It was really fun.