Microsoft’s latest Azure announcements echo Intel’s recent focus on the “developer cloud.” At this year’s Ignite, Microsoft is describing Azure’s growing range of developer-centric tools as its own developer cloud, with a focus on building cloud-native applications that reach from GitHub to Visual Studio and out onto the Azure platform.
A key part of Microsoft’s developer cloud is Azure’s role as a flexible infrastructure, not only for deployment but also as an isolated, configurable development platform that can be delivered with minimal administration. Giving developers a sandboxed, self-service platform for code and test within practical constraints is a big change in how we both fund and manage application development—an opportunity to accelerate application development by removing the wait for infrastructure.
How developers are using Microsoft Dev Box
In May 2022 at Build, Microsoft announced its Microsoft Dev Box environment. Building on the commercial Windows 365 cloud PC platform, Dev Box uses cloud resources to host complete development environments that be accessed from any device anywhere. In advance of Ignite, I talked to Anthony Cangialosi, group program manager in Azure’s developer division, about Dev Box and its role in the growing Azure developer cloud.
There’s a lot of value in Dev Box, especially for regulated industries that have strict rules about application development. Cangialosi notes that the current pilot has seen a lot of interest from banks and other financial institutions that need a clear demarcation between code and other work, and even between code developed for different parts of the business. Using Dev Box, it’s possible to give each project its own environment, using Azure Active Directory’s role-based access control to lock down access to the development space, APIs, and service endpoints, using a managed virtual network in Azure along with on-premises Git or other source control instances.
That same approach helps organizations manage contingent staff, consultants, vendors, and contractors by giving them controlled access to resources without exposing their machines to corporate networks or Azure accounts. All you need to do is set up an Azure AD account with access to the appropriate resources.
Using Git repositories along with preconfigured development environments helps support some of the more complex use cases Microsoft is seeing, including one bank that completely resets all developer environments every couple of months. Now, instead of losing days while developers rebuild their toolchains from scratch, you can quickly pull a fresh Dev Box image from either Microsoft’s library or your own, reconnect to Git, and start coding. If you need more power, simply scale up the host VM; if you need less, scale down.
New Visual Studio Dev Box images
The original preview release of Microsoft Dev Box was obviously derived from the Windows 365 product and offered only Windows 10 and 11 images that had the option of the Microsoft 365 productivity tools. Although you could use your own licenses to build custom images stored in your own gallery, the lack of Visual Studio–based images was a big gap in the platform. Microsoft has now quietly released a set through its Azure Marketplace, not as part of the default library of Dev Box images.
These are Gen 2 VM images, again based on Windows 10 and 11, with a choice of Visual Studio 2019 or Visual Studio 2022. Perhaps more interesting, they’re preloaded with a reasonably comprehensive toolchain, at least for the Microsoft Windows and Azure ecosystems. This includes Visual Studio Code, Git for Windows, Windows Terminal, and the Azure CLI. You’ll still need to bring your own Microsoft 365 licenses, as well as any Visual Studio subscriptions.
As these images support both Hyper-V and Windows Developer mode, you should be able to use them for more than Windows and Azure development. Azure’s support for nested hypervisors will allow you to run both the Windows Subsystem for Linux (WSL) and the Windows Subsystem for Android inside Dev Box VMs. Developers using these new VM images will be able to work with them for both cloud-native development, building containers in WSL for use on Azure’s various Kubernetes implementations, and for cross-platform application development, using .NET MAUI to target Android as well as Windows.
Building code is only one part of the developer experience. Toolchains now extend beyond development devices into CI/CD systems and deployment environments. It’s always been hard to build an effective test environment that mirrors the final deployment platform, with budgets often preventing purchase of the appropriate hardware. However, Azure makes it easier to programmatically deploy virtual infrastructures as needed.
Production-scale cloud infrastructures
The new Azure Deployment Environments go a long way to simplifying managing and delivering development environments, offering a managed service that works alongside your existing development platform, another endpoint for a CI/CD pipeline. At the heart of the platform is a way to deliver template-based environments from either a portal or a CLI.
The idea of infrastructure as code is at the heart of most devops best practices, as it allows teams to treat virtual infrastructures as idempotent elements of builds and deployments. Each fresh deployment comes with its own infrastructure, integrating with platform services such as data and storage. It’s an approach that ensures infrastructure governance is baked into each deployment, with security tools and services already in place.
Bringing this model to Azure Deployment Environments allows developers to spin up an environment when they want to test some code, with different instances for different sets of features. The process can be automated as part of a CI/CD action. There’s even the opportunity for ad-hoc deployments: If you need to test some code on a VM that connects to an Azure service, simply pick an appropriate template from your organization’s library and connect it to Visual Studio’s or Visual Studio Code’s remote development tool.
Infrastructure as code, for code
Currently, templates are built using the familiar ARM model, though there are plans to add support for Terraform and Bicep in future releases. By using a template language, you can take advantage of familiar tools, with code in repositories and managed via Git or similar processes. With a central repository of templates, you’re able to give different teams different environments as well as to apply access control rules to manage deployment rights.
It’s interesting to note that both Dev Box and Deployment Environments are, at heart, governance tools. They allow architects, development leads, and operations teams to set guidelines and rules that help cement security best practices along with regulatory compliance. By providing environments that are already compliant, there’s no need for developers to spend time concentrating on those requirements; they can get straight to the code.
There’s even scope for developers to build their own environments outside of the Azure Deployment Environments tool, and when they’re ready, developers can share them with operations and architects to be refined and added to the gallery of approved architectures. The process needs to be iterative and collaborative, with any deployment environments seen as the product of teamwork rather than an edict.
Using Azure as a developer cloud makes a lot of sense. Organizations get both the control and the elasticity they need, and at the same time, they remove drudgery and delay, delivering environments in minutes and hours that may have taken days or weeks in the past. As Cangialosi says, “You are a new developer in a new space at different points in your career, even when you don’t leave your current job.” Anything that helps get over Day One issues and lets you get coding has to be a win.
Copyright © 2022 IDG Communications, Inc.