Apple Podcasts 
Spotify 
Youtube Music 
Spreaker 
Podchaser 
Amazon Music Bicep - Simply Explained
Azure Bicep is Microsoft's modern Infrastructure as Code (IaC) language for deploying and managing Azure resources using a clean, readable, and declarative syntax. In this episode of Microsoft Knowledge Nuggets on M365 FM, Mirko Peters explains why Azure Bicep has become Microsoft's recommended replacement for traditional ARM Templates and how it helps organizations build secure, scalable, and repeatable cloud environments with less complexity.
You'll learn the core building blocks of every Azure Bicep project, including resources, parameters, variables, outputs, modules, conditions, loops, and symbolic names. The episode demonstrates how Bicep automatically handles resource dependencies, simplifies infrastructure deployments, and enables reusable modules that dramatically reduce duplicate code across Azure projects. Whether you're deploying virtual machines, networking, storage, databases, or complete enterprise landing zones, Bicep makes Azure automation easier to understand and maintain.
Beyond the language itself, the episode explores Infrastructure as Code best practices for real-world Azure environments. You'll discover how to structure Bicep projects, separate configuration from infrastructure, use parameter files for different environments, integrate version control and CI/CD pipelines, and build deployment templates that work consistently across development, testing, and production. The discussion also explains why modular design, code reviews, and automation are essential for modern cloud operations.
Whether you're preparing for an Azure certification, migrating from ARM Templates, or starting your Infrastructure as Code journey, this episode provides a practical introduction to Azure Bicep and modern Azure deployment strategies. Learn why Bicep has become the preferred choice for Azure engineers, cloud architects, and Microsoft partners looking to deploy cloud infrastructure faster, more reliably, and with significantly less code.
Quick answer: Bicep is a declarative language for deploying Azure resources in a clearer, more maintainable way than raw ARM templates. This episode explains modules, parameters, repeatable deployments, and how Bicep supports infrastructure-as-code practices, governance, and reliable Azure delivery.
Bicep - Simply Explained is a domain-specific language that uses a declarative syntax for deploying Azure resources. This innovative tool allows you to specify the infrastructure you want, ensuring consistent deployments throughout your development lifecycle. Traditional methods, like manual deployments via the Azure Portal, often lead to complications such as debugging deeply nested JSON objects.
Common pain points in Azure resource management include:
- Complexity increases with larger environments.
- Maintenance becomes difficult with bloated files.
- Merge conflicts arise frequently.
With Bicep - Simply Explained, you can simplify these challenges and streamline your resource management.
Key Takeaways
- Bicep simplifies Azure resource management with a user-friendly syntax, making it easier to write and understand code.
- You can compile Bicep code into ARM templates, ensuring compatibility with Azure while reducing complexity.
- Bicep promotes code reusability through modularization, allowing teams to collaborate more effectively on projects.
- Enhanced tooling support in Bicep, like IntelliSense in Visual Studio Code, helps catch errors and improves coding speed.
- Using Bicep can reduce the amount of code you write by up to 60%, saving time and effort in managing infrastructure.
- Bicep supports multi-environment deployments, ensuring consistent setups across development, testing, and production.
- Version control with Bicep allows you to track changes and roll back if needed, enhancing project reliability.
- Bicep is free and open-source, making it accessible for anyone looking to improve their Azure resource management.
Bicep Overview
Key Features
Bicep is Microsoft's Infrastructure as Code (IaC) language designed specifically for Azure. It serves as a transparent abstraction over Azure Resource Manager (ARM) templates. This means you can perform all actions possible with ARM templates while enjoying a more user-friendly experience. Here are some of the primary features that make Bicep stand out:
-
Simplified Syntax: Bicep simplifies the syntax for writing Infrastructure as Code. You can write cleaner, more readable code compared to traditional ARM JSON. This user-friendly interface reduces complexity and makes it easier to manage your infrastructure.
-
Compilation to ARM Templates: Bicep is a compiled language. It transpiles your Bicep code into ARM template code for resource deployment. This ensures compatibility with Azure's infrastructure while allowing you to leverage the power of ARM templates without the associated difficulties.
-
Code Reusability: Bicep emphasizes code reusability. You can modularize your code without the need for repetitive code. This feature enhances collaboration among team members and streamlines the provisioning process.
-
High Discoverability and Validation: The tooling associated with Bicep is designed for high discoverability and validation. This enhances your user experience, making it easier to find and fix issues in your code.
-
Intuitive Interaction: Writing Bicep feels more intuitive, akin to having a conversation with Azure. This approach simplifies the process, making it less daunting compared to traditional ARM templates.
How Bicep Works
Syntax and Compilation
Bicep's syntax is designed to be straightforward and user-friendly. Unlike traditional ARM templates, which use verbose JSON, Bicep employs a concise and readable syntax. This makes it easier for you to define your infrastructure without getting lost in complex structures.
To illustrate the differences, consider the following table:
| Feature | ARM Templates | Azure Bicep |
|---|---|---|
| Syntax | Verbose JSON format | Concise and readable syntax |
| Tooling | Limited tooling support | Integrated tooling support (IntelliSense, etc.) |
| Modularity | Less support for modularization | Supports modularization for reusability |
When you write a Bicep file, you can easily compile it into an ARM template. The compilation process involves several steps:
- Orchestration: You create Bicep templates and initiate deployment.
- Compile-time: Bicep templates are compiled into ARM templates.
- Runtime: The ARM templates are executed.
- Resource output: The resources are created in Azure.
To compile a Bicep file into an ARM template, you can use the command bicep build main.bicep. This command converts your Bicep file into a JSON file named main.json, ready for deployment.
Resource Management
Bicep integrates seamlessly with Azure Resource Manager (ARM) for resource deployment. This integration allows you to manage your resources efficiently. Here are some key features of Bicep's resource management:
| Feature | Description |
|---|---|
| Language feel | Bicep is a Domain Specific Language (DSL) that allows for a more code-like experience in resource deployment. |
| Readability | Bicep files can be organized into modules, making them cleaner and easier to read compared to ARM templates. |
| Reusable variables | Variables can be reused across modules, enhancing modularity and reducing redundancy in code. |
| VSCode integration | Bicep extensions in VSCode help validate deployment files, ensuring correctness before deployment. |
| More options | Bicep provides additional configuration options, such as resource locks and role assignments, without needing CLI tools. |
| Loops | Bicep supports loops, allowing for efficient resource management, such as adding multiple access policies in one statement. |
| Dependency management | Azure Resource Manager handles dependencies, allowing for controlled deployment order and parallel processing. |
When you deploy resources using Bicep, you follow a clear process:
- Install Bicep: Install the Bicep CLI on your local machine.
- Authoring Bicep Files: Create .bicep files to define your Azure resources.
- Compiling Bicep to ARM Templates: Compile your .bicep files into ARM templates using the Bicep CLI.
- Deploying with Azure CLI: Use the Azure CLI to deploy your compiled ARM templates.
To deploy the Bicep file directly using Azure CLI, use the command:
az deployment group create \
--template-file azuredeploy.bicep \
--resource-group myResourceGroup
With Bicep, you can manage your Azure resources more effectively. The simplified syntax and robust integration with Azure make it a powerful tool for your cloud infrastructure needs.
Benefits of Bicep
Simplified Syntax
Bicep's simplified syntax significantly enhances your productivity when managing Azure resources. You can write cleaner and more concise code compared to traditional ARM templates. This reduction in complexity allows you to focus on defining your infrastructure rather than getting lost in intricate syntax. Here are some key benefits of Bicep's syntax:
- Less Code: Bicep reduces the amount of code you need to write by up to 50% to 60% compared to JSON-based ARM templates. This means you can accomplish more with less effort.
- Improved Readability: Cleaner code improves readability. You and your team can quickly understand the infrastructure setup, making it easier for new members to onboard.
- Enhanced Tooling Support: Integration with tools like Visual Studio Code provides features such as Linting, IntelliSense, and validation. These tools help you write code more quickly and with fewer errors.
The simplified syntax not only accelerates the development process but also fosters better collaboration among team members.
Enhanced Collaboration
Bicep promotes collaboration in team-based Azure projects. Its features allow you to work effectively with others, ensuring everyone stays on the same page. Here are some ways Bicep enhances collaboration:
- Version Control: Bicep allows for version control of files. This feature enables you to track changes over time, making it easier to collaborate with your team.
- Integration with CI/CD Tools: Bicep integrates seamlessly with CI/CD tools like GitHub Actions and Azure DevOps. This integration facilitates automated deployments and ensures consistent environments across your projects.
- Modular Approach: Bicep supports modularization, allowing you to break down complex deployments into smaller, manageable components. This modularity enhances teamwork by enabling different team members to work on separate modules simultaneously.
Bicep also helps reduce configuration drift, which often occurs in cloud environments. The following table summarizes how Bicep minimizes this issue:
| Feature | Benefit |
|---|---|
| Domain-Specific Language | Ensures consistent and repeatable deployments, reducing the likelihood of drift. |
| Integration with Azure | Enforces organizational standards and compliance, ensuring resources meet defined configurations. |
| Automation via CI/CD | Minimizes manual errors, which are a common source of configuration drift. |
| Deployment Stacks | Provides control over resource lifecycle, further reducing drift. |
| Azure Policy | Enforces compliance at scale, ensuring resources adhere to security requirements. |
By leveraging Bicep's features, you can enhance collaboration and maintain a consistent deployment process, ultimately leading to more successful Azure projects.
Getting Started with Bicep
Installation Steps
To begin using Bicep, you need to install it on your system. Follow these steps based on your operating system:
-
- Open PowerShell.
- Create a folder for the installation.
- Fetch the Bicep CLI binary.
- Add the binary to your PATH.
- Verify the installation by running
bicep --help.
-
Install on macOS:
- Open the terminal.
- Fetch the Bicep CLI binary.
- Mark it as executable.
- Add a Gatekeeper exception.
- Move it to
/usr/local/bin. - Verify the installation by running
bicep --help.
-
Install on Linux:
- Open the terminal.
- Fetch the Bicep CLI binary.
- Mark it as executable.
- Move it to
/usr/local/bin. - Verify the installation by running
bicep --help.
Before you start, ensure you meet the prerequisites for a smooth installation. Here’s a quick overview:
| Prerequisite | Description |
|---|---|
| Install Bicep software | Required to create and deploy Bicep files. |
| Azure CLI or Azure PowerShell | Necessary for deploying and decompiling Bicep files. |
| Visual Studio Code & Extension | Provides an integrated development environment for Bicep. |
| Azure CLI version | Must be version 2.20.0 or later. |
| Azure PowerShell version | Must be version 5.6.0 or later. |
Writing Your First Bicep File
Now that you have Bicep installed, you can write your first Bicep file. Here are some best practices to follow:
- Use clear and descriptive names for parameter declarations to enhance readability.
- Utilize parameters for settings that vary between deployments. Use variables for static settings.
- Ensure default values are safe for deployment. Use the @allowed decorator judiciously.
- Provide descriptions for parameters and use comments for clarity within the Bicep files.
- Specify minimum and maximum character lengths for parameters controlling naming.
To create a basic Bicep file that deploys a virtual machine, follow these steps:
- Create a Resource Group Module: Define a resource group in
resource-group.bicep. - Create a Virtual Network Module: Define a virtual network and subnet in
virtual-network.bicep. - Create a Virtual Machine: Define a virtual machine and its associated resources in
virtual-machine.bicep. - Combine Modules in Main Bicep File: Use
main.bicepto combine all modules for deployment. - Parameter File: Use
env/dev.parameters.jsonfor necessary parameters. - Deployment Command: Use Azure CLI commands to authenticate, validate, and deploy the Bicep templates.
With these steps, you can effectively manage your Azure resources using Bicep. Enjoy the streamlined process and the clarity that comes with using this powerful tool!
Use Cases for Bicep
Infrastructure as Code
Bicep plays a crucial role in Infrastructure as Code (IaC) practices within Azure environments. It allows you to define your infrastructure in a clear and concise manner. Here are some key benefits of using Bicep for IaC:
- Declarative Language: Bicep provides a clean abstraction over ARM templates. This makes resource declarations simpler and more intuitive.
- Consistency: You can ensure identical environments across development, testing, and production. This consistency reduces errors and improves reliability.
- Versioning: Store your infrastructure in Git. This allows you to track changes and roll back if necessary.
- Automation: Bicep integrates seamlessly with CI/CD pipelines. This eliminates the need for manual interactions with the Azure portal.
- Documentation: Your Bicep code serves as a blueprint for your architecture. This makes it easier for team members to understand the setup.
For example, consider the following Bicep code snippet that defines a storage account:
param location string = resourceGroup().location
param storageAccountName string = 'myapp${uniqueString(resourceGroup().id)}'
resource stg = {
name: storageAccountName
location: location
kind: 'StorageV2'
sku: {
name: 'Standard_LRS'
}
properties: {
accessTier: 'Hot'
}
}
This example illustrates how Bicep simplifies the process of defining resources, making it more accessible for you.
Multi-Environment Deployments
Bicep excels in multi-environment deployments. It helps you maintain a standardized infrastructure across various environments like development, QA, staging, and production. Here are some advantages of using Bicep for these deployments:
| Advantage | Description |
|---|---|
| Standardization | Bicep helps maintain a consistent infrastructure across multiple environments. |
| Modularity | The use of modular components reduces duplication and enhances maintainability. |
| Consistency | Parameterized templates ensure consistency between different environments. |
Bicep also simplifies the management of different environments. You can use parameterized templates to define settings specific to each environment. This reduces the risk of errors that often arise from manual configuration management.
However, challenges can arise when managing separate configurations. You may face inefficiencies and error-prone processes if you do not use Bicep effectively. By leveraging Bicep's capabilities, you can streamline your deployments and enhance your overall workflow.
Bicep offers significant advantages for managing Azure resources effectively. Its readability makes Bicep files shorter and easier to understand compared to traditional ARM templates. The modularity feature allows for easy reusability through modules, creating resources in a structured way. Additionally, using tools like Visual Studio Code enhances the authoring experience with features such as IntelliSense and linting.
| Benefit | Description |
|---|---|
| Readability | Bicep files are significantly shorter and easier to read compared to ARM templates. |
| Modularity | Bicep allows for easy reusability through modules, enabling the creation of resources in a structured way. |
| Authoring | The use of VS Code with the Bicep Extension enhances the writing experience with features like Intellisense and linting. |
| Order of Operations | Bicep manages resource dependencies automatically, ensuring proper deployment order and parallel processing. |
| Control Statements | Bicep includes looping and conditional statements, simplifying deployment schemes and reducing code complexity. |
To implement Bicep in your projects, consider these recommendations:
- Break down tasks into actionable items for clarity.
- Utilize Azure DevOps for automation to enhance deployment efficiency.
- Run analysis commands to check for consistency across all artifacts before implementation.
Explore Bicep further and consider integrating it into your Azure projects. By adopting Bicep, you can streamline your infrastructure management and improve collaboration within your team.
FAQ
What is Bicep?
Bicep is a domain-specific language for deploying Azure resources. It simplifies Infrastructure as Code (IaC) by using a clean, declarative syntax.
How does Bicep differ from ARM templates?
Bicep offers a more readable syntax compared to ARM templates, which use verbose JSON. Bicep compiles into ARM templates, retaining their functionality while simplifying the authoring process.
Can I use Bicep for existing ARM templates?
Yes, you can convert existing ARM templates into Bicep files. This process allows you to take advantage of Bicep's simplified syntax and features.
Is Bicep free to use?
Absolutely! Bicep is an open-source tool provided by Microsoft. You can download and use it without any cost.
What tools support Bicep development?
You can use Visual Studio Code with the Bicep extension for a better development experience. This setup provides features like IntelliSense and syntax validation.
How do I deploy resources using Bicep?
To deploy resources, write your Bicep file, compile it into an ARM template, and use the Azure CLI to execute the deployment command.
Can I use Bicep for multi-environment deployments?
Yes, Bicep is ideal for multi-environment deployments. You can create parameterized templates to manage different settings for development, testing, and production environments.
Where can I find more resources on Bicep?
You can explore the official Bicep documentation on Microsoft's website. This resource offers tutorials, examples, and best practices for using Bicep effectively.
🎧 Listen to this episode
Want a practical explanation of Bicep? This episode breaks down the topic in clear language and shows why it matters for Microsoft 365, Azure, Power Platform, security, AI, and modern work.
Listen to this episode if you want to:
- Understand the key concepts behind Bicep
- See how it fits into the wider Microsoft technology ecosystem
- Learn where it can create practical value for your organization
You may also enjoy these related M365 FM episodes:
- Azure Bicep at Scale: Modular Infrastructure as Code
- Azure Bicep Fundamentals for Production Projects
- ARM Templates vs Bicep: Why Azure Teams Are Switching
- PowerShell vs Bicep for Azure Infrastructure Automation
- Terraform vs Azure Bicep: Which IaC Tool Should You Choose?
Discover more practical Microsoft conversations on M365 FM.
Last reviewed: July 2026.
Who Should Listen
This episode is for Microsoft practitioners, architects, business leaders, and partners who need a practical foundation before making implementation, governance, or growth decisions.
🎧 You Should Also Listen To
- Infrastructure as Code — A practical next step for extending this topic.
- Azure Resource Manager — A practical next step for extending this topic.
- Azure DevOps — A practical next step for extending this topic.
🚀 Want to be part of m365.fm?
Then stop just listening… and start showing up.
👉 Connect with me on LinkedIn and let’s make something happen:
- 🎙️ Be a podcast guest and share your story
- 🎧 Host your own episode (yes, seriously)
- 💡 Pitch topics the community actually wants to hear
- 🌍 Build your personal brand in the Microsoft 365 space
This isn’t just a podcast — it’s a platform for people who take action.
🔥 Most people wait. The best ones don’t.
👉 Connect with me on LinkedIn and send me a message:
"I want in"
Let’s build something awesome 👊
1
00:00:00,000 --> 00:00:03,800
Welcome to another episode of Microsoft Knowledge Nuggets here on M365.
2
00:00:03,800 --> 00:00:05,460
FM, I'm your host, Mirko Peters.
3
00:00:05,460 --> 00:00:08,660
You've been deploying Azure resources by clicking around in the portal.
4
00:00:08,660 --> 00:00:11,360
It works fine until it doesn't, then you need to do it again,
5
00:00:11,360 --> 00:00:13,200
but you can't remember exactly what you picked.
6
00:00:13,200 --> 00:00:16,400
You need to hand it off to a teammate and they can't follow your steps.
7
00:00:16,400 --> 00:00:18,200
Version control, there's nothing to commit.
8
00:00:18,200 --> 00:00:20,100
That's the problem we're going to solve today.
9
00:00:20,100 --> 00:00:23,640
By the end of this episode, you'll understand what infrastructure as code is,
10
00:00:23,640 --> 00:00:24,900
why Bicep exists,
11
00:00:24,900 --> 00:00:27,840
and how it makes Azure deployments simpler and more reliable.
12
00:00:27,840 --> 00:00:31,880
We'll start with the problem, then the solution, then a practical example you can follow.
13
00:00:31,880 --> 00:00:34,340
Grab your coffee and let's dive in.
14
00:00:34,340 --> 00:00:37,400
The portal problem, the click to deploy trap feels fast.
15
00:00:37,400 --> 00:00:40,160
You log in, fill out a form, hit create and you're done.
16
00:00:40,160 --> 00:00:42,840
But what happens when you need to do it again with the same settings,
17
00:00:42,840 --> 00:00:44,140
region and naming convention?
18
00:00:44,140 --> 00:00:47,940
You have to remember every single thing you picked and that's where things fall apart.
19
00:00:47,940 --> 00:00:52,980
Manual deployment means inconsistent results, human error, and no audit trail.
20
00:00:52,980 --> 00:00:54,440
Here's a real world example.
21
00:00:54,440 --> 00:00:57,740
Someone on your team creates a resource with slightly different settings.
22
00:00:57,740 --> 00:00:59,540
Now you have two environments that don't match.
23
00:00:59,540 --> 00:01:02,840
One works, the other doesn't, and good luck figuring out why.
24
00:01:02,840 --> 00:01:04,640
Then there's the documentation problem.
25
00:01:04,640 --> 00:01:09,240
Infrastructure as a Word document or worse, a YouTube video recorded six months ago
26
00:01:09,240 --> 00:01:11,040
when the portal looked completely different.
27
00:01:11,040 --> 00:01:13,540
Features move, menus change, new options appear.
28
00:01:13,540 --> 00:01:16,640
I sat down with a product manager from the Azure portal team and he said
29
00:01:16,640 --> 00:01:18,440
they released new features twice a day.
30
00:01:18,440 --> 00:01:19,340
Twice a day.
31
00:01:19,340 --> 00:01:21,840
Your Word document is outdated before you finish writing it.
32
00:01:21,840 --> 00:01:24,240
Here's the thing, clicking around works for learning.
33
00:01:24,240 --> 00:01:25,440
It fails for production.
34
00:01:25,440 --> 00:01:26,640
So what's the alternative?
35
00:01:26,640 --> 00:01:30,640
You write a file that describes what you want, then you tell Azure to build it.
36
00:01:30,640 --> 00:01:32,640
What is infrastructure as code?
37
00:01:32,640 --> 00:01:35,440
Infrastructure as code means managing your cloud setup with code
38
00:01:35,440 --> 00:01:37,140
instead of clicking through a web portal.
39
00:01:37,140 --> 00:01:38,440
Here's the core idea.
40
00:01:38,440 --> 00:01:42,640
You write a file that describes your infrastructure, that file lives in your repository,
41
00:01:42,640 --> 00:01:45,840
and you can version control it, review it in a pull request,
42
00:01:45,840 --> 00:01:48,340
and run it again tomorrow to get the same result.
43
00:01:48,340 --> 00:01:50,140
There's a key term here, declarative.
44
00:01:50,140 --> 00:01:53,340
That means you describe what you want, not how to build it.
45
00:01:53,340 --> 00:01:57,040
You don't tell Azure first create a resource group, then add a storage account,
46
00:01:57,040 --> 00:01:58,640
then configure networking.
47
00:01:58,640 --> 00:02:01,840
Instead you say, I want a resource group with a storage account and networking
48
00:02:01,840 --> 00:02:04,440
configured this way, and Azure figures out the order.
49
00:02:04,440 --> 00:02:06,340
The result is something called idempotency.
50
00:02:06,340 --> 00:02:09,040
Run it once, run it a hundred times, and you get the same result.
51
00:02:09,040 --> 00:02:09,740
That's the power.
52
00:02:09,740 --> 00:02:12,140
Think of it like a blueprint versus building by hand.
53
00:02:12,140 --> 00:02:15,140
A blueprint is repeatable, shareable, and reviewable.
54
00:02:15,140 --> 00:02:18,140
Hand it to someone else and they'll build the exact same thing.
55
00:02:18,140 --> 00:02:19,440
Now several tools do this.
56
00:02:19,440 --> 00:02:22,240
Arm templates, bicep, terraform, poloomi.
57
00:02:22,240 --> 00:02:24,440
They all implement the same concept in different ways.
58
00:02:24,440 --> 00:02:25,940
That's an important distinction.
59
00:02:25,940 --> 00:02:27,640
Infrastructure as code is the concept.
60
00:02:27,640 --> 00:02:29,840
Bicep is just one tool that implements it.
61
00:02:29,840 --> 00:02:30,840
But here's the thing.
62
00:02:30,840 --> 00:02:34,040
Azure has had an IAC language for years called arm templates.
63
00:02:34,040 --> 00:02:36,340
And there's a reason Microsoft built a new one.
64
00:02:36,340 --> 00:02:37,640
The arm template problem.
65
00:02:37,640 --> 00:02:40,040
Arm templates are the original Azure IAC format.
66
00:02:40,040 --> 00:02:42,640
They're JSON files, and they have a lot going for them.
67
00:02:42,640 --> 00:02:44,840
Full coverage of every Azure resource,
68
00:02:44,840 --> 00:02:48,140
and the same deployment engine as your users internally.
69
00:02:48,140 --> 00:02:51,640
If you can create it in the portal, you can define it in an arm template.
70
00:02:51,640 --> 00:02:52,640
So what's the problem?
71
00:02:52,640 --> 00:02:55,440
JSON is great for machines, but terrible for humans.
72
00:02:55,440 --> 00:02:56,440
Let me show you what I mean.
73
00:02:56,440 --> 00:02:59,840
A storage account in an arm template takes about 20 lines of code.
74
00:02:59,840 --> 00:03:02,240
The same storage account in bicep, about 10 lines.
75
00:03:02,240 --> 00:03:04,340
The JSON version is roughly twice the size.
76
00:03:04,340 --> 00:03:05,740
And that's just a simple resource.
77
00:03:05,740 --> 00:03:09,140
Imagine a full deployment with networking, compute, databases,
78
00:03:09,140 --> 00:03:10,440
and security rules.
79
00:03:10,440 --> 00:03:12,840
The arm template becomes a wall of text.
80
00:03:12,840 --> 00:03:14,840
The common pain points are predictable.
81
00:03:14,840 --> 00:03:17,340
Missing commas, mismatched brackets for both nesting
82
00:03:17,340 --> 00:03:19,440
that makes it hard to tell where one resource ends
83
00:03:19,440 --> 00:03:20,640
and another begins.
84
00:03:20,640 --> 00:03:22,840
You spend more time wrestling with JSON syntax
85
00:03:22,840 --> 00:03:24,740
than actually defining your infrastructure.
86
00:03:24,740 --> 00:03:26,240
And then there's dependencies.
87
00:03:26,240 --> 00:03:29,140
In ARM, you have to manually declare depends on.
88
00:03:29,140 --> 00:03:31,740
If resource A needs resource B to exist first,
89
00:03:31,740 --> 00:03:33,740
you have to write that out explicitly,
90
00:03:33,740 --> 00:03:35,840
miss one, and your deployment fails.
91
00:03:35,840 --> 00:03:37,740
Good luck figuring out which one you missed.
92
00:03:37,740 --> 00:03:40,840
If you've ever tried to write a 200 line JSON file by hand,
93
00:03:40,840 --> 00:03:42,440
it's not fun, not even a little bit.
94
00:03:42,440 --> 00:03:43,840
The learning curve is steep.
95
00:03:43,840 --> 00:03:46,640
New team members struggle to understand arm templates.
96
00:03:46,640 --> 00:03:48,140
The barrier to entry is high.
97
00:03:48,140 --> 00:03:49,340
And what happens in practice?
98
00:03:49,340 --> 00:03:52,540
Many teams end up with one person who knows the arm template.
99
00:03:52,540 --> 00:03:54,440
That person becomes a single point of failure.
100
00:03:54,440 --> 00:03:56,440
They're the only one who can modify the deployment
101
00:03:56,440 --> 00:03:58,640
and the only one who can debug it when something breaks.
102
00:03:58,640 --> 00:04:00,140
That's not sustainable.
103
00:04:00,140 --> 00:04:01,640
Microsoft heard the feedback.
104
00:04:01,640 --> 00:04:04,240
So they built bicep to fix exactly these problems.
105
00:04:04,240 --> 00:04:05,540
What is bicep?
106
00:04:05,540 --> 00:04:06,840
So what exactly is bicep?
107
00:04:06,840 --> 00:04:09,540
It's a language designed for deploying Azure resources
108
00:04:09,540 --> 00:04:11,440
and at its core, it's a transpiler.
109
00:04:11,440 --> 00:04:14,640
You write bicep and it compiles down to arm JSON.
110
00:04:14,640 --> 00:04:17,040
Same engine underneath, but a much cleaner way to write.
111
00:04:17,040 --> 00:04:20,940
And the name bicep is actually arms-beld backwards, bicep arm.
112
00:04:20,940 --> 00:04:22,640
A little inside joke from Microsoft.
113
00:04:22,640 --> 00:04:23,940
But once you see it in action,
114
00:04:23,940 --> 00:04:24,740
it makes sense.
115
00:04:24,740 --> 00:04:26,840
bicep sits on top of arm instead of replacing it.
116
00:04:26,840 --> 00:04:28,840
You get the same power with a simpler syntax.
117
00:04:28,840 --> 00:04:30,040
bicep doesn't replace arm.
118
00:04:30,040 --> 00:04:31,440
It builds on top of it.
119
00:04:31,440 --> 00:04:33,740
Everything you can do with arm, you can do with bicep.
120
00:04:33,740 --> 00:04:35,640
Every resource type, every API version,
121
00:04:35,640 --> 00:04:37,440
every configuration option is all there.
122
00:04:37,440 --> 00:04:39,140
The only difference is how you write it.
123
00:04:39,140 --> 00:04:40,540
The syntax is much cleaner.
124
00:04:40,540 --> 00:04:43,140
No quotes around property names, no comments between properties,
125
00:04:43,140 --> 00:04:44,140
no brackets to track.
126
00:04:44,140 --> 00:04:45,140
It's just simpler.
127
00:04:45,140 --> 00:04:47,240
Compare the two versions side by side.
128
00:04:47,240 --> 00:04:50,040
The arm JSON version of a storage account is full of noise,
129
00:04:50,040 --> 00:04:52,740
quotes, commas, brackets, nesting.
130
00:04:52,740 --> 00:04:54,840
The bicep version has the same information,
131
00:04:54,840 --> 00:04:55,840
but it's readable.
132
00:04:55,840 --> 00:04:57,640
You can look at it and immediately understand
133
00:04:57,640 --> 00:05:00,240
what it's doing without having to pass through layers
134
00:05:00,240 --> 00:05:01,440
of JSON syntax.
135
00:05:01,440 --> 00:05:04,240
One big improvement is automatic dependency inference.
136
00:05:04,240 --> 00:05:07,240
In arm, you have to manually declare depends on.
137
00:05:07,240 --> 00:05:10,440
But in bicep, if resource a references resource b,
138
00:05:10,440 --> 00:05:12,840
the system figures out the dependency automatically.
139
00:05:12,840 --> 00:05:13,940
You don't need to write it out.
140
00:05:13,940 --> 00:05:14,840
It just works.
141
00:05:14,840 --> 00:05:16,840
And that alone saves hours of debugging.
142
00:05:16,840 --> 00:05:18,540
Modules are another big piece.
143
00:05:18,540 --> 00:05:20,640
You can break your infrastructure into smaller,
144
00:05:20,640 --> 00:05:23,340
reusable pieces and share them across projects.
145
00:05:23,340 --> 00:05:25,040
One team builds a networking module,
146
00:05:25,040 --> 00:05:26,440
and another team uses it.
147
00:05:26,440 --> 00:05:28,440
No need to reinvent the wheel every time.
148
00:05:28,440 --> 00:05:31,240
Parameters and variables let you define your inputs once
149
00:05:31,240 --> 00:05:32,740
and reuse them everywhere.
150
00:05:32,740 --> 00:05:35,540
No more searching and replacing hard-coded values.
151
00:05:35,540 --> 00:05:38,440
And string interpolation means you can write prefix storage
152
00:05:38,440 --> 00:05:40,740
instead of complex concatenation functions.
153
00:05:40,740 --> 00:05:43,440
The tooling is another reason bicep is so nice to work with.
154
00:05:43,440 --> 00:05:45,440
The VS code extension gives you Intel eSense,
155
00:05:45,440 --> 00:05:48,240
syntax highlighting and real-time error checking.
156
00:05:48,240 --> 00:05:50,840
Honestly, it's one of the best language extensions in VS code.
157
00:05:50,840 --> 00:05:53,640
You start typing and it suggests what comes next.
158
00:05:53,640 --> 00:05:55,640
Make a mistake and it tells you immediately.
159
00:05:55,640 --> 00:05:57,240
No more waiting for deployment to fail
160
00:05:57,240 --> 00:05:59,240
before you find out you missed a comma.
161
00:05:59,240 --> 00:06:01,240
So what does this actually look like in practice?
162
00:06:01,240 --> 00:06:03,240
Let's look at how bicep differs from arm.
163
00:06:03,240 --> 00:06:05,840
Bicep versus arm, what's actually different?
164
00:06:05,840 --> 00:06:07,440
Let's talk about what's actually different
165
00:06:07,440 --> 00:06:09,640
when you write bicep instead of arm JSON.
166
00:06:09,640 --> 00:06:11,440
File size is one obvious difference.
167
00:06:11,440 --> 00:06:15,240
Bicep files are roughly half the size of equivalent arm templates.
168
00:06:15,240 --> 00:06:16,640
That's not an exaggeration.
169
00:06:16,640 --> 00:06:19,240
You remove all the quotes, commas, brackets and boilerplate
170
00:06:19,240 --> 00:06:21,440
and what's left is just the infrastructure definition.
171
00:06:21,440 --> 00:06:23,040
Half the code, same result.
172
00:06:23,040 --> 00:06:24,640
Readability follows naturally.
173
00:06:24,640 --> 00:06:27,840
Few aligns, cleaner structure, and easier to understand at a glance.
174
00:06:27,840 --> 00:06:29,640
When you open a bicep file, you can scan it
175
00:06:29,640 --> 00:06:31,240
and understand what's being deployed.
176
00:06:31,240 --> 00:06:33,840
With arm JSON, you have to pass through layers of nesting
177
00:06:33,840 --> 00:06:36,040
before you find the actual resource configuration.
178
00:06:36,040 --> 00:06:38,040
Dependencies are a huge time saver.
179
00:06:38,040 --> 00:06:40,440
In arm, you manually declare depends on.
180
00:06:40,440 --> 00:06:42,240
This one and your deployment fails.
181
00:06:42,240 --> 00:06:45,240
In bicep, if resource A references resource B,
182
00:06:45,240 --> 00:06:47,040
the system handles it automatically.
183
00:06:47,040 --> 00:06:49,640
It adds the dependency when it compiles to arm JSON.
184
00:06:49,640 --> 00:06:51,640
You don't think about it, it just works.
185
00:06:51,640 --> 00:06:53,840
And that alone saves hours of debugging.
186
00:06:53,840 --> 00:06:55,440
Modules are another major difference.
187
00:06:55,440 --> 00:06:58,240
Arm had nested templates, but they were painful to work with.
188
00:06:58,240 --> 00:07:00,840
Separate files, complex linking, hard to version.
189
00:07:00,840 --> 00:07:04,440
Bicep has modules which are cleaner, versionable and reusable.
190
00:07:04,440 --> 00:07:07,640
You define a module once, publish it to a registry
191
00:07:07,640 --> 00:07:09,040
and reference it from anywhere.
192
00:07:09,040 --> 00:07:11,440
Same module, same configuration every time.
193
00:07:11,440 --> 00:07:13,440
The deployment process itself is identical.
194
00:07:13,440 --> 00:07:16,040
Bicep compiles to arm JSON, then Azure resource manager
195
00:07:16,040 --> 00:07:18,440
deploys it, same engine, same pipeline.
196
00:07:18,440 --> 00:07:20,240
You don't need to change your deployment process,
197
00:07:20,240 --> 00:07:22,240
you just change how you write the templates.
198
00:07:22,240 --> 00:07:24,440
What if is a feature that arm technically has,
199
00:07:24,440 --> 00:07:26,640
but bicep makes it much more accessible?
200
00:07:26,640 --> 00:07:28,640
You can preview changes before deploying
201
00:07:28,640 --> 00:07:31,640
and see exactly what will be created, modified or deleted.
202
00:07:31,640 --> 00:07:33,640
No surprises, no accidental deletions.
203
00:07:33,640 --> 00:07:35,240
You run what if, review the output,
204
00:07:35,240 --> 00:07:36,840
and if it looks right, you deploy.
205
00:07:36,840 --> 00:07:39,240
The learning curve is one area where bicep stands out.
206
00:07:39,240 --> 00:07:41,240
Arm JSON assumes you know what you're doing.
207
00:07:41,240 --> 00:07:43,240
It's designed for machines, not humans.
208
00:07:43,240 --> 00:07:44,640
Bicep is designed for beginners.
209
00:07:44,640 --> 00:07:46,640
Intuitive syntax tooling that guides you.
210
00:07:46,640 --> 00:07:48,640
You can learn it in an afternoon and be productive
211
00:07:48,640 --> 00:07:49,640
by the end of the week.
212
00:07:49,640 --> 00:07:52,440
Microsoft has made bicep the recommended authoring experience
213
00:07:52,440 --> 00:07:55,040
all new features and improvements target bicep first.
214
00:07:55,040 --> 00:07:57,640
Arm templates still work and they're not going away,
215
00:07:57,640 --> 00:07:59,640
but you probably shouldn't be writing new ones.
216
00:07:59,640 --> 00:08:01,240
If you're starting a new project today,
217
00:08:01,240 --> 00:08:02,440
bicep is the way to go.
218
00:08:02,440 --> 00:08:05,240
Three lines of bicep to deploy a resource group.
219
00:08:05,240 --> 00:08:06,240
Just three lines.
220
00:08:06,240 --> 00:08:08,440
The equivalent arm JSON is about 15 lines.
221
00:08:08,440 --> 00:08:10,040
Same result, same deployment,
222
00:08:10,040 --> 00:08:12,440
but one is readable and the other is noise.
223
00:08:12,440 --> 00:08:13,840
Now, you might be wondering,
224
00:08:13,840 --> 00:08:14,840
what about terraform?
225
00:08:14,840 --> 00:08:16,640
Should I learn bicep or terraform?
226
00:08:16,640 --> 00:08:18,240
Bicep versus terraform,
227
00:08:18,240 --> 00:08:19,440
which one should you use?
228
00:08:19,440 --> 00:08:21,640
Welcome back to Microsoft Knowledge Nuggets.
229
00:08:21,640 --> 00:08:22,640
I'm Möko Peters
230
00:08:22,640 --> 00:08:24,840
and today we're tackling a question that keeps coming up.
231
00:08:24,840 --> 00:08:26,040
Bicep or terraform?
232
00:08:26,040 --> 00:08:26,840
Let's break it down.
233
00:08:26,840 --> 00:08:28,440
Terraform works across multiple clouds.
234
00:08:28,440 --> 00:08:30,640
You can use it for Azure, AWS, GCP,
235
00:08:30,640 --> 00:08:32,040
or even all three at once.
236
00:08:32,040 --> 00:08:34,840
Bicep on the other hand is built for Azure and nothing else.
237
00:08:34,840 --> 00:08:36,440
That core difference affects everything else.
238
00:08:36,440 --> 00:08:38,840
Now, if you're working across multiple clouds,
239
00:08:38,840 --> 00:08:40,440
terraform is the way to go.
240
00:08:40,440 --> 00:08:43,440
You learn one language, one tool, one workflow,
241
00:08:43,440 --> 00:08:45,040
and it works everywhere.
242
00:08:45,040 --> 00:08:46,840
But if you're primarily Azure,
243
00:08:46,840 --> 00:08:48,840
bicep has some real advantages.
244
00:08:48,840 --> 00:08:49,840
Here's the first one.
245
00:08:49,840 --> 00:08:51,440
No state file to manage.
246
00:08:51,440 --> 00:08:54,440
Terraform keeps a state file that tracks what it deploys
247
00:08:54,440 --> 00:08:55,840
and that file is critical.
248
00:08:55,840 --> 00:08:57,640
If it gets corrupted or out of sync,
249
00:08:57,640 --> 00:08:58,840
you have a serious problem.
250
00:08:58,840 --> 00:09:02,240
You have to store it securely, back it up, and manage access.
251
00:09:02,240 --> 00:09:05,040
Bicep talks directly to Azure Resource Manager,
252
00:09:05,040 --> 00:09:07,640
checking what's already there and figuring out the differences.
253
00:09:07,640 --> 00:09:09,640
No state file means no sync issues
254
00:09:09,640 --> 00:09:11,240
and no risk of corruption.
255
00:09:11,240 --> 00:09:13,440
Second advantage, day zero support.
256
00:09:13,440 --> 00:09:15,640
When Microsoft releases a new Azure feature,
257
00:09:15,640 --> 00:09:18,040
bicep supports it immediately, same day.
258
00:09:18,040 --> 00:09:20,240
Terraform has to wait for a provider update,
259
00:09:20,240 --> 00:09:22,840
which is sometimes fast, sometimes takes weeks.
260
00:09:22,840 --> 00:09:24,840
If you need to use a new feature right away,
261
00:09:24,840 --> 00:09:26,640
bicep is the only option.
262
00:09:26,640 --> 00:09:28,240
Third, it's built by the Azure team,
263
00:09:28,240 --> 00:09:30,640
the tooling, the IntelliSense, the error messages,
264
00:09:30,640 --> 00:09:33,440
all designed around how Azure actually works.
265
00:09:33,440 --> 00:09:35,640
When you write bicep, you're using a language
266
00:09:35,640 --> 00:09:38,040
that understands Azure resources natively.
267
00:09:38,040 --> 00:09:39,640
It knows what properties are required,
268
00:09:39,640 --> 00:09:42,040
what values are valid, and what dependencies exist.
269
00:09:42,040 --> 00:09:43,840
That deep integration is hard to replicate
270
00:09:43,840 --> 00:09:45,040
with a third-party tool.
271
00:09:45,040 --> 00:09:46,240
You can also use both.
272
00:09:46,240 --> 00:09:49,040
Many organizations use bicep for platform and landing zones
273
00:09:49,040 --> 00:09:51,240
and Terraform for multi-cloud workloads.
274
00:09:51,240 --> 00:09:52,840
They're not mutually exclusive.
275
00:09:52,840 --> 00:09:55,040
You can pick the right tool for each job.
276
00:09:55,040 --> 00:09:56,440
The honest answer is this,
277
00:09:56,440 --> 00:09:57,840
for learning Azure specifically,
278
00:09:57,840 --> 00:09:59,440
bicep has fewer moving parts.
279
00:09:59,440 --> 00:10:01,440
It's a simpler path when you're starting out.
280
00:10:01,440 --> 00:10:02,840
You don't need to learn about state files,
281
00:10:02,840 --> 00:10:04,640
providers, or back-and-configuration.
282
00:10:04,640 --> 00:10:08,040
You install Azure CLI, OpenVS code, and start writing.
283
00:10:08,040 --> 00:10:09,040
Enough theory.
284
00:10:09,040 --> 00:10:11,840
Let's talk about what you actually need to get started.
285
00:10:11,840 --> 00:10:12,840
Getting started.
286
00:10:12,840 --> 00:10:14,040
What you actually need.
287
00:10:14,040 --> 00:10:15,840
You need two things to get started.
288
00:10:15,840 --> 00:10:18,840
Azure CLI and the bicep extension for vs code,
289
00:10:18,840 --> 00:10:19,440
that's it.
290
00:10:19,440 --> 00:10:21,240
No separate bicep CLI to install.
291
00:10:21,240 --> 00:10:22,640
No extra tools to configure.
292
00:10:22,640 --> 00:10:24,640
Azure CLI comes with bicep built-in.
293
00:10:24,640 --> 00:10:26,640
Installing Azure CLI is pretty simple.
294
00:10:26,640 --> 00:10:27,840
Go to Microsoft Docs.
295
00:10:27,840 --> 00:10:30,440
Find the install page for your operating system.
296
00:10:30,440 --> 00:10:32,240
If you're on Mac, it's one command,
297
00:10:32,240 --> 00:10:34,040
brew install as your client.
298
00:10:34,040 --> 00:10:36,040
On Windows, there's an MSI installer,
299
00:10:36,040 --> 00:10:37,440
download it, run it, done.
300
00:10:37,440 --> 00:10:39,440
It also works on Linux through your package manager.
301
00:10:39,440 --> 00:10:40,640
Once it's installed,
302
00:10:40,640 --> 00:10:43,440
run AZ version to confirm everything's working.
303
00:10:43,440 --> 00:10:45,440
You should see both the Azure CLI version
304
00:10:45,440 --> 00:10:47,040
and the bicep version listed.
305
00:10:47,040 --> 00:10:48,040
Now OpenVS code,
306
00:10:48,040 --> 00:10:50,040
go to the extensions panel on the left side
307
00:10:50,040 --> 00:10:51,440
and search for bicep.
308
00:10:51,440 --> 00:10:53,040
Install the one from Microsoft.
309
00:10:53,040 --> 00:10:54,040
Not a third party one,
310
00:10:54,040 --> 00:10:55,040
the official one.
311
00:10:55,040 --> 00:10:56,440
You really need this extension.
312
00:10:56,440 --> 00:10:58,840
It gives you IntelliSense that suggests resource properties
313
00:10:58,840 --> 00:11:00,640
as you type, highlight syntax,
314
00:11:00,640 --> 00:11:02,240
so you can spot errors at a glance,
315
00:11:02,240 --> 00:11:03,840
and checks for mistakes in real time.
316
00:11:03,840 --> 00:11:05,240
You'll see red squiggly lines
317
00:11:05,240 --> 00:11:07,640
under anything that's wrong before you even try to deploy.
318
00:11:07,640 --> 00:11:10,240
Honestly, it's one of the best language extensions in VS code
319
00:11:10,240 --> 00:11:13,040
and a big part of why bicep is so pleasant to work with.
320
00:11:13,040 --> 00:11:15,040
Now create a new file and name it main.
321
00:11:15,040 --> 00:11:16,440
Bicep, that bicep extension,
322
00:11:16,440 --> 00:11:18,440
tells VS code to activate the extension.
323
00:11:18,440 --> 00:11:20,440
Without it, you're just writing plain text.
324
00:11:20,440 --> 00:11:22,840
With it, you get the full tooling experience.
325
00:11:22,840 --> 00:11:23,840
Here's a quick example.
326
00:11:23,840 --> 00:11:26,240
A resource group deployment in three lines of code.
327
00:11:26,240 --> 00:11:28,840
First, you set the target scope to subscription,
328
00:11:28,840 --> 00:11:30,440
then you define the resource,
329
00:11:30,440 --> 00:11:32,240
a resource group with a name and a location.
330
00:11:32,240 --> 00:11:33,440
That's it, three lines.
331
00:11:33,440 --> 00:11:35,440
Compare that to the ARM JSON equivalent,
332
00:11:35,440 --> 00:11:38,040
which is about 15 lines of brackets and quotes.
333
00:11:38,040 --> 00:11:40,440
To deploy it, you use the Azure CLI.
334
00:11:40,440 --> 00:11:42,640
Because you're deploying at the subscription scope,
335
00:11:42,640 --> 00:11:44,840
the command is AZ deployment subcreate.
336
00:11:44,840 --> 00:11:47,240
You pass in a location for the deployment metadata
337
00:11:47,240 --> 00:11:48,640
and point it to your bicep file.
338
00:11:48,640 --> 00:11:49,840
That's the command line way,
339
00:11:49,840 --> 00:11:51,440
but there's also a guided experience.
340
00:11:51,440 --> 00:11:53,440
In VS code, right-click the bicep file
341
00:11:53,440 --> 00:11:55,240
and select deploy bicep file.
342
00:11:55,240 --> 00:11:56,840
It walks you through the whole process.
343
00:11:56,840 --> 00:11:58,240
It asks for a deployment name,
344
00:11:58,240 --> 00:12:00,040
asks you to select your subscription,
345
00:12:00,040 --> 00:12:02,240
asks you to create or select a resource group,
346
00:12:02,240 --> 00:12:04,440
and asks if you have a parameter file.
347
00:12:04,440 --> 00:12:06,040
You say no and it deploys.
348
00:12:06,040 --> 00:12:07,840
The result appears in you as your portal.
349
00:12:07,840 --> 00:12:09,240
Same is clicking around in the portal,
350
00:12:09,240 --> 00:12:11,040
but now you have a file you can reuse.
351
00:12:11,040 --> 00:12:12,440
You can commit it to your repository,
352
00:12:12,440 --> 00:12:13,440
share it with your team,
353
00:12:13,440 --> 00:12:14,640
and run it again tomorrow.
354
00:12:14,640 --> 00:12:16,040
And here's the magic part.
355
00:12:16,040 --> 00:12:18,640
Run the same deployment again and watch what happens.
356
00:12:18,640 --> 00:12:21,040
The power of identity.
357
00:12:21,040 --> 00:12:22,640
Here's the thing about running deployments.
358
00:12:22,640 --> 00:12:24,640
You want to be able to run them over and over
359
00:12:24,640 --> 00:12:25,640
without breaking anything.
360
00:12:25,640 --> 00:12:27,440
That's exactly what identity gives you.
361
00:12:27,440 --> 00:12:29,040
The first time you run the bicep file,
362
00:12:29,040 --> 00:12:30,240
it creates the resource group,
363
00:12:30,240 --> 00:12:32,640
but the second time you run it, nothing happens.
364
00:12:32,640 --> 00:12:35,040
No error, no duplicate, nothing.
365
00:12:35,040 --> 00:12:36,640
bicep checks what's already in Azure,
366
00:12:36,640 --> 00:12:37,840
compares it to what you asked for,
367
00:12:37,840 --> 00:12:39,640
and says there's nothing to change.
368
00:12:39,640 --> 00:12:41,640
It didn't try to create a new resource group,
369
00:12:41,640 --> 00:12:44,040
and it didn't error out saying one already exists.
370
00:12:44,040 --> 00:12:47,240
It just confirmed that the current state matches the desired state.
371
00:12:47,240 --> 00:12:49,840
Think of it like running GitStaters on a clean repository.
372
00:12:49,840 --> 00:12:50,840
There's nothing to do.
373
00:12:50,840 --> 00:12:52,840
Everything is already exactly how it should be.
374
00:12:52,840 --> 00:12:55,040
This is the power of infrastructure as code.
375
00:12:55,040 --> 00:12:56,640
You can run your deployment over and over
376
00:12:56,640 --> 00:12:59,040
and end up with the same result every single time.
377
00:12:59,040 --> 00:13:00,640
No surprises, no drift.
378
00:13:00,640 --> 00:13:03,240
You know exactly what's deployed because the file says so.
379
00:13:03,240 --> 00:13:05,240
The file becomes your single source of truth.
380
00:13:05,240 --> 00:13:07,440
You never have to wonder if you remember the setting
381
00:13:07,440 --> 00:13:08,440
or deal with the,
382
00:13:08,440 --> 00:13:10,240
it works on my machine problem
383
00:13:10,240 --> 00:13:13,440
or hunt through the Azure portal to check if someone changed something.
384
00:13:13,440 --> 00:13:14,840
The file tells you what's there.
385
00:13:14,840 --> 00:13:16,040
If you want to change something,
386
00:13:16,040 --> 00:13:17,640
you change the file and redeploy.
387
00:13:17,640 --> 00:13:18,840
If you want to verify,
388
00:13:18,840 --> 00:13:20,240
you run the deployment again
389
00:13:20,240 --> 00:13:22,040
and it confirms everything matches.
390
00:13:22,040 --> 00:13:24,240
That's how you build confidence in your infrastructure.
391
00:13:24,240 --> 00:13:26,040
The file is the source of truth.
392
00:13:26,040 --> 00:13:27,840
Not your memory, not a word document,
393
00:13:27,840 --> 00:13:29,840
not a YouTube video from six months ago.
394
00:13:29,840 --> 00:13:30,840
The file.
395
00:13:30,840 --> 00:13:33,840
So where does bicep fit into the bigger picture of Azure?
396
00:13:33,840 --> 00:13:34,840
The big picture.
397
00:13:34,840 --> 00:13:36,440
Where bicep fits.
398
00:13:36,440 --> 00:13:39,440
bicep lives inside the Azure Resource Manager ecosystem.
399
00:13:39,440 --> 00:13:40,640
It's not a separate tool.
400
00:13:40,640 --> 00:13:42,040
Many people think it is,
401
00:13:42,040 --> 00:13:44,840
but it's actually just a better way to write arm templates.
402
00:13:44,840 --> 00:13:46,240
Under the hood, it's still arm.
403
00:13:46,240 --> 00:13:48,240
The same deployment engine, the same API,
404
00:13:48,240 --> 00:13:48,840
the same everything.
405
00:13:48,840 --> 00:13:50,240
The only difference is how you write it.
406
00:13:50,240 --> 00:13:52,440
And because bicep compiles to arm,
407
00:13:52,440 --> 00:13:54,840
everything that works with arm works with bicep.
408
00:13:54,840 --> 00:13:57,640
Azure Policy enforces compliance on your deployments.
409
00:13:57,640 --> 00:13:59,840
RBAC controls who can deploy what?
410
00:13:59,840 --> 00:14:02,040
Cost management track spending on your resources,
411
00:14:02,040 --> 00:14:04,040
Azure DevOps and GitHub actions,
412
00:14:04,040 --> 00:14:06,040
deploy your bicep files through pipelines.
413
00:14:06,040 --> 00:14:09,240
All of it works perfectly because bicep produces standard arm, Jason.
414
00:14:09,240 --> 00:14:11,040
You don't lose anything by switching.
415
00:14:11,040 --> 00:14:12,440
In fact, you gain clarity.
416
00:14:12,440 --> 00:14:15,440
Microsoft has built a whole ecosystem around bicep.
417
00:14:15,440 --> 00:14:20,040
Azure Verified Modules or AVM is a curated library of bicep and terraform modules
418
00:14:20,040 --> 00:14:21,240
that follow best practices.
419
00:14:21,240 --> 00:14:23,040
You don't have to write everything from scratch.
420
00:14:23,040 --> 00:14:25,440
You can use pre-built modules for common patterns
421
00:14:25,440 --> 00:14:28,640
like virtual networks, storage accounts and app services.
422
00:14:28,640 --> 00:14:30,440
They're tested, maintained and aligned
423
00:14:30,440 --> 00:14:32,040
with the well-architected framework.
424
00:14:32,040 --> 00:14:35,240
The Cloud Adoption Framework includes bicep reference implementations
425
00:14:35,240 --> 00:14:37,240
for standardized enterprise architectures.
426
00:14:37,240 --> 00:14:38,440
If you're building a landing zone,
427
00:14:38,440 --> 00:14:40,240
there's a bicep template for that.
428
00:14:40,240 --> 00:14:42,440
Deployment stacks give you life cycle management
429
00:14:42,440 --> 00:14:43,840
for groups of resources.
430
00:14:43,840 --> 00:14:45,240
You can deploy a stack,
431
00:14:45,240 --> 00:14:47,440
and if you remove a resource from your bicep file,
432
00:14:47,440 --> 00:14:49,040
the stack can clean it up for you.
433
00:14:49,040 --> 00:14:51,240
Or protect it from accidental deletion.
434
00:14:51,240 --> 00:14:52,240
You decide.
435
00:14:52,240 --> 00:14:54,240
The ecosystem keeps growing with more modules,
436
00:14:54,240 --> 00:14:57,640
better tooling and deeper integration with AI and GitHub Copilot.
437
00:14:57,640 --> 00:14:59,640
You can describe what you want in plain English
438
00:14:59,640 --> 00:15:02,440
and Copilot generates the bicep code for you.
439
00:15:02,440 --> 00:15:04,640
Microsoft continues to invest in bicep
440
00:15:04,640 --> 00:15:06,840
as the primary authoring experience for Azure.
441
00:15:06,840 --> 00:15:09,040
So new features target bicep first.
442
00:15:09,040 --> 00:15:10,440
Arm templates still work,
443
00:15:10,440 --> 00:15:12,240
but the innovation is happening in bicep.
444
00:15:12,240 --> 00:15:13,040
So here's the takeaway.
445
00:15:13,040 --> 00:15:14,640
If you're working in a rure,
446
00:15:14,640 --> 00:15:17,640
bicep is the natural next step beyond clicking in the portal.
447
00:15:17,640 --> 00:15:20,040
You don't have to learn terraform or master arm Jason.
448
00:15:20,040 --> 00:15:21,240
You install two things,
449
00:15:21,240 --> 00:15:22,440
write a few lines of code
450
00:15:22,440 --> 00:15:24,040
and you're deploying infrastructure
451
00:15:24,040 --> 00:15:26,440
that's repeatable, version controlled and reliable.
452
00:15:26,440 --> 00:15:29,040
Let me leave you with something practical you can do today.
453
00:15:29,040 --> 00:15:31,240
So now you know what infrastructure as code is,
454
00:15:31,240 --> 00:15:34,440
why bicep exists and how it makes Azure deployments simpler.
455
00:15:34,440 --> 00:15:35,440
Here's the main point.
456
00:15:35,440 --> 00:15:37,440
Bicep isn't a different deployment system.
457
00:15:37,440 --> 00:15:40,840
It's a better way to write the same arm templates you'd write anyway
458
00:15:40,840 --> 00:15:44,040
using the same engine and as your resource manager under the hood,
459
00:15:44,040 --> 00:15:46,440
just in a language humans can actually read and write.
460
00:15:46,440 --> 00:15:47,840
Here's a challenge for you,
461
00:15:47,840 --> 00:15:49,240
create a main dot bicep file,
462
00:15:49,240 --> 00:15:51,640
deploy a resource group and run the deployment twice.
463
00:15:51,640 --> 00:15:53,040
Watch it work both times.
464
00:15:53,040 --> 00:15:55,440
The first time it creates the resource and the second time
465
00:15:55,440 --> 00:15:57,040
it confirms nothing changed.
466
00:15:57,040 --> 00:15:59,040
That's the moment it clicks when you realize
467
00:15:59,040 --> 00:16:01,240
you're never going back to clicking around in the portal.
468
00:16:01,240 --> 00:16:03,040
This is the foundation.
469
00:16:03,040 --> 00:16:04,640
From here you can add storage accounts,
470
00:16:04,640 --> 00:16:08,240
virtual networks and app services using the same pattern.
471
00:16:08,240 --> 00:16:10,240
Write a file, deploy it, run it again.
472
00:16:10,240 --> 00:16:12,040
That file becomes your source of truth
473
00:16:12,040 --> 00:16:13,840
and everything else follows from it.
474
00:16:13,840 --> 00:16:15,040
If you found this helpful,
475
00:16:15,040 --> 00:16:17,840
share it with someone who's still clicking around in the portal.
476
00:16:17,840 --> 00:16:18,840
They'll thank you.
477
00:16:18,840 --> 00:16:20,840
Subscribe on your favorite podcast platform
478
00:16:20,840 --> 00:16:25,840
and in the next episode will take bicep further by deploying real resources with real properties.
Founder of m365.fm, m365.show and m365con.net
Mirko Peters is a Microsoft 365 expert, content creator, and founder of m365.fm, a platform dedicated to sharing practical insights on modern workplace technologies. His work focuses on Microsoft 365 governance, security, collaboration, and real-world implementation strategies.
Through his podcast and written content, Mirko provides hands-on guidance for IT professionals, architects, and business leaders navigating the complexities of Microsoft 365. He is known for translating complex topics into clear, actionable advice, often highlighting common mistakes and overlooked risks in real-world environments.
With a strong emphasis on community contribution and knowledge sharing, Mirko is actively building a platform that connects experts, shares experiences, and helps organizations get the most out of their Microsoft 365 investments.
