Getting Started With Bicep
Sunday, 04 May 2025
When working with cloud services like Azure, it's important to have a reliable way to set up and manage your resources. This is where Infrastructure as Code (IaC) comes in. IaC lets you define your infrastructure using code, so you can automate deployments, make changes easily, and keep track of everything in version control like Git, which is really important.
You might have used tools like Azure CLI or Azure PowerShell to create resources manually or through scripts. These methods work but can get complicated quickly as your environment grows. Other tools like Terraform are also popular for IaC and can work with multiple cloud providers. But if you're mainly using Azure, Bicep is a great option, it’s made specifically for Azure and is much easier to read and write than the older ARM templates.
Bicep is a domain-specific language (DSL) that simplifies the authoring of Azure Resource Manager (ARM) templates. Think of it as a cleaner, more maintainable alternative to raw ARM JSON. With Bicep, you get the full power of ARM, without the complexity.
One of the biggest advantages of using Infrastructure as Code is that your templates become your source of truth. This is incredibly helpful in disaster recovery (DR) scenarios. If something goes wrong, say an entire resource group is deleted, you can quickly and reliably recreate everything using your Bicep files. Instead of relying on memory, documentation, or screenshots, you’ve got a trusted, version-controlled blueprint of your infrastructure ready to go. This makes recovery faster, reduces stress, and helps ensure nothing important gets missed.
What is Bicep? 💪
Bicep is a declarative language created by Microsoft to make it easier to write infrastructure as code for Azure. Before Bicep, the only native option was using ARM templates written in JSON, which can be hard to read and maintain. Bicep was introduced to simplify that process by providing a cleaner, more user-friendly syntax while still compiling down to the same JSON format that Azure uses behind the scenes.
Why You Should Use Bicep 🚀
Using Bicep is a great step toward managing your infrastructure more efficiently. As your Azure environment grows, having a structured and clear way to define your resources can save time and reduce mistakes. Bicep makes this process approachable, especially for those just starting with Infrastructure as Code.
- Simpler Syntax: Bicep uses a clean, concise syntax that is easier to read and write.
- Modularity: Easily create reusable components.
- Type Safety & Intellisense: Get help from your editor to avoid mistakes.
- Tooling Support: Built-in support in Visual Studio Code.
Learning Bicep is also a great way to grow as a developer. Infrastructure as Code isn’t just about automation, it teaches you how cloud services are structured and helps you think about infrastructure in a more programmatic way. As you progress in your career, having IaC skills like Bicep in your toolbox makes you more versatile and capable of taking on bigger, more complex projects with confidence.
My Bicep Journey 💭
I first started using Bicep while working at Flagship, and I was surprised at how quickly I was able to get up and running with it. It made deploying infrastructure feel clean and structured, without the clutter of traditional JSON-based ARM templates or having to write lots of PowerShell logic (something I used to do before).
Since moving to Mobilityways, I've continued that journey. In fact, when I joined the team, there was no Infrastructure as Code in place at all. Bicep became the perfect tool to introduce, making it easier to standardise and automate our Azure deployments from the ground up. It's been exciting to see the impact it's had, and it's only reinforced how valuable Bicep can be when you're managing infrastructure in Azure.
Prerequisites
Before you get started, make sure you have the following installed. Don’t forget, you’ll also need an Azure subscription. If you don’t have one yet, you can sign up at azure.com and get some free credits to experiment with:
Your First Bicep File 🛠️
I think the best way to learn is to have a go, so let’s dive in and write some Bicep! We’re going to start by creating a simple Bicep file that deploys a storage account in Azure. It’s a great hands-on way to see how Bicep works and get a feel for writing infrastructure as code.
param location string = resourceGroup().location
param storageAccountName string
resource storageAccount 'Microsoft.Storage/storageAccounts@2024-01-01' = {
name: storageAccountName
location: location
kind: 'StorageV2'
sku: {
name: 'Standard_LRS'
}
kind: 'StorageV2'
properties: {}
}
Save this as main.bicep.
Let’s break down what’s happening in this file:
- param is how you define inputs to your Bicep file. In this case, we’re asking for a location (with a default value from the resource group) and a storageAccountName, which you’ll provide when deploying.
- resource is where you define what you’re deploying. Here, we’re creating a storage account using the appropriate resource type and API version.
These two of the building blocks at the core of every Bicep file. Parameters let you make your templates flexible and reusable, while resources are the actual things you’re deploying to Azure, like storage accounts, virtual networks, or databases. There are also modules which we’ll touch on later and do a deeper dive in another blog.
Deploying the Bicep File 🚢
Before you deploy, make sure that you have installed either the Azure CLI or Azure PowerShell modules and that you're signed in to your Azure account using az login or Connect-AzAccount. This ensures your commands will run against the correct Azure subscription.
You can deploy this using the Azure CLI:
az deployment group create \
--resource-group "your resource group name" \
--template-file main.bicep \
--parameters storageAccountName="storageaccountname"
or you can use Azure PowerShell (my preference):
$resourceGroupName = "resourceGroupname"
$params = @{
storageAccountName = "mystorageaccountname"
}
New-AzResourceGroupDeployment `
-ResourceGroupName $resourceGroupName `
-TemplateFile main.bicep `
-TemplateParameterObject $params
What’s Next? 🔮
Stay tuned for a future blog post where I’ll dive deeper into Bicep. We’ll look at modules, more advanced patterns, and real-world examples to level up your infrastructure-as-code game!
From here, you can:
- Learn about modules to break down your Bicep files into reusable components.
- Use loops and conditions to add flexibility.
- Leverage existing resources and outputs to compose complex deployments.
Bicep is continuously evolving, so keeping an eye on official docs is a great idea.
Summary 📘
I know this has been a high-level and fast-paced overview, but hopefully it’s helped you get a feel for Bicep, or at the very least, shown you why Infrastructure as Code is something you should be doing.
Here’s a quick recap of what we’ve learned.
- Why Infrastructure as Code is important and how Bicep fits into the Azure ecosystem.
- What Bicep is, why Microsoft created it, and what makes it easier than ARM templates.
- The benefits of using Bicep over other methods like Azure CLI, PowerShell, or Terraform.
- How to write a simple Bicep file and what the key concepts like parameters and resources mean.
- How to deploy a Bicep file using both Azure CLI and Azure PowerShell.
You’re now set up with the basics and ready to start exploring more advanced features!
Happy templating! And thanks for reading.
Chris 🙏
Subscribe so you don't miss out 🚀
Be the first to know about new blog posts, news, and more. Delivered straight to your inbox 📨