Endjin - Home

How Azure DevTestLabs is helping me climb Everest

by Carmel Eve

So, the title may be somewhat misleading… But I’ve got you here now…

For those who don’t know, endjin is a fully remote company, this is brilliant in a lot of ways (which I won’t list now) but one of the main bonuses is it gives us the freedom to work from wherever we happen to be. With this in mind, and my trip to hike to Everest base camp rapidly approaching (I fly on the 16th October!), I decided to pack up my portable office and work from the Lake District this week in order to squeeze in some last-minute training.

However, on Tuesday evening, disaster struck. My laptop decided it had had enough. So, with a heavy heart, I shipped it back to Microsoft (I really hope they send it back to me Azure stickers intact…). This meant that I was then suddenly without a working machine.

My housemate very kindly offered to let me use her 10-year-old MacBook Air. However, though Microsoft has now released Mac-friendly versions of a lot of their products (VSCode, Azure CLI etc.), I don’t think it was quite up to the task (not that I’m knocking the thing, it’s well and truly saved my life).

Thankfully…

Azure DevTestLabs to the rescue

Azure DevTestLabs allows you to quickly provision pre-defined environments. Within the DevTestLabs you can set up VMs with defined specs and artifacts (e.g. installed programs), to meet whatever requirements you have.

When you create a new DevTestLab, you can set up a default auto shut down time. This means that all of the VMs within the environment will be deprovisioned at a certain time. This means that, for example, if the VMs are automatically turned off after 6PM, they won’t accidentally be left on overnight which would over double the running costs!

One the Lab is set up, you can create a VM:

There are loads to choose from, depending on what you’re going to be doing. These come with programs and SDKs already installed, so have a look at what’s available and pick one that works for you. You then choose the specs for the machine (I just left it with the defaults, which has since been pointed out to me, was perhaps not the best idea). At this point you can add artifacts (though you can also do this later).

Anything you add here will be automatically installed on your VM. You will want to add anything you need in this way, because anything you directly install on the machine once you’re on it will be removed when it’s deprovisioned.

And with that, we’re ready to go!

Connecting to the VM

Now, I am using the old version of Microsoft Remote Desktop (as it’s compatible with the version of OS that I’m running), but there is a newer version available.

From the Virtual Machines tab in the Lab, if you right click on the VM and click “Connect” it will download an RDP file.

If you then open this file with Remote Desktop, and double click on the listed desktop you will then be asked to sign in with the password you set up.

And there you have it, easily provisioned and configured VM that will shut down automatically and can be updated as necessary to fit your requirements!

The upshot of this being that I am currently sat in a youth hostel in Windermere, on a 10 year old MacBook, connected into a PC which is running from a data centre somewhere in Europe. My only problem so far was that when I went to book my train ticket, the prices automatically displayed in Euros!

About the author

Carmel is a 3rd year apprentice software engineer focusing on Azure based solutions for data handling. She has a masters degree in physics from the University of Manchester which has given her a keen interest in problem solving in new and imaginative ways. You can follow Carmel on Twitter.