Operating virtual systems in the cloud?!

The last instalment in my blog series checked out a few hybrid approaches. They included using virtual machines in Azure to balance load peaks. My musings were entitled “Does it have to be the whole cloud?” Of course it doesn’t, but sometimes it just makes sense. Anyone looking to shed some light on the topic of virtual machines in Azure will sooner or later come across some recurring terms and concepts. So let’s use this blog article to approach the topic systematically and explain what it’s all about.

Virtual machines are part of the Infrastructure as a Service solutions in Azure. Essentially there is no substantial difference between virtual systems in Azure and others that are hosted in a company’s dedicated datacenter (DC). They all come with a certain set of hardware (CPU, RAM, HDD, network) and an operating system. But virtual machines running in Azure are rigorously standardized in order to optimize resources and costs. The VM classes created in this way define clear limits for available resources.

Any blanket assumption that operating virtual machines in Azure will lead to cost savings is likely to be erroneous. Costs are incurred through running a VM in Azure just the same as in a dedicated DC.

But the cloud VMs do have one substantial advantage compared with their on-premises siblings: They only incur costs when they are actually in operation. That precisely is the added value of cloud-based virtual machines in a nutshell. It is, for instance, conceivable to reduce an Azure-hosted remote desktop farm to a minimum number of servers during the nighttime hours, and only to run the ‘full’ farm with its commensurate costs during the day. Equally, it would be entirely possible to dynamically adjust the VM capacities and hence to respond actively to the fluctuating performance and resource requirements. In this way, virtual machines with a lot of computing power or main memory will only incur costs when they are actually needed.

It is this flexibility that makes virtual machines operated in Azure so valuable. What’s more, one’s own hardware gear can be left entirely out of the equation when running virtual machines. New requirements can be accommodated flexibly and without delay at any time (by procurement and implementation).

Operating test or development systems is the ideal scenario in which to use Azure VMs, as the initial benefits are immediately apparent even on a basic level: Cloud solutions provide a simple and cost-efficient alternative wherever consultants or IT specialists would otherwise need notebooks with sufficient local resources to run test and development systems in mobile environments as well.

The practically unlimited resources mean that even large test and development environments can be provided with reliable mobile availability. Moreover, new tests or provisioning are available for deployment in Azure even on short notice. This consigns to history the internal processes used so far that have tended to make tests and development sluggish and inefficient.

In addition, test or development systems differ from productive systems, as they are not required 24 hours a day. In most cases it will be perfectly sufficient to ensure system availability during the core work times. Proceeding in this way reduces costs and enables efficient testing.

The question of availability is a key issue for the provisioning of virtual machines in Azure. It is necessary to understand how datacenters are structured and where VMs are positioned in order to shed additional light on this aspect.

Fault and update domains have an important role to play in the operation of virtual machines in Azure. Here, fault domains describe systems with identical dependencies such as power supply, network access or server racks. Update domains are systems in which the same maintenance cycle – for instance identical patching – is applied. There are several fault and update domains in each Azure region.

Please bear in mind that systems running within the same fault and/or update domain may under certain circumstances experience simultaneous outage!

This is why SLAs are not provided in any form for individual VMs running in Azure. At least two virtual machines must be operated within one availability group in order to receive guaranteed availability. In this respect, the system will be set up to ensure that VMs offering the same service are operated on hosts with varying maintenance windows and in different DC regions. This way there will always be at least one virtual machine that remains up and running within the availability group.

There are several templates available in the Azure Catalog for the provisioning of virtual machines. The templates are actually VM images that Microsoft updates regularly. They include Windows Server operating systems or also Ubuntu or CentOS.

Besides the provisioning of virtual machines based on Catalog templates, there is also an option to work with images or VMs that users create themselves.

First of all, 1:1 migration of a virtual machine previously used on premises for operation in Azure is possible. Here, the local VHD file is transferred to an Azure storage account where it can be launched using an Azure VM.

There is another method of storing your own VM images in the Catalog. Here the virtual machine and all of its settings can be prepared in a local environment. The system is sysprepped and a valid image is created once all of the configurations are complete. Afterwards this image is uploaded to Azure and used to create new VMs.

A cloud-based method to create images or for VM mobility does exist alongside its hybrid cousins. It involves provisioning a virtual machine with suitable, prior configuration in Azure. VM capture is a method of transferring this kind of virtual machine to your own image catalog, where it can be used in turn to create new VMs.

Azure virtual machines as integral elements in an IaaS solution by Microsoft can be deployed flexibly and are only billed according to their actual use. This produces numerous scenarios in which dynamic modifications/provisioning can lead to noticeable cost savings. But all the different scenarios have one thing in common: The hardware and suchlike can be left out of the equation, and users will only have to focus on what really counts – the virtual machines.