This course covers the Architect An Azure Compute Infrastructure part of the 70-534 exam, which is worth 10 - 15% of the exam. The intent of the course is to help fill in an knowledge gaps that you might have, and help to prepare you for the exam.
Welcome back. In this lesson, we'll talk about virtual machines, specifically virtual machine sizes, creating virtual machines and understanding images.
Azure virtual machines are what's known as Infrastructure as a Service or IaaS. Virtual machines give you full control over the software that you want to run by providing you with virtualized hardware that you can use to run the operating system of your choice.
Let's have a quick look at a typical Infrastructure as a Service configuration. An Infrastructure as a Service offering will provide you with a virtual machine and an operation system, and then optionally, some pre-installed software on top of that. A key benefit of Infrastructure as a Service is that you have total control of the software that runs on the VM. You can customize the software running on it just the same as you would with a physical server.
VMs are useful for situations where there's no ready-made Azure service offering, and that includes things like using a VM to run SSAS, RavenDB, Kafka or really anything else that isn't already a managed Azure service. VMs work well for porting an existing bespoke application to the cloud without re-architecting it, and that's what's referred to as lift and shift.
Just like physical servers, VMs have a lot of potential value for different workloads. One of the key features of virtual machines in Azure is the ability to scale the size of the virtual machine up and down quite easily. This is useful for handling increased demand on the VM. You can scale up, also known as vertical scaling, by increasing the capacity of the VM, and this is done by changing the size of the VM.
Resizing a VM allows you to change its performance. For example, if you start out with a DS1 V2, you'll have a one-core CPU, 3.5 gigs of storage, and 3,200 max IOPS. If you change the size to a DS2 V2, you'll double those numbers.
The size of the virtual machine also impacts the cost. Actually, the guest operating system also impacts the cost. Linux and Windows VMs with the same hardware configuration will have different prices. The price that you see in the portal is based on the per-month price. However, you're actually only billed per minute of execution.
And speaking of pricing, there's two pricing tiers. There's the basic and standard, and the basic tier are for machines that are in development stage, testing and maybe simple production environments. The standard tier is for production machines and offers load balancing and autoscaling.
In addition to pricing tiers, there are also different categories of machines, referred to as machine series, which combine different classes of CPU, memory, graphics and IO.
Let's do a quick rundown of these different series. First up is the general purpose, which has a balanced CPU-to-memory ratio. Now these are going to be ideal for testing and development, small to medium databases and maybe web servers with low to medium traffic.
Next up is the compute optimized, which provide a high CPU-to-memory ratio. Now these tend to be useful for medium traffic web servers, network appliances, batch processing and application servers.
Then we have the memory optimized, which have a high memory-to-core ratio. It's great for relational database servers, medium to large caches and in-memory analytics.
Next up are the GPU series, which are specialized VMs targeted for heavy graphics rendering and video editing. And they're available with single or multiple GPUs.
And then finally there's the high-performance compute, which are VMs with the most powerful CPUs and optionally, high throughput network interfaces. So there are a lot of options when it comes to virtual machine resources.
All right, let's switch gears slightly to cover virtual hard disks. Azure virtual machines have two types of disks. They have operating system disks and data disks. Both are stored as blobs behind the scene in an Azure storage account. You can attach multiple disks to a specific virtual machine, and you can upload your own local virtual hard disk into Azure and connect it to the VM as well as a disk.
Data disks contain persistent data, so if a VM shutdown or restarted, that data is still preserved. In case of scaling or disaster recovery, where moving to another machine is necessary, those disks are going to be detached from that one machine and re-attached to the new machine behind the scenes, and that will persist your data.
Each disk has fixed performance levels, which are measured as input-output operations per second, which is often abbreviated as IOPS. Now typically each standard hard disk performs 500 IOPS, while some of the lower-end machines will use 300 IOPS disks. And while that measure is fixed, you can use multiple disks alongside each other and along with multiple threads or processes to increase IO performance. And that will distribute the work over multiple disks.
If you need to get better performance, you can also consider using premium storage, which uses solid-state disks, which are currently the default option when you create a new VM. When you create a VM, you can use prebuilt images from the Marketplace.
You can also use your own images. Now if you want to provide your own, it can be based on an existing Azure VM, or a local VM, and that allows you to create your own images and use them as a sort of template for new VMs.
Azure VM images come in two forms. There are specialized and generalized. A generalized VM contains an OS disk that's been generalized and needs to be provisioned during deployment time. What that means to be generalized is that for Windows images the sysprep has been run and for Linux VMs that you've run the WA agent.
Generalized images are kind of templates for making VMs based on that generalized image. Specialized images are meant to be a snapshot of a VM at a point in time. They're not meant to be clones that are mass deployed as a part of an application tier.
These are more like your OS on your laptop, so you might take a snapshot of it so you can roll back to a point in time, but you wouldn't clone it and then deploy that image to multiple systems. So having the ability to use generalized or specialized VMs will give you that flexibility when you're architecting different solutions.
Being able to instantiate VMs based on custom images is one of the best parts about VMs. It allows you to pre-install the supporting software for you application and use that generalized image as a template, and this is a fairly common thing to do.
Companies will create what they refer to as golden images, which contain everything needed to run their applications. Now in some cases these images contain the latest version of the application itself, and the images are versioned so that they can deploy and rollback as needed. Golden images are one way to approach getting your application installed on VMs and deployable.
However, there are other options, referred to as configuration management. And that's going to be the topic of the next lesson. So if you're ready to keep learning, then let's get started in the next lesson.
About the Author
Ben Lambert is a software engineer and was previously the lead author for DevOps and Microsoft Azure training content at Cloud Academy. His courses and learning paths covered Cloud Ecosystem technologies such as DC/OS, configuration management tools, and containers. As a software engineer, Ben’s experience includes building highly available web and mobile apps. When he’s not building software, he’s hiking, camping, or creating video games.