BICEP

Infrastructure-as-code made easy with Bicep language

In this article, we will explore what Bicep is, how it works, and how it can help you simplify and automate your Azure deployments.

Hector Sven

Hector Sven

— 5 min read
Infrastructure-as-code made easy with Bicep language

Setting the stage

Have you ever heard the phrase "treat infrastructure like cattle instead of pets"? Treating infrastructure like cattle instead of pets aligns seamlessly with the principles of Infrastructure as Code (IaC). In the IaC paradigm, infrastructure is defined and managed through code, emphasizing automation, consistency, and scalability; by scripting infrastructure we ensure a standardized, reproducible, and efficient approach to handling azure resources, comparable to handling a herd of cattle, rather than individually and with personal attention, as one would with pets.

Demystifying concepts

Just for the sake of clarity...

Infrastructure-as-code (IaC)

Infrastructure-as-code (IaC) is a key DevOps practice that involves the management of infrastructure, such as networks, compute services, databases, storages, etc. in a descriptive model; IaC allows teams to develop and release changes faster and with greater confidence.

Azure Resource Manager (ARM)

Azure Resource Manager (ARM) is the deployment service for Azure, it provides a management layer that enables you to provision resources in your account using JSON templates, declarative syntax, and tags.

Writing and maintaining IaC scripts can be challenging, especially when using JSON-based Azure Resource Manager (ARM) templates, which are verbose, complex, and error-prone... let me show you how an Azure Data Factory JSON ARM Template would look like!

Not very user friendly, right? To address these challenges, Microsoft has introduced Bicep, a new domain-specific language (DSL) for declaratively deploying Azure resources.

BICEP

Bicep is a transparent abstraction for ARM templates that provides concise syntax, reliable type safety, and support for code reuse... like this, much better isn't it? 😁

💪
The question shouldn't be which one to use (json or bicep), but how to use BICEP as soon as possible!!! This is what I want to show you next 😉🤞

Solution

From MSFT How Bicep works

[...] you submit the Bicep template to Resource Manager, which still requires JSON templates. The tooling that's built into Bicep converts your Bicep template into a JSON template. [...] The conversion happens automatically when you submit your deployment, or you can do it manually.

My proposed solution will orchestrate above sequence using an Azure DevOps pipeline as follow...

This is what we will need...

  1. AzDO Yaml Piepline. I will be using my multipurpose resilient pipeline explain in detail here in this post
Resilient Azure DevOps YAML Pipeline
Embark on a journey from Classic to YAML pipelines in Azure DevOps with me. I transitioned, faced challenges, and found it all worthwhile. Follow to learn practical configurations and detailed insights, bypassing the debate on YAML vs Classic. Your guide in mastering Azure DevOps.
TechTacoFridayHector Sven
  1. Bicep scripts. I'm going to organize our infrastructure-as-code using module and resource bicep files; modules improve the readability of your Bicep files by encapsulating complex details of your deployment.
🤓
As any other language, BICEP has data types, variables, conditions, functions, operators, etc. a full reference to BICEP language can be found in the Bicep documentation

Finally the code!

I need to connect the what comes next to another article I published

Handling Infrastructure in Azure: Shared vs Data-Product
Shared Infrastructure is not merely a set of resources; it’s a carefully designed approach to resource management that promotes efficiency, reduces redundancy, and ensures a unified foundation for Enterprise-Scale Analytics Data-Products.
TechTacoFridayHector Sven

I'm going to define for this example Infrastructure the following shared resources: Azure Data Factory and two Storage Accounts one for Data Ingestion (Hierarchy enabled) and one for Workload Support (Hierarchy disabled)

I'll explain just the most relevant parts of the code

👨‍💻
You can get the whole code from this AzDO Git repository infrastructure-as-code-made-easy-with-bicep 😁🤞

Files structure

I'm using one module file called main.bicep (1) to reflect that within is contained the complete solution's infrastructure it needs so all resources are deployed together. The other is the source files, the one shown below is adf.bicep to create a Data Factory, this is what I just called a resource file and its define in such manner that I can use it as a template!

😉
Of course not your main nor any other file has to be name like, this is the way I use my biceps and it worked pretty well for me thus far, that's why I'm suggesting you to use it ... hope it serve your needs.

Bicep files explained

  1. Resource group. By default, a Bicep file is scoped to the resource group, what that means is that usually you have an Azure resource group already created to target your deployments, in this case, we are creating the resource group from scratch, that is, we need to scope our deployment at subscription level.
  1. Data Factory. For the data factory, notice how on line #40, I', sending to the bicep template adf.bicep a repository configuration only when the environment is development, in the next article, I'll explain more about Git vs Live modes and it's practical implication within a DevOps cycle... stay tune 😁🤞
  1. Storage Accounts. This is the benefits of splitting your biceps into modules and resources (templates), I can create many different Azure resources just by sending different configurations thru it's input parameters! In this example, I just use enableHns, but you can virtually add parameters to each property!! And it makes the code easy to read and update 😁

Read more