In my October 2013 article “Moving Testing to the Cloud: A Look at Windows Azure and CloudShare,” I wrote about the need to move lab environments to the cloud due to the withdrawal of Microsoft TechNet subscriber downloads, a service that, for a reasonable annual fee, IT administrators could use most Microsoft server and client products on on-premise servers for testing purposes.
Since summer 2013, I’ve been using both CloudShare and Microsoft Azure (formerly Windows Azure) to build test labs in the cloud, and thought I’d share my final conclusions with you.
If you are new to the concept of cloud computing, it might be worth briefly explaining exactly what Microsoft Azure and CloudShare are, and their intended uses.
Microsoft Azure is Microsoft’s cloud computing platform, a rival to Amazon’s EC2 cloud solution, providing organizations cloud access to servers running Windows or Linux, storage, Active Directory, and many other features that allow services to be created and scaled on demand. Azure is for production systems and isn’t geared specifically towards creating lab environments (although there is no reason why you can’t use it for that purpose).
CloudShare differs fundamentally from Azure in that it is for creating lab environments and sharing them amongst developers for testing purposes. It’s designed to be very easy to use and has a simpler pricing structure than Microsoft Azure. CloudShare isn’t for running production servers.
In my article, “Moving Testing to the Cloud: A Look at Windows Azure and CloudShare,” I noted that both Azure and CloudShare appeared to provide fast VM performance. After six months of use, I can safely say that Azure provides better performance than VMs running on CloudShare. While this is not based on any scientific measurement, it would make sense that VMs provisioned in Windows Azure are likely to perform better with a similar hardware configuration to their CloudShare counterparts due to the nature of the service Azure provides; i.e. for production servers with an SLA.
Azure networking and VM configuration is more advanced, enabling sophisticated test environments to be created. CloudShare subscriptions limit you to the amount of resources that can be assigned to your VMs. I found this limited was quickly reached with the basic subscription.
Microsoft Azure VMs can also communicate with servers not hosted on Azure, something that CloudShare is not designed to do. This enables you to test real-world scenarios in which Azure would be part of a production solution, such as when provisioning backup domain controllers in the cloud for your on-premise Active Directory.
Azure subscription plans allow you to upload your own virtual hard disk images, to run VMs with operating systems or images not provided natively. This may result in an unsupported scenario, but shouldn’t be too much of an issue for lab testing. CloudShare also provides this feature with Team Labs or enterprise subscriptions.
Related: Give Microsoft Azure a go with this free trial!
If you are looking for something that is quick and easy to set up, CloudShare takes the crown. One or more environments can be configured, containing VMs that can communicate with each other on a virtual network. VMs in each environment can be stopped or started together, which is handy to get you up and running quickly each morning. Networking is also simple to understand and configure, with support for static IP addresses.
CloudShare allows you to take snapshots of an entire environment to easily roll back to a previous configuration, something that is not supported in Azure. There is also a plugin for Visual Studio 2012 that provides developers with view and management capabilities without leaving VS.
Microsoft Azure has a much steeper learning curve, largely due to the more complex virtual networking and new concepts that you will need to understand. It’s ultimately worth the effort to learn how to use Azure, as even in simple scenarios the extra flexibility provided will be welcome to most system administrators.
Azure’s UI is also not as intuitive as CloudShare’s, and just the task of starting up several VMs can be a little frustrating. There is however one plus, and that is Azure’s PowerShell API. You can write simple PowerShell scripts to start up and manage VMs collectively or individually from a remote machine, amongst other management tasks.
CloudShare has a simple pricing structure, where you purchase a monthly subscription that permits you to use a number of resources and environments. You can be sure that there won’t be any nasty surprises because your lab was accidentally left on over the weekend. By default, CloudShare automatically shuts down each environment after a set period, which is great for the environment but bares no difference on your monthly bill.
Microsoft offers subscriptions and pay-as-you-go options for Azure. Your monthly costs will largely depend on the resources you use and whether CPUs and storage are allocated to the Azure infrastructure fabric when idle. In most cases, Azure VMs are not designed to be switched off and deallocated from the fabric. Even if a VM is powered off, you will incur charges – hardly ideal for lab testing. But with a few simple workarounds, you can power off VMs and deallocate any assigned resources to ensure you are not charged for compute time when your labs are not being used.
Despite CloudShare’s ease of use and ability to roll back environments to a previous state, unless your test environment is going to be quite limited, I recommend jumping in at the deep end and using Azure for your cloud lab. CloudShare is geared more toward creating lab environments for developers with no expertise required, rather than toward system administrators who need to test backend infrastructure configurations. Azure wins on speed, flexibility, and manageability, and while there is a learning curve involved, it will be worth the investment in the long term.