The need to choose a target architecture

Just as important as understanding the platform that you are moving from, you have to have a clear vision of what your target platform needs to look like. In Azure, this target platform will be quite different from the legacy platform, mainly because it will all be virtual. The need to define a target architecture for your legacy workloads is the first step in laying the foundation of your virtual data center in the cloud. The compute, networking, storage, and other ancillary services need to be thought out and defined prescriptively in Azure if you wish to have a scalable and manageable environment. An example here might explain this concept.

In Azure, one of the fundamental containers for resources is an Azure subscription. One approach that some have used when defining their Azure environment is to create one subscription and then create all the necessary artifacts and assets within that subscription. There are some inherent problems with this approach when it comes to manageability and governance. On the opposite end of the spectrum, there is the approach of overusing subscriptions since they provide such a nice security and billing boundary. The correct approach lies somewhere in the middle. This is where Azure Landing Zones can be very useful.

Azure Landing Zones

We will discuss Azure Landing Zones later in this book, in Chapter 6. For now, it is good to know that an Azure Landing Zone (ALZ) allows the Azure architect to create a prescriptive architecture typically defined in an Azure Resource Manager (ARM) template. This approach allows for a scalable and modular implementation that is highly agile and can be deployed for different purposes. A good example is standing up a replica of production for QA testing or possible training.

There are essentially two types of landing zones:

• Platform Landing Zones, which are typically used to provide centralized services such as networking and identity. These services will be used by various workloads and applications.
• Application Landing Zones, which are typically application-specific and are used, for example, as a way to ensure that group policies are being applied correctly for a particular application group.

For this book, we will focus on Application Landing Zones as our intent will be to migrate legacy applications.

One of the first questions that needs to be answered when you are defining the target environment is, What are my target application containers? Should I use virtual machines, typically called Infrastructure as a Service (IaaS), Kubernetes, or the more cloud-native microservices? There are pros and cons to each.

Infrastructure as a Service (IaaS)

IaaS uses Azure Virtual Machines as the application container. VMs have been leveraged for years both on-premises and in the cloud. Virtual machines are a virtual definition and implementation of a physical machine and as such, they require an OS and application software. This means that they take more time to deploy and manage than, say, something such as Kubernetes. Having said that, virtual machines can be grouped in application clusters within Azure and can horizontally scale. We will dive into this later in Chapter 6.

Here is an example of an architecture for multiple Mainframe workloads migrated to Azure. You can see that the primary site is replicated to a paired region where Azure Site Recovery (ASR) keeps the application tier virtual machines in sync, while Microsoft SQL Server Always On provides fault tolerance for the data tier:

Figure 1.1 – High-level Azure architecture for legacy systems

Azure Kubernetes Service (AKS) and microservices

Microservices decompose the applications running on virtual machines into independent modules that are loosely coupled and distributed. The benefits are applications that are much more scalable and agile but also more complex to manage unless you have a managed service such as Kubernetes. In Azure, this service is called Azure Kubernetes Service (AKS) and provides a way to orchestrate and define relationships between components.

Azure Functions and Service Fabric

There are other deployment vehicles for microservices in Azure, such as Azure Functions and Service Fabric. They offer similar benefits with some variations. We will discuss these later in Chapter 6.

Now that we have looked at the need to define a target architecture, let’s understand the constraints.