Microsoft now released Azure DevBox as a new service aimed at developers, and I know many might be thinking.. well how does this differ from Windows 365 or even Azure Virtual Desktop?
I wrote about DevBox waaay back when it was still in preview (Getting started with Microsoft DevBox – msandbu.org) while it is a VDI service aimed at developers it is not so much different underneath the hood compared to AVD and Windows 365.
While there is a main difference between AVD and Windows 365, is that AVD provides customization, where I can define which virtual instance type to use in the service and secondly, I have multi-user session as an option. While Windows 365 on the other hand is a pure DaaS service with a dedicated machine per user.
But both Windows 365 and AVD use the same protocol and the same underlying architecture for connectivity. Also, support much of the same features on the protocol level such as ShortPath and optimization features.
DevBox can be seen as an alternative to Windows 365, where you get a personal VDI machine, from a predefined SKU that Microsoft has on their pricing page. The main difference is that DevBox provides self-service capabilities while Windows 365 provides a pre-created virtual machine based upon a provisioning policy.
This is really similar to the DevTest labs feature that Microsoft had, but this is not using public IP services but using Azure Virtual Desktop / Windows 365 components to tunnel the traffic from the user/developer to the virtual machine.
Developers can get the screen shown above, where they can provision one or multiple virtual machines and have direct access to them. The big advantage of this service is not just the DevBox feature, but another feature that is also integrated here called Deployment Environments.
This feature is also part of the DevBox self-service portal. allows us to predefine a set of templates that can be available for ordering through the self-service portal. These services can then be configured using a time schedule and templates that be directly sourced from Github or Azure DevOps. This allows us to have a predefined set of service templates that are based on Github or Azure DevOps to be available for “ordering” by users in our tenant.
While DevBox on its own is still a small service, I see more benefits of the future of the service with more self-service capabilities and that in a later iteration, it will also support Terraform (it currently only supports Azure Resource Manager templates) which will allow for organizations to reuse Terraform modules to be the source of the self-service capabilities in the DevBox portal.