So, there’s a lot going on in the ARM deployment scene.

Bicep

First of all, the new language Bicep was launched almost three weeks ago as an open source project on GitHub. Bicep (still a working title) makes way to write your templates without using JSON. Readability is one of Microsofts key reasons to go this route. The Bicep code basically compiles down to an ARM template. So, after writing your Azure resources declaration in the Bicep language, you can build the Bicep code to an ARM template. The ARM template essentially becomes an intermediate language and can be considered a deployment artifact like a NuGet package. Then you can deploy the arm template as you usually would.

This is an alpha release, do not use in production! At least wait until v0.3. Read the readme in the github repo to find out the current state of Bicep.

Limits

Recently Microsoft removed a few limits regarding ARM: There was a limit to how many resource groups you could deploy in one deployment operation, this is now been raised to 800. Another annoying one was the 800 deployment limit per resource group. You had to manually delete the deployments (or script it to run in a runbook) before you could deploy to the same resource group again. Now this isn’t necessary as the deployments are auto-pruned, but only if there are no CanNotDelete lock on the resource group!

What else?

Apart from what we have seen the last months, like deployment scopes on tenant, management group and subscription level, the Visual Studio Code extension with intellisense to speed up writing arm templates significantly, the ARM Testing Toolkit went open source, we have seen some stuff in public preview.

Deployment scripts

Deployment scripts have been in private preview since beginning of the year and is set to go GA in october. Deployment scripts are the swiss army knife when it comes to ARM templates as you are able to execute PowerShell or Azure CLI before, during or after the rest of the deployment. Some stuff you simply could not do in an ARM template are now possible with Deployment Scripts. This makes sure you can now have all the logic within your template itself instead of having extra scripts in your deployment pipeline.

What-if operation

ARM template deployment what-if operation is a way to test your arm template and see what the result would be if you would deploy to your azure environment. For example, a result would be that one resource is created, another is changed, and a third is deleted. If you know Terraform, this basically has the same functionality as the ‘plan’ operation, except, the what-if operation is looking at the actual state of the azure environment instead of a file representing the state, the so-called statefile. The problem with statefiles is, they tend to divert from what is actually in the cloud environment as there is always someone doing something manually. Now, with what-if, this problem doesn’t exist anymore. What-if is in Public Preview still and is planned to go GA this october.

Template Specs

Template Specs are the new way to store and deploy your templates. The use case is simple: store your ARM templates as a resource in Azure and everyone with at least reader access to the Template Spec is able to deploy the template. As a Template Spec is basically a package of ARM templates, you can use linked templates, but you need a new way to reference the child templates called ‘relativePath’. This is a huge improvement from the ‘first upload to blob storage, and then use a SAS-url as the reference to your child templates’ way of work. Currently only ARM templates are facilitated, and no other artifacts like scripts for Deployment scripts.

Azure Blueprints

Did we forget about Azure Blueprints? They have been in public preview for a few years now (Ignite 2018 if I recall correctly) and are the recommended way to build your landing zones, to create a governed Azure environment. They haven’t gone GA because this new technology called Deployment Stacks is not yet ready. Later on that. Blueprints are planned to go GA first half year 2021. Some use Blueprints as a way to orchestrate their deployments, but Template Specs basically replaced that idea for the most part. Blueprints will actually use Template Specs instead of the current Blueprint definition.

Deployment Stacks

Deployment Stacks is something entirely new. As microsoft puts it: “A ‘deploymentStack’ is a grouping concept to create an association between resources and the deployment that allows for lifecycle operations to be performed on the defined group” Resource groups were the common and recommended way to organize your resources in a way to facilitate the lifecycle of those resources. By grouping resources with the same lifecycle you can easily replace a resource group for a new version. For example an applications Database in one resource group, and the front end in another resource group. Deployment Stacks defy this view. With Deployment Stack you can for example span such a Stack over multiple resource groups to update or delete this entire Stack. Also a rollback scenario to go to a good known state is on the roadmap.

Final notes

So how this this all come together?

I recon we’ll be writing Bicep code in VS Code next year or so, build the code to ARM templates, package the ARM templates to Template Specs, and may or may not use Blueprints with those Template Specs. First we’ll test those ARM templates with the ARM TTK, next the What-If operation, and if all is good, deploy to Azure. All of course in proper pipelines.