How The Cloud Is Changing Dev/Test

A few years ago, I was managing a team building out a project for a client. It was a pretty typical set of WCF services that exposed the client’s data to their partners. This client had adopted some sound approaches for hosting their services and letting them communicate with each other via differing protocols like TCP and HTTP, so their infrastructure needs for this project were a little complex.

As my team waited for the client’s IT department to provision the servers, set up the databases, establish the routing rules, create the accounts and install the software we’d need for development and QA, I decided to try to get my team productive sooner by using Microsoft’s Azure cloud platform. I logged in to the Azure portal with our MSDN account, provisioned a few virtual servers, set up some cloud firewall rules and published the solution from Visual Studio on my own machine. My fellow devs and testers could begin interacting with the services and databases right away. Eventually, when the client’s IT department was ready, we started using their infrastructure – after overcoming a few configuration glitches, which is not unheard of with manual provisioning. By jumping to the cloud as part of our development approach, we were able to get up and running a lot sooner.

I didn’t know it at the time, but I was dipping my toes into the world of dev/test in the cloud. I was really intrigued by the idea of using the cloud while creating software that may or may not eventually wind up being deployed to the cloud. So, I started researching the offerings and all the different needs of a software development team (especially an Agile one) and found that not only is dev/test in the cloud amazingly flexible and powerful, but it’s also relatively cheap and well integrated with a variety of development tools. Here are some of the reasons why I think that an organization’s use of the cloud for dev/test will give them a productivity (and competitive) edge:

The cloud is about self service

With the cloud, development teams have the ability to log into a portal and spin up just about anything needed in terms of virtual machines, from a single box with SQL Server and IIS to a set that includes a domain controller, a database server, an app server and a web server. There’s no waiting for IT to build up the environment and no dealing with complexities of having to isolate the environment while still keeping it accessible.

The cloud is about flexibility

Outside the cloud, if you need a database, you pretty much have to add one to an existing SQL Server instance, or build up your own instance. In the cloud, if you just want data services – that is, the ability to create tables, views and stored procs, and perform CRUD operations – you don’t have to bring up a VM with SQL Server on it, you can just use the Azure SQL Database service. Create an account in the service, log in, run a T-SQL script, set up those firewall rules, and you’ve got a data repository for testing your app (running either locally or in the cloud). If you’re actually using SQL Server features beyond data storage, like reporting services or integration services, then feel free to install a full version of SQL Server running on a VM in the cloud. You don’t even need to do your own install, because you can create VMs from templates in the Azure portal that already have one of several versions of SQL Server on them. Frontend tiers benefit greatly from the cloud’s flexibility. You can load up your web apps (Microsoft or other) on Azure web sites, or package them up as an Azure Cloud Service, or even go so far as to host your own IIS in a VM and deploy the app there.

The cloud is about repeatability

The best tests start from a known state. We have scripts that clean up old data or old files, or we restore a backup of a database. Because of the ability in the cloud to create a new VM from an image (either provided by Microsoft or one you create), it’s easy to start with that proverbial clean slate each time we need to run tests. Plus, storing the VM images in the cloud means starting from that clean slate is incredibly fast.

The cloud is about variety

Want to see how your app will perform on various operating systems with different patches? Bring up virtual machines to do that. Want to try your apps with a database in Oracle or MySQL instead of SQL Server? Bring one of those up, too. Load up VMs with different OSes and browsers and test web apps. For SharePoint developers, bringing up a SharePoint VM in the cloud (with or without Visual Studio on it) is a huge timesaver.

The cloud is about experimentation

If you want to check out the latest versions of SQL Server or Visual Studio, but don’t want to install them on your own VM or directly on your workstations, you’re in luck, because Microsoft’s product teams have put VMs in Azure that have the latest CTPs and betas of Visual Studio, so you can try out your projects in them, or just play around with the new features. There are also VMs that help you do a POC around a new feature coming in SQL Server 14.

The cloud is about automation

While interacting with all the cloud has to offer through a browser-based portal is great for getting started, at some point you’re going to want to automate things. Powershell and Azure can do some pretty amazing things together around spinning up and tearing down VMs, copying files around and gathering logs. Also, when you integrate TFS with Azure for continuous integration, you get some excellent results. This is only going to get better with new offerings like Azure Automation.

The cloud is about connectivity

Doing dev/test in the cloud doesn’t mean your app is isolated up there. With Azure’s Virtual Networking, you can connect those VMs with your local intranet and have them access internal systems and services to do the testing that you need.

The cloud is about economy

Who wants to invest in building out their own huge data center and having to manage that infrastructure, whether on premises or at a colocation facility? With dev/test in the cloud, you just pay for what you use. You can deploy a huge webfarm, run a bunch of load tests, then decommission those VMS and spend far less than you would on your own hardware and software licenses. And, if you do invest in your own infrastructure, when you move on to the next project, you’ve lost the test environment for the previous version of your project. Calling on the cloud when you need it means you won’t have lost the test environment for the old project, you’ve just left it dormant as a disk image and can bring it up when needed.

It’s worth considering that last point about economy in light of the fact that Microsoft made changes recently to Azure billing to really enable dev/test usage in the cloud. Scott Guthrie lists the changes in this blog post, but the two major ones to note are the free Azure credits that are included with various levels of MSDN subscriptions, and the drastically reduced rate for Azure compute time and other services.

Cloud based dev/test is not specific to Azure, but Microsoft has really led the pack here with not only billing incentives, but also other things like integration with Visual Studio and TFS. I think if you’re developing with Microsoft tools and technologies, going with Azure for dev/test is a natural option.