 Hi, my name is Andrew Hall, and I'm a Program Manager Lead in the Visual Studio team working on .NET Azure Tooling. Hey there, I'm Paul Yiknovich. I'm another Program Manager Lead working on Azure Development. What's a little known fact about us, Paul? Yeah, what people really don't know is that we're actually twin brothers, and that makes us totally interchangeable. It is true. We were just separated at birth, so different last names, but yeah, one for one swap, except Paul knows twice as much as I do, but I'm better looking. Well, you can tell by the height we're brothers, right? That's exactly true. That's right. We're sitting down though, so maybe. Oh, that's true. So today, we're going to talk about five Azure services every .NET developer needs to know. The goal of what we want you to come away with from this session today is, if you're looking to get started with Azure, we want to make sure that you get a really crystal clear view on where you should look to start with Azure. I think the five services that we've picked, we think are going to be the things that probably 80 to 90 percent of apps when they first try to go to Azure are going to need. Yeah, and we looked at a few different ways. We looked at how do you modernize the infrastructure that your app is using? How do you modernize the actual application to make it work just totally optimized for the Cloud, and then even how do you modernize your DevOps? So you're going to see that theme throughout. It's a perfect transition. Okay. So our agenda for today. So we're going to actually start off a little bit with some Azure terminology. We're going to make sure that we're not throwing around terms accidentally that we haven't defined. Every technology has done specific terminology, and you know what or you don't. So we make sure that that's clearly defined. As you mentioned, we're going to talk about hosting applications in Azure. So you have your code that was running either locally somewhere or some other provider. How do you actually create something in Azure where that can run, and you can hit it and you have a public endpoint to do that. As you mentioned, then we want to talk about how do we modernize it to take advantage of more of the power of the Cloud. Then as you said, introduce how do we start to onboard to a modern DevOps process. So with that, let's flip through some terminology real quickly. So one of the fundamental things you always have to deal with in Azure is an Azure account. So basically this is the credentials that you sign into Azure with. So if you were to go to the Azure portal or when you're in Visual Studio trying to work with Azure, you're going to have to be logged in with your Azure account. So I could use like my school account, my work account, my MSA, Microsoft account. That is correct. Hotmail, that kind of thing. Then under the account that kind of fits into the hotel, you have what's called subscriptions. So subscriptions is the billing plan that Azure resources are created inside. So this is when you create Azure resources, basically where is the money coming from if it's a paid resource. There's a lot of free resources which are worth mentioning. For a quick call out, if you have a Visual Studio subscription, you get Azure credits every month. So if you pick your Visual Studio subscription, for example, when I say unit of billing, it'll just use your monthly credits which reset every month. If your credits run out, you're not going to go bankrupt, I promise, Paul. Azure will just turn everything off. At least not for this. Not for this. Okay. Azure will just turn everything off, and you won't ever get a bill. You just can't actually access the resource until your credits. Yeah, I get that question a lot too about the like, if I'm using a free trial and I hit the limit of free, what happens? Yes. Yes. Great question. So if you're using a free trial and you hit the limit of free, Azure will turn everything off, and unless you have explicitly opted in, and it's an opt-in, the default is everything turns off and you can't use the resources, you could go in and you could say, okay, let me go over my free credits, and here's a credit card that goes with that. So it's like a spending cap and you could lift the cap but that's up to you. That is correct. So it's safe by default. It is safe by default. You will never, without choosing to say, you can bill me more than my credits allow, ever end up in a position where you get a really large bill you didn't expect. So free is truly free? Free is truly free. Okay. And even if you're trading against credits, it's only credits, you're never dealing with real money. Okay. So next thing, we talked about creating resources inside accounts. So we should talk about resource, and a resource is maybe obviously, but any service that you would create inside Azure, anything that's going to actually take any CPU or memory or storage or anything like that, but I want to be able to take it in. Kind of like an instance of a service. Instance of a service is a great way to think about it. So resource groups are one of the most fundamental primitives in Azure that you're going to deal with and it groups all of your resources that you create, and all the resources that you create actually have to be placed into a resource group. The analogy I use for resource groups is like creating stuff on your local machine, that you always put it in a folder. A resource group is basically a folder. Folder or even like a namespace almost, right? Yeah. Namespace would be another good analogy there. Yeah. So anytime you- I'm in my OO kind of a mood today, so I guess I'll just- Perfect. Yeah, I'll take it. Anytime you create a thing, you always ask you and the general guidance for resource groups is you want to organize things that are going to have the same lifecycle together in the same resource group. It's almost like if I have a unit of deployment, and these are things that should deploy together, that's a good idea for resource group. That's correct. Okay. Or delete even. Exactly. Where it becomes really convenient is if I'm doing some testing, I want to get started, I think we'll look at that here in a little bit, and I say, oh, I want to try this application up in Azure, and I'm going to- It's going to have an ASP to an application that has a SQL database associated with it and has some storage account associated with it or anything else. If I put that all in the same resource group and I go, hey, yeah, I got it working, but I don't need this anymore, I just delete the resource group and it gets rid of all of those resources for me, just like deleting the folder, right? If you have some temporary stuff on your disk as opposed to having to go through and potentially clean up and delete four files. So for DevTest, you can just create each of these namespaces but they're called resource groups and then at the end you can purge them. Exactly. Okay. And then it stops trading at your credit. Yeah, I'll be showing it a bit later. Like once you use Azure for a while, you can really rack up a lot of resources. I think that's going to be handy. Absolutely. And the last term that you may hear us use sometimes is provisioning. So in Azure, provisioning is simply the act of creating Azure resources. Okay. But if you use any of the management APIs or anything like that, it'll be dealt with as provisioning. So I may use that term sometimes. It's extra fancy. It's extra fancy, that's right. So the next thing we want to talk about a little bit is the idea of hosting versus services. And this is really a distinction that you and I came up with. It's captured in the Azure docs but they won't necessarily talk about it exactly this way. And they're all services, right? There's like you're making a distinction between hosting services and other ones. Exactly, really hosting and software as a service. Okay. So hosting and the definition that we're going to use today is where you provide your code. And then what Azure's going to do is Azure's going to execute the code that you wrote according to the application model of that code. An example of that would be an ASP.NET application, right? So you write it, you compile it, you build it somewhere. It gets deployed or published into an Azure environment and Azure is going to hook up and it understands how to call into and route requests to the ASP.NET application. At the end of the day, all of the interesting stuff that's happening is a custom code that I provide it, right? If I have a web API that says some and I accidentally subtract instead of some, it's going to return that wrong number because Azure's not doing the math for me. It's whatever I wrote. But maybe another way to think about it. So if I just, if I have a web app, a web API, today I'm used to, you know, I work with my, let's say at my IT team, I get some servers with IES and I just push into that. So now in the cloud this sounds like, yep, exactly. A similar thing. It's kind of like IES is a service, right? It's exactly correct. Yeah. So then service or really software as a service from definition that we're going to use here is where you provide the data or information and Azure's implementation actually takes the action on what it's provided. So if we go back to my analogy of adding two numbers, if Azure had a software as a service, a service that was addition, I couldn't make a mistake in saying A minus B instead of A plus B because I would just say, hey Azure, here's two numbers A and B and it would do, use its own implementation and return the result to me. And a great example of this for our purposes is blob storage, right? So I basically give it streams of data. It stores it for me. I can ask it to do things. I can say list stuff for me, you know, delete, write, update. But at the end of the day, Azure has an implementation that's actually dealing with how that gets copied into a persistent storage mechanism for me and I just have an API service. So hosting, I put my app or my APIs in a hosting service. The service you have, I'm using Microsoft's APIs. That's correct. Directly and they're already in the cloud and that's high scale, I'm guessing, availability, all the good stuff we want for them. All the good stuff that we want. That is absolutely correct. That's a good way to think about it. And so with that, we've been talking for a little while. Why don't we roll over and do our, look at our first two services from a demo perspective. So to introduce what we're gonna do, I'll start here in Visual Studio. And I have a ASP.NET application that I've written that's gonna behave like a photo gallery. So it has, what it does right now is it has a SQL, local SQL DB that I can log in as a user. And so let's go ahead and do that. Hopefully I, you know, remember my, anybody, there's my email address. Anybody needs to talk to me? There you go. So we'll log in and perfect. Nope, I don't want to remember that password. And so now I'm a logged in user. So that used my SQL, local DB account that was running on my local machine. I can upload images. So if I want to pick another image, I can say, okay, so I'll upload that. But you're not putting those images in the database, right? I'm not putting the images in the database. I'm just storing them on, on disk right now. So they're going to a, so now I return to my gallery and I see the other image that I loaded. If you look over here in Visual Studio, there's a user images folder. And so that image appeared in that folder. Cool. So at this point, what I'd like to do is before I do anything else, I need to get this application off of my local machine or off of on-premise. And I need to get that running up in Azure. Okay. And so I have come two requirements right now. You don't want to put in a request for a machine and wait? I really don't. Oh, okay. I've heard that. I'm your guy though. Okay, I've heard the cloud's the future, Paul. All right. And I don't want to put in a request. I don't want to run it on-premise. In fact, my boss has told me that he'd like to stop running the server in his office. It's making it really hot in the summer. Yes. So I need two requirements here. I need to host the ASP.NET part of the application. So going back to where we're kind of talking about hosting. And then I'm going to need a database because SQL LocalDB obviously isn't going to work up in Azure. Okay, we can do that. So if we go ahead and cut over to Paul's machine, can you talk me through how I would do that in Azure? Yeah, sure. Okay, so we're going to switch to my machine. Great, we're already over. All right, so the first service that we're going to use, this is service number one of the five, is we're going to use app service web apps. Now, and we're looking at it right here. So I said create a resource in the Azure portal and we'll create a web app. I really think of a web app kind of like it's IES as a service, as a managed service. Microsoft runs the operating system. It runs IES. It handles the hardware and the infrastructure. You bring your app off you go. So this is really good for web apps. It's good for web APIs. It's good for web jobs. And this is really where I start for most workloads. Now, there's plenty of good reasons when you're going to do something more intensive that goes beyond what a web app does. And we have other services for that, but this is a great place to start for that. So let's just create a web app. My initials, pie, not to be confused with Python. Be really explicit. Andrew talked before about a subscription. I have any number of subscriptions here. That's quite a lot. And we talked about this idea of a resource group. So this will be handy and I'll show you in a second. I'm going to create it with a few strings I can find like Andrew. I'm even going to just say dev test for myself. Just makes it a little easier to find it later. We'll start with Windows, but we're using .NET Core, right? So we could do Windows or Linux. We have the choice there. And there's this thing called a plan. I don't know if we, did we talk about that in the concepts? We haven't talked about plan yet. Okay, cool. So that's a nice one for me. So I think about a plan as the, like kind of like the hardware that you're going to be running. So it's literally, it's literally like a virtual machine that has a size. It has a certain amount of RAM and CPU. And this gives you the flexibility to choose a plan. Right, so I could go ahead and create one. One thing I want to be careful about is I like to create it in a data center that makes total sense. So we're in the Northwest. I'm going to pick West US two. And then you have lots of options for pricing tiers. I'm going to start with the initial one, but you could see if my demands were higher, I just pick a higher plan with better hardware. Okay, and that's really all we have to do. I like to turn on application insights that will help us down the road. And maybe a sneak peek of what one of the services could be. We'll just go ahead and create it. Now, if you like working with a UI or a GUI, the portal's a great place. It's kind of a ubiquitous place to create everything in the cloud. I think I just want to talk about, one of the tools in our tool belt is the Azure CLI, or command line interface. And really everything you can see in the management interface of the portal, you can also do at the command line. So what that would enable me to do is it sounds like that would enable me to check in scripts that would let me have repeatable deployments. For example, if I wanted automate it to stand up my environment for testing purposes or whatever on a just a scriptable, repeatable way, I could assume I could write scripts that use the Azure CLI. But I could check in with my source code. Right, like if you're, whatever scripting language you're comfortable with, whether it's PowerShell or Batch or even Bash, you can go ahead and script this. And it's totally useful just like you said for automation, for repeatable actions. It'll just take the guesswork and the variability out of things. Another thing I find is, once you know what you want to do, the CLI is very definitive and it's very fast. And you can reduce a lot of clicks in a user experience using the CLI with a one-liner. So here you can see, we did a few clicks, right? But to replicate the same thing, AZ, web app, create some of the parameters for the resource group, the name and the plan. You know, and off we go. It's gonna happen. Make it so. Great. Couple of questions for you real quick, Paul. Sure. So I'll just mention, you showed the portal and I think it'd be awesome if you could tour us through kind of the various capabilities you mentioned that app service is a great place to start. App service web apps is the place to start for hosting web applications. Yeah, that's good. So what makes it such a great place to start? Obviously, it was quick to create. One of the things we'll show later is you showed the portal, you can create and everything from Visual Studio with app service, so web apps, which is a great thing. We wouldn't have to go through the portal just to get a quick web test environment and I'll show that in a little bit. But let's say I actually want to use it for production workloads. Does it scale? What other capabilities does it give me? Or is it really just a place for me to dev test and then I have to find somewhere else to host production? Well, let me answer that right away. Yes, it's absolutely a place to scale. We even run a lot of our mission critical apps on app service. So we need a front end or an API, it's great for that. So let's take a look at some of the things you can do. First thing is, if I can type, I mentioned that having these resource groups make it really easy to just search. So I love this kind of text box in the middle of the portal. You just start typing in and you can find things. So right at, because we were careful about the resource group, we're gonna find this PY Andrew that we made. What I'm looking at now, this is the app service plan and it lives inside of this resource group, right? So I can see now the resource group has my app service. It has my plan or basically the host server hardware that I'm running on and even has app insights. So it's keeping it all organized. And again, one of the things about getting to prod is you probably have a few different environments, whether it's like Dev's test, integration testing, maybe a staging prod. So you can organize the different resources and you can actually even make sure that there's different access control or RBAC for each one. You'll really wanna think about that. Like prod, probably don't want the testers, testing against prod. RBAC, resource-based access control, I assume. Mm-hmm, yes, or roles-based, either one. Okay, so let's go back to my app service and just take a, we'll take kind of a lap around it. So we saw all the same information before, kind of a subscription. There's a really easy way to diagnose and solve problems or to get insights over the app. But some of the things I wanna get to are kind of the cool things that make this more Pazzy, right, so. Quick question right before you click back, sorry. If you go back to your overview page, I noticed that there was a URL. So I just wanna make sure I understand, because I think what we just happened is in less than five minutes, and really it was probably less than one minute, you instead of, as you kind of talked about submitting a ticket and getting something created on a local network on my own sort of company, right, or going and bothering my boss or whoever controls the hardware, you stood up a full hosting environment that has a public endpoint in about a minute to two minutes. Right, that's a really good catch. So it's a fully networked, secure hosting environment with the URL on the internet. Pretty cool, like you got that right away and then you can even redeploy over and over the content to that hosting environment and that networking will be durable. Like that host name, the networking to it will just kind of stick around. So think of your app service as this configurable host in the cloud that can kind of stick around and you can keep dynamically pushing new content to it. Very awesome. Yeah. Okay, sorry, I didn't mean to interrupt. Yeah, okay, perfect. So let's talk about where this goes beyond, let's just say ordinary IS on a VM, right? So the first thing is there's a first class idea of application settings in an app service. I really like this because it kind of lets you configure things on the fly. You can do it dynamically, change it anytime. So let's say the framework version that I'm expecting, the Bitness 32 or 64 version of HTTP. And then all the way down to things like, I think of them as environment variables. The term here is app settings, but I can dynamically set configuration values, key value pairs and they will live in the environment. And so you talk about getting to prod, a pattern I would do is I would say, here's my database connection string. So let's go ahead and add it. And we won't pick a real one right now, but kind of like this, right? And I am going to write my app in a durable way against DB connection, but I know in each environment I can actually override the value, kind of like change that environment variable so that the right database connection exists and is loaded in that environment. It's also very secure, right? Because only people who have access to this environment can even get at these settings. Right, so this is a much more secure way than trying to have something in my build server that tries to inject it into my web.config, right? It is, and sadly, when we think about security, we even have to think about all the internal people who have access to things. So it's just kind of out of sight, out of mind. It keeps things really isolated to where they belong and that's probably a good thing. Some other things, you mentioned prod, so I just want to mention, I'm not going to hook it up now, but we can set up SSL and TLS. So use basically HTTPS for your website. So that's really cool. Another thing I want to talk about is scale, right? Like one of the promises of the cloud is really just kind of near infinite scale. So to show that, again, if I wanted to provision 10 machines, because I know that we're coming into a holiday, it's going to be a really important time for our site, I'd have to request it. But just with Azure, it's as easy as sliding the slider bar. Should we make Azure work a little bit? I'm not paying for this. Let's go ahead. Looks like you also have autoscale, right? So you, instead of me being responsible for coming in and changing the slider, if things get popular in Europe while I'm asleep, autoscale, Azure will detect that until they just spin up automatically on my behalf. Right, it sounds like you know a lot about that. So what would you want to scale based on, do you think? I generally request. The request volume that's coming in, if I was seeing a major dip in response rate. Very cool. Yeah, so it's kind of like you can be metrics based, think about a threshold. So one would be, you know, the requests are going hot, like more requests than you think the machine can handle through testing. Another one might be like CPU or memory. You can really just use that as a trigger to scale out. And it's not just about scaling out, it's also about scaling back, which is really cool and that avoids the waste. So right now, by the way, servers are just being provisioned and that'll be pretty cool. Can you remind me to delete those after? I will do that. Okay, excellent. And I think for getting to cloud, for getting to prod, the main things I wanted to show you were, you know, you can do SSL, you can scale out, you can autoscale, and you can set environment variables. Makes sense. So next question, if we think about our app, so we figured out we're going to host it, that's going to be app service. Yep. The next thing I want to know is, so remember I have a SQL database that my application has to work. Yeah, totally. Using SQL local DB. Do I have to go create a VM and go install SQL server on it? You don't have to. I mean, and by the way, that's a perfectly fine option. Like if that's the first step you want to take, we have VMs that are preconfigured with SQL and you can pay like a little bit more than a normal VM to use SQL. But we want to go all in on the cloud here, right? So like, why do that? So we have this thing called Azure SQL DB and that would be the next thing we'd check out. So let's go to, that's right here. So we have the SQL database. And then the really cool thing here is I can create both a database and even a database server. If I wanted to prime it for more DevTest, we could throw in AdventureWorks or our own backup. And then a lot like app service plan, there are plans for databases. And here you kind of pay by the DTU. That's kind of like a mathematical scale unit. But there's some good guidance here to kind of understand how many DTUs you might need. So I would just check that out. When you say DTU, what does that mean? Well, let's click the what is DTU. I knew you'd ask. Yeah, so yeah, I want to say it's a transaction unit. Yeah, am I right? Yes, data transaction unit. But for me, it's more complicated to explain because it's an aggregate, right? It's an index unit over a number of other units, right? Like we're seeing things like IO, IOPS, CPU, uptime, retention and things like that. So basically you pay a bit more, you get to do more transactions. But the cool thing about that as well though is instead of paying a fixed fee to your point about wasting money with having resources up that we don't need and we don't need them, same thing from a database perspective, right? By using the software as a service Azure SQL DB, only actually paying for what I'm using. So if I'm trying to get started, you know, it's my own dev test thing or it's even a line of business application that's relatively small, I'm not gonna pay much because I'm not using, doing many transactions or storing a lot of data in that. So I don't have to pay $15 a month to reserve a dedicated database. You can even see this right here, a scalable database in the cloud that gets patched for you by Microsoft, $15 USD. Right, just to get started with that. So pretty cool. So that's what, so just to kind of wrap this all up. So we created, you know, you described a data-centric web app, right? So we've got the web app that can work in DevTest or Prod, we've got databases that can work in DevTest or Prod and basically we've just modernized our infrastructure and even the way we pay for things just for those two steps. Very cool. So one question and then we can go ahead and move on. So a question was you created resources in West US and what if you want to change the geographical area that something's located? Is that possible? Yes, it is possible. So we have commands and operations where you can move from one resource group to another. And you also talked about the plans here in SQL and app service, right? I pick a specific plan without blowing away my data and recreating it, do I have the ability to upgrade that plan? Yes, absolutely. So these sliders are basically re-entrant and maybe I'll give you a visual example. So let's go back to PY app for Andrew. Okay, we're gonna save our database right now. Yeah, we didn't go ahead and do that right now. So here, just to give you a quick example. So scale out the way I think about that. It's going from let's say one machine or one instance to many. Scale up is about improving the hardware and the skew and the plan that you're actually using. So I would go to scale up in this case and you can see that I can actually dynamically change the hardware that I'm using. And Azure is pretty smart about this. It'll like spin up the new hardware, it'll start draining the traffic from the current instance and kind of redirecting it to the new one. So I can start cheap if I need. And then without losing any data, without recreating or redeploying anything, as my site gets popular or perhaps I move it from a staging to production or preview to RTW status and I see traffic uptick. It's just a couple of clicks and a couple of clicks, scale it out, scale it out. Or you could do a command line parameter. You know, and just my recommendation, think about how you can build your apps to scale out first. In the end, you're going to get a lot more economy that way. But you can also scale up and just increase your hardware. But my first instinct would always be to scale out. Perfect. Makes sense. That would be a great transition for our next status. So we'll go ahead and come back to my machine. And so just a quick review. So the first thing we talked about is Azure App Service. And we think that is the place that you should look at to start when you're hosting applications in Azure. Right? As my requirements get more advanced, I may look at some of the other hosting options available in Azure. But this would be the place that we'd recommend starting until it doesn't meet your needs. So for example, if I need a hyperscale distributed app with microservices, I might look at service fabric. Yeah, exactly. That, right? And so I think the other thing that's really worth mentioning is we didn't talk about it specifically. It's a fully managed service, which means that Microsoft or Azure takes care of automatically applying all the framework and operating system updates. So I'm not going to be in a place where I'm vulnerable to the next ransomware attack that got patched six months ago. Too soon. But I'm sorry. Because they're going to be updating that on a regular basis. Yeah, absolutely. I go back to when it comes to the hardware, the operating system, and even your middleware like IES, Microsoft is on the hook for that. So really, as a developer, we're on the hook for applications when we use a service like this. Yeah, and so I think the one thing we didn't talk about, which we'll show here in a few minutes, is the concept of deployment slots. It's another really cool capability. We'll get to that in a little bit. But and then we'll also show the first class integration with Visual Studio. App service is just brain dead symbol to get started with from Visual Studio. It is. In fact, even a lot of the stuff I did, you're going to show me up with how the tooling makes it easy. So everything you just showed at the portal, I can actually do from Visual Studio without ever having to log into my web browser. But it's good. I figured the VS guy would do that. Any good infomercial, you can't open the milk container until I have the screw on straw, right? That's right. You have to struggle a little bit. You need to drop your laptop first and then. And then we talked about SQL database. So a lot of the same concepts that come in with Azure App Service, right? Most of my ASP and applications that I work on personally all have a SQL database that back them. And so Azure SQL database is a great software as a service place that just makes it really quick. It'll create the database again. Speaking of dwelling on the page, have you ever created a database cluster? Because you haven't lived until you've created a database farm or cluster. You know, I have to say I haven't. OK. We have to save that. Leaving that to Microsoft, I'm happy about that. For a more advanced scenario. So with that, let's go ahead because one of the things we talked about is a designer app for scale and modernization. So let's go ahead back to our application and talk about adding some more capabilities. My mouse aside, mouse, there we go. And so we go ahead to Visual Studio. So one of the things that we mentioned a little bit ago is that when this was running in an on-premises server, I was storing all of the images that users uploaded into local file storage. And that works when we publish it to Azure. So if I have my site, I can publish it, and it'll work. But the problem with that is that data is not the storage for local file storage isn't persistent, isn't guaranteed to be there. And so any images that are uploaded that I store on that local app service VM, if upgrades occur or whatever and I get a new VM, none of the stuff that I store that got dynamically created at runtime is going to guarantee to live. And so to really modernize this application and take advantage of the cloud, what I need to do is I'm going to move over to storing that stuff in Azure Storage. Because that's going to be the persistent storage model for storing large objects, so blob storage in Azure. Right, it's durable, right? So it'll always be around, I don't have to worry about getting wiped out when I redeploy or like delete a server even. And one of the things that I do a lot of times, even as you change files and things like that, is one of the options when you publish is to delete any files that are inconsistent on the server if you want to clean stuff up. And if you have that option set, like I do in a lot of my projects. I do too, and I debate this with people, but. Yeah, exactly. Well, that's right, you remove a CSS file, I don't need that up there anymore. And so the fastest way is that, but it'll blow away any of that data. If I put it in storage, which would be the correct model to do that, then I'm not going to run into any issues. So I'm going to get started on my local machine here with Azure Storage. And I don't even have to use Azure, no subscription required. The Azure Storage emulator installs by default with both the web and Azure workloads. Yeah, that might be the Explorer, which is it. That is a Explorer, you're right. But thank you by the way for pumping that. Yeah. I know the people who work on that. Storage emulator is what I meant to do. So I'm just going to go ahead and manually start that, and I'll see it'll fire up here and perfect. It started and it's running, which means that my application can connect to it locally. And so what I want to do is I want to update my application, and I already have the code written here under services. So I have an Azure Storage service. Oh, yep, it's running. Thank you for telling me that. And so what I'm going to do is my application starts up here, is it's going to actually store the information in Blob Storage. So there's lots of good tutorials online. I don't necessarily need to show how to write the code. This is creating all the connection information for storage, getting the, grabbing the connection string, which in my case, because I'm working with the storage emulator, it's just an app settings at JSON, right. No idea what that was. Yeah, there's no like big secret there, right? That for some reason, I don't know why that wants to open, but are you in run mode? No, I'm not in run mode, but we'll just open it as a, sure. So yeah, so you can see my connection string is as simple as use development storage. So that's like the built-in connection string for local. That's the built-in connection string for local. Okay, cool. And then we just have to take note and remember to go back to those app settings correct. Don't let me forget that. I won't, I promise. And the last thing I have to do here is I just have to, so in my startup code, because I use an interface, so both of my file provider and my storage provider implemented an iStorage service interface. I'm just gonna swap that to not use the storage connection rather than the local file connection. Okay. And so when we go ahead and start up this app. It's almost like you made a provider, like one for files, one for storage. That's correct. That's not the same, but you're re-implementing it. That's cool. That's correct. So now we've, before we did a little bit more of kind of like a lift and shift. You know, just changing our infrastructure. Now you're really modernizing the app at this point. I'm modernizing the app at this point, that's correct. Okay. So what I wanna do, log in. I should have had it remember me, but I won't make that mistake again. Now it can remember me. Minute to learn lifetime to master these things. That's right. All right, so what I'm gonna do is, now I'm gonna go ahead and say I'm gonna upload an image. And let's just pick a different image. This one will work. That's pretty sweet. Yeah. Did you take those? I did not. They come from our official Microsoft image samples that were allowed to use for things like this. Oh, that's good. So perfect, protect the innocent. So it uploaded and you mentioned storage explorer. So it's worth showing that at this point. Cause what I wanna do is I wanna make sure that this image actually uploaded correctly into storage. And so storage. It's almost like observability tools for storage. Correct. So from the first step in my development process is I think I wrote the code that put something in Blob Storage. Yep. Let's make sure that indeed it actually put it into Blob Storage. And so I will mention that Visual Studio has some basic tools built in for working with storage. But it's a storage explorer is a free download and it's just a lot more powerful, a lot more UI. Yep. And so. Works on Mac and Linux too even. Yep. It's not showing me my local one. Do you know why that is? So what I'm doing here, click this little thing. So we mentioned various subscriptions. And so I'm going to, it'll load my subscriptions and I can pick the subscriptions that I wanna see here while I'm in storage explorer. Apparently you have a lot of them. I do have a lot of them. It's the hazards of working on Azure here. Oh, even at mine. I do have yours. Yep. Okay. I have my Visual Studio Enterprise subscription. That's because of that RBAC. Right, so the local node should have it right there. That's your local and then it should be an operative word. All right, that's all right. So we'll go ahead to mention that Visual Studio has great tools built in. So we'll go to Cloud Explorer. So I hit Control Q, great tip in Visual Studio. Cloud Explorer. And so this is a tool built into Visual Studio. Again comes by default with Visual Studio. It's kind of a subset of stuff. Subset of stuff, but sure enough I have local here. And so I can browse in my various subscriptions. You know what? Okay. We have an issue with, I have a gut feeling. Yeah, there's an issue. Is there any weird subscription filter you have on? Not that it should affect local, but yeah. Anyways, it worked because it got uploaded. We can show it on my machine. Hazards of live demo, perfect. Yeah, your machine would be great. It did force me to sell an upgrade. So maybe that broke something with local. But it's going in, but one of the things you mentioned a little bit ago was you talked about designing the application for scale. And now that we're uploading images and now that these are gonna have a public endpoint on the cloud, I mentioned that what these were came from a pre-approved list of images in this particular case. But what I wanna make sure is I wanna make sure that nobody steals our images without us being able to trace back and say that we actually owned them. So I wanna add some logic to this to stamp a watermark into the image when it's uploaded before it gets displayed back to the user. So anybody coming and browsing the image gallery, if they go download it, it's gonna have a little watermark stamped into it. Cool. And when I think about modernizing my app and designing it for the cloud or for scalability and for the cloud, I don't actually want that to happen in that process. Because we talk about scaling up my application and somebody uploads images if this gets amazingly popular, like I expect it to do and we'll be retiring next year. Paul, with all the money we make off of our great image gallery site. Then, right, stamp, like image processing and stamping watermarks is significantly more CPU intensive operation than serving up pages. And so it'd be great to move that into a worker type pattern where that upload occurs, the watermarking or image processing occurs in a scalable way that happens independently outside my process. It also lowers the risk to the application because the only logic out of the application is reading and writing from storage. And if anything goes wrong with that process, the image won't show up, it's not gonna take my site down. It kind of, it's almost like a queue worker pattern. We've done this for decades, right? Like you queue up work and something else that could be a little beefier could actually go take care of that work, right? Exactly, okay. And so the way that I wanna do that, the perfect project type for this is Azure Function Project. And so Azure Functions are event-based serverless applications, which means that I don't have to take care of any of the provisioning or scaling or anything like that. I just write some code and Azure will take care of deciding how many instances I need. It will run it only when events occur. I'm only gonna pay for the CPU and memory resources I use per function execution. So it's just a great model for this. As I mentioned, it moves all of the kind of risky logic into a separate service. So the way I added as I'm in the new project dialogue, I clicked on the solutions at add and Azure Functions is the project type. We'll go ahead and actually switch over here in a minute. I have one in a different branch and then I can choose the various type of triggers that I want. In this case, blob trigger is exactly what I want because we're gonna push an image in and we wanna process it. I think we're just explaining triggers for a sec. Yeah, so what a trigger does is a trigger is whenever an event occurs, I mentioned they're event-driven, it's gonna execute code to process that event. And so in this case, a blob trigger is gonna say, whenever anything shows up in this blob container, call some code that can do some processing on it. And of course I define all of the code that does that processing on it. Okay, so kind of like your inbox is actually the blob container. You put some images in it and that's like your inbox to do work and it gets processed. That is correct. There's lots of other ones, Cosmos DB. I could do things when data got written into new tables or not into new tables, but got written into tables. I could, HTTP trigger gives me an HTTP endpoint if I need to call it FES. Is that almost like a webhook? It's almost like a webhook, exactly. And there's a lot of webhooks integration, there's timer triggers, there's service bus triggers, there's queue triggers for message passing. It seems like a lot of those things you call services, they have events and you can wire them up with a function. That's correct. Okay. So in this case, I mentioned I already have kind of a project created. So let's go ahead and cancel out of this and I'll just switch over to our next branch that has that. Oh, it's gonna be unhappy with me because I have to push my changes, commit. It won't let me switch branches while I have pending changes. So let's go ahead over. Probably a good thing. Yeah, probably is a good thing. All right, so let's go over here to our next branch. And so I can see that I have an Azure Functions project now available here to me. And so what I wanna do is I wanna go ahead and add that blob trigger. So we have the basic project infrastructure there, but I'm gonna right click, I'm gonna say add new Azure Function. Let's pick the name of this. This is gonna be, we're gonna process the image. So image uploaded, perfect. And so this is the list of triggers available that we just talked about it. This is gonna be a blob trigger in this particular case. And this is gonna be the name of the connection string. So Azure Functions always have this connection string called Azure WebJobStorage that points to a storage account that backs the function. I'm just gonna share that for the purposes here with my function app. So Azure WebJobStorage is the name of that connection string. It's already in my local about settings. And then the path to my thing is images. So this is the container that I wrote it into in my code. This is the blob, name of the blob container basically. Yep. So I'm gonna click okay. It's gonna add that function for me. And so now when we go into functions and we talk about one of the really cool things if you think back to this Azure Storage Service, whenever I was dealing with my storage account, I had all of this code to read and write and create the connection to blob storage and read information to and from my things. And then Azure Function, they do what's called a binding. And so I had this blob trigger attribute which was generated on my behalf. And it simply gives it the name to path to the connection string in that particular case. And then it's gonna automatically do all of that for me. It's gonna initialize the connection. It's gonna listen for changes. When something new gets written into it, it's gonna read that into a stream and it's gonna pass that to me as a user in a stream. So this my blob is whatever image has gotten put into that queue since I did something with it. And so now we're just gonna do a little bit of wire up to, so let me go ahead and just copy and paste this over a new version of the function. I'll explain what it does here in a second. So that's the input blob that we just talked about. And what I can do is I can add an arbitrary other number of binding as well. So in this case, I mentioned that I was gonna watermark the image and so I need to write back out the modified image. And so I'm gonna have an out parameter in this particular case that's gonna be an out blob stream. And so I just put the new bits or new bytes for the modified watermarked image into this output blob. And it's gonna automatically just get written into my whatever queue that I want for that. And in that particular case, the watermark container, it's gonna be instead of slash images, it's gonna be images hyphen watermarked. And so my application website's now gonna read them from the watermark. So on one hand, I mean, it sounds like it's doing a lot of process and machinery for you, which it is, but at the end of the day, it lets you think about more like functional programming, like there's an input, there's an output in the code that you write is what decides what gets output. That's correct. And the runtime handles all of the, I'd say, heavy lifting and connection goo on my behalf to the Azure resource. And it keeps a quality of service between you and the storage. Exactly. So now that we have this function written, let's go ahead and I wanna start both my website and my function app. So let's go down here to my properties and my solution. And we'll go ahead and set it to have multiple startup projects. We'll can launch the regular application without debugging. And we'll go ahead and launch our function app with debugging just because I wanna show the breakpoint get hit when we push something into that storage queue. So let's go ahead and hit a five. One of the really cool things about Azure Functions from a serverless platform compared to a lot of the other options available out there is the full integration with Visual Studio, full local development and debugging experience available to me as a user. And there should be something in that queue already. So I actually expect from our last upload it never got processed. So I'll expect this function to actually get hit right away before I even upload an image as a user. Because there's a pending image to process in there. Yeah, that gives you a lot of flexibility. Using an emulator, it saves cost and time basically. Exactly. It's a lot less to administer. So you can see that in this particular case my breakpoint got hit. The name of the image that I got uploaded, I'm assigning a grid to them to make sure they never get duplicated. But that's the image that I uploaded. And so you can see, so F5, right. Perfect, processed it. Let's go back here. Let's upload another image. It feels like the event driven program we've done forever, right? It's the event driven program we've done forever in the cloud. Boom, upload another image, gets hit. Perfect. But the other thing that I think we talked about a little bit before that was really, really important here was the fact that it's now running a sub-process. So I added functionality to my existing application that we wanted to move into Azure in an event driven way with very minimal risk by using a storage or queue or some other pattern as the communication mechanism in between. And now if I come back here to my gallery. Perfect, I can see all those images and I can see some watermarks that are getting stamped in here. So I have it set to stamp in the lower right hand corner and so you can see it showing up there. Sweet. So you're really, now it's really, it's more than a web app now. It's like really a cloud compute intensive app, right? Exactly. That's pretty cool. Even though it's a simple example. Exactly. Another thing just to re-emphasize there is as you mentioned, all this was on my local machine working with emulators. Yep, right. Yeah, that's cool. But you could also use the cloud resources if that's the way you use it. I could, and I'll show because we talked, I promised that I would show, put you to shame from the portal from Visual Studio. So now that we have our application working. Andrew, Andrew. I want to go ahead and let's just say I want to publish all of this up into Azure. I'd have to do each project individually. We'll pick the web app first. So I'm going to pick app service, right? I'm going to create a new app service. And then so it's going to load my subscriptions. We talked about that. If I had just one, that would have been pretty much instant. I have a lot that at Paul Yuck Corp. I can put this on your bill, right? Yep. So this is the app name that you were showing earlier. This is going to be the public URL. Yeah. I can choose my plan. So we talked about right, all that information that's available to me, my sizes. That's handy. It even summarizes what the hardware is. That's cool. Exactly. And I can even start with a free plan if I want. Yep. Which again is 100% free. I picked the region. You showed the ability to add SQL. I can create a SQL database that'll automatically be associated with my application and it'll write the connection string in my behalf into those settings that you talked about. So not only is it creating it, it's setting up the patterns in your app for DevOps. Exactly. I can create a storage account because our application now uses storage. I just want to hit a question that was on there too from Vlad. He's saying, you know, what's behind SQL DB service? Is it an instance of a SQL server? I mean, that is a good way to think about it. So there's two resources. There's the database resource and it's backed by a server resource. Now the service is much more special than an ordinary server on a VM because it's replicated and it's meant to run at scale all over the world. In fact, it's even backed by service fabric and it's stateful cache in a ring. So it's an extra fancy SQL server. But yes, at the end of the day, you would literally see a SQL server in the portal that you manage. Yeah, and the other thing that's worth mentioning because the SQL team likes to talk about this as well is that they actually, it's built from the same source code that the on-premises SQL server that you would run or install is. I mean, there are a few differences and we have good docs that talk about it. And even a lot of the differences are important to run at a cloud scale. But also keep in mind, there's something called SQL managed instance. So if you need absolute perfect fidelity with a SQL server on-prem that you want it run by Microsoft, go check that out. Yeah. Yes, just to finish summarizing, what I did here is I have myself set up to publish a new app service that will turn application insights on on my behalf that will create a SQL Azure database and will create a storage account and write those connection strings in on my behalf. And so when I click publish the create button, it would take probably about two to three minutes creating all of that stuff. And then I'd have a site that's up and running with a SQL server connection string written, storage account connection string written and application insights on it. I've been told, you know, I listen to Hanselman and these folks really don't write the connection string to code. So how do you- This isn't writing the connection string code. This is writing into the app service settings that you showed. Beautiful. So just the way that you showed going- So it's really that environment variable pattern. Yeah, exactly. It's like the 12 factor app. It's just the tools doing it on my behalf. That's awesome. There's nothing stored in code. Okay. You are putting me out of business, sir. All right, with that, let's go just to quickly resummarize. We talked about Azure storage. So they have multiple different storage types. What we showed here specifically was blob storage, but there's also tables, queues and files depending on your needs. It's automatically replicated, backed up. I can do optional geo-replication if I am trying to scale across different geographies and it just has a lot of capabilities available for me as mentioned. Once I put stuff in there, it's never coming out of there unless I choose to explicitly delete it. Okay. Azure Functions, we took up their serverless, which is really great because I never have to create or manage any virtual machines or clusters. Even the auto scaling thing that you showed the slider for App Service, Azure Functions will auto scale on my behalf. Right. No, nothing to have to do. It's event-driven. One other thing to even mention, there's like, I think you mentioned there's consumption-based billing. You just pay for the consumption, but you could also use one of those App Service plans if you want a more kind of always running host dedicated to your functions. I could. So you have two options. Yep, that's correct. Or if I wanted to just share my App Service by resources like my website wasn't that popular. Or you just have some resources left over. Why not? You're already paying for it. Exactly. Yeah. Okay. Perfect. And once again, we have great integration with Visual Studio for all of this stuff as we demo it. So the last thing we've talked about it a couple of times, we've hinted at it, that I'm curious if you can teach me about a little bit, Paul, but how do I modernize my DevOps process as the first time for everything? So we can do it. So you want to Paul's machine. Okay. So let's go to my machine and... Well, Paul's getting set up. I'll answer one question that came in and said, can you opt out of patches or roll them back if there's an issue on App Service? And the answer to that is no. No, yeah. You can patch your own app, but not the OS. Like you really, with this kind of a service, you really want us patching it. Now that said, I remember I said before, if something breaks with the operating system, the hardware or even IES, Microsoft's on the hook. So we are monitoring the heck out of applications. And if we see that a patch is harming apps, Microsoft will take care of that. So like leave the rollback to Microsoft in that case. If you want more control, I would suggest looking at containers because containers you can explicitly choose the exact patch level. Perfect. Okay. Cool. So I'm back in my resource group and I'm kind of like a cooking show. I'm gonna date myself. I grew up with Julia Childs, but so here we have another app service and this one I took it just a little bit further along with some more setup. But basically what I did is I set up application insights. And this is by the way, service number five. We've been hinting at it. We're not very good at keeping secrets, but this is application insights. And it's a key part of application monitoring that is app centric. Okay. So we've already set it up. It's really easy just through this flow. If it's not set up the first time, we'll go ahead and create it. Also you showed Visual Studio, makes it quite easy. So you've got lots of ways. You click on app insights and we're gonna start showing you a lot of telemetry that I think is a developer we care about. Let's actually make sure this is the one I think I wanna look at 15, 28. Is that the right one? Yep. There we go. You probably need to increase your time range on the previous one. We've been on the stage for an hour, so we haven't been sending in any traffic. Totally, okay. So the first thing I wanna just call out is you can even use application insights to basically discover what's going on. Like what are the services? What is the service health? What are your dependencies? So here we can see that that web service, sorry that web application as a service that you deployed, that's represented as this node and then it's making calls off to storage. And I can just visualize that from a glance, which is super handy. So there's basically like this instrumentation engine that's keeping an eye on dependencies and figuring this stuff out. Another thing that's super important to watch, I think from the developer and the DevOps side is the failure rate. So I can see at a glance that I've got a bit of a failure rate going on and I can inspect those failures and just go ahead and investigate those right away. So in terms of just like you wanna understand the server failures or the exception failures in your app, this is an incredibly handy tool. And without writing any code, you're just using standard.net framework calls, right? And so those exceptions were captured. And if you used a logging framework like an iLogger of some kind or Logly, they would just show up here too. I think the other interesting thing I was pointing out is you're running the same copy that I just showed running on my machine, which we tested and saw it working. So it seems like most of the requests are succeeding but there's something that for some reason up on our production site, it's failing on occasion. Yes. So from here, is there any way I can drill in to actually figure out? Yeah, totally. So like one thing we'd be used to just looking at our server, the server logs would show 500, which is helpful. It kind of points us in the right direction. We know what's failing, but we don't know why, right? And so just to kind of figure out why, I can actually see there's exceptions underneath object not set to an up. Is this the one we wanted? Yes, we're getting an all reference exception sometimes but not all times. And it has to do with my Azure storage service. So I have a hypothesis that, remember how you promised you were gonna remind me on the connection string? Yeah, so actually this is an all reference exception. So you scroll over to the call stack, you have one frame higher, I just wrote this code so I remember it. And so- So it's even a good way to keep an eye on churn from your developers. Yeah, so actually I can see from the parameters, it looks like what's happening. It turns out the issue is I shouldn't be letting people upload images when they're not logged in. And so actually what you're catching, if we go look at that lit place in the code, you'll see that I'm trying to use the username which when you're not logged in is null. Got it. So the cool thing is kind of from a monitoring and observability standpoint, like I'm immediately alerted to there were failures. I understood the failure rate and we could zoom into any particular failure, get a stack and we're already in the right place. But this is cool because I forgot to test that scenario and obviously escaped into production because everything worked on my machine because I clicked that, remember me. And so every time I launched my site and tested it, I was just logging in like I would expect. So- That's awesome. You helped me find a failure in production that I didn't understand the repro steps for locally. Perfect. And just a couple more things I'll call out. Like if all telemetry, you can search over from the search view. Even we have a capability, I love this, my favorite new feature. You can watch a live metric stream and a live log stream. It's kind of like tailing with superpowers. Cool. So that was service number five. Very cool. And we'll back- One other question that came up before we do that. Can I set up alerts? Like so do I have to log into the portal? Absolutely. And that's the best practice. You can set up alerts programmatically or through the portal. There's another alerts blade on the portal that I didn't go through. And basically you pick the criteria and off you go. And by the way, application insights and absolutely any resource in Azure through what's called Azure monitoring has the capability to do alerts. So it's just built in. You don't have to buy like a pager duty or anything else for that. Very cool. So I can actually get emails when things start failing. I don't have to- Emails, pages, texts, you know, you can choose. Social, if you want to have it go into Slack. Great. Excellent. So go ahead and come back to my machine. So to wrap up, because we want to make sure that you get out on time. So the last service that we, service number five, application insights is part of the broader Azure monitor service. And so obviously we didn't have time to tour everything. I think each of these services that we just showed you could do- They may have a few hours, yeah. But hopefully we kind of wet your whistle and helped you understand more places to go explore to get started with Azure. But as we just saw that, having application insights on or monitoring can save me a lot of headache for remote debugging or when something fails, if I turned it on at the beginning, I just have the data. And if we show, I get call stacks and variable information. Hopefully the days of like remote desktop or FTPing or SSHing in or over just use this tool, it's so much easier. So a couple of honorable mentions. Obviously we didn't have time to talk about everything. A couple of other hosting options that are really good options depending on what you need. We have Azure Kubernetes Service. If you're looking to work with containers, it's a great place to work with containers, awesome orchestration system. Azure Service Epic Mesh is really good for distributed microservices. They have a very interesting programming model that just helps- Yeah, let's say you want to have a stateful collection instead of a cache, you could just write to the collection. And then a couple of the services that'll really help you. A few of the questions that unfortunately we didn't have time to get to, we talked about securing things. Yeah, and so Key Vault's a great service to go explore for storing certificates and secrets and things like that that are actually even more secure than storing MS environment variables. Perfect. So with that, let's kind of just go back to a couple of resources that'll help you keep getting going. We generally announce and talk about a lot of these things on the web developer blog. So that's aka.ms.webdevblog.net.azuredev, so aka.ms.netazuredev. We'll take you to our.netazured developer center where we have links to Quick Starts. Every single thing you and I talked about, there's a Quick Start that will help you get started in five minutes doing each of those services. Right, even the same sample app, all of it, right. And then lastly, we have a migrate to cloud page. If you're looking to take an existing application and migrate that from on-premises to Azure, the migrate to cloud aka.ms.migratetocloud will point you to page, so I'll give you resources to get started with that. We saw Cesar was here earlier. Watch his talk too, because that's a great resource for that. Yeah, that, thank you very much. Thank you.