Chapter 3: Infrastructure Design

In this chapter, we will focus on infrastructure architecture with Azure. Here, we will review the different concerns that every infrastructure engineer and architect has to deal with on a daily basis. More specifically, we will cover the following topics:

• The Azure infrastructure architecture map
• Zooming in on networking
• Zooming in on monitoring
• Zooming in on high availability and disaster recovery
• Zooming in on backup and restore
• Zooming in on HPC
• The AKS Architecture Map and a reference architecture for microservices

We will provide a 360˚ view of what it means to build infrastructure with Azure, including the most common practices and pitfalls. We will also see how challenging it is to have a consistent and coherent disaster recovery approach by walking you through a concrete real-world use case on a globally distributed API offering. Last but not least, we will dedicate a good part of this chapter to...

Technical requirements

In this chapter, we will be using Microsoft Visio files. You will need Microsoft Visio to open the diagrams, although the corresponding PNGs are also provided.

The maps and diagrams used in this chapter are available at https://github.com/PacktPublishing/The-Azure-Cloud-Native-Architecture-Mapbook/tree/master/Chapter03.

The Azure infrastructure architecture map

The Azure infrastructure architecture map (as shown in Figure 3.1) is intended as your Azure infrastructure compass. It should help you to deal with the typical duties of an infrastructure architect, which we described in Chapter 1, Getting Started as an Azure Architect. Unlike the solution architecture map, which was more high-level, this map is a vertical exploration of infrastructure topics. It is by no means the holy grail, but it should help you to grasp the broad infrastructure landscape at a glance. Throughout this chapter, we will describe its various elements, and apply context using real-world implementations:

Figure 3.1 – The Azure infrastructure architecture map

Important note

To see the full Infrastructure Architecture Map (Figure 3.1), you can download the PDF file available at https://github.com/PacktPublishing/The-Azure-Cloud-Native-Architecture-Mapbook/blob/master/Chapter03/maps/Azure...

Zooming in on networking

Networking is one of the essential foundations of any Azure landing zone. Figure 3.2 shows the various connectivity options available in Azure:

Figure 3.2 – Zooming in on networking

We introduced the landing zone concept in Chapter 2, Solution Architecture. We briefly explained that the purpose of a landing zone is to structure, govern, and rule the Azure platform for the assets that will be hosted on it. Controlling network flows is one of the key governance aspects. Controlling the network means mastering internal and external traffic, inbound and outbound, flow logs, and so on. This is a vast topic and an important challenge. Let's now dive deeper. The network section has five top-level groups:

• DNS
• MOST COMMON ARCHITECTURE
• DC CONNECTIVITY
• ZONING
• ROUTING

In the DNS section of Figure 3.2, we see two DNS services, which are public and private DNS zones:

• Azure DNS zones help you...

Zooming in on monitoring

Figure 3.4 is the same as the one we had in Chapter 2, Solution Architecture. In this section, we will explain a typical approach to monitoring Azure applications with native tools. The usage of Splunk, or any other third party, is beyond the scope of the book:

Figure 3.4 – Zooming in on monitoring

When an application is deployed to Azure, we must do the following:

• Monitor the application events. This can be achieved with Application Insights. Note that very recently, Microsoft launched workspace-based Application Insights, which in a nutshell couples Azure Application Insights and Log Analytics together.
• Monitor the Azure services, health. This can be achieved by redirecting diagnostic logs to Log Analytics.
• Define alerts on standard metrics or specific diagnostic log events.

Firstly, it is important to distinguish between logs and metrics. Log data can be used to perform root-cause analysis of a...

Zooming in on high availability and disaster recovery

First of all, let's review the difference between high availability and disaster recovery and put that in the Azure context. A high availability (HA) solution is continuously available for a desired amount of time. In Azure, most HA solutions are scoped to a single geographical region.

Disaster recovery (DR) aims to recover from a severe incident, such as a fire (or flooding) in the data center, an earthquake, or any other type of heavy damage. In Azure, an example of a severe outage is the complete unavailability of an entire region, or of a service within a region. DR-compliant systems often rely on multiple regions, which incurs extra costs. Usually, a design that is DR-compliant is also HA.

Whether you design a solution for HA or DR depends on the expected recovery time objective (RTO) and recovery point objective (RPO) defined by the business or expected by your customers (if you provide the service). Figure 3.13...

Zooming in on backup and restore

Backup and restore processes are also part of the broader disaster recovery picture. However, you might end up with a corrupted database or accidental data deletion, even in a non-disaster situation:

Figure 3.16 – Zoom-in on backup and restore

Figure 3.16 is far from being comprehensive, but it should give you the key aspects to consider for a good backup and restore strategy. Figure 3.16 includes four top-level groups:

• NON-DB PAAS: This top-level group refers to managed services that are not related to database engines.
• ON-PREMISES/CLOUD VM: This is applicable to both on-premises and cloud-hosted virtual machines.
• STORAGE ACCOUNTS: AzCopy is usually used to push and pull data to/from storage accounts.
• PAAS DB: This top-level group relates to database-specific managed services.

We first distinguish database services from other PaaS services, because the way to back up and restore them is...

Zooming in on HPC

High-performance computing (HPC) is a pure infrastructure topic, because it boils down to bringing an unusual amount of compute and memory to a given workload. In general, HPC jobs are handled by dozens, hundreds, or even thousands of machines in parallel. Figure 3.17 shows most of the current Azure HPC landscape:

Figure 3.17 – Zoom-in on HPC

For memory-driven workloads, such as computational fluid dynamics (CFD), you may rely on HB-series virtual machines, which are bandwidth-optimized. For FLOPS-driven (short for floating-point operations per second) workloads, which require a fast and optimized CPU, you can rely on the HC series. If you are unsure of whether your workload is memory- or flops-driven, you might rely on Azure Cray, a supercomputer delivered as a managed service. When it comes to job scheduling and underlying infrastructure management, you can count on Azure Batch and Azure Cycle Cloud. Azure Batch is a fully managed...

AKS infrastructure

AKS is an entire world within the Azure universe. This is by no means a service like the others. It is a partly managed service, as shown in Figure 3.18.

Figure 3.18 – AKS, a semi-managed service

The control plane is the brain of AKS, and it is fully managed by Microsoft for free. Your duty as an Azure infrastructure architect is to take care of the worker nodes, which are plain virtual machines, connected to the brain via kubelet, the Kubernetes (K8s) primary node agent. It runs on each node, and the agent registers the node with the API server automatically. Rest assured, Azure comes with pre-defined node images, and you do not have to build the worker nodes yourself, just manage them. Although self-hosting a K8s cluster is even more demanding, you should not neglect the number of operations left to the cloud consumer when working with AKS. Unlike a fully managed PaaS or FaaS service, AKS requires special care and upfront analysis...

Summary

In this chapter, we did a vertical exploration of infrastructure practice in Azure. We covered several topics, such as networking, monitoring, backup and restore, high availability, and disaster recovery for both Azure itself and AKS. We made it clear that AKS is a special service that comes with its own practices and ecosystem. As an Azure infrastructure architect, you should pay special attention to AKS, whenever it lands on your plate. Our message here is this: yes, use AKS – but do not overlook its complexity and particularities.

In this chapter, we also explored two concrete use cases. The first one demonstrated how challenging (and costly) it can be to have a consistent and coherent disaster recovery strategy for a global API deployment. The second one was about using AKS for microservices. We explained why we think that AKS is more suitable than pure Azure-native services for large microservices implementations. We concluded with a reference architecture for...