How Microsoft is modernizing Azure

Clearly, Microsoft put a lot of love in the making of Azure Bicep. Unlike its perplexing parent, ARM templates, all the good stuff we expect from a modern infrastructure-as-code comes baked in: declarative syntax, modularity, versioning, and authorship.

We could summarize the effort as such:

It's not because code needs to be machine-readable that is must not be human readable.

Under the heavy influence of Terraform, and to increase/ease the general adoption of automated deployments, Microsoft took the wise decision to modernize its back-end without replacing ARM templates - this would have broken many internal processes and negatively impacted customer experience. Instead, they chose to position Bicep as a kind of front-end to traditional ARM REST APIs.

Stateful deployments

So ARM templates are not gone (one can still use them to "bypass" Bicep), and state management remains "the" core feature of ARM orchestration. As far as states are concerned, thanks to Terraform heritage, the ARM API brings something new and super useful to the table: what-if scenarios. Since Bicep is a front-end to ARM, this what-if feature is, of course, available first-hand in Bicep.

What-if scenarios let customers plan changes and thoroughly assess impact. It's a first class feature of any automation pipeline. It's even more than that:

Without previewing, there is no production-grade infrastructure-as-code.

Amazon understood this long before Microsoft: they implemented Cloudformation change sets in 2016.

From small scale to large scale deployments

Up until recently, complex deployments in Azure were impaired by a lack of stacks management: the prime candidate, Azure Blueprints, was somehow lacking a solid, natural way of managing resources, and never went Generally Available.

For a year or so, customers were left in an uncomfortable situation: Azure Blueprints was going to be deprecated and its successor, Azure Deployment Stacks, was only in Preview. Would the latter make it to production? Given Microsoft track record, this was not very clear.

Fortunately, Azure Deployment Stacks went live in spring 2024.

Combining what-if conditions (brought by ARM) with a modern syntax (brought by Bicep) and proper stacks management (brought by Azure Deployment Stacks) offers a competitive solution for state of the art infrastructure-as-code compared to other cloud providers such as Amazon.

The next big thing

So, yes, I think Microsoft did a fantastic job at modernizing their Cloud platform. But there is still a small problem. If Microsoft was a new player, we would call it a technical problem. Given Microsoft long-term experience in running a major public Cloud platform, I prefer to call it a mindset problem.

Here it is: currently, what-if evaluations time out if they cannot unfold and assess nested templates within 5 minutes.

Why 5 minutes? Why not 1 second, or 60 days? How does this number relate to customer concerns? Or Microsoft concerns, for what matters? This doesn't make sense to me. It probably doesn't either to its main competitor, which is more accustomed to deal with failures by looking at 99.9 (or more) success percentiles.

There is a similar issue with Azure Policy, by the way: policy evaluations are performed at fixed intervals. Is the unique, static choice driven by a risks reduction strategy? It's very unlikely.

So, here's the takeaway: given a great infrastructure-as-code platform, are we ready to hand over the full management of our deployment states if we are not guaranteed that impact assessment won't fail when complexity reaches a certain threshold?

If Microsoft cannot solve this mindset problem elegantly (meaning: grounding evaluations to customer expectations, seamlessly and for free), chances are we are going to stick to Terraform for some time.