When running as a consumption plan, Azure Functions is best suited to short-lived tasks – for tasks that run longer than 10 minutes, you should consider alternatives or running them on an App Service plan.

You should also consider how often they will be executed because you pay per execution on a consumption plan. If it is continuously triggered, your costs could increase beyond that of a standard web app. Again, consider alternative approaches or the use of an App Service plan.

Finally, consumption-based apps cannot integrate with VNets. Again, if this is required, running them on an App Service plan can provide this functionality.

Logic Apps

Azure Logic Apps is another serverless option – when creating logic apps, you do not need to be concerned with how much RAM or CPU to provision; instead, you pay per execution or triggering them.

Important note

Consumption versus fixed price: Many serverless components, including Logic Apps and Functions, can be run on isolated environments, or in the case of Logic Apps, an Isolated Service Environment (ISE), whereby you pay for provisioned resources in the same way as a virtual machine.

Logic Apps shares many concepts with Azure Functions; you can define triggers, actions, flow logic, and connectors for communicating with other services. Whereas you define this in code with Functions, Logic Apps provides a drag-and-drop interface that allows you to build workflows quickly.

Logic Apps has hundreds of pre-built connectors that allow you to interface with hundreds of systems – not just in Azure but also externally. By combining these connectors with if-then-else style logic flows and either scheduled or action-based triggers, you can develop complex workflows without writing a single line of code.

The following screenshot shows a typical workflow built purely in the Azure portal:

Figure 7.7 – Logic Apps example

With their extensibility features, you can also create your custom logic and connectors for integrating with your services.

Finally, although the solution can be built entirely in the Azure portal, you can also create workflows using traditional development tools such as Visual Studio or Visual Studio Code. This is because solutions are defined as ARM templates – which enables developers to define workflows and store them in code repositories. You can then automate deployments through DevOps pipelines.

What to watch out for

Logic Apps provides a quick and relatively simple mechanism for creating business workflows. When you need to build more complex business logic or create custom connectors, you need to balance the difficulty of doing this versus using an alternative approach such as Azure Functions. Logic Apps still requires a level of developer experience and is not suitable if business users may need to develop and amend the workflows.

Power Automate

Power Automate, previously called Flow, is also a GUI-driven workflow creation tool that allows you to build automated business processes. Like Logic Apps, using Power Automate, you can define triggers and logic flow connected to other services, such as email, storage, or apps, through built-in connectors.

The most significant difference between Power Automate and Logic Apps is that Power Automate workflows can only be built via the drag-and-drop interface – you cannot edit or store the underlying code.

Therefore, the primary use case for Power Automate is for office workers and business analysts to create simple workflows that can use only the built-in connectors.

In general, AKS and Kubernetes are more complicated than other technologies, especially Azure native alternatives such as App Service or Azure Functions. Additional tools are often required to better monitor and deploy solutions, which can sometimes lead to security concerns for some organizations. Although these can, of course, be satisfied, there is more work involved in setting up and using AKS for the first time.

Kubernetes is also designed to host multiple services and therefore may not be cost-effective for smaller, more straightforward applications such as a single, basic website. As an example, the recommended minimum number of nodes in a production AKS cluster is three nodes. In comparison, a resilient web app can be run on just a single node when using Azure App Service.

App Service

App Service is a fully managed hosting platform for web applications, RESTful APIs, mobile backend services, and background jobs.

App Service supports applications built in ASP.NET, ASP.NET Core, Java, Ruby, Node.js, PHP, and Python. Applications deployed to App Service are scalable, secure, and adhere to many industry-standard compliance standards.

App Service is linked to an App Service plan, which defines the amount of CPU and RAM available to your applications. You can also assign multiple app services to the same App Service plan to share resources.

For highly secure environments, Application Service Environments (ASEs) provide isolated environments built on top of VNets.

App Service is, therefore, best suited to web apps, RESTful APIs, and mobile backend apps. It can be easily scaled by defining CPU and RAM-based thresholds and are fully managed, so you do not need to worry about security patching or resilience within a region.

What to watch out for

Because App Service is always running, is always costs – that is, it is never idle. However, using automated scaling can at least ensure a minimal cost during low usage, and scale-out with additional instances in response to demand.

• Scalability

Different services have different methods for scaling. Legacy applications may need to use traditional load balancing methods by building VMs in web farms with load balancers in front to distribute the load.

Modern web applications can make use of App Service or Azure Functions, which scale automatically without the need for additional components.

• Availability

Each Azure service has a Service-Level Agreement (SLA) that determines a baseline for how much uptime a service offers. The mix of components used can also affect this value. For example, a single VM has an SLA of 95%, whereas two VMs across Availability Zones with a load balancer in front has an SLA of 99.99%.

Azure Functions and App Service have an SLA of 99.95% without any additional components.

Important note

Service-Level Agreements (SLAs) define specific metrics by which a service is measured. In Azure, it is the amount of time any particular service is agreed to be available for. This is usually measured as a percentage of that uptime – for example, 99.95% (referred to as three and a half nines) or 99.99% (referred to as four nines). Your choice of components and how they are architected will impact the SLA Microsoft offers.

An SLA of 99.95% means up to 4.38 hours of downtime a year is allowed, whereas 99.99% means only 52.60 minutes are permitted.

• Security

As services move from IaaS to PaaS and FaaS, the security responsibility shifts. For VMs, Microsoft is responsible for the physical security and underlying infrastructure, whereas you are responsible for patching, anti-virus software, and applications that run on them. For PaaS and FaaS, Microsoft is also responsible for security on the service. However, you need to be careful of different configuration elements within the service that may not be compliant with your requirements.

For some organizations, all traffic flow needs to be tightly controlled, especially for internal services; most PaaS solutions support this but only as a configurable option, which can sometimes increase costs.

• Cost

FaaS provides a very granular cost model in that you pay for execution time. Whereas IaaS and some PaaS demand you provision set resources based on required CPU and RAM. For example, a VM incurs costs as long as it is running, which is continual for many use cases.

When migrating existing legacy applications, this may be the only option, but it isn’t the most efficient from a cost perspective. Refactoring applications may cost more upfront but could be cheaper in the long run as they only consume resources and incur costs periodically.

Similarly, a new microservice built to respond to events on an ad hoc basis would suit an Azure function, whereas the same process running on a VM would not be cost-effective.

• Architecture styles

How an application is designed can directly impact the choice of technology. VMs are best suited to older architectures such as N-tier, whereas microservice and event-driven patterns are well suited to Azure Functions or containerization.

• User skills

Azure provides several technologies for no-code development. Power Automate, and the workflow development system, is specifically built to allow end users with no development knowledge to quickly create simple apps.

As you can see, to decide on a compute technology, you must factor in many different requirements. The following chart shows a simple workflow to help in this process:

Figure 7.1 – Compute options workflow

Next, we will look in more detail at each service and provide example use cases.

In the previous chapter, we looked at how to secure our Azure applications using key vaults, security principals, and managed identities.

When building solutions in Azure many components use some form of compute – such as a virtual machine (VM). However, there are many different types of compute, each with its own strengths. Therefore, in this chapter, we focus on the different types of compute services we have available to us and which options are best suited to which scenarios.

We will then maintain the security and health of VMs by ensuring they are always up to date with the latest OS patches.

Finally, we’ll look at containerization and how we can use Azure Kubernetes Service (AKS).

With this in mind, we will be covering the following topics:

• Understanding different types of compute
• Automating virtual machine management
• Architecting for containerization and Kubernetes

Technical requirements

This chapter will use the Azure portal (https://portal.azure.com) for examples.

Understanding different types of compute

When we architect solutions, there will often be at least one component that needs to host, or run, an application. The application could be built specifically for the task or an off-the-shelf package bought from a vendor.

Azure provides several compute services for hosting your application; each type can be grouped into one of three kinds of hosting model:

• Infrastructure as a Service (IaaS): VMs are within this category and support services such as storage (that is, disk drives) and networking. IaaS is the closest to a traditional on-premise environment, except Microsoft manages the underlying infrastructure, including hardware and the host operating system. You are still responsible for maintaining the guest operating system, however, including patching, monitoring, anti-virus software, and so on.
• Platform as a Service (PaaS): Azure App Service is an example of a PaaS component. With PaaS, you do not need to worry about the operating system (other than to ensure what you deploy to it is compatible). Microsoft manages all maintenance, patching, and anti-virus software; you simply deploy your applications to it. When provisioning PaaS components, you generally specify an amount and CPU and RAM, and your costs will be based on this.
• Serverless or Function as a Service (FaaS): FaaS, or serverless, is at the opposite end to IaaS. With FaaS, any notion of CPU, RAM, or management is completely abstracted away; you simply deploy your code, and the required resources are utilized to perform the task. Because of this, FaaS pricing models are calculated on exact usage, for example, the number of executions, as opposed to IaaS, where pricing is based on the specific RAM and CPU.

Some services may appear to blur the line between the hosting options; for example, VMs can be built as scale sets that automatically scale up and down on demand.

Generally, as you move from IaaS to FaaS, management becomes easier; however, control, flexibility, and portability are lost.

When choosing a compute hosting model for your solution, you will need to consider many factors:

• Deployment and compatibility

Not all applications can run on all services without modification. Older applications may have dependencies on installed services or can only be deployed via traditionally installed packages. For these legacy systems, an IaaS approach might be the only option.

Conversely, a modern application built using Agile DevOps processes, with regularly updated and redeployed components, might be better suited to Web Apps or Azure Functions.

• Support

Existing enterprise systems typically have support teams and processes embedded within the organization and will be used to patch and update systems in line with existing support processes.

Smaller companies may have fewer IT resources to provide these support tasks. Therefore, they would benefit significantly from PaaS or FaaS systems that do not require maintenance as the Azure platform handles this.

We will replace the key vault that used a client ID and secret in the following walk-through. This time, we will use an AzureServiceTokenProvider, which will use the assigned managed identity instead:

1. Open your web app in Visual Studio Code.
2. Open a Terminal window within Visual Studio Code and enter the following to install an additional NuGet package:
   dotnet add package Microsoft.Azure.Services.AppAuthentication
3. Open the Program.cs file and add the following using statements to the top of the page:
   using Microsoft.Azure.KeyVault;
   using Microsoft.Azure.Services.AppAuthentication;
   using Microsoft.Extensions.Configuration.AzureKeyVault;
4. Modify the CreateHostBuilder method as follows:
   public static IHostBuilder CreateHostBuilder(string[] args) =>
   Host.CreateDefaultBuilder(args)
   .ConfigureAppConfiguration((ctx, builder) =>
   {
   var azureServiceTokenProvider = new AzureServiceTokenProvider();
   var keyVaultClient = new KeyVaultClient(
   new KeyVaultClient .AuthenticationCallback(
   azureService TokenProvider.KeyVaultTokenCallback));
   builder.AddAzureKeyVault (“https://packtpubkeyvault01.vault.azure.net/”, new DefaultKeyVaultSecretManager());
   })
   .ConfigureWebHostDefaults(webBuilder =>
   {
   webBuilder.UseStartup();
   });
5. Open a Terminal window in Visual Studio Code to rebuild and republish the application by entering the following:
   dotnet build
   dotnet publish -c Release -o ./publish
6. Next, right-click the publish folder and select Deploy Web App.
7. Select your subscription and web app to deploy, too, when prompted.
8. Once deployed, browse to your website.

Your website is accessing the secret from the key vault as before; only this time, it is using the managed identity.

In this section, we have replaced a service principal with a managed identity. The use of managed identities offers a more secure way of connecting services as login details are never exposed.

Summary

This chapter covered three tools in Azure that can help secure our applications, particularly around managing data encryption keys and authentication between systems.

We looked at how to use key vaults for creating and managing secrets and keys and how we can then secure access to them using Access policies. We also looked at how we can use security principals and managed identities to secure our applications.

This chapter also concluded the Identity and Security requirement of the AZ-304 exam, looking at authentication, authorization, system governance, and application-level security.

Next, we will look at how we architect solutions around specific Azure infrastructure and storage components.

Exam Scenario

The solutions to the exam scenarios can be found at the end of the book.

Mega Corp plans a new internal web solution consisting of a frontend web app, multiple middle-tier API apps, and a SQL database.

The database’s data is highly sensitive, and the leadership team is concerned that providing database connection strings to the developers would compromise data protection laws and industry compliance regulations.

Part of the application includes the storage of documents in a Blob Storage account; however, the leadership team is not comfortable with Microsoft managing the encryption keys.

As this is an internal application, authentication needs to be integrated into the existing Active Directory. Also, each of the middle-tier services needs to know who the logged-in user is at all times – in other words, any authentication mechanism needs to pass through all layers of the system.

Design a solution that will alleviate the company’s security concerns but still provides a robust application.

In the previous section, we looked at working with security principals that can provide programmatic access to key vaults from our applications. There are a couple of problems with them – you must generate and provide a client ID and secret, and you must manage the rotation of those secrets yourself.
Managed identities provides a similar access option but is fully managed by Azure – there is no need to generate IDs or passwords; you set the appropriate access through role-based access controls. The managed identity mechanism can also be used to provide access to the following:
• Azure Data Lake
• Azure SQL
• Azure Storage (Blobs and Queues)
• Azure Analysis Services
• Azure Event Hubs
• Azure Service Bus

We have the option of using either a system-assigned or user-assigned identity. System-assigned is the easiest route – and is ideal for simple scenarios – but they are tied to the resource in question – that is, a virtual machine or web app. User-assigned identities are discrete objects and can be assigned to multiple resources – this can be useful if your application uses numerous components to give them all the same managed identity.

As well as Web Apps and Virtual Machines, the following services can also be set to use managed identities:
• Azure Functions
• Azure Logic Apps
• Azure Kubernetes Service
• Azure Data Explorer
• Azure Data Factory

As with security principals, working through using a managed identity is the easiest way to understand it.

Assigning a managed identity

In the next example, we will modify the web app we created in the Working with security principals section to use a managed identity instead:

1. Navigate to the Azure portal at https://portal.azure.com.
2. In the top search bar, search for and select App Services.
3. Select your web app – for example, packtpub-secureapp.
4. On the left-hand menu, click Identity.
5. System assigned is the default identity type; set the status to On as in the following example:

Figure 6.18 – Setting the app identity

6. Click Save.
7. In the top search bar, search for and select Key vaults.
8. Click on your key vault.
9. On the left-hand menu, click Access policies.
10. Click Add Access Policy.
11. Click the drop-down list next to Configure from template and choose Secret Management.
12. Under Select Principal, click None selected. Search for the name of the web app you created earlier in Deploying a web app – in our example, packtpub-secureapp.
13. Click Add.
14. Click Save.

With the managed identity set up on our web app, and the necessary policy linked in our key vault, we can update our code to use the identity instead of the security principal.

To enable AD integration, we must first set a login redirect URI for our new website on the service principal we created earlier, and then configure the web app to use that principal:

1. Navigate to the Azure portal at https://portal.azure.com.
2. In the top search bar, search for and select Azure Active Directory.
3. On the left-hand menu, click App registrations.
4. Select the SecureWebApp registration.
5. On the left-hand menu, click Authentication.
6. Click + Add a Platform.
7. In the Configure Platforms window that appears, choose Web.
8. Paste in the URL from your web app into Redirect URIs and add the following to it: /.auth/login/aad/callback. In this example, the URI would be https://packtpub-secureapp.azurewebsites.net/.auth/login/aad/callback.
9. Click Configure.
10. Scroll down the page to Implicit grant, tick the ID tokens box, then click Save. The page should look like this:

Figure 6.16 – Setting app authentication

11. We now need to configure your app to use the app registration – in the top search bar, search for and select App Services.
12. Select your web app – for example, packtpub-secureapp.
13. On the left-hand menu, click Authentication/Authorization.
14. Set App Service Authentication to On.
15. Under Action to take when a request is not authenticated, choose Log in with Azure Active Directory.
16. Under Authentication Providers, click Active Directory.
17. On the next page, set the first Management mode option toExpress, and the second Management mode option to Select Existing AD App.
18. Click Azure AD App, and select the app registration we created in Creating the service principal in the Working with Security Principals section.
19. Click OK. The page should look like the following. Click Save.

Figure 6.17 – Setting authentication

Wait a few minutes for the changes to take effect, then browse to the web app; for example, https://packtpub-secureapp.azurewebsites.net. You will now be prompted to log in with your Active Directory account, and once authenticated, you will be directed back to your application. If you are not prompted to sign in, open a private browsing window instead, as your credentials may already be cached in the browser.

As you can see, integrating your application into your Azure Active Directory tenant is very easy and provides a secure and seamless login experience for your users.

The first half of this section involved using a security principal to access the key vault. service principals can be used to access many different services; however, they do rely on a client ID and secret being generated and shared.

Next, we will look at an alternative and more secure method of providing authenticated access to many Azure resources, called managed identities.