As a consultant I am 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? Utilizing Azure Virtual Machines I can create an instance in the cloud, RDP into it and configure it to my project. This gives me incredible flexibility as to when and how I develop. If I am at home I simply connect, if I am at the Cardinal office I simply connect, and if I am on a client site, you guessed it, I simply connect. Keep in mind that I am 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 will provide some of the common scenarios that we face at Cardinal while consulting for our clients.
- Client Infrastructure
Oftentimes clients either have a small development team or none at all. In these situations it is 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, the problems that often arise are 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 that 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 will 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 preinstalled which is usually a great start to building out your own image. A great 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 have been on that take over a week to get me setup 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 their 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. A client of mine recently 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 have found that the download/upload speeds of my Azure Virtual Machines far exceeds even my business connection in the office. While there is no claim to speed by Microsoft, I routinely see download speeds north of 200 Mbps and upload speeds up to 50 Mbps. While you will still need an ISP to get you connected to the Virtual Machine itself, your day to day tasks (checking in code, download 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 up 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 MSDN subscription, you are provided a monthly credit of up to $150/month depending on your subscription level. You also enjoy the same low MSDN usage rates and is exclusively available for MSDN subscribers.
How do we actually get started? Head on over to the Azure Portal here to get started.
Click the "Marketplace" tile from the dashboard.
From here we can select "Virtual Machines" and search for "Visual Studio 2013."
We can select the template that we like, in this case it is Windows Server 2013 with Visual Studio Community 2013 preinstalled.
Click "Create" to bring up the creation wizard where we will enter:
- The host name of the virtual machine
- The username and password to log into the machine
- The pricing tier which is basically just the number of cores, number of disks and the amount of memory
- The datacenter 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 we can click on the tile for our VM.
At the top of the page we click "Connect" which will download the .rdp file.
Once the file downloads we click on it and enter our credentials.
Now we are logged into to our Remote Desktop Session and can work as we normally would!
- Port Blocked
Some organizations will block ports causing you 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 is important to shut down the VM when not in use. You will 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 automatically 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 HW costs of running a beefy developer machine, OS licensing, and data redundancy if the VM hard drive fails.