Adopt a DevBox today!
Microsoft DevBox is, in their words, a “pre-configured, project-specific” cloud-based, customizable developer focussed workstation-class virtual machine hosted on Azure and available through its own portal (once everything has been deployed and configured) at devbox.microsoft.com.
Try saying that in one breath!
Basically, DevBox is a fast developer VM, pre-configurable and designed to be managed by a project team itself.
Monday, 9.00 am
Day one of your new job as a developer with ‘evilcorps’. After introductions and possibly your first standup with your new team, the task of setting up your development machine starts. You ask around your team. So, what IDE? What version of the various packages do you use? Someone says they are using version 3.2 of a plugin but someone else is using 5.3? Which should you use? New, old or both? Also, someone is using Jet Brains, someone else is using VS Code and yet someone else is using Visual Studio. But wait! Do you even have permission to install software on your machine?
A bit of an extreme example but we’ve seen it happen. I’ve even seen a team of three people use three different IDEs. (I was the fourth person on the team and choosing which IDE to choose felt like such a political decision! I knew I was going to upset someone and shift the uneasy balance. Stressful!!)
This is the scenario that DevBox is designed to prevent. Monday, 9.00 am, you log in. Your Entra ID has been added to the DevBox project and you can log in to the portal and start up your very own DevBox that comes with exactly the software, libraries and access you need as a team member.
Microsoft says a new DevBox takes between 25 and 65 minutes to provision, but in my experience, it could be quicker.
Create a new DevBox and by the time standup is over and you’ve met your team-mates, your DevBox is ready to use. A minimum of waiting, a minimum of fuss, a maximum of productivity!
That’s the plan!
Context
We are a team of consultants embedded within a large client organisation that has many internal projects and project teams. Within these project teams, some are more technical than others and developers may be consultants from our own company (usually!) or another consultancy (Boo, hiss, grr!). The customer has a specific drive to develop the ability to be able to spin up services in a more efficient and timely way than they have had in the past and to ensure teams get working as soon as possible after onboarding.
As with many large organisations, they have been used to shipping laptops to remote workers and would like to not have to have the complications this brings and to increase the flexibility of the organisation to respond to emergencies where infrastructure and development environments can be deployed at the drop of a hat (almost!).
I won’t go into every feature and use for DevBox in this blog, suffice to say that Microsoft have lots of documentation here: Microsoft Dev Box documentation | Microsoft Learn
Note: As a product in ongoing development, the life cycle of this post may be limited, but it is offered as a “point-in-time” snapshot of a real-world DevBox use case.
Behind the scenes.
In July 2023 Microsoft moved DevBox from early access to General availability and when a customer had a requirement for an Internal Developer Platform we decided to introduce them to DevBox and to roll out a proof-of-concept DevBox deployment.
An offshoot of the Microsoft DevTest labs approach, DevBox deployment and configuration happens mostly in Azure but a user will just see the portal as a front end and care little about the behind-the-scenes configuration.
From a DevOps perspective there is a distinct hierarchy to the infrastructure:
· A DevCenter is a resource where many DevBox Projects can be configured.
· A DevBox Project is a resource where many DevBox VM pools can be configured.
· A DevBox pool is a resource which facilitates the creation of many DevBoxes.
While accurate, the above is a huge simplification and there are many other interlinking parts in the setup process, but we will address these later as they become relevant.
As a DevCenter is the heart of the whole service, for our testing we have chosen to have a single DevCenter, controlled by the DevOps team. This has been useful as far as it goes, but we may look at the option of allowing internal teams to create their own DevCenters at some point, given each project’s very different needs. This will depend on the team having a DevOps capability and the development of IaC for DevBox. As the Infrastructure as Code for DevBox is quite immature at the moment, this may be something we don’t look at for a while.
DevBox as Code
Our preferred method for deploying to Azure is via an Azure DevOps pipeline and Terraform. The latest version of terraform at the current time is 1.7.3 and an AzureRM provider version is 3.91.0. In these current versions, the only DevBox options available are shown in the image below:
Screenshot from the Azurerm provider documentation at azurerm_dev_center | Resources | hashicorp/azurerm | Terraform | Terraform Registry
While this is surely under constant development and I can vouch that it has improved over time, there are more components to the DevBox whole than are available in the Terraform Azurerm provider. No sign of DevBox Project Pools or schedules or of adding DevCenter network connections, DevBox definitions or DevBox Environments etc.
For our proof of concept, I first worked through what was needed in Pulumi. Pulumi was new to me and I won’t go into the pros and cons or a comparison with Terraform. I found it a useful wrapper around the Azure API and it allowed me to develop the early approach.
The project demanded that we use Terraform, however. And this means the AZAPI provider. AZAPI, is a term that strikes fear into the heart of junior DevOps engineers everywhere! Having done the early work in Pulumi, I was reasonably well prepared for what awaited with the API and was able to get up to speed quite quickly.
Using the API gives access to most DevBox features in code, although there are some idiosyncrasies. For example, you can see in the screenshot below I have added a comment to the fact that while you can give the “devbox_schedule” a name, if you do not use “default” as the name you will get an error explaining that only “default” is a valid value!
But I can forgive these little quirks as we are still early on in the lifecycle of DevBox as IaC.
As well as Infrastructure as Code, DevBox documentation also leans into a “Configure as Code” approach. This is something I will mention later in the post. Currently, our position on this is somewhat ambiguous after a discussion with the DevBox development team.
Discussion
Having given a brief overview of how we have been approaching DevBox, there are a few things that I would like to touch on regarding the experience of the DevBox service as a whole (in its current state.) I also have been the “DevBox Evangelist” within our team and have used it myself for development.
First and foremost, I want to say that I LOVE using DevBox.
When using Azure DevOps for our repos and Pipelines, I find the whole experience ridiculously fast, allowing me to correct most of my silly mistakes before the other DevOps engineers even spot them! Seriously, the process of using a code repository is stunningly fast (thanks to the 2Gb Azure networking). The machine feels very powerful, much more so than my current dev laptop. I feel more productive, not having even the teensy annoyance of waiting for a push to complete. Internet searches are instant and even large data uploads and downloads from SQL servers and Storage Accounts are like lightning! I love it.
While DevBox can be used via browser (and I use this to demo the service to the client’s internal teams) the real experience is to be found when using the DevBox RDP client. Don’t use a version of Remote Desktop from the Windows store or anywhere else, follow the instructions on your DevBox portal to get the correct version that will work with DevBox. This client opens up the world of low-latency connections and (gasp!) dual monitor use!
But like every love affair, if you’re realistic, over time you come to see some minor irritants in the one you love — eating too loud, snoring or introducing the dog before they introduce you, for example. (Note, possible human flaws included for illustration purposes only!)
It is these minor issues with DevBox that I feel are holding back our widescale deployment of the service, and I’d like to (not quite) rant about them.
The first issue, and one that we discuss a lot, is the “Configure as Code” aspect. For myself, this can range from the creation and production of custom images through to using the post-creation software installation. Here is a recent DevBox blog post around this issue: New capabilities help simplify and streamline the experience with Microsoft Dev Box — Microsoft Community Hub
Given the structure of our client interaction, we are primarily focussed on delegating as much control to each project as possible, and we want this to be the case with DevBox deployments as well. The facility is there within the project and the DevCenter and the DevCenterAdmin role for them to be able to create their own required developer environment. Admittedly there may need to be some assistance from an Azure administrator, but the initiative to develop and refine the environment needs to come from dev leads and project management. However, there is the question of who should be responsible for the creation and maintenance of the image.
In our current phase, we are happy to guide those teams who want to create an image but, long term, we are not that sort of DevOps team, if that makes sense. DevBox updates and maintenance will, in the long term, be handled by Microsoft Intune, as they are automatically enrolled in the service, but there is already an expectation that ‘we’ will deliver the image to the team and will be available to support VMs.
As a result, we are somewhat of a standoff with teams who expect us to create and support their images for them. Our project is focussed on putting as much power into the hands of other projects and teams as possible and we currently are counting on stubbornness, education and management to get the message across that the teams have the power to deliver their own custom DevBoxes inside the team itself. Ultimately this may be an issue only we face at the moment. Further, as DevBox does have a cost, the implication is that our team should shoulder the behind the scenes costs, such as storage and we do not have the budget to do so. Sadly, everyone loves DevBox until they realise their DevBoxes are coming out of their budget!
The next issue worth considering is the actual time requirements of creating the custom DevBox definitions themselves. While touting the idea of “Config as Code”, a recent chat with the DevBox dev team is worth repeating. While you ‘can’ add post creation deployment steps for a DevBox, the question is ‘should’ you?
If we look at the diagram below, you can see that creating the DevBox image is a ‘front-loaded’ time block that will not be aware of. However, post-creation DevBox “Config as Code” configuration will have a more critical impact on the user of the DevBox. The user does not have to know about the image creation time frame — they just know that they can go to the portal and a DevBox will be provisioned with an hour or so. If they create a DevBox and it takes and hour to create the DevBox, and then an indeterminate amount of time to configure policies and software installations and OS updates etc, then their user experience will be poorer.
Whilst this will only happen on first creation, it still takes us away from being able to provision a DevBox for the user in as quick a time as possible.
Its all about the network.
Finally, and possibly, the biggest issue we face, at the moment, is the question of networking. I’ll discuss this with the caveat that we know this will be sorted very soon (as do most of or suggestions for improvements)!
Now, our problem with networking currently is not in the sense that there is something that doesn’t work, but more that, when delegating the project to development teams, we need to acknowledge that many different teams may have different networking requirements.
Currently, this is not available in the recent release versions of DevBox. This is frustrating. This one of the first things we would like to be able to do. All the rest of our hassles and issues are somewhat ‘political’ but when one project wants sites blocked and one project wants to be able to access resources in a specific vnet and a third wants internet usage block completely, this causes us a particular headache, as trying to sell DevBox to teams who have specific network requirements can be awkward.
This is the difference between a network connection that is shared between projects and dedicated DevBox networks.
The current shared connection will work very well for many teams, and we have trialled DevBox successfully using this method. But we know our customer, and we know the diverse needs of the teams and ultimately we can’t really begin to sell DevBox fully until we know that we can provide network isolation and fine grained control over each project’s network capabilities.
And while I realise this will be available to use very soon, right now, as of writing this post I’m having to be somewhat circumspect about what we discuss with teams regarding networking.
One (semi-related) note on this: We recently had a change to our DevBox networking, including such common changes as routing and firewall rules. Suddenly we couldn’t create DevBoxes any more! This is due to the fact that as part of the provisioning step the DevBox reaches out to some Windows Virtual Desktop urls. I’d love to see some documentation that comes along with the much needed expansion of networking within DevBox to highlight the specific calls that we need to have firewall / nsg rules for. Similar to this documentation: Required FQDNs and endpoints for Azure Virtual Desktop | Microsoft Learn It might even be exactly this information that we need, but it would be nice to see a link to this in the DevBox documentation.
Are we there yet?
Just to reiterate, I LOVE DEVBOX and I am just frustrated because I feel like we’re a point in time where amazing things are just over the horizon, and I’m being impatient wanting them now! Like Bart Simpson I’m repeating “Are we there yet?”
Anyway, thanks for taking the time to read this and I will post a follow up when we get a little further down our DevBox learning path!
About the author
Thomas Watson is an Azure DevOps Engineer here at Version 1.
