Adventures in Declarative – with Bicep

In Azure - codifying Infrastructure has remained either an artform of adaptation (via exporting directly from Azure or baking from the Azure Quickstart templates), or it was the domain of the esoteric.  Now that Bicep has rolled on to the scene (really in the last year+) much of the complexity has been removed and has turned some Infrastructure folks into the cool programming kids (ok maybe not cool but they are no longer the Debby-downers that bring just the harsh realities of security, network, and Kubernetes complexity).  This article will be the starting point for using and abusing Bicep to its fullest.  Keep in mind this is not designed to be a series on Bicep development but a point of reference for more content.

Bicep is a domain-specific language that uses a declarative syntax to deploy Azure resources - (source: Bicep language for deploying Azure resources) - Explanation: Bicep is the strategic declarative syntax for deploying resources into Azure.  It serves as a clear, poignant, and declarative interpreter that easily translates into and out of the Azure JSON syntax while remaining to be both future-proof and feature-aligned.  Long-winded definition yes, but the examples will be worth the wait.

Without a doubt, it is easy to get into the imperative vs declarative discussion.  What do I mean - well learning BASH, Python, or Powershell as part of normal system operation makes it tempting to deploy infrastructure in an already familiar way (see Functional programming vs. imperative programming ) but Bicep is: easy to learn, extensible (via modules), and far more efficient (by means of coordinating resources and maintaining state (which is handled by the MS backplane versus state files)

Simplified syntax - this a key attribute of Bicep.  An example will be shared below.  But this mitigates a lot of the complexity and poor readability found in ARM JSON templates

Future proof - as part of the resource building the API version is part of the declarative syntax - familiar to any JSON user but it is important to note that this capability is not going away.

Feature aligned - because it translates to (and from) native ARM templates  - when a new resource, or resource feature is released it is also available through Bicep.

Intelli-genius - not actually a thing, but the Bicep team has really invested heavily to simplify the syntax adoption.  The intellisense capability is fantastic, specifically in Visual Studio Code (https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-bicep), though my guess is that other IDEs have leveraged this capability

Modularity - repeatable snippets of IaaC capability, much needed functionality for enterprise scale implementation.  (They are also working on the Bicep implementation of Enterprise Scale Landing Zones -  https://github.com/Azure/ALZ-Bicep)

See https://docs.microsoft.com/en-us/azure/azure-resource-manager/bicep/overview?tabs=bicep#benefits-of-bicep

I wanted to take the opportunity to demonstrate where Bicep really shines, and how it can easily integrate into any enterprise's Azure adoption. Some of these are features from Visual Studio Code with the Bicep extension, but most of these capabilities can be extended into any IDE.

Bicep is a vast improvement to building Infrastructure as Code for Azure over ARM templates. It has borrowed some features of Terraform (as in minimal code, and modularity) and added some (by maintaining state information directly in the Azure Backplane for consistency). For native Azure adoption take a look at Bicep and provide feedback directly to the developers.

More information

1. Bicep language for deploying Azure resources (windows.net)
2. Fundamentals of Bicep - Learn | Microsoft Docs
3. Intermediate Bicep - Learn | Microsoft Docs
4. Advanced Bicep - Learn | Microsoft Docs
5. Azure resource reference - Bicep & ARM template reference
6. Azure/ALZ-Bicep

and thank you for reading and sharing.