Cloud Comparison: CloudShare Labs vs. Azure Dev/Test VMs

Over the next few weeks, we will discuss CloudShare’s place in the cloud. Our goal is to sharpen the contradictions among these platforms, explain the benefits of virtual labs and highlight CloudShare’s unique features. First, let’s compare Azure dev/test VMs to virtual lab management in CloudShare.

Virtual Lab Management at Works vs. Azure Virtual Machines

CloudShare’s goal is to automate the complex, rote tasks that trap developers, testers and IT professionals in technological “red tape.” For Microsoft pros, “red tape” takes many forms — testing Active Directory, connecting Office 365 environments with existing Exchange servers, or setting up any version of SharePoint.

While completing a few of these end-to-end set-ups can be a great learning experience – and an opportunity to gain credibility on TechNet and StackOverflow – rebuilding systems for each code tweak or client request is a waste of time. Not only does the learning curve flatten to boredom, but the user, client or prospect experiences no benefit.

With CloudShare, there is no need to build and configure, then, rebuild and reconfigure – this repetitive work is automated. The system builds an environment of VMs, networks, and any uploaded tools or appliances. Once it’s configured, the user saves the set-up, and it can be spun up and down with a click or an API call. There is no waiting on IT for servers or digging through blogs for arcane permission rules, roles and configurations. It’s lab management that works.

For many of our users on the Microsoft stack, this is old news. But for IT pros who are new to Cloudshare, “automation” the ubiquity of cloud (marketing) can make it difficult to understand the diffrences. Moreover, since “cloud” often means “Azure” to Microsoft pros, the question often arises: “How are you different from Azure?”

First, what is Azure? Originally a platform as a service connecting primarily to Microsoft services, Azure now offers virtual machines through Azure IaaS on Hyper-V. As the “service” in Microsoft’s now-retired “devices and services” mantra, Azure is meant to handle many use cases – mobile back-ends, storage, hosting, load testing and as of summer 2012, provisioning VMs. It is an all-in-one “integrated system” at least within its own capabilities and the limits of Microsoft tools.

The problem with “integrated systems” is that they are rarely best in class for any particular use case. Consider a transit system and an automobile. Both serve the same need, but modern transport “users” would never confuse the two or think twice about the differences. The automobile is the best tool when you need to get somewhere; that is its design. Mass transit systems are designed to move people, but the real benefit of the large scale system is that it connect many different riders, schedules, and methods of transportation. This allows the system to compete, often on price, with slower, less efficient service than a car or a bike. Azure has the ambitious goals of a private utility – e.g. “ubiquitous computing” – and large scale. However, it is not a best-in-class tool for development and testing labs.

Testing requires building, copying and sharing full environments that spin up and down for each new test. CloudShare’s snapshotting and cloning abilities make this simple to manage. While the Azure Portal and Powershell provide tools that can be used to create full application environments, they cannot be cloned while running, copied and saved into a blueprint library. They must be spun down, saved to disk, and then rebooted. For a testing team that needs a virtual lab, this is not a best-in-class solution.

Next week, we’ll cover cloud costs how certain features of a virtual lab – primarily policies and suspension – make it a powerful testing service, but often more cost effective than general purpose IaaS.