Microsoft Dev Box: Your development workstation on Azure

Setting up a new development PC can take time. We’ve all experienced it: My latest device arrived in February and I’m sure that everything I need isn’t there yet, even with a long list of apps and tools that I’ve used to guide installations. The list gets longer with each new project and each new technology, too.

It’s a problem that eats into developer productivity, especially when starting a new project. What tools will you need to install, and how will they interact with your normal toolset? A machine tuned for .NET development is unlikely to need the same things as one that’s building machine learning models in PyTorch. Then there’s the underlying hardware. If I’m building JavaScript plug-ins for Office, I’m not going to need 64GB of RAM and a high-end GPU, a specification that’s highly likely for a machine that’s building and testing computer vision code.

Developers need to be fast and flexible, and that usually requires the latest hardware with all the bells and whistles. Every little bit of power makes it easier to deliver bug-free code that does exactly what’s needed. But no matter how fast the PC, it takes time to install and configure a project toolchain, from IDE to project libraries and Git.

How can we ensure that developers are ready to start work as soon as they’re assigned to a project? Microsoft and its GitHub subsidiary have been thinking about this problem for some time, and we’re now at a point where two key trends are meeting: the ability to containerize the tools and services we want and the capabilities of remote desktop installs.

Hosted on Azure, managed by Windows 365

Build 2022 saw Microsoft announce Microsoft Dev Box, a way to build development environments in Azure-hosted Windows virtual machines so that developers can quickly open a preconfigured system and get to work without having to change the underlying PC. Dev Box builds on tools Microsoft has developed to manage business desktops in the cloud, including Windows 365 and the various components of its Endpoint Manager system management tools.

Microsoft’s existing managed Windows 365 cloud PC service is its virtual desktop platform, offering hosted Windows 10 and Windows 11 installations that can be managed through the same Intune cloud device management platform as on-premises and mobile hardware, along with the rest of the Endpoint Manager suite. Putting Windows in the cloud is the first step to delivering tools such as Dev Box, as you’re now able to configure and provision virtual desktop images that can be spun up on demand.

With Windows 365 already supporting remote and hybrid work, it makes a lot of sense to deliver task-specific environments that can be used on any PC or tablet, with familiar productivity software and custom line-of-business tools, and then to extend it to support developers. New Windows features will allow devices to boot to a Windows 365 environment or quickly switch to it using the same tools you use for Windows’ built-in virtual desktop tools. With fast broadband and modern remoting tools, latency is kept to a minimum, making a remote virtual desktop indistinguishable from a local one.

For now, however, you’re limited to using a separate Remote Desktop tool to access Windows 365 and Windows Dev Box environments. This is a new version of the familiar Remote Desktop bundled with Windows that’s only able to connect to managed cloud environments. It’s somewhat confusing: It’s not in the Windows Store but has the same icon and name. If you’re using Remote Desktop to manage your development servers and work with Azure resources, you’ll end up needing two different versions for now.

For users, a Dev Box will simply be a link on a portal. Click the link and it’ll open in Remote Desktop (or prompt for a download). This spins up a virtual machine running a preconfigured image. Once launched, all the tools needed to start work will be there. Users will get more rights over their images than a typical user gets in Windows 365, allowing them to install tools as needed. It’s important to remember that there’s no relationship between the capabilities of the device connected to a Dev Box and the virtual environment; I could be using an old iPad to check some code from home on the weekend and I’d have the same performance as my workstation in my office (which in these days of hybrid work could be anywhere).

Under the VM image will be a host with the appropriate resources for the project. It might be a VM with a vGPU, or it might be one with enough to run an editor and connect to a CI/CD (continuous integration and continuous delivery) system to run a build. As an architect or project lead, you get to define who gets what resources, allowing you to budget for the tools needed for a project. Admin tools show what resources are being used, so you can tune requirements up and down as necessary and help keep projects on budget. Dev Boxes can be automatically hibernated when users aren’t connected to keep compute costs to a minimum.

Dev Boxes for every task and toolchain

Administrators and architects can preload applications to images so that each Dev Box has a complete toolchain and is ready to go. Images can be stored until needed so it’s possible to build out a library of Dev Boxes that are suitable for a range of different tasks and even have test environments to try out new tools.

One of the more interesting aspects of Dev Box is the ability to assign more than one to a user. You might have one Dev Box configured with data science tools and services to build and train machine learning models. While it is training a model, you can open another that’s configured to build and test an application using the model’s APIs. Switching is handled through the same portal you use to connect to a Dev Box. Two identical Dev Boxes connected to the same repository can show the effects of new libraries or new components on your code without affecting your main branches.

It’s important to note that Dev Box is not a version of GitHub’s Codespaces, though there’s no reason why a Dev Box couldn’t be connected to a Codespace—and many good reasons why it should! Codespace is a containerized environment for building and testing cloud-native applications, and although it’s connected to a cloud-hosted editing environment, it’s more like being able to code against your runtime platform from anywhere without using production resources.

Microsoft is taking some of the Codespaces concepts and using them as part of another new set of developer tools announced at Build. Azure Deployment Environments are a way of building templates for a deployment infrastructure, giving developers a self-service target for their code that can be managed and monitored by platform engineers. You can have multiple Deployment Environments for different stages of the application life cycle, for example, development and test with different security and network models so that only production environments have access to the internet or to corporate vLANs.

Like Dev Box, Deployment Environments can be scheduled. You can spin one up at 9 a.m. to test code as you write it and shut it down at 7 p.m. when everyone goes home. Scheduled availability can help improve work/life balance, letting developers pack up, knowing everything will be ready in the morning. And as these environments all run in the cloud, even Dev Box, all they need is a network connection to see their remote desktop, wherever they may be. It’s summer, so code on the beach? With Dev Box and Azure Deployment Environments, there’s no reason why not.