(This post was originaly published on Matricis Blog)
Usually my posts are a lot more technical, but this time I decided to share an experience with Windows Azure that saved me a lot of headaches while saving my boss a bunch of money ;)
The Context
Here at Matricis, we often set up our development environments on virtual machines (VMs) witch we host on our internal infrastructure. We have several different development VM configurations, based on the technologies and versions needed. A big advantage to doing so is that if the required environment changes, we simply choose the corresponding VM template. For the project I'm about to talk about, we needed quite a powerful development system, especially since every developer required Visual Studio 2012, SharePoint Foundation 2013, SQL Server, ADFS, and a handful of other tools (fiddler, notepad++, different browsers, etc.)
The Problem
To be able to develop with SharePoint, it is strongly recommended to have at least 8 gigabytes of RAM (I first tried with just 6 gigs, but it was still a nightmare). My laptop only has 8 gigs of memory, so I couldn't run the VM locally. I asked our IT guys if it was possible to host the VM on a local on-premise server. They answered that they didn't have enough space for the environment. They were very sorry, but I was actually quite happy about it; I now had a perfect use-case to work in Windows Azure!
The Solution
I went to see my boss and explained the situation: instead of buying a brand new server for development and test environment purposes, we should simply use Windows Azure’s IaaS! We could start setting up the VM in less than 10 minutes. In an hour we would be ready to code! The development VM would only be up while it was in use, meaning that it wouldn’t cost a cent while nobody was working on it. On project completion… we would delete all the VMs we were using, and no more fees! My boss loved the idea!
The core team for this project involved four full-time developers, and here is a high level look at our development environment: The Active Directory is shared but every developer has their own SharePoint, Sql Server, and ADFS making them autonomous.
As you can see, it's a hybrid environment since the Team Foundation Server (TFS) is on one our local servers. In the morning, I start my VM and within a few minutes, I'm connected remotely and I’m ready to work on a great machine. With a little PowerShell script that I wrote, I don't even need to log in to the Azure Portal to start and stop my VM. Another great joy to this scenario is that I can now work from anywhere and on any kind of machine: from home on the family computer without VPN or from a Hotel on my laptop or my Surface Pro! Happiness often comes from simple things.
In general, I would say that the experience was very positive, but on the road we did encounter some issues that we had to resolve. Since all IPs on Azure are dynamic, we discovered that the domain controller that is hosted in Azure, must be started before the other VMs. This way its IP will always be the first one, therefore the other VMs will find it without any issues. Furthermore, in our architecture, the source-control (TFS) is on-premise. When you check-out or check-in your code, you are passing through the firewall. However, since these actions are intensive, the firewall may interpret the activity as attacks.
Because the job of a firewall is to protect your network, you can imagine what happened... the connection was lost. Once we identified this and created Firewall exceptions for the Azure VMs, everything was good.
In Conclution
I hope this post will encourage you to try Windows Azure as a development and test environment, because it's a really effective and cost-beneficial way to execute on different projects. For more information about the Windows Azure Infrastructure as a Service go to the Windows Azure Web Site.
~Frank