A first look at using Azure Managed DevOps Pools

author Richard Fennell calendar Aug 1, 2024 · 4 min read  ·
Share on: linkedin copy

Background

We have for many years based our Azure DevOps build and release pipelines on on-premise agents. This was done to provide a means to scale up each agent using ‘bigger & faster’ local VMs then the Microsoft Hosted agents provided, and to utilise spare Hyper-V hosts we had after moving services such as SharePoint to Office 365.

To provide consistency of build agent experience to our developers, we decided we wished to use the same VM images on our on-premise agents as used by the Microsoft’s hosted agent pools. I have blogged previously on the process of creating these images with Packer and deploying them to Hyper-V with Lability. This is a process we still follow every couple of months to keep the images reasonably up to date.

Enter Azure Managed DevOps Pools

Azure Managed DevOps Pools (MDP) offer an alternative to our on premise agents and have just gone into public preview.

MDP are the logical successor to Azure Virtual Machine Scale Set Agent Pools (VMSS). VMSS are still an option as they are not going away, but MDP are easier to setup and have enhanced features. The key ones being:

  • You can pick your Agent Images
    • You can use the same image as the Microsoft Hosted Agent, but with no need to create them yourselves as we do via Packer (a feature not available with VMSS)
    • You can use standard Azure VM images.
    • Or any VM image you create yourself and place in an Azure Image Gallery.
  • You can pick the VM size and performance, you are not limited to the fixed performance of the Microsoft hosted pool agents
  • You can choose how your pool scales
    • Maximum number of agent VMs
    • Minimum number of agent VMs ready to accept work (can be zero to minimise cost, more VMs are created on-demand with a short start up delay)
  • Maybe most important - You can join your MDP to your own Azure VNET, so your VMs can access your private Azure resources (avoiding the need to deploy self managed agents for deployment jobs)
  • You only pay for cost of the running agent VMs
  • They are licensed using your on-premise agent parallel job licenses

We have been lucky enough to be part of the private preview and have been able to test them out, with great success.

Who are MDPs for?

People who need to connect to private resources on a private VNET

There are many use cases for MDPs, but the one I think we will see most is people who want the ease of hosted agents, but need to connect to private resources on a private VNET to do part of their CI/CD process.

This has been a big win for us, as we, and our clients, have a lot of private resources in secure hybrid Azure architectures.

People who need to scale up their agents

MDPs will also allow us to consider how we will replace our on-premise agents when their host Hyper-V servers reach their end of life.

It will be much easier to manage and scale MDP based agents, as there is no need to rebuild the on premise images every couple of months; each new MDP agent can get an up to date Microsoft hosted agent image upon startup.

For this use case, any decision will be based on the cost of the MDP VMs vs the cost of the time to maintain the images and run them on-premises. From initial estimates we think it will be a close call, we need to do some more detailed analysis as to the actual utilisation of the agents, how many are actually active at any given time, and how long they are active for. However, a key factor will be that MDPs mean we can scale down the number of VMs to zero, so we only pay for what we use.

But we have to remember everyone’s milage will vary as to whether MDPs are cheaper than running on-premise agents over a multi-year purchase cycle, but my suspicion is that for many the MDPs will be the cheaper option.

Summing Up

So I urge you irrespective of how you use Azure DevOps build agents to take a look at the Managed DevOps Pools. They could be a game changer for you in both functionality and cost management.

For the original version of this post see Richard Fennell's personal blog at A first look at using Azure Managed DevOps Pools