I hope you enjoyed learning about Azure’s compute services. Let’s do a quick review of what you learned. 

You can put an application’s VMs into availability sets to help it survive both planned and unplanned outages. An availability set lets you configure the number of update domains and fault domains. 

Update domains put virtual machines into groups where the VMs will be rebooted at the same time. By default, your VMs will be put into 5 update domains, but you can set it to anything between 2 and 20. 

To survive unplanned outages, put VMs into fault domains. The maximum number of fault domains is either 2 or 3, depending on the region. Fault domains are physically isolated from each other, but they’re still within the same datacenter, so they won’t protect you against a datacenter failure.

Availability zones are an alternative to availability sets. An availability zone is a physically separate zone within an Azure region. Putting VMs in separate availability zones will protect you against a datacenter failure. 

To protect against a regional failure, you need to use multiple regions. When choosing a backup region, you should take into account regional pairs because Microsoft tries to ensure that at least one region in each pair is available. 

To scale an application, you can use vertical scaling, which means to use bigger VMs, or horizontal scaling, which means to use more VMs. With a scale set, you can set metrics to autoscale the number of VMs in the set.  A regional scale set is deployed across availability zones, so it provides a high level of both scalability and availability.

Azure IaaS VM Backup only backs up Azure VMs. The Azure Backup Agent supports both cloud-based and local VMs, as well as physical servers. However, it only supports Windows, and you have to install the agent on every virtual and physical machine you want backed up. Both of these products store their backups in a Recovery Services vault.

System Center DPM and Azure Backup Server can back up anything except Oracle. They can store their backups in a Recovery Services vault or locally attached disk. System Center DPM can also store them locally on tape.

To apply a backup policy to a large number of VMs, it’s easiest to do it from a Recovery Services vault.

The Site Recovery service supports three failover scenarios: Azure to Azure, on-premises to Azure, and on-premises to secondary site. To support physical or VMware servers, you need a Configuration server, a Process server, and a master target server. You also need to install a Mobility service on each server that needs to be replicated. To support Hyper-V, you install the Azure Site Recovery Provider and Recovery Services agent on each Hyper-V host or cluster node. In the event of an outage, you have 6 different options for which recovery point to failover to. Latest is the default.

Microsoft’s primary serverless offering is Azure Functions. It’s event-driven and it’s invoked using a trigger that you specify. Inputs and outputs are configured with bindings. Durable Functions is an extension that lets you create orchestrator functions.

Azure Logic Apps is simpler than Azure Functions and it doesn’t require you to write any code. It’s also invoked using triggers.

To implement a microservices architecture, you need to use containers. Azure Container Instances is not really suitable unless you have very simple requirements. Instead, you should use either Azure Kubernetes Service or Azure Service Fabric.

Azure API Management acts as a gateway between clients and microservices. It also handles management tasks like security, monitoring, analytics, and rate limiting.

To deploy a web application that doesn’t have a microservices architecture, Azure App Service Web Apps is usually the best choice. One useful feature is deployment slots. You can have multiple versions of your app in different slots and then swap your staging slot with your production slot when you’re ready. 

Three typical ways to increase the performance of a web app are scaling, caching, and using an edge network. You can configure App Service to autoscale based on metrics and schedules. For caching, you can use Azure Redis Cache. To serve static content to users in different geographic regions, you can use a content delivery network.

To make a web app highly available, deploy a standby copy in the paired region. Use Azure Traffic Manager to handle routing during a failover.

If your web app needs more than 20 instances or instances with a high memory-to-CPU ratio or secure network isolation, then you can use the Isolated service tier.

You can host a web API by creating an API App in Azure App Service. To secure the API, use Azure Active Directory. You can use AAD alone or use the AAD B2C service, which is designed for customer-facing web and mobile apps. You can also use the API Management service as a gateway to your API.

Azure Batch is usually the best way to run HPC applications. To use it, you upload the application and data files to Azure Storage, create a pool of compute nodes, create a job, and add tasks to the job. In many cases, you can use low-priority VMs to save money. 

Now you know how to design Azure solutions using virtual machines, serverless computing, and microservices; design web solutions using Azure App Service; and run compute-intensive applications using Azure Batch.

Please give this course a rating, and if you have any questions or comments, please let us know. Thanks!