Q&A

Take a Whirlwind Tour of Building .NET Apps in Azure with Microsoft's Matthew Soucoup

• By David Ramel
• 06/20/2023

Are you mystified by all the Azure services Microsoft provides to help developers build .NET apps in the cloud?

Sure, building an app with .NET is simple enough, but what happens when it needs to scale to remain responsive or be made resilient for disaster scenarios -- all while being deployed around the world for super-fast access by anyone?

To help sort out all the Azure services that can help, Matthew Soucoup, a principal cloud developer advocate for .NET at Microsoft, will guide a "Whirlwind Tour of Building .NET Apps in Azure" at next month's big Visual Studio Live! developer conference being held at Microsoft Headquarters in Redmond, Wash., July 17-21.

Attendees of his July 20 presentation will learn to make the most of Azure to build scalable, robust and resilient .NET web (and mobile!) apps with Azure. Some of the services and functionality that can be used -- as shown in the screenshot of a previous Soucoup presentation above -- range from Azure App Service to Blob Storage to Azure Functions and more.

We caught up with Soucoup to learn more about what attendees can expect during his 75-minute presentation.

VisualStudioMagazine: What's the main selling point of using Azure App Service to build .NET apps?
I'd rather think about the high impact, low-cost wins that you can get by using App Service than listing off selling points. And one of the things I like the best is that you can bring your apps from on-prem -- as is -- to App Service and get them working in the cloud with very little changes needed on your part. And I'm talking about both .NET Framework web apps and later iterations of .NET. So there are very little code changes needed to start using App Service (and its built-in features like scaling). Then once you're "up in the cloud" you can start making code changes to modernize your app to make it more cloud-native to take advantage of everything Azure has to offer.

Soucoup: How do you choose the right Azure services for your .NET app based on your scalability, performance and resilience requirements?
Now that's the million-dollar question (almost literally 🙂). There's going to be two parts to this, the first obviously being to really understand what the requirements are and what they mean. Do you really need 99.99 percent up-time? Or would 99.9 percent suffice? Where are your users geographically? The second part is to understand what each Azure service provides. And that's where things like "The Beginner's Series to .NET on Azure" and "The Reliable Web App Pattern" help out. These are guides and videos that introduce Azure services, what they provide and how to use them together. The Reliable Web App Pattern even provides prescriptive guidance and best practices of what you should do.

How do you deploy your .NET app to Azure App Service using Visual Studio or Azure DevOps?
You forgot GitHub Actions 🙂. When initially prototyping I using the "right-click deploy" from Visual Studio (or VS Code). But as soon as the team comes up with anything that we're going to start iterating on, a CI/CD pipeline comes into play. CI/CD is a pillar of Operational Excellence. If for no other reason that it reduces "fat finger" errors when pushing code to new environments (of course there are many other benefits).

Personally, I like GitHub Actions. That's a personal choice. There's nothing wrong with Azure DevOps. And if my organization was already using it, that's a great solution.

How effective is monitoring and troubleshooting a .NET app on Azure App Service using diagnostic logs and debugging tools?
Very. You can monitor just about anything using Application Insights. From performance to exceptions -- including getting stack traces to custom events. You can create dashboards in the Azure Portal to get a quick glance of what is going on in your application. Setup alerts to let you know when a number of exceptions crosses a pre-determined threshold and then you can check the traces to see what's up. The Applications Insights .NET SDK integrates seamlessly with Visual Studio and Azure so you can see which functions are causing issues in the function's adornments. It's almost scary good.

What's a typical pain point in using Azure Functions to create serverless .NET apps that respond to events and pay per execution?
I think the first pain point people run into is getting into the mindset that Functions are designed to run once and run independently -- you're designing small functions to be executed -- not an application to be executed. Also the easiest example for functions is always the "HTTP trigger" -- or a Function that kicks off from an incoming web request. But they can be kicked off from so much more -- a blob being created, a row inserted into a queue or a row inserted into Cosmos DB. So wrapping your mind around the events that can be handled, making them into their own individual function, and designing for Functions to be chained together if your workflow is complex enough -- knowing an individual Function could get kicked off from outside of your workflow.

How do you connect your .NET app to various Azure data services such as Azure SQL Database, Cosmos DB and Blob Storage?
Where possible, do not use connection strings. Instead use managed identities. A managed identity gives your web application an entry into your Azure subscriptions Active Directory -- you can think of it as a user now. Then you can grant that managed identity access to resources such as Azure SQL -- and only the lowest amount of access it needs. You'll have to use the Azure Identity SDK in combination with the particular Azure service's SDK in order to enable managed identity -- but it's fairly straightforward to do. And once you do so, you only will need the public DNS address of the resource you want to connect to -- no username or password -- to connect to the resource. As a benefit -- the Azure Identity SDK also allows you -- individual developers -- to develop with managed identities seamlessly. Make sure your Azure user accounts have access to the resources in question, and the same code that you'd use in product you can use in development -- no connection strings will ever be needed. You'll hear this called passwordless. Not all Azure services support managed identities as I type this -- but they are all headed in that direction.

What's another questions we should have asked?
Other than my favorite type of cheese or the best hike in the Pacific Northwest -- a question I get asked a lot is "do I need to make my app cloud native to use Azure?" The answer is no. The answer also is -- "what does cloud native mean to you?" As I mentioned above, you can get a .NET Framework web application running on App Service with little to no code changes. That may be all you need to do to satisfy your application's requirements. Is it cloud native? Well, it's in the cloud. But if you want to design with a container and microservice architecture and make use of things like Azure Kubernetes Service -- sure, that's cloud native too. My point is -- you don't have to re-architect your application and the rewrite it to move it to Azure. You can do your cloud journey in steps -- and it's OK to stop when you feel the app is running as fast and secure and reliably as it needs to.

Note that those wanting to attend Soucoup's session who register for the VSLive! event by Friday, June 23, can save hundreds of dollars according to the event pricing page.