Coding Azure 1: Creating Cloud-Native Apps

If you find that the documentation and training around creating a cloud-native Azure app isn’t giving you the help you need, Coding Azure intends to fix that.

Here’s what this series of blog posts is about: All the steps to create a functioning cloud-native application, involving all the necessary resources—from configuring the resources through securing them and writing the necessary code to use them. This series will show you how to do that, using both Visual Studio and Visual Studio Code and with a single sample app as my case study.

Which raises the question: Why is this necessary?

The Business Reason

For me, the driver for going to cloud-native applications is to avoid spending my time on things that don’t make my clients (or organization) better. I would never, for example, suggest to my clients that building their own Accounts Payable system is a good idea (in fact, I would actively try to talk them out of it). Unless presented with some compelling way that a custom AP system will make your organization better, you should be doing AP like everyone else, which means you should buy, not build, your AP system (typically, the technical term for doing Accounts Payable differently from everyone else is “fraud”).

For me, that same philosophy extends to managing the standard parts of your application infrastructure: database engines, storage, server management and so on. In other words, all the stuff that Azure gives you.

There are, however, two problems with that philosophy: First, based on my experience as a developer, creating cloud-native applications with Microsoft Azure resources is … challenging. Second: While you don’t have to manage these resources, in order to use them you still have to know quite a lot of stuff and, mostly, stuff you didn’t know before.

The spirit of the SOLID principles is that we build complicated programs out of simple components. Extended to the application level, that means we build complicated systems out of simpler applications—microservices. While there are many definitions of microservice, the two that matter to me is that a) a microservice is small enough that the team that supports it can fully understand it and b) that knowledge can be passed on to any new addition to the team in a single sprint.

The Knowledge Reason

And, as this series is going to demonstrate, even a minimal cloud-native Azure application requires that team—or “you”—to be familiar with multiple Azure Resources (App Services, Azure SQL databases, Key Vaults and more). If you go beyond a “minimal” application to create a more reliable, scalable, extendable and maintainable application, then you’ll need to be familiar with even more Azure resources (queues and events, for example).

That means not only knowing how to use those resources wisely and how to set them up/configure them, but also how to access those resources from code, how to write the required code that lives inside these resources and how to deploy that code into those resources during development using the typical “Microsoft developer” toolset (Visual Studio and Visual Studio Code).

But wait, there’s more: You need to be equally interested in how to best secure your part of the application. While you may not have oversight of how the application’s resources are managed after it’s built, you can do your part to close out as many opportunities for a security breach as possible as you create the application.

My Goal

It’s important to me that this series helps you understand both the what and the why of all of those activities.

To facilitate that understanding, in these posts I’m going to lean on the various GUIs available to you by favoring the Azure Portal over the Azure CLI or PowerShell. I have nothing against CLIs for scripting repetitive tasks, but they tend to obscure what’s going on. Interacting with the GUIs (in my opinion) promotes understanding of what, exactly, you’re doing (and walking you through those GUIs gives me an opportunity to explain the options available to you).

Understanding the available options is important because, when it comes time for you to perform these tasks, you won’t be doing exactly what my case study app requires—you’ll need to tweak my solutions to meet your needs. So, to support understanding, I’m also going to avoid using utilities that take care of multiple steps for you. Those utilities are terrifically useful for implementing the typical solution, but if you need to do something that’s not the typical implementation—well, you need to understand what’s going on.

The Sample App

About my sample app: I’m a business application developer, and business apps are all about retrieving and updating data. As a result, my next post is going to be about setting up an Azure SQL database (it’s one of the posts in this series that’s going to be all configuration).

After that post, I’m going to use Visual Studio to create a server-side C# Web API application using minimal APIs to retrieve data from my database. I’ll also set up an Azure Web App/App Service and deploy that Web Service to it.

Once I’ve got that Web Service working, I’ll have it access the database and configure the service and database so that the only application that can access the database will be my Web Service.

After that, I’ll create in Visual Studio Code both client-side and server-side apps that access my Web Service and deploy those apps to another App Service/Web App. Once that’s working, I’ll configure my Web Service so that the only thing that can talk to it will be my frontend (and I’ll configure that app so that it can only be accessed by authorized users).

After those first posts, you’ll have everything you need to create a secure three-tier app and be able to deploy your code from either Visual Studio or Visual Studio Code. Along the way, I’ll look at some of the tools you’ll need for debugging your code, implementing logging, redeploying Azure resources and any other typical development tasks that crop up.

Summing Up and the Next Steps

This series is intended to be everything a team member would need to know to support a minimal microservice (except for the logic specific to an application—that will be up to you).

After that, I’ll show how to (not necessarily in this order):

• Use Azure Key Vault to hold secrets and certificates (and access those resources from your application)
• Use Azure Functions in place of a Web Service hosted in an App Service
• How to leverage the Web API to unify, simplify and document your Web Services
• Integrate queue-based processing to create reliable, scalable and extensible apps
• Replace that queue-based processing with the Azure Event Grid to move to a publish/subscribe, event-driven design

All these components will be running in my Azure tenant, and their access will be restricted (with one exception) to specific clients, also running in my Azure tenant. Even then, those permitted clients will be restricted, able to perform specific authorized activities on those components they can access. The one exception to that is my application’s frontend, which can be accessed by authorized users who, presumably, live outside of Azure.

If you feel that I’ve missed some topic a team would need, email me (peter.vogel@phvis.com) or put a note in the comments.

And, with all that out of the way, here’s the link to that next post on setting up an Azure SQL database.