TL;DR Recently at GenUI, we had the opportunity to put the suite of Azure and .NET Core services to the test to continuously deliver a web application for one of our customers. Beyond a reliable cloud hosting environment, Azure provides a suite of services for developers including Azure functions, Application Insights, Azure Service Bus, Managed Identities, and Key Vault.
Each of these services integrate fairly easily with .NET Core. That integration, coupled with well established design patterns and readily available sample code had the effect of providing a more stable, testable codebase.
Other advantages include easily configurable automated API documentation through Swagger and live debugging on the server through Visual Studio. Overall this switch enabled the team to spend less time reinventing established coding conventions and more time innovating.
The following is the transcript of the above video from tech talk was given during lunch at GenUI on March 7.2019
"...we need to trade the ability for us to move and iterate very very quickly with the ability for us to maintain what we have in the future."
[00:02:14] So why did we make the decision to move away from Node. Well we didn't have to conform to any particular pattern Express is pretty loose with what it will let you do. There was no real support for some of the weird legacy Microsoft Exchange token validation that we needed to do as a result of our project. Can you integrate an Express server with Microsoft services on Azure? Probably mostly sometimes but it can be really difficult to find code examples for that stuff and you have to kind of roll your own on some things and maybe it is supported maybe it isn't. And that can get to be difficult. Again if you still kind of want to move quickly. Also we were just kind of like logging to a file on the server which is a terrible idea because if you need to inspect your logs and you gotta log into the server you gotta retrieve that file if that file got too big maybe you crashed your server in there are all kinds of reasons not to do that. Now again can we configure an Azure service to do it. We can but it didn't immediately work and then we weren't sure why and that kind of stuff. Also I don't know if you all have worked with the Node debugger locally or otherwise. It's it's an experience not a great experience. So you know you can set up debugging in Node but it's another thing that just like it takes extra time and for me when I'm developing you know there are just a vast number of decisions that I personally don't want to make. I don't want to set up my own custom debugging environment. I don't want to make my own API design patterns I don't want to read in like do my own dependency injection model. I just want to use something that's there. So we moved to .NET. Why? Well Microsof stuff works pretty well with other Microsoft stuff. And so you know at the time here's what I thought that we were gonna get.
[00:04:15] I thought hey you know we're probably going to have much better libraries to integrate with all this Microsoft oAuth that we're trying to do to integrate with our other services. I was again particularly interested in Application Insights because I didn't want to log to a file on the server and I figured hey you know at least we should get some more sample code so that. We're not trying to hunt down, how do I configure, how do I configure, how do I configure and those are all good reasons. But what we actually got was like so much more than that. .NET you know love it or hate it it's a mature system. And so I don't have to reinvent the wheel on anything that's standard. If I want to build a standard API I follow .NET standards and I get one. If I want API documentation without having to think very much about it. Well people pretty much use Swagger for that. And so there are lots of examples you get Swagger set up in half an hour. We also since we've converted to .NET that we added five new Azure technologies which we'll talk about.
[00:05:23] We got Azure functions, we got Application Insights, we have a service bus queue, we got we're using managed service identities, we're using Key Vault and particularly with Key Vault which we did in the last week I looked at a code example I followed the code example I ran some commands in the command line and it works the first time and I was like this is awesome. This never happens. That makes my life so much easier because at the end of the day like I don't really want to spend a lot of my time and my thinking brainpower for like how do I manage secrets. There is a standard way you do it the standard way and you get on with your life.
"There is a standard way, you do it the standard way and you get on with your life."
[00:06:01] Also I am sort of pretty excited about line item number four here which is that you can actually live debug what is on the server from your local Visual Studio instance.
[00:06:15] So not only can I log into Application Insights and see "Oh hey I've got a null reference exception", I can see the line of code that it's on I can attach my instance to the server I can put a breakpoint and I can actually see what is happening on the server in real time so that I know how to fix it.
[00:06:34] So that's pretty great. So I said that this was a talk about Azure I haven't really talked much about Azure. So when I think about what makes Azure or Microsoft services different from AWS or different from Google Cloud Platform the way I frame it in my mind is. Well of course it's cloud services you're hosting your app whatever but Microsoft has this tendency to really focus on their clients as businesses. They're not really catering to hobby developers they're not really catering to folks who just want to put up a little website they're catering to businesses and often very large businesses. So when we talk about well what are some concepts that are existing in Azure.
[00:07:32] One is that if you as a developer kind of just want to go in there and poke around and do a couple things to see how it works that can be a little tough because you have to have a subscription set up and you have to pay for it. And sometimes they'll give you like oh this is four hundred dollars free because so you can poke around as a developer but you still have to give it your credit card. Do all this stuff as opposed to going on Heroku where you're like hey give me my hobby Dev instance for free and they will do that. There's a concept in Azure of a tenant and you can think of a tenant as essentially your business. So like GenUI has a tenant. There's tons of stuff on there but that's really a business level entity that is managing all of your applications, all of your cloud services, all of your e-mail addresses, for that matter, is going out live on a tenant.
[00:08:33] Another key concept in Azure is called a resource group. And my my personal understanding of what a resource group is and how best to leverage them is changing but essentially if you want to provision a little package of things and then build them all together you'll build them into a resource group. Why is that helpful? Well that means that if I want to spin up a new Dev instance and provision all the little cloud services that I need for my dev instance I could do that as a part of just one Resource Group. And then when I'm done with it because we don't have a second pair on the project or whatever then I can delete it all at once. And that is one way to measure or manage all your stuff in Azure which can get to be pretty unmanageable as you can invision like we're on Microsoft's tenant even just for our stuff we've got like oh I made this resource in that resource and there's an app service and there's a Key Vault and there's a this and there's a that if there's no like underlying system for how they're all put together it can get to be a lot to sort of wade through.
[00:09:34] And finally there's the azure CLI. So the Azure portal is what you would see if you went onto the website and you logged in and there is a nice GUI therefore you can do a lot of what's possible in Azure through a command line interface which can be really useful again if you're like writing scripts and trying to dynamically allocate and deallocate stuff.
[00:09:58] Cool. So I mentioned Application Insights. I've been mentioning Application Insights. I'm so excited about Application Insights. Why is that. Well. You had a lot of stuff for free. When I log in Azure and I go to our app and I look at our Application Insights instance this is on prod. I can see that something is failing once every five minutes in prod. I can see my average server response time. I can see my server requests and I can drill in actually and see well how many requests are made on which end points with what frequency do they fail? What are the exceptions when they do fail? How many users do? I have how long do those users spend on the site? What browsers are those users using when they come to our site? I get all of that simply as a result of having included Application Insights on my project. I've added some custom logs but those those are just logs that's just me trying to see what's going on in our service. I can see every call that's been made to every one of our other server dependencies and whether it succeeded or failed. So in terms of again our ability to debug what's happening on the server without having to go in and do a bunch of custom stuff that has suddenly become extremely easy just as a result of using Application Insights. So how hard was that to add to our project? Literally in Visual Studio you're just like right click and you say add Application Insights and then you keep clicking until it says that you have Application Insights. It's really that simple. What else do I have? This is basically everything I just said. Oh yeah I really want to do this. I haven't done it yet but if I want I can create custom stats and Application Insights which I do we want to know who's taking shuttles. We want to know how often folks are canceling the reservations in addition to just is anyone using the app that is a key piece of information. And so I can collect it. I can run a report I can make all those nice charts and graphs or whatever and then I can send an automated email once a week to everyone on the project. So that's pretty cool and I can configure alerts. So if like I mean to do this if our matching algorithm just like falls down and can't pick itself back up which happened recently that actually has an error severity level on it. And so I can set it up to say hey if we're getting an error of this severity please send me an email and that's like. Again nothing is free in Azure. We already discussed it's like a buck fifty for every month for that notification. Yeah that's right. Hey you know then at least we would know that our service had fallen down and we needed to do something about it. Cool.
"...our ability to debug what's happening on the server...has suddenly become extremely easy just as a result of using Application Insights."
[00:12:47] So speaking of our matcher when we had built this app in Node we had a like a long running Daemon process happening in the background which is creating rideshares it's going to see hey do we have any reservations. Do we need to match people up and it's running more or less continuously. We went ahead and we moved this to Azure functions not just because like serverless list is so cool right now although I am gonna say serverless is so cool right now. But because having this as an Azure function allows us to take advantage of some security benefits again which are all integrated as a part of Azure we'll talk about that in a minute. So our Azure function is running on a timer like a chron job like every five seconds and we can monitor it here so we can see hey we've had many many successful runs of this in the past 30 days and a few that failed. I can go ahead and run the same query and Application Insights get some more information as it relates to that. I can actually also click into here and watch it run if I have nothing better to do. So running an Azure function a serverless function on a timer is one way you can do serverless but you can also set serverless in front of a queue. So it's receiving messages from an external cue and reacting in that way. You can set up a function as an API end point so you're actually making web requests to your serverless function. And one of the primary benefits of it other than security is that you're only paying for the compute time that you actually use. So particularly in the case of an API it'll scale depending on how many requests it gets.
[00:14:39] So you don't have to worry about that. And then you only pay for what you actually use. When I went to MS Build last year I ran into some guys who worked for some like national dentistry practice. They were so excited about Azure functions it just made their billing so much simpler than it had been for running all these websites for dentists. And so presumably if you had a lot of clients if you needed to support lots of different businesses then you could actually sort of pass out and only really build them for what they're using in addition to you on for what you're using.
"...you only pay for what you actually use."
[00:15:15] Yeah. There was all that stuff. Cool. So. Queue what about that queue? We are doing a couple of things in our app that take a little longer than is convenient for just using for an API. So for instance when you make a new ride share as a user what you actually want to see the experience you want to have from the front end is that you click a button and it says OK it should say OK pretty quickly you should not have to wait 5 seconds for it to say OK but unfortunately we need no I don't know not five seconds but we need a little more time because what we are doing under the hood is we do save to our database but then we also go out to MS Graph which is where the user's calendar lives and we're putting some stuff on their calendar we're updating their calendar. I feel like we're doing something else too. Anyway it takes a little time and we didn't want to take that time in the API itself. And so instead what we do is we send the message to a queue and that queue looks like that. Yes. So we send a message to the queue and then the queue will spit back responses to a listener. Now we happen to set up our listener to live in our API as well but it could live in an Azure function it could live in another application. It can really be anywhere and then in the background we go ahead and do all that mucking around with the user's calendar and in this other stuff that takes some time. Do I have other stuff to say about that? Oh yeah. So when I go in Azure: This is what my queue looks like. It can tell me how many messages were scheduled. It can tell me actually in another tab how many messages it's been sending and receiving lately I can schedule messages with a queue. So if for instance I only want to call a shuttle for the user at the time that they need a shuttle then I just tell my queue "Hey send me this message back again tomorrow afternoon at 4 o'clock and it will do that". So one of the downsides is that it will do that within the context of this system where it's still only receiving and then sending messages one at a time. So there is a latency issue where if you needed something to happen like immediately queues maybe not the best system you don't have fine tune control over how quickly you receive those messages back. But it has for us been a pretty good system to kick stuff off in the background on demand.
[00:17:43] Cool. So what we have been working on in the past couple of weeks is enterprise level security which has been an interesting thing to tackle. And so it's necessary for us to take a couple of extra steps we as an application have permission to read and write on everybody's calendar. So that's some pretty powerful stuff. And we want to make sure that our secrets are secret. So we are using Key Vault for that. It's another Azure service and because everything is like a nice and integrated and we're in this Microsoft environment what you're looking at here is code that gets run in .NET core when the application runs and we're getting most of our configuration settings from our own settings files. That's what that is. But then we'll go ahead and just pop pop some environment variables into there and then connect Key Vaults and throw all of our secrets into the config too. So we're able to like what this is like six lines of code. Go ahead and pop into all of the various place where we might keep environment settings mash them together and then just use them throughout our application. Without me having to think about how that works or having to do something custom or special. This is just some sample code I pasted it it worked we all got on with our lives.
[00:19:30] Finally in order to connect to that Key Vault we can use a password but then of course the whole point of using the Key Vault for your passwords is that your passwords are not in your code or in another place that's easier to compromise. And so we're using something called the managed service identity. So Microsoft has this really helpful diagram to talk about what managed service identity is. In my mind the way that I have been thinking about it is our application when it runs in Azure is unique. It lives on a VM it has its own kind of fingerprint. And so rather than saying hey I have a key or I have a password to get into that Key Vault it says hey I am myself I'm using a fingerprint. Please let me in. You said that I could be in and that is how we are accessing our secrets in Key Vault. We're able to use this also to access our database or. That's what Paul and I are working on today so that we're really just trying to remove points of vulnerability so that we can get into our stuff securely.
[00:20:36] So I think that's it.
[00:20:38] Yeah. So those are the things we've been doing on Azure.
[00:20:44] Are there any questions.
Audience: [00:20:51] Can you just speak to the fingerprint part a little bit more detail. No not really.
Slater: [00:20:57] Paul can you speak to that.
Paul: [00:21:05] Since you're running a Azure your controls all the infrastructure while you're running as an app service it just says you are running your code is running in our environment we know that you are that app service your identity is actually that service. And so when you connect to Key Vault all you don't provide a password you say hey I'm running as I'm running in Azure under this in this context just give me access and that gives you access without needing anymore. Exactly. Exactly. By virtue of the fact you're running there.
Audience: [00:21:45] So you mentioned how you started using Node and Express and I think that was another. Other people are working on that project at the time. Would you recommend doing that again for future projects and then switching over to Microsoft Azure if it becomes or .NET. I'm sorry.
Slater: [00:22:07] I think that these are always difficult conversations to have in decisions to make especially when you're at the beginning of the projected you may or may not know where it's headed. So I mean really I'm going to say it depends on the project and the expertise of the people involved in it and you know kind of trying to walk that line certainly for me because we're having more and more folks here who have some facility with .NET. Certainly if I were looking at this kind of project in the face again, I would have started and done that.
Audience: [00:24:01] I just want to say how thrilled I am at this foray into Azure and how deeply you've explored it, and lot of great insights in here and it's clearly a really key area for us and something that we'll do more and more of in addition to every AWS and GCP and you know Note and Express on Heroku it takes all kinds you know and different strokes but we absolutely want to curate a conversation about what we care about as a community and what we think is good as a community and what we think is better than others and not all of us are going to agree all the time and that's what makes it a healthy discourse. So I think the really valuable perspective that you've presented and I'm more eager about Azure than in the past just after having watched it. So yeah I think there's a lot of a lot of opportunity there and it seems like it's pretty decent stuf AWS. To your question. Yeah. Last time I touched it was still pretty Byzantine. There are people who know how to navigate through it pretty well. But yeah it's there's a lot in there.
Audience: [00:25:13] So so you we didn't start on .NET. And I know that you sort of felt the pain of wanting to switch over to it. How did you think about sort of the tradeoffs of that. How did you communicate it to the client and then Paul to you like how did how did how did that play out in your mind from a cost perspective.
Slater: [00:25:46] I'm thrilled but boy there was there were some moments where I was concerned it took longer it considerably longer than I had anticipated. And it also happened at a time that we had a sudden influx of folks on the project because we suddenly sort of had some more budget and also as the holidays so people were in and out and that kind of thing. Ultimately as a result of that of having so many folks in the codebase it's much better than if I had gone and done it myself. So that was extremely valuable and our ability to. The code base is so much more tested now than it was because .NET core has this dependency injection model. So we just kind of got onto that by default and then as a result our code did get a lot better and it's just so much easier to integrate with all this other stuff. You know when I was thinking about it I was really thinking specifically about Microsoft authentication but now that we have the security review I'm like thinking about trying to do that Node. I'm glad that we don't have to.
"The code base is so much more tested now than it was before because .NET core has this dependency injection model."
Paul: [00:26:56] In terms of the decision point to switch over to C# I didn't actually kind of even push for that I didn't even realize that the team was having so many problems with interacting with the security model for Azure in Node. So they came to me and said so they came to me and said hey we're thinking of doing C# I was like well that's great. You know that sort of fits nicely with my skill set. So I was very happy with that. But I'd certainly push for that.
Slater: [00:27:36] Yeah. No. That was absolutely from our end. But now we have the added benefit of having Paul come and help us with stuff he knows about. So I'm loving it.