July 14, 2026
Bicep - Simply Explained
Deploying Azure resources through the Azure Portal is great for learning, but it quickly becomes difficult to repeat, document, and automate. That's where Bicep comes in. In this episode, we explain Microsoft's Infrastructure as Code language in plain English, showing how Bicep simplifies Azure deployments while providing consistency, automation, and version control. Whether you're an Azure administrator, cloud engineer, developer, or just starting your Infrastructure as Code journey, this episode will help you understand why Microsoft recommends Bicep as the future of Azure deployments.
WHY MANUAL DEPLOYMENTS DON'T SCALE
Creating Azure resources by clicking through the portal may seem fast, but it introduces inconsistency, human error, and poor documentation. Every manual deployment risks configuration drift, forgotten settings, and environments that no longer match each other. As organizations grow, these challenges become increasingly difficult to manage. Bicep solves this by replacing manual configuration with reusable deployment files that can be reviewed, version-controlled, and executed repeatedly with identical results.
UNDERSTANDING INFRASTRUCTURE AS CODE
Infrastructure as Code (IaC) is the practice of managing cloud infrastructure through source code instead of manual administration. Rather than describing deployment steps one by one, Bicep follows a declarative approach where you simply describe the desired end state. Azure Resource Manager determines how to provision resources while automatically handling deployment order and dependencies. This approach creates predictable, repeatable deployments that become the single source of truth for your cloud infrastructure.
WHY MICROSOFT CREATED BICEP
Before Bicep, Azure deployments relied primarily on ARM Templates written in JSON. While ARM remains extremely powerful, JSON templates can become lengthy, difficult to read, and challenging to maintain. Bicep was created to solve these problems without replacing Azure Resource Manager itself. Instead, Bicep compiles directly into ARM Templates behind the scenes, giving administrators the same deployment engine while dramatically improving readability, maintainability, and developer productivity.
WHAT MAKES BICEP DIFFERENT?
Bicep introduces a clean, domain-specific language designed specifically for Azure deployments. It removes unnecessary JSON syntax, automatically detects resource dependencies, supports reusable modules, simplifies parameter handling, and offers powerful tooling through Visual Studio Code. Features such as IntelliSense, syntax validation, real-time error detection, and string interpolation make writing Azure infrastructure significantly easier while reducing common deployment mistakes.
BICEP VS ARM TEMPLATES
Although both technologies ultimately deploy resources through Azure Resource Manager, the authoring experience is very different. Bicep files are significantly smaller, easier to understand, and require far less boilerplate code than equivalent ARM Templates. Automatic dependency inference removes the need for manually managing deployment order, while modular design encourages reusable infrastructure components that can be shared across multiple projects and teams. Microsoft now recommends Bicep as the preferred language for all new Azure Infrastructure as Code projects.
BICEP VS TERRAFORM
Bicep and Terraform both implement Infrastructure as Code but serve different purposes. Terraform excels in multi-cloud environments where Azure, AWS, and Google Cloud are managed together. Bicep focuses exclusively on Azure, offering immediate support for new Azure features, seamless Azure Resource Manager integration, and no external state file to maintain. For organizations building primarily on Microsoft Azure, Bicep often provides the simplest and most integrated deployment experience.
GETTING STARTED WITH BICEP
Starting with Bicep requires only Azure CLI and the official Microsoft Bicep extension for Visual Studio Code. Developers can create a simple .bicep file, deploy resources directly through Azure CLI or Visual Studio Code, and immediately begin managing Azure infrastructure using source-controlled deployment files. Because Bicep integrates naturally with GitHub Actions, Azure DevOps, and CI/CD pipelines, it becomes easy to automate deployments while maintaining consistent environments throughout the software development lifecycle.
THE POWER OF IDEMPOTENT DEPLOYMENTS
One of Bicep's greatest advantages is idempotency. Running the same deployment once, twice, or even one hundred times always produces the same desired infrastructure state. Existing resources remain unchanged unless the deployment file has been modified, eliminating duplicate resources and dramatically reducing configuration drift. Instead of relying on memory, documentation, or manual procedures, the Bicep file itself becomes the authoritative definition of your Azure environment.
KEY TAKEAWAYS
Bicep is Microsoft's modern Infrastructure as Code language for Azure. By simplifying ARM Template authoring while retaining the full power of Azure Resource Manager, Bicep enables organizations to automate deployments, improve collaboration, reduce human error, and manage cloud infrastructure through version-controlled source code. Whether you're deploying a single resource group or an enterprise-scale landing zone, Bicep provides a clean, maintainable, and future-ready foundation for Azure automation.
Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.
🚀 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.
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.
