• 3 min read

Azure Deployment Manager now in preview

How complex are your services? Do you have tens of resources split over a bunch of resource groups and regions? Hundreds? Thousands? Does your engineering system make it easy to declaratively define the topology of those resources, how they work together, and how they can be deployed and updated in a safe, scalable fashion?

How complex are your services? Do you have tens of resources split over a bunch of resource groups and regions? Hundreds? Thousands? Does your engineering system make it easy to declaratively define the topology of those resources, how they work together, and how they can be deployed and updated in a safe, scalable fashion?

At this year’s Ignite conference we are happy to unveil Azure Deployment Manager (ADM) for preview. A new set of features for Azure Resource Manager (ARM) that greatly expand your deployment capabilities. If you have a complex service that needs to be deployed to several regions, if you’d like greater control over when your resources are deployed in relation to one another, or if you’d like to limit your customer’s exposure to bad updates by catching them while in progress, then ADM is for you.

ADM allows you to perform staged rollouts of resources, meaning they are deployed region by region in an ordered fashion. As part of this region by region rollout, the health of your services is monitored, and if unacceptable performance degradation is detected, deployment will automatically stop, allowing you to troubleshoot and reduce the scale of the impact. This exact set of tools is used internally by hundreds of Microsoft services to ensure safe, reliable deployments ensuring high availability and preventing or dramatically reducing service unavailability caused by regressions in updates.

ADM introduces two new concepts to the ARM deployment story:

  • Service Topologies
  • Rollouts

A service topology describes the hierarchy of the resources you deploy to Azure by organizing them into groups.

image

Template and parameter files form the basis of any ARM deployment. These represent the Service Units or individually deployable chunks of a given service such as the front end of a service. A group of Service Units comprises a Service, and a Service Topology is nothing more than a group of Services.

ADM makes it easy to define these kinds of complex topologies, even when the Services span multiple regions, subscriptions, and/or resource groups. Once defined, they can be deployed and then updated any number of times through the use of Rollouts.

A Rollout defines the structure and timing for how to deploy the Service Units in a staged, safe fashion.

image

A Rollout is composed of Step Groups. The Step Groups define the ordering of deployment and support both sequential and parallel operations. For example, I can have Step Groups 1 and 2 deployed in parallel before deploying Step Group 3.

As the name implies, Step Groups are further broken down into Steps. Steps to take before a deployment, and steps to take after a deployment. Examples of such steps include:

  • Wait
    • Pause deployment for a specified amount of time before continuing.
    • This allows for manual tests as well as time for the resources to bake. 
  • Custom code execution
    • Need to populate a SQL database that you just deployed using a custom script or web service? Make it a step in your Rollout and voila!
    • Custom code execution is already used by some Azure services, and while this type of step is not yet available in the ADM public offering, it is coming very soon after Ignite.
  • Health checks
    • ADM integrates with your existing service monitoring provider to check the health of your service as deployments are underway.
    • If the health of your service degrades, deployment is halted.
    • Note that this type of step, used by Microsoft when deploying Azure services, is not yet available but is coming very soon after Ignite.
  • More to be announced soon!

Creating a Step Group is as simple as defining what Steps you want to use before and after the Service Unit deployment, and then slotting it into the rollout ordering by indicating what other Step Groups it depends on. In the example depicted in the figure above, Step Group 2 will deploy first, since Step Group 1 depends on it. It’s simple, powerful, and scalable to meet your needs.

We’re extremely excited for you to give the Azure Deployment Manager preview a try, and we have a sign-up form where you can go to get your name on the list for access. If you want to learn more, come to check us out at Ignite session BRK3390 or check out the links below.