Developing in the Cloud Using Azure Virtual Machines
As a consultant, I'm constantly moving. Moving from client to client, location to location and even computer to computer. This causes some headaches when maneuvering my work laptop. Most of what I do is published to the cloud, so why not develop in the cloud as well?
Using Azure Virtual Machines (VMs), I can create an instance in the cloud, remote-desktop into it and configure it to my project. This gives me incredible flexibility as to when and how I develop. If I'm at home, I simply connect. If I'm at the office, I simply connect. If I'm on a client site — you guessed it — I simply connect. Keep in mind I'm connecting to the exact same environment and can even share that environment with others on my development team.
Supplying developers with workstations for development has long been the only viable approach for many companies. The inherent cost of the hardware with specifications to handle development has always been a concern, and slow machines can cost your developers time — which directly relates to money.
The benefits of developing in the cloud can vary depending on your application. Here I'll provide some of the common scenarios we face while consulting for our clients:
- Client infrastructure
Oftentimes, clients either have a small development team or none at all. In these situations, it's common for a team to run the development effort from their local machines and commit code to a central source code repository. While this approach is valid, problems often arise after the engagement is complete.
What if future application enhancements are needed? Or a bug is found months after the site is launched? All the effort that went into configuring that development environment could be lost. We could have a dedicated machine the client maintains, but this option has several disadvantages. First, I have to coordinate time to go back to the client to get the machine, increasing the latency of my response. Second, the client has to store an asset on the possibility that we'll need it in the future. If an Azure VM was created for development, we would simply start it and connect, all of which could be done remotely.
- Developer image
Azure offers a gallery of virtual machine images that include Visual Studio pre-installed, which is usually a great start to building out your own image. A nice benefit is the ability to configure the environment for your development team's need and save off an image. This will create a snapshot that can be used as a starting point for onboarding a new developer. I can't tell you how many clients I've encountered that take more than a week to get me set up with hardware. That initial delay can have a huge cost impact before the project even gets moving.
Just as we may need to scale up a deployed application, the same need may occur on our development machine. This scaling of a machine is nothing new but typically requires going to internal IT, requesting more memory or disk space, and could, in some cases, take weeks, depending on the organization and its processes. With Azure, this can be accomplished with a few clicks and less than 10 minutes of provisioning time.
Just as an instance can be scaled up, it can be scaled back down. One client pulled me into a digital asset manager evaluation for several vendors. Running these on my machine was taxing, so I simply increased the CPU/memory of my instance for the week I was doing the evaluation. The overall cost was far less than that of the time it would have taken to swap out the memory, not to mention the cost of the memory itself.
- ISP throughput
A commonly overlooked benefit of using an Azure Virtual Machine is throughput. I've found that the download/upload speeds of my Azure Virtual Machines far exceed even my business connection in the office. While there's no claim to speed by Microsoft, I routinely see download speeds north of 200 Mbps and upload speeds up to 50 Mbps. You'll still need an Internet Service Provider (ISP) to get you connected to the virtual machine itself, but your day-to-day tasks (checking in code, downloading designer resources, etc.) are all performed in your VM and benefit from its throughput.
- Remote access
The ability to remotely connect to my development environment opens several options for me. Quite simply, I can access my development environment from any machine that has an internet connection. The fact that I can leave my workstation in my office, drive home and then immediately connect is very powerful.
- MSDN users
If you have an individual Microsoft Developer Network (MSDN) subscription, you're provided a credit of up to $150/month depending on your subscription level. You also enjoy the same low MSDN usage rates, which are exclusively available for MSDN subscribers.
How do we actually get started? Head on over to the Azure Portal and click the Marketplace tile from the dashboard.
Select Virtual Machines and search for Visual Studio 2013.
We can select the template we like. In this case, it's Windows Server 2013 with Visual Studio Community 2013 pre-installed.
Click Create to bring up the creation wizard where we'll enter:
- The host name of the virtual machine
- The username and password to log in to the machine
- The pricing tier, which is basically just the number of cores, number of disks and amount of memory
- The data center to host the virtual machine
Once created, the instance will start to be provisioned. This can take up to 10 minutes (or more, depending on the image used).
Connecting to the virtual machine
Once the virtual machine has been provisioned, we can connect to it. On the Azure Dashboard, click on the tile for our VM.
At the top of the page, we click Connect, which will download the .rdp Remote Desktop Protocol file.
Once the file downloads, click on it and enter your credentials.
Now we're logged in to the remote desktop session and can work as we normally would.
- Port blocked
Some organizations will block ports, causing issues with connecting to your Azure VM. One simple way to overcome this is to update the Remote Desktop public port to use 443 (typically reserved for HTTPS).
Leaving a VM on when it's not being used will drive up your day-to-day costs. It's important to shut down the VM when not in use. You'll still be charged for the disk storage, but this is far less than the running VM. One way to automate this is to use Azure Automation Services to turn your VM on/off at specific times. You can read more about this in the Get Started With Service Management Automation: Walkthrough Guide.
Hosting your development environment in an Azure Virtual Machine may be a cost-effective way for your team to develop in a more flexible manner. The increased cost of the Azure instance is easily offset by the hardware costs of running a beefy developer machine, operating system licensing and data redundancy if the VM hard drive fails.