The samples provided in this chapter will require Visual Studio 2019 Community Edition with .NET 5 SDK installed.

You can find the sample code for this chapter at https://github.com/PacktPublishing/Software-Architecture-with-C-9-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.

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.

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.

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

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.

Nowadays, C# is one of the most commonly used programming languages all over the world, so good tips about C# programming are fundamental for the design of good architectures that satisfy the most common non-functional requirements.

The following sections mention a few simple but effective tips – the associated code samples are available in the GitHub repository of this book.

String concatenation

This is a classic one! A naive concatenation of strings with the + string operator may cause serious performance issues since each time two strings are concatenated, their contents are copied into a new string.

So, if we concatenate, for instance, 10 strings that have an average length of 100, the first operation has a cost of 200, the second one has a cost of 200+100=300, the third one has a cost of 300+100=400, and so on. It is not difficult to convince yourself that the overall cost grows like m*n², where n is the number of strings and m is their average length. n² is not too big for small n (say, n < 10), but it becomes quite big when n reaches the magnitude of 100-1,000, and unacceptable for magnitudes of 10,000-100,000.

Let us look at this with some test code, which compares naive concatenation with the same operation that is performed with the help of the StringBuilder class (the code is available in this book's GitHub repository):

Figure 2.11: Concatenation test code result

If you create a StringBuilder class with something like var sb =new System.Text.StringBuilder(), and then you add each string to it with sb.Append(currString), the strings are not copied; instead, their pointers are queued in a list. They are copied in the final string just once, when you call sb.ToString() to get the final result. Accordingly, the cost of StringBuilder-based concatenation grows simply as m*n.

Of course, you will probably never find a piece of software with a function like the preceding one that concatenates 100,000 strings. However, you need to recognize pieces of code similar to these ones where the concatenation of some 20-100 strings, say, in a web server that handles several requests simultaneously, might cause bottlenecks that damage your non-functional requirements for performance.

Exceptions

Always remember that exceptions are much slower than normal code flow! So, the usage of try-catch needs to be concise and essential, otherwise, you will create big performance issues.

The following two samples compare the usage of try-catch and Int32.TryParse to check whether a string can be converted into an integer, as follows:

private static string ParseIntWithTryParse()
{
    string result = string.Empty; 
    if (int.TryParse(result, out var value))
        result = value.ToString();
    else
        result = "There is no int value";
    return $"Final result: {result}";
}
private static string ParseIntWithException()
{
    string result = string.Empty;
    try
    {
        result = Convert.ToInt32(result).ToString();
    }
    catch (Exception)
    {
        result = "There is no int value";
    }
    return $"Final result: {result}";
}

The second function does not look dangerous, but it is thousands of times slower than the first one:

Figure 2.12: Exception test code result

To sum this up, exceptions must be used to deal with exceptional cases that break the normal flow of control, for instance, situations when operations must be aborted for some unexpected reasons, and control must be returned several levels up in the call stack.

Multithreading environments for better results – dos and don'ts

If you want to take advantage of all the hardware that the system you are building provides, you must use multithreading. This way, when a thread is waiting for an operation to complete, the application can leave the CPU to other threads, instead of wasting CPU time.

On the other hand, no matter how hard Microsoft is working to help with this, parallel code is not as simple as eating a piece of cake: it is error-prone and difficult to test and debug. The most important thing to remember as a software architect when you start considering using threads is does your system require them? Non-functional and some functional requirements will answer this question for you.

As soon as you are sure that you need a multithreading system, you should decide on which technology is more adequate. There are a few options here, as follows:

• Creating an instance of System.Threading.Thread: This is a classic way of creating threads in C#. The entire thread life cycle will be in your hands. This is good when you are sure about what you are going to do, but you need to worry about every single detail of the implementation. The resulting code is hard to conceive and debug/test/maintain. So, to keep development costs acceptable, this approach should be confined to a few fundamental, performance critical modules.
• Programming using System.Threading.Tasks.Parallel classes: Since .NET Framework 4.0, you can use parallel classes to enable threads in a simpler way. This is good because you do not need to worry about the life cycle of the threads you create, but it will give you less control about what is happening in each thread.
• Develop using asynchronous programming: This is, for sure, the easiest way to develop multithreaded applications since the compiler takes on most of the work. Depending on the way you call an asynchronous method, you may have the Task created running in parallel with the Thread that was used to call it or even have this Thread waiting without suspending for the task created to conclude. This way, asynchronous code mimics the behavior of classical synchronous code while keeping most of the performance advantages of general parallel programming:
  • The overall behavior is deterministic and does not depend on the time taken by each task to complete, so non-reproducible bugs are more difficult to happen, and the resulting code is easy to test/debug/maintain. Defining a method as an asynchronous task or not is the only choice left to the programmer; everything else is automatically handled by the runtime. The only thing you should be concerned about is which methods should have asynchronous behavior. It is worth mentioning that defining a method as async does not mean it will execute on a separate thread. You may find useful information in a great sample at https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/async/.
  • Later in this book, we will provide some simple examples of asynchronous programming. For more information about asynchronous programming and its related patterns, please check Task-Based Asynchronous Patterns in the Microsoft documentation (https://docs.microsoft.com/en-us/dotnet/standard/asynchronous-programming-patterns/task-based-asynchronous-pattern-tap).

No matter the option you choose, there are some dos and don'ts that, as a software architect, you must pay attention to. These are as follows:

• Do use concurrent collections (System.Collections.Concurrent): As soon as you start a multithreading application, you have to use these collections. The reason for this is that your program will probably manage the same list, dictionary, and so on from different threads. The use of concurrent collections is the most convenient option for developing thread-safe programs.
• Do worry about static variables: It is not possible to say that static variables are prohibited in multithreading development, but you should pay attention to them. Again, multiple threads taking care of the same variable can cause a lot of trouble. If you decorate a static variable with the [ThreadStatic] attribute, each thread will see a different copy of that variable, hence solving the problem of several threads competing on the same value. However, ThreadStatic variables cannot be used for extra-thread communications since values written by a thread cannot be read by other threads. In asynchronous programming, AsyncLocal<T> is the option for doing something like that.
• Do test system performance after multithreading implementations: Threads give you the ability to take full advantage of your hardware, but in some cases, badly written threads can waste CPU time just doing nothing! Similar situations may result in almost 100% CPU usage and unacceptable system slowdowns. In some cases, the problem can be mitigated or solved by adding a simple Thread.Sleep(1) call in the main loop of some threads to prevent them from wasting too much CPU time, but you need to test this. A use case for this implementation is a Windows Service with many threads running in its background.
• Do not consider multithreading easy: Multithreading is not as simple as it seems in some syntax implementations. While writing a multithreading application, you should consider things such as the synchronization of the user interface, threading termination, and coordination. In many cases, programs just stop working well due to a bad implementation of multithreading.
• Do not forget to plan the number of threads your system should have: This is important especially for 32-bit programs. There is a limitation regarding how many threads you can have in any environment. You should consider this when you are designing your system.
• Do not forget to end your threads: If you do not have the correct termination procedure for each thread, you will probably have trouble with memory and handling leaks.

Scalability, performance tips, and multithreading are the main tools we can use to tune machine performance. However, the effectiveness of the system you design depends on the overall performance of the whole processing pipeline, which includes both humans and machines.

As a software architect, you cannot improve the performance of humans, but you can improve the performance of man-machine interaction by designing an effective user interface (UI), that is, a user interface that ensures fast interaction with humans, which, in turn, means the following:

• The UI must be easy to learn in order to reduce the time that is needed for learning and time wasting before the target users learn to operate it quickly. This constraint is fundamental if UI changes are frequent, and for public websites that need to attract the greatest possible number of users.
• The UI must not cause any kind of slowdown in data insertion; data entry speed must be limited only by the user's ability to type, not by system delays or by additional gestures that could be avoided.

It is worth mentioning that we have UX experts in the market. As a software architect, you must decide when they are essential to the success of the project. The following are a few simple tips when it comes to designing easy to learn user interfaces:

• Each input screen must state its purpose clearly.
• Use the language of the user, not the language of developers.
• Avoid complications. Design the UI with the average case in mind; more complicated cases can be handled with extra inputs that appear only when needed. Split complex screens into more input steps.
• Use past inputs to understand user intentions and to put users on the right paths with messages and automatic UI changes; for instance, cascading drop-down menus.
• Error messages are not bad notes the system gives to the user, but they must explain how to insert correct input.

Fast user interfaces result from efficacious solutions to the following three requirements:

• Input fields must be placed in the order they are usually filled, and it should be possible to move to the next input with the Tab or Enter key. Moreover, fields that often remain empty should be placed at the bottom of the form. Simply put, the usage of the mouse while filling a form should be minimized. This way, the number of user gestures is kept to a minimum. In a web application, once the optimal placement of input fields has been decided, it is enough to use the tabindex attribute to define the right way users move from one input field to the next with the Tab key.
• System reactions to user inputs must be as fast as possible. Error messages (or information ones) must appear as soon as the user leaves the input field. The simplest way to achieve this is to move most of the help and input validation logic to the client side so that system reactions do not need to pass through both communication lines and servers.
• Efficacious selection logic. Selecting an existing item should be as easy as possible; for example, selecting one out of some thousands of products in an offer must be possible with a few gestures and with no need to remember the exact product name or its barcode. The next subsection analyzes techniques we can use to decrease complexity to achieve fast selection.

In Chapter 16, Blazor WebAssembly, we will discuss how this Microsoft technology can help us with the challenges of building web-based applications with C# code in the front-end.

Designing fast selection logic

When all the possible choices are in the order of magnitude of 1-50, the usual drop-down menu is enough. For instance, this currency selection drop-down menu:

 

Figure 2.13: Simple drop-down menu

When the order of magnitude is higher but less than a few thousand, an autocomplete that shows the names of all the items that start with the characters typed by the user is usually a good choice:

Figure 2.14: Complex drop-down menu

A similar solution can be implemented with a low computational cost since all the main databases can efficiently select strings that start with a given substring.

When names are quite complex, when searching for the characters that were typed in by the user, they should be extended inside each item string. This operation cannot be performed efficiently with usual databases and requires ad hoc data structures.

Finally, when we are searching inside descriptions composed of several words, more complex search patterns are needed. This is the case, for instance, with product descriptions. If the chosen database supports full-text search, the system can search for the occurrence of several words that have been typed by the user inside all the descriptions efficiently.

However, when descriptions are made up of names instead of common words, it might be difficult for the user to remember a few exact names contained in the target description. This happens, for instance, with multi-country company names. In these cases, we need algorithms that find the best match for the character that was typed by the user. Substrings of the string that was typed by the user must be searched in different places of each description. In general, similar algorithms can't be implemented efficiently with databases based on indexes, but require all the descriptions to be loaded in memory and ranked somehow against the string that was typed by the user.

The most famous algorithm in this class is probably the Levenshtein algorithm, which is used by most spell checkers to find a word that best fits the mistyped one by the user. This algorithm minimizes the Levenshtein distance between the description and the string typed by the user, that is, the minimum number of character removals and additions needed to transform one string into another.

The Levenshtein algorithm works great, but has a very high computational cost. Here, we give a faster algorithm that works well for searching character occurrences in descriptions. Characters typed by the user don't need to occur consecutively in the description but must occur in the same order. Some characters may miss. Each description is given a penalty that depends on the missing characters and on how far the occurrences of the characters typed by the user are from the others. More specifically, the algorithm ranks each description with two numbers:

• The number of characters typed by the user that occurs in the description: the more characters contained in the description, the higher its rank.
• Each description is given a penalty equal to the total distance among the occurrences of the characters typed by the user in the description.

The following screenshot shows how the word Ireland is ranked against the string ilad, which was typed by the user:

Figure 2.15: Sample of Levenshtein usage

The number of occurrences is four (4), while the total distance between character occurrences is three (3).

Once all the descriptions have been rated, they are sorted according to the number of occurrences. Descriptions with the same number of occurrences are sorted according to the lowest penalties. The following is an autocomplete that implements the preceding algorithm:

Figure 2.16: Levenshtein algorithm user interface experience

The full class code, along with a test console project, is available in this book's GitHub repository.

Selecting from a huge number of items

Here, huge does not refer to the amount of space needed to store the data, but to the difficulty the user has in remembering the features of each item. When an item must be selected from among more than 10,000-100,000 items, there is no hope of finding it by searching for character occurrences inside a description. Here, the user must be driven toward the right item through a hierarchy of categories.

In this case, several user gestures are needed to perform a single selection. In other words, each selection requires interaction with several input fields. Once it's decided that the selection can't be done with a single input field, the simplest option is cascading drop-down menus, that is, a chain of drop-down menus whose selection list depends on the values that were selected in the previous drop-down menus.

For example, if the user needs to select a town located anywhere in the world, we may use the first drop-down menu to select the country, and once the country has been chosen, we may use this choice to populate a second one with all the towns in the selected country. A simple example is as follows:

Figure 2.17: Cascading drop-down menu example

Clearly, each drop-down menu can be replaced by an autocomplete when required due to having a high number of options.

If making the right selection can be done by intersecting several different hierarchies, cascading drop-down menus become inefficient too, and we need a filter form, as follows:

Figure 2.18: Filter form sample

Now, let us understand interoperability with .NET Core.

.NET Core brought Windows developers the ability to deliver their software into various platforms. And you, as a software architect, need to pay attention to this. Linux and macOS are no longer a problem for a C# lover – it is much better than that – they are great opportunities to deliver to new customers. Therefore, we need to ensure performance and multi-platform support, two common non-functional requirements in several systems.

Both console applications and web apps designed with .NET Core in Windows are almost completely compatible with Linux and macOS, too. This means you do not have to build the app again to run it on these platforms. Also, very platform-specific behaviors now have multi-platform support, as shown, for instance, by the System.IO.Ports.SerialPort class, which, starting from .NET Core 3.0, is on Linux.

Microsoft offers scripts to help you install .NET Core on Linux and macOS. You can find them at https://docs.microsoft.com/dotnet/core/tools/dotnet-install-script. Once you have the SDK installed, you just need to call dotnet the same way you do in Windows.

However, you must be aware of some features that are not fully compatible with Linux and macOS systems. For instance, no equivalent to the Windows Registry exists in these OSes and you must develop an alternative yourself. If needed, an encrypted JSON config file can be a good option.

Another important point is that Linux is case-sensitive, while Windows is not. Please, remember this when you work with files. Another important thing is that the Linux path separator is different from the Windows separator. You can use the Path.PathSeparator field and all the other Path class members to ensure your code is multi-platform.

Besides, you can also adapt your code to the underlying OS by using the runtime checks provided by .NET Core, as follows:

using System;
using System.Runtime.InteropServices;
namespace CheckOS
{
    class Program
    {
        static void Main()
        {
            if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
                Console.WriteLine("Here you have Windows World!");
            else if(RuntimeInformation.IsOSPlatform(OSPlatform.Linux))
                Console.WriteLine("Here you have Linux World!");
            else if (RuntimeInformation.IsOSPlatform(OSPlatform.OSX))
                Console.WriteLine("Here you have macOS World!");
        }
    }
}

Creating a service in Linux

The following script can be used to encapsulate a command-line .NET Core app in Linux. The idea is that this service works like a Windows service. This can be useful, considering that most Linux installations are command-line only and run without a user logged in:

• The first step is to create a file that will run the command-line app. The name of the app is app.dll and it is installed in appfolder. The application will be checked every 5,000 milliseconds. This service was created on a CentOS 7 system. Using a Linux terminal, you can type this:

  cat >sample.service<<EOF
  [Unit]
  Description=Your Linux Service
  After=network.target
  [Service]
  ExecStart=/usr/bin/dotnet $(pwd)/appfolder/app.dll 5000
  Restart=on-failure
  [Install]
  WantedBy=multi-user.target
  EOF
  

• Once the file has been created, you must copy the service file to a system location. After that, you must reload system and enable the service so that it will restart on reboots:

  sudo cp sample.service /lib/systemd/system
  sudosystemctl daemon-reload 
  sudosystemctl enable sample
  

• Done! Now, you can start, stop, and check the service using the following commands. The whole input that you need to provide in your command-line app is as follows:

  # Start the service
  sudosystemctl start sample
  # View service status
  sudosystemctl status sample
  # Stop the service
  sudosystemctl stop sample
  

Now that we have learned about a few concepts, let us learn how to implement them in our use case.

As we have seen up to here in the book, the opportunities and techniques we have for developing software are incredible. If you add all the information you will read about in relation to cloud computing in the next chapters, you will see that the opportunities just increase, as does the complexity to maintain all of this computing environment.

As a software architect, you must understand that these opportunities come with many responsibilities. The world has changed a lot in the last years. The second decade of the 21^st century has required lots of technology. Apps, social media, Industry 4.0, Big Data, and artificial intelligence are no longer future objectives, but mainly current projects that you will lead and deal with in your routine.

Considering this scenario, security must have a different approach. The world has moved to regulate companies that manage personal data. For instance, GDPR – the General Data Protection Regulation – is not only mandatory for European territory, since it has changed the way software is developed not only in Europe but all over the globe. There are many initiatives comparable to GDPR that must be enlisted to our belt of techniques and regulations, considering the software you design will be impacted by them.

Security by design must be one of your areas of focus for designing new applications. This subject is huge, and it is not going to be completely covered in this book, but as a software architect, you have to understand the necessity of having a specialist in the information security area in your team to guarantee the policies and the practices needed to avoid cyber attacks and maintain confidentiality, privacy, integrity, authenticity, and availability of the services you architect.

When it comes to protecting your ASP.NET Core application, it is worth mentioning that the framework has many features to help us out with that. For instance, it includes authentication and authorization patterns. In the OWASP Cheat Sheet Series, you'll be able to read about many other .NET practices.

ASP.NET also provides features to help us out with GDPR. Basically, there are APIs and templates to guide you in the implementation of policy declaration and cookie usage consent.

List of practices for achieving a safe architecture

The following list of practices related to security certainly does not cover the entirety of the subject. However, these practices will certainly help you, as a software architect, to explore some solutions related to this topic.

Authentication

Define an authentication method for your web app. There are many authentication options available nowadays, from ASP.NET Core Identity to external provider authentication methods, such as Facebook or Google. As a software architect, you must consider who the target audience of the application is. It would also be worth considering using Azure Active Directory as a starting point if you choose to go down this route.

You may find it useful to design authentication associated with Azure AD, a component for managing the Active Directory of the company you are working for. This alternative is pretty good in some scenarios, especially for internal usage. Azure currently offers Active Directory for usage as B2B – Business to Business, or B2C – Business to Consumer.

Depending on the scenario of the solution you are building, you will need to implement MFA – Multi Factor Authentication. The idea of this pattern is to ask for at least two forms of proof of identity before allowing the solution usage. It is worth mentioning that Azure AD facilitates this for you.

Do not forget that you must determine an authentication method for the APIs you provide. JSON Web Token is a pretty good pattern, and its usage is totally cross-platform.

You must determine the authorization model you will use in your web app. There are four model options:

1. Simple, where you just use the [Authorize] attribute in the class or method;
2. Role-based, in which you may declare Roles for accessing the Controller you are developing;
3. Claims-based, where you can define values that must be received during the authentication to indicate that the user is authorized;
4. Policy-based, in which there is a policy established to define the access in that Controller.

You may also define a controller or method in a class as being fully accessible to any user, by defining the attribute [AllowAnonymous]. Be sure this kind of implementation will not cause any vulnerabilities in the system you are designing.

The model you decide to use will define exactly what each user will be able to do in the application.

Sensitive data

While designing, you, as a software architect, will have to decide which part of the data you store is sensitive, and it will need to be protected. By connecting to Azure, your web app will be able to store protected data in components such as Azure Storage and Azure Key Vault. Storage in Azure will be discussed in Chapter 9, How to Choose Your Data Storage in the Cloud.

It is worth mentioning that Azure Key Vault is used to protect secrets your app may have. Consider using this solution when you have this kind of requirement.

Web security

It is totally unacceptable to have a production solution deployed without the HTTPS protocol enabled. Azure Web Apps and ASP.NET Core solutions have various possibilities to not only use but enforce the usage of this security protocol.

Thera are many known attacks and malicious patterns, such as cross-site request forgery, Open Redirect, and cross-site scripting. ASP.NET Core guarantees and presents APIs to solve them. You need to detect the ones that are useful for your solution.

Good programming practices, such as avoiding SQL injections by using parameters in your queries, is another important goal to achieve.

To finish, it is worth mentioning that security needs to be treated using the onion approach, which means that there are many layers of security to be implemented. You must have a policy determined to guarantee a process to access the data, including physical access to people who use the system you are developing. In addition, you will also have to develop a disaster recovery solution in case the system is attacked. The disaster recovery solution will depend on your cloud solution. We will discuss this later in Chapter 4, Deciding the Best Cloud-Based Solution.

The development of this book's use case will be based on various kinds of .NET Core Visual Studio projects. This section describes all of them. Let us select New project in the Visual Studio File menu.

You can filter .NET Core project types by typing in the search engine, as follows:

Figure 2.19: Searching types of .NET Core projects in Visual Studio

There, you will find common C# projects (console, a class library, Windows Form, WPF), and various types of test projects, each based on a different test framework: xUnit, NUnit, and MSTest. Choosing among the various testing frameworks is just a matter of preference since all of them offer comparable features. Adding tests to each piece of software that composes a solution is a common practice and allows software to be modified frequently without jeopardizing its reliability.

You may also want to define your class library projects under the .NET Standard, which will be discussed in Chapter 13, Implementing Code Reusability in C# 9. These class libraries are based on standards that make them compatible with several .NET versions. For instance, libraries based on 2.0 standards are compatible with all .NET Core versions greater than or equal to 2.0, and with all .NET Framework versions greater than 4.6. This compatibility advantage comes at the price of having fewer available features.

Besides filtering Project Types to Cloud, we have several more project types. Some of them will enable us to define microservices. Microservice-based architectures allow an application to be split into several independent microservices. Several instances of the same microservice can be created and distributed across several machines to fine-tune the performance of each application part. Microservices will be described in:

• Chapter 5, Applying a Microservice Architecture to Your Enterprise Application
• Chapter 6, Azure Service Fabric
• Chapter 7, Azure Kubernetes Service

Finally, testing will be discussed in detail in Chapter 18, Testing Your Code with Unit Test Cases and TDD, and Chapter 22, Automation for Functional Tests. Finally, we have the ASP.NET Core application we already described in the Creating a scalable web app with .NET 5 subsection. There, we defined an ASP.NET Core application, but Visual Studio also contains project templates for projects based on RESTful APIs and the most important single-page application frameworks, such as Angular, React, Vue.js, and the Blazor framework based on WebAssembly, which will be discussed in Chapter 16, Blazor WebAssembly. Some of them are available with the standard Visual Studio installation, while others require the installation of an SPA package.

Functional requirements that describe system behavior must be completed with non-functional requirements that constrain system performance, scalability, availability, resilience, interoperability, usability, and security.

Performance requirements come from response time and system load requirements. As a software architect, you should ensure you have the required performance at the minimum cost, building efficient algorithms and taking full advantage of the available hardware resources with multithreading.

Scalability is the ability of a system to be adapted to an increasing load. Systems can be scaled vertically by providing more powerful hardware, or horizontally by replicating and load balancing the same hardware, which increases the availability. The cloud, in general, and Azure can help us implement strategies dynamically, with no need to stop your application.

Tools such as .NET Core that run on several platforms can ensure interoperability, that is, the capability of your software to run on different target machines and with different operating systems (Windows, Linux, macOS, Android, and so on).

Usability is ensured by taking care of the input field's order, the effectiveness of the item selection logic, and how easy your system is to learn.

Besides, the more complex your solution is, the better resilience it should have. The idea of resilience is not to guarantee that the solution does not fail. Instead, the idea is to guarantee that the solution has an action defined when each part of the software fails.

As a software architect, you must consider security from the very beginning of the design. Following the guidelines to determine the correct patterns and having a security specialist in your team would be a great option to achieve all the current regulations we have.

In the next chapter, you will learn how Azure DevOps tools can help us when it comes to collecting, defining, and documenting our requirements.

1. Which are the two conceptual ways to scale a system?
2. Can you deploy your web app automatically from Visual Studio to Azure?
3. What is multithreading useful for?
4. What are the main advantages of the asynchronous pattern over other multithreading techniques?
5. Why is the order of input fields so important?
6. Why is the .NET Core Path class so important for interoperability?
7. What is the advantage of a .NET standard class library over a .NET Core class library?
8. List the various types of .NET Core Visual Studio projects.

The following are some books and links you may consider reading in order to gather more information in relation to this chapter:

• https://www.packtpub.com/virtualization-and-cloud/hands-azure-developers
• https://docs.microsoft.com/en-us/azure/architecture/best-practices/auto-scaling
• https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/azure-apps/
• https://docs.microsoft.com/en-us/dotnet/standard/parallel-processing-and-concurrency
• https://docs.microsoft.com/en-us/dotnet/standard/parallel-programming/
• https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-5/
• https://docs.microsoft.com/en-us/dotnet/standard/security/
• https://docs.microsoft.com/en-us/aspnet/core/security/
• https://owasp.org/
• https://cheatsheetseries.owasp.org/cheatsheets/DotNet_Security_Cheat_Sheet.html
• https://docs.microsoft.com/en-us/aspnet/core/security/gdpr
• https://docs.microsoft.com/en-us/azure/architecture/patterns/category/resiliency
• https://docs.microsoft.com/en-us/azure/architecture/patterns/category/availability