The course is part of these learning paths
Overview of the course
What is a Virtual Machine?
Creating and Connecting to Azure VMs
Scaling Azure Virtual Machines
Design and Implement VM Storage
Configure Monitoring & Alerts for Azure VMs
Azure Resource Manager Virtual Machines
Virtual Machines are a very foundational and fundamental resource in Cloud Computing. Deploying virtual machines gives you more flexibility and control over your cloud infrastructure and services, however, it also means you have more responsibility to maintain and configure these resources. This course gives you an overview of why use virtual machines as well as how to create, configure, and monitor VMs in Azure Resource Manager.
Azure Resource Manager Virtual Machines: What You'll Learn
|Lesson||What you'll learn|
|Overview||Overview of the course and the Learning Objectives|
|What is a Virtual Machine?||Understand what are Azure Virtual Machines and what workloads are ideal for VMs|
|Creating and Connecting to Azure VMs||Learn to deploy Windows and Linux VMs as well as how to connect to these VMs|
|Scaling Azure Virtual Machines||Understand VM scaling, load-balancing, and Availability Sets in Azure Resource Manager|
|Configuration Management||Understand the basic concepts of Desired State Configuration and the options available to Azure VMs|
|Design and Implement VM Storage||Gain an understanding of the underlying Storage options available to VMs as well as Encryption|
|Configure Monitoring & Alerts for Azure VMs||Learn to monitor VMs in Azure Resource Manager as well as configure alerts.|
|Summary||Course summary and conclusion|
Thus far we’ve been creating virtual machines using the Azure Resource Manager deployment model which we call ARM for short. The legacy deployment model is often referred to as “Classic” which is part of the Azure Service Manager (ASM) which you may think of as Azure v1. Many people also associate the “Classic” model with the old portal, manage.windowsazure.com and the ARM model with the new portal, portal.azure.com. It’s true, that while most people using ARM use the new portal, you can actually access “Classic” model resources from the new Portal, but this is just more for backwards compatibility.
But I want to take a step back for a second and discuss a few high-level differences between the ARM and “Classic” deployment models.
To help illustrate the differences I reference the architecture images directly from the Microsoft documentation
As you can see in the Classic deployment model, virtual machines live in what’s called a “Cloud Service.” Thus far in our ARM VMs we’ve connected to the Public IP of the VM itself, however in the “Classic” model we have to connect over the internet to the Public IP or “VIP” (Virtual IP) of the Cloud Service such as RDP port 3389. However the cloud service uses Network Address Translation (NAT) to reference a random non well-known port and translates that port to the appropriate VM and the actual port 3389. In “Classic” terminology you configure “Endpoints” which are Inbound NAT Rules configured on the External Load balancers to connect to specific ports on a Cloud Service and thus a VM. This is similar to the Network Security Group or NSG rule we created for our ARM VM.
Another major drawback in the “Classic” model is that you had to create the Virtual Network first before you created the VM, because you could not move a VM which already exist in a Cloud Service to different virtual networks. You have to have this worked out upon creation of the VM, else you would have to rebuild the VM in order to put it on the virtual network. The storage account where the OS disks are created follow similar architecture to that of ARM VMs.
This is a diagram of the ARM VM Architecture. One advantage we can immediately see in this architecture is that resources are now separated into different components which allows us the ability to build each component separately and mix and match these components without being tied to a specific Cloud service for example. When talking about the smaller components we often referred to these as “Resources.” In ARM a “Resource Provider” or RP is responsible for providing the appropriate resource. So in this diagram we have SRP, CRP, and NRP for the Storage, Compute, and Network Resource Providers respectively.
In ARM the Cloud Service we saw in the “Classic” model is replaced with a Network Interface Card or “NIC.” We can further break this down and create a Public IP address as a separate resource on its own for which we can then associate to any NIC. We may then associate a NIC to any VM. NICs can also have Private IP addresses just like the VMs we’ve created which are connected to a Virtual Network as you can see from the square block in the center of the diagram. NICs can also serve as endpoints for load balancer backends, etc.
The Storage Account can be created as a standalone resource as well. In this diagram we see that two different VMs are using the same storage account for their disks. Finally, you’ll notice the “cube” icon in the bottom-right. This is the same icon used in the Azure Portal to refer to what’s called a “Resource Group” which is a logical collection of resources with ARM. In this case, all the resources in the diagram live within the same Resource Group. This can make it easier to manage such as deleting all the resources by simply deleting the Resource Group.
About the Author
Chris has over 15 years of experience working with top IT Enterprise businesses. Having worked at Google helping to launch Gmail, YouTube, Maps and more and most recently at Microsoft working directly with Microsoft Azure for both Commercial and Public Sectors, Chris brings a wealth of knowledge and experience to the team in architecting complex solutions and advanced troubleshooting techniques. He holds several Microsoft Certifications including Azure Certifications.
In his spare time, Chris enjoys movies, gaming, outdoor activities, and Brazilian Jiu-Jitsu.