Enabling scalability, availability, and resiliency with Azure and .NET 5

A short search on scalability returns a definition such as the ability of a system to keep working well when there is an increase in demand. Once developers read this, many of them incorrectly conclude that scalability only means adding more hardware to keep things working without stopping the app.

Scalability relies on technologies involving hardware solutions. However, as a software architect, you must be aware that good software will keep scalability in a sustainable model, which means that a well-architected software can save a lot of money. Hence, it is not just a matter of hardware but also a matter of overall software design. The point here is that the running cost of a system should also be a factor in the architectural decisions.

In Chapter 1, Understanding the Importance of Software Architecture, while discussing software performance, we proposed some good tips to overcome bad performance issues. The same tips will help you with scalability too. The fewer resources we spend on each process, the more users the application can handle.

Although scalability is important, cloud computing applications must be designed to work with system failures. Every time you guarantee that your application recovers from a failure without exposing this failure to the end user, you are creating a resilient application.

You may find cloud architecture resiliency patterns at https://docs.microsoft.com/en-us/azure/architecture/patterns/category/resiliency.

The reason why resiliency is especially important in cloud scenarios is because the infrastructure provided to you may need a small amount of time to manage updates, resets, and even hardware upgrades. You are also more likely to be working with multiple systems, and transient errors are likely to occur in communicating with them. That is why this non-functional requirement started to be spread in recent years.

The possibility of having scalable and resilient solutions gets more exciting when you can enable high availability in the system. All the approaches presented in this book will guide you to design solutions with good availability, but in some cases, you will need to design specific alternatives to achieve the goal you have.

You may find cloud architecture availability patterns at https://docs.microsoft.com/en-us/azure/architecture/patterns/category/availability.

It is worth knowing that Azure and .NET 5 web apps can be configured to achieve these non-functional requirements. Let us check this out in the following subsections.

Creating a scalable web app in Azure

It is simple to create a web app in Azure, ready for scaling. The reason why you must do so is to be able to maintain different numbers of users during different seasons. The more users you have, the more hardware you will need. Let us show you how to create a scalable web application in Azure.

As soon as you log in to your Azure account, you will be able to create a new resource (web app, database, virtual machine, and so on), as you can see in the following screenshot:

Figure 2.1: Microsoft Azure – Create a resource

After that, you can select Web App in the Popular Options, or even type it into the Search the Marketplace textbox. This action will take you to the following screen:

Figure 2.2: Microsoft Azure – Creating a web app

The required Project Details are as follows:

• Subscription: This is the account that will be charged for all application costs. 
• Resource Group: This is the collection of resources you can define to organize policies and permissions. You may specify a new resource group name or add the web app to a group specified during the definition of other resources.

Besides these, the Instance Details are as follows:

• Name: As you can see, the web app name is the URL that your solution will assume after its creation. The name is checked to ensure it is available.
• Publish: This parameter indicates whether the web app will be delivered directly or whether it is going to use Docker technology to publish content. Docker will be discussed in more detail in Chapter 5, Applying a Microservice Architecture to Your Enterprise Application. If you opt for the Docker Container publication, you will be able to configure the Image Source, Access Type, and Image and tag information to have it deployed to the web app.
• Runtime stack: This option is obviously only available when you decide to deliver code directly. At the time this chapter was written, you could define stacks for .NET Core, ASP.NET, Java 11, Java 8, Node, PHP, Python, and Ruby.
• Operating System: This is the option for defining the OS that will host the web app. Both Windows and Linux may be used for ASP.NET Core projects.
• Region: You may consider where you want to deploy your application, considering Azure has many different data centers all over the world.
• App Service Plan: This is where you define the hardware plan that is used to handle the web app and the region of the servers. This choice defines application scalability, performance, and costs.
• Monitoring: This is a useful Azure toolset for monitoring and troubleshooting web apps. In this section, you will be able to enable Application Insights. It is always recommended that you keep the same regions for different components of your solution, since this will save costs in terms of traffic exchange from one data center to another.

Once you have created your web app, this application may be scaled in two conceptually different ways: Vertically (Scale up) and Horizontally (Scale out). Both are available in the web app settings, as you can see in the following screenshot:

Figure 2.3: Scaling options of web apps

Let us check out the two types of scaling.

Vertical scaling (Scaling up)

Scaling up means changing the specification of hardware that will host your application. In Azure, you have the opportunity of starting with free, shared hardware and moving to an isolated machine in a few clicks. The following screenshot shows the user interface for scaling up a web app:

Figure 2.4: Vertical scaling options

By choosing one of the options provided, you can select more powerful hardware (machines with more CPUs, storage, and RAM). Monitoring your application and its App Service plan will guide you on how to decide the best infrastructure for running the solution you are proving. It will also offer key insights, such as possible CPU, memory, and I/O bottlenecks.

Horizontal scaling (Scaling out)

Scaling out means splitting all requests among more servers with the same capacity instead of using more powerful machines. The load on all the servers is automatically balanced by the Azure infrastructure. This solution is advised when the overall load may change considerably in the future since horizontal scaling can be automatically adapted to the current load. The following screenshot shows an automatic Scale out strategy defined by two simple rules, which is triggered by CPU usage:

Figure 2.5: Horizontal scaling sample

It is worth highlighting that you can choose to have a hardcoded instance count or implement rules for automatic scale in/out.

A complete description of all the available auto-scale rules is beyond the purpose of this book. However, they are quite self-explanatory, and the Further reading section contains links to the full documentation.

The Scale out feature is only available in paid service plans.

In general, horizontal scaling is a way to guarantee availability in the application even with a number of simultaneous accesses. For sure, its use is not the only way to keep a system available, but it will definitely help.

Creating a scalable web app with .NET 5

Among all the available frameworks for implementing web apps, running it with ASP.NET Core 5 ensures good performance, together with low production and maintenance costs. The union of C#, a strongly typed and advanced general-purpose language, and continuous performance improvements achieved in the framework, mark this option out in recent years as one of the best for enterprise development.

The steps that follow will guide you through the creation of an ASP.NET Core Runtime 5-based web app. All the steps are quite simple, but some details require attention.

It is worth mentioning that .NET 5 brings the opportunity to develop to any platform – Desktops (WPF, Windows Forms, and UWP), Web (ASP.NET), Cloud (Azure), Mobile (Xamarin), Gaming (Unity), IoT (ARM32 and ARM64), and AI (ML.NET and .NET for Apache Spark). So, the recommendation from now on is to only use .NET 5. In this scenario, you can run your web app on both Windows and cheaper Linux servers.

Nowadays, Microsoft recommends classic .NET, just in case the features you need are not available in .NET Core, or even when you deploy your web app in an environment that does not support .NET Core. In any other case, you should prefer .NET Core Framework because it allows you to do the following:

• Run your web app in Windows, Linux, macOS, or Docker containers
• Design your solution with microservices
• Have high performance and scalable systems

Containers and microservices will be covered in Chapter 5, Applying a Microservice Architecture to Your Enterprise Application. There, you will get a better understanding of the advantages of these technologies. For now, it is enough to say that .NET 5 and microservices were designed for performance and scalability, which is why you should prefer .NET 5 in all your new projects.

The following procedure will show you how to create an ASP.NET Core web app in Visual Studio 2019 with .NET 5:

• As soon as you start VS 2019, you will be able to click on Create a new project.
• Once you select ASP.NET Core Web Application, you will be directed to a screen where you will be asked to set up the Project name, Location, and Solution name:

  

Figure 2.6: Creating an ASP.NET Core web application

• After that, you will be able to select the .NET version to use. Select ASP.NET Core 5.0 to get the most advanced and brand-new platform. For this demo, you can select the Web Application template.
• Now that we are done with adding the basic details, you can connect your web app project to your Azure account and have it published.
• If you right-click the project you created, in Solution Explorer, you have the option to Publish:

  

Figure 2.7: Publishing the ASP.NET Core web application

• You will find different targets to publish your web app. Select Azure as the target.
• Then, you will be able to decide the Specific target to publish. Select Azure App Service (Windows) for this demo.
• You may be required to define your Microsoft Account credentials at this time. This is because there is full integration between Visual Studio and Azure. This gives you the opportunity to view all the resources you created in the Azure portal in your development environment:

  

Figure 2.8: Integration between Visual Studio and Azure

• Once you have decided on your Publish settings, that is, the publish profile, the web app will be automatically published when you click Publish. Pay attention here to select the F1 tier of pricing so that this process does not incur any costs:

  

Figure 2.9: Publish profile options

• You have currently two modes for deployment. The first, Framework-dependent, will require a web app configured with the target framework. The second, self-contained, will no longer need this feature since the binaries of the framework will be published together with the application.
• It is worth mentioning that in order to publish ASP.NET Preview versions in Framework-dependent mode, you must add an extension in the web app setup panel in Azure Portal, as shown in the following screenshot. However, consider using the self-contained mode, especially when you are under preview versions:

  

Figure 2.10: Adding extensions in Azure Web App Service

For more information on deploying ASP.NET Core 5.0 to Azure App Service, please refer to the following link: https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/azure-apps/?view=aspnetcore-5.0&tabs=visual-studio.

Here, we described the simplest way to deploy a web app. In Chapter 20, Understanding DevOps Principles and Chapter 21, Challenges of Applying CI Scenarios, we will introduce you to the Azure DevOps Continuous Integration/Continuous Delivery (CI/CD) pipeline. This pipeline is a further Azure toolset that automates all the required steps to get the application in production, that is, building, testing, deployment in staging, and deployment in production.