In my last post, I discussed the reasons that speak for Microsoft Azure as a testing platform. Today, I will talk about a few downsides of running a lab in Azure.

Of course, there always is the other side of the coin. The cloud has its disadvantages, although things are a bit different here between production systems and a test environment. For instance, security, which is one of the major concerns of moving production systems to the public cloud, is probably not an issue when it comes to testing software. But let’s have a look at the downsides of running your test environment in Azure.

Windows 8.1 in Microsoft Azure

Windows 8.1 in Microsoft Azure

Testing experience ^

A remote desktop always feels different from a local desktop. Since “remote” comes in degrees, your “testing experience” will depend on how remote Azure is from your location. If your bandwidth to the next Azure datacenter is low, running your lab in the cloud won’t be much fun.

The good thing about the cloud is that you can easily test if your connection is good enough without having to invest a lot money. You can simply launch a virtual machine in Azure and see how it feels to work on a remote machine.

Local convenience ^

However, even if you have a sufficiently fast connection to Azure, you will notice differences from your local lab. If your current lab consists solely of a PC in your office where you run virtualization software, such as VMware Workstation or Oracle VirtualBox, you will miss the direct access to your virtual machines.

For instance, you can just drag files from your host machine to your VMs, and you can easily access all your local ISO files. Of course, you can always copy your files to the cloud. However, depending on your bandwidth to Azure, you could experience delays and you might miss the convenience of accessing local files.

If your on-prem lab isn’t in your office and you have to access it anyway through RDP, you probably won’t notice a difference from a cloud lab provided your connection is fast enough.

Local resources ^

Whereas copying all your software to the cloud is perhaps just inconvenient, you sometimes will need resources that are unavailable in the cloud. For instance, you can’t (easily) access printers, scanners, and other devices that you have to connect physically to your test machines.

This problem also applies to some software resources. Perhaps you want to connect your lab to your production Active Directory to run a realistic test, or you need some backend applications that you can’t just replicate to the cloud.

In theory, you might manage to connect to some of these resources from the cloud through VPN. However, in many cases, you will feel that doing so is overkill for just running a relatively simple test.

Boot-up speed ^

Perhaps you think that running a Windows client on high-end servers in Azure is always faster than on a simple PC. Whereas you can always tune the performance by launching a bigger virtual machine in Azure, you have no influence on the boot-up speed. In my test, a Windows 8.1 virtual machine with 1.75GB of RAM required about three minutes to boot up. On my laptop, a comparable virtual machine required 15 seconds to start under VirtualBox.

Yes, say that three minutes is not much, and you probably won’t be in a hurry when you launch a test system. However, I noticed that I often prefer to launch a local virtual machine because it is almost instantly available. Three minutes can be long if you want to quickly try something.

You already guessed that my laptop uses an SSD, whereas the Azure VM probably runs on HDDs. Thus, if your on-prem lab also runs on HDDs, you might not notice much of a difference with Azure. And things will look different if you have to launch more than just a VM for your test. The more VMs you have to start simultaneously, the faster Azure will be compared to your on-prem lab. Thus, I could also have listed the boot-up speed under the “advantages” heading of my last post.

Cloning and snapshots ^

By nature, tests are run because one doesn’t really know what one is doing. This is the reason why you need to run a test—to ensure that your production system is not affected if you mess things up. But destroying your test environment with a wrong click or a buggy PowerShell script can be painful, too, if you have to start from scratch and rebuild your test environment. Perhaps the main advantage of testing in a virtual environment is that you can capture the current state of all your systems and then proceed with a risky move.

You can, of course, capture virtual machines in Azure and store them in a new image. However, you can’t really compare the Azure capture functionality with the sophisticated cloning and snapshot features of virtualization solutions such as VMware Workstation or Oracle VirtualBox. The main difference is that, if you clone a VM, you create a complete copy of the VM with all its virtual hardware settings, whereas in Azure you only create an image that you can then use to create a new VM. But then you have to launch the VM creation wizard again and fill out all the settings. By contrast, if you arrive at a critical point, you can create linked clones or snapshots of all your test systems within seconds, and going back to a previous state can be accomplished with a few clicks.

Note that you can also create blob snapshots in Azure with the Start-AzureStorageBlobCopy cmdlet. However, in my view, this cmdlet is mostly for creating backup scripts and is not really suitable for quickly restoring a previous state in a test environment. Things might look a bit different, though, if your test environment consists of a very large number of virtual machines. A PowerShell script that restores all the virtual machines to their previous state is faster than doing this manually through the GUI of your virtualization tool (provided that your on-prem lab has the resources to run large test environments).

Also note that, in the future, another option could be the new Azure Site Recovery service, which is currently only available as a preview.

Limited operating systems ^

As mentioned in my last post, the only Windows clients you can run in Azure are the 64-bit versions of Windows 7 and Windows 8.1. If you want to test 32-bit Windows clients as well as Enterprise editions, and older Windows versions such as Windows Vista or Windows XP, a lab in Azure is not for you. The situation is similar for server operating systems. Azure only supports Windows Server 2012 R2 Datacenter, Windows Server 2012 Datacenter, and Windows Server 2008 R2 SP1.

Conclusion ^

Running your lab in the cloud has advantages and disadvantages, and deciding which solution is better for you depends very much on the kind of tests you are running. In general, if you often test with many virtual machines, the cloud might be the better option. However, if your test environment is small enough to run your tests with a virtualization tool on your desktop, an on-prem lab will be more convenient and flexible. However, this is not a one-way-or-the-other decision. The nice thing about the cloud is that you can just use it when you really need it without having to make an upfront investment. Thus, you can just launch a lab in Azure whenever your on-prem lab is not powerful enough to run your test.

In my view, Microsoft turns away quite a few potential Azure customers. Testing has always played an important role in the cloud. Many users of Amazon’s cloud—Azure’s main competitor—are running their labs in AWS. However, Amazon’s focus is still on Linux, which is essentially why any Linux distro is available in AWS. If Redmond offered the same variety of Windows editions in Azure, many organizations that, until now, had no interest in the cloud would have a closer look. Running a lab in the cloud is without risk and can be accomplished quickly. If those new users notice how efficient the cloud is, they are more likely to move their production systems to the cloud. Thus, Microsoft’s first step should be to offer Windows clients not just for MSDN subscribers but for any paying customers who want to run a lab in Azure. In addition, features such as linked clones and convenient snapshot creation would certainly attract more curious admins.


Leave a reply

Your email address will not be published.


© 4sysops 2006 - 2022


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account