November 7, 2024 • 34 mins
Welcome to Episode 388 of the Microsoft Cloud IT Pro Podcast. In this episode, we dive into Azure Bicep, Microsoft’s streamlined language for defining cloud infrastructure. If you’re new to Infrastructure as Code (IaC) or looking to simplify your Azure deployments, listen in to learn how easy it is to get started with Azure Bicep. We walk through the essentials, from setting up the necessary tools such as Visual Studio Code and the Azure Bicep extension, to exploring the intuitive features that make Bicep so powerful. Discover how Bicep’s functions, objects, and simplified syntax improve your workflow, offering a more readable and maintainable alternative to traditional ARM templates.
Whether you’re an Azure admin or a developer, this episode provides a clear path to building and managing Azure resources effectively with Bicep. Tune in and start coding your infrastructure with confidence!
Like what you hear and want to support the show? Check out our membership options.
Show Notes
Microsoft Ignite
What is Bicep?
Bicep functions
Quickstart: Create Bicep files with Visual Studio Code
Azure/azure-quickstart-templates
˚Decompiling ARM template JSON to Bicep
Learn modules for Bicep
About the sponsors
Would you like to become the irreplaceable Microsoft 365 resource for your organization? Let us know!
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:03):
Welcome to episode 388
of the Microsoft Cloud IT Pro Podcast,
recorded live on November 1, 2024.
This is a show about Microsoft 365 and
Azure from the perspective of IT pros and
end users, where we discuss a topic or
recent news and how it relates to you.
It's time to switch back to an Azure
(00:23):
topic this week. In this episode,
we dive into Azure Bicep,
Microsoft's streamlined language for defining cloud and front
infrastructure.
If you are new to infrastructure as code
or looking to simplify your Azure deployments,
listen in to learn how easy it is
for you to get started with Azure Bicep.
(00:44):
We shall be at Ignite for the entire
week doing
podcast stuff. Yes. So if you were going
to be I know I already heard from
one listener that said they're gonna be at
Ignite and they wanna meet up. So all
the rest of you that are gonna be
at Ignite, let us know. We can say
hi. You can be on the podcast. If
you wanna be if you're at Ignite, you
wanna be on a podcast, come find us
and tell us you wanna be on the
(01:05):
podcast. Maybe we'll let you on. Maybe. You're
just giving folks a lot of A lot
of optimism there. We will absolutely
have you on the podcast because we love
inviting our listeners
to participate. No. It would be fun. If
you're gonna be at Ignite, we would love
to see you meet up. We'll be around,
like you said, the entire week. So it
(01:26):
should be fun, Scott. This is the 1st
Ignite I have been to live and in
person
since 2019.
I think so. I was trying to think
back. I was I was talking to my
wife last night at dinner while we were
out about this. She's, oh, you're going back
to that conference, the one that you used
to go to all the time. Yeah. That
that's the one.
But, yeah, well,
(01:48):
it's been a hot minute since we've been
out there and and done this whole thing
and seen people. So I'm looking forward to
it. It also seems like they're expanding
the pool a little bit. I think there
were, like, more in person tickets and things
that were made available for sale this year.
So it's not as big as it used
to be, but it's getting back up there,
(02:09):
like, creeping up slowly.
So that's good to see. I'm very excited
for just a hallway track and a week
of digging in and
seeing what's new and what's coming. Yeah. And
if you are, so not only are we
gonna be there doing podcasts, Scott, I also
these are
I'm not allowed to share these. I did
(02:29):
get confirmation this is no longer under NDA.
I will be helping to proctor a lab
a couple days too. So if you want
to go learn how to supercharge charge your
SOC with Microsoft Defender,
it's lab
4
59 in the session guide. My name is
not on it. The proctors were not cool
enough to get our names on it. Only
the speakers that are leading the lab are
on it, but I will be there helping
(02:51):
to proctor that lab a couple of days
as well. I think there's one on
Wednesday
and one on Friday.
If you're gonna be there, you wanna learn
about SOC and Microsoft Defender, get hands on
with SOC and Microsoft Defender or Microsoft Defender
for a SOC.
Come join me in the lab too. It
should be fun. Although, you told me I
have a sick sense of fun when you
told me when I told you that sounded
(03:12):
like fun. You do have a weird way
of expressing it sometimes, and I'll I'll I'll
leave it at that.
But, yeah, the session guides are live for
Ignite, so that finally lit up. It's always
a confusing experience when you go register for
Ignite before the session guides are live, and
it looks like the entire website's broken and
you can't sign in or you can't do
anything. I really don't understand why it continues
(03:32):
to be that way, but
it does.
But session guides are live, so you can
go through. And if you are going, you
can figure out your week. Certainly, if you're
attending in person or for digital attendees, you've
also got the sessions open as well. So
Ignite is not being gated to an in
person only event. It's also got the digital
(03:53):
component to it. So you got a couple
days of that of being able to follow
along with the sessions
or the recordings if they don't fit into
your time zone
where you happen to reside at the time,
things like that. So
it's all out there and available
and ready to go. Good times.
So with that, announcements
(04:15):
out of the way, I think. No more
announcements. Should we talk about
something
Azure y? That should be a new word.
Something Azure y today. Azure y? Let's talk
about
something Azure y.
Do you feel overwhelmed by trying to manage
your Office 365
(04:35):
environment? Are you facing unexpected issues that disrupt
your company's productivity? IntelliJunk is here to help.
Much like you take your car to the
mechanic that has specialized knowledge on how to
best keep your car running, Intelligent helps you
with your Microsoft Cloud environment because that's their
expertise.
Intelligent keeps up with the latest updates in
the Microsoft Cloud to help keep your business
(04:55):
running smoothly and ahead of the curve. Whether
you are a small organization with just a
few users up to an organization of several
1000 employees,
they want to partner with you to implement
and administer your Microsoft Cloud technology.
Visit them atintelliginc.com/podcast.
That's
intelligink.com/podcast
(05:20):
for more information or to schedule a 30
minute call to get started with them today.
Remember, IntelliJunk focuses on the Microsoft cloud so
you can focus on your business.
So for
our Azure y topic, that should be a
new word. I did not sleep enough last
night, Scott. You're gonna have to try really
hard to keep me focused today.
(05:41):
We have not talked about this a ton.
We had one recording, I think, we did
maybe a couple years, like, ready to go
with AC, mentioned it in passing a lot,
but we decided
to dive into a little bit of
bicep
today, not our muscles because those are sadly
lacking, at least mine are. I will speak
(06:01):
for myself, but the declaratively
deploying Azure resources
by step instead of using JSON templates for
going in, creating resources, deploying resources,
infrastructure
as
as code
type of topics
because infrastructure
guys
(06:22):
now must be developers, Scott. I have resigned
myself to the fact that to some extent,
we are developers now. We're not developers, but
we're still scripters, and I I continue to
maintain that it is helpful to
think like a developer as an IT pro.
Like, there are many constructs of consuming functions,
doing
(06:43):
manipulation between data types, say, casting
integers to strings or things like that.
There are concepts
of object oriented programming inside of some of
the scripting languages, especially PowerShell comes to mind
here as something we work with every day.
If somebody's ever worked with an object in
PowerShell, congratulations.
(07:03):
You too are now a developer.
You've got that going for you. There there's
just a whole bunch going on between casting,
data types,
consumption,
and uses of functions, all these kinds of
things. And I think Bicep,
like, one of the things that can clue
you in that it's maybe a little bit
more than just
(07:24):
declarative
infrastructure as code
is Bicep is a
domain specific language or a DSL.
So when we say domain specific language,
there are other languages out there. So let's
think like programming languages
like
dot net, Python,
(07:45):
Java,
Go, things like that.
And those can all be used across a
bunch of domains. They're more generic. Java runs
on multiple platforms.
It's something that it's meant to pick up
and you put your logic into it and
you go from there. So you could absolutely,
say, pick up, like, the Java management playing
SDKs
that
(08:06):
Microsoft and Azure provide,
and you could use those management playing SDKs
to provision your resources.
Or you can use something like Bicep, which
is this domain specific language. So it means
it's really
a programming language, and it's designed for a
specific application
or a problem domain. And in this case,
(08:26):
the application slash problem domain
is Azure Resource Manager.
And
being able to manipulate Azure Resource Manager and
ultimately, like, leverage the underlying REST APIs that
power ARM
or Azure Resource Manager using
Bicep.
So it goes a little bit beyond maybe
ARM templates in that it is
(08:48):
a little bit more,
it it it is a little bit more
programmer y at the end of the day.
And I think you find that out pretty
quick, especially when you start using
some kinda common things in bicep, say, a
for loop in your bicep template
and consuming custom iterators,
moving into more formal, like, objects,
(09:11):
and
having hash maps available to you. There's just
all sorts of stuff in there that wasn't
available to you in Arm.
Now the interesting thing here is bicep's a
little bit of a programming language, but when
you go to run bicep and you go
to run a bicep template,
it turns out that your
bicep template
(09:33):
or your bicep
files, like your dot bicep file, your bicep
modules, what whatever it happens to be,
is actually converted into a call to Arm
and ultimately submitted as an Arm deployment.
So let's say you create a bicep file
where you want to
create a virtual machine, and a virtual machine
needs its VM, it needs a VNET, it
(09:55):
needs a NIC, all those kinds of things.
So you'll author that in Bicep, which is
its own specific language, but then you'll maybe
go off to, like, the CLI or PowerShell,
and you'll say, hey. Let me do a
new deployment.
And just like you would pass in an
ARM file, like that dot JSON file from
an ARM template deployment, you would just pop
pass in your dot bicep file and under
(10:17):
the hood, that gets translated
into
an ARM template or a set of ARM
templates and submitted to
the deployment engine and then spun up from
there.
And then you can leverage all the same
things as ARM templates do, including things like
outputs on the outside
or outputs from your ARM templates, things like
(10:37):
that.
It's
it takes the
I would say it takes the goodness of
Arm and it uplevels it into just this
very specific language, like less generic JSON,
and being far more opinionated about here's the
things that we're gonna let you do with
a domain specific language
that is focused 100%
(10:57):
on Azure Resource Manager as a domain. Yes.
And I think that's where it kinda I
would say it sits in the middle because
naturally someone will probably ask Terraform, where Terraform,
you probably wouldn't consider it one of those
domain specific languages. Terraform
has modules for Azure, modules for
AWS,
so I think for GCP. I'm not a
(11:18):
100% sure. Where Bicep kinda sits in the
middle of between maybe ARM templates and Terraform
of it's close to Terraform, but it only
works on Azure. I think one thing to
think about too, and I'm curious
on your thoughts, and we've hinted at it
some is we already have ARM templates. We
already have all the JSON.
What are those advantages? If people are looking
(11:40):
to, we're gonna be in Azure, we wanna
use infrastructure as code, we've been using JSON
templates, or
why would we go learn Bicep if we
already know JSON templates?
Why why use Bicep versus
just JSON or ARM deployments or, for that
matter,
I know why you'd use it over the
GUI, but over ARM templates. It's far more
(12:01):
expressive, I I think is the way I
would frame it. So
JSON
as a language for capturing configuration
is
pretty inflexible.
It's not specific to ARM. JSON's just a
thing that's out there, JavaScript object notation.
So there's lots of solutions that leverage JSON,
(12:23):
and you can certainly have, like, rules for
JSON. K. It must pass
this set of linting rules, things like that,
commas in the right places, closing strings, all
the all that kind of stuff. But it's
still just JSON at the end of the
day. Like, there's nothing specific in there that
says, oh, this is ARM specific or Azure
Resource Manager specific, and that's where Bicep's gonna
(12:44):
come in. So it's gonna be more expressive
in that it is ARM specific, and it's
gonna be very geared and opinionated
towards just doing ARM over just straight JSON
and having to figure out the linter and
and things that you're gonna pick along the
way for it. And the other is
it really is like a little miniature programming
language.
Again, things like
(13:05):
native for loops
inside
of your
bicep
your bicep templates or your modules.
You can have custom user defined data types,
which
you can actually have, like, in a Bicep
file, you can have a type that's an
object, and you can have an object with,
like, dot properties on it. So let me
(13:27):
say so so maybe for a virtual machine,
when I spin up a virtual machine, it
has a SKU or a VM family, it
has a name, things like that. So I
would I could absolutely define all those as
individual parameters or things like that, or I
could just group them all into a single
object. I could have, like, my VM, and
then inside that object, I could have a
property called name that's of type string. I
(13:48):
could have a property of SKU of type
string. I could have a property of number
of nicks
of type integer, things like that, and then
I could even set default values around those.
And then I just consume that object and
pass that object around
within
my bicep modules
and and templates and things like that along
the way.
(14:08):
I think that's super powerful for you to
have. There's a ton of
built in functions around things.
So there's a bunch of array functions.
There's way more for dates and times
and kinda date and time formatting.
There are specific functions that you have available
(14:30):
around
numbers. So, say, like, casting something as an
integer, being able to do, min and max.
Say you have an array of items and
you wanna access an array in in items,
you can do things like dot first or
dot last in in a collection as you
pass them through.
There's tons and tons of string functions. There's
(14:50):
30 plus string functions out there. So things
you're used to maybe from Armland, say unique
string, like, unique string still exists over here,
but it's actually way more powerful because it
supports, like, parameters
for
seeding the hash and for length of the
hash. You've got GUIDs. You've got string padding,
string trimming, like trim left, trim right to
(15:12):
upper to lower.
You can pull out like, there there's functions
for manipulating
URLs. Say you're working with, I don't know,
a storage account. 1 of the outputs for
creating the storage account is what the primary
endpoint is. Say you wanted to do something
with that URI as it comes back, there
there's functions available for that.
Lambda functions,
file functions.
(15:34):
Let's see. There's functions specific to parameters
within your templates that you create in Bicep.
So I don't know. Like, one of the
fun things you can do in a Bicep
file that you can certainly do
in, like, a Bash script or a PowerShell
script and pass it in as a parameter
in an ARM template, but you gotta go
(15:54):
through that extra machination,
is
Bicep has the ability to do things like
read environment variables.
That's cool. Right? Like, just have
environment variables spun up within your shell, and
you can actually pull those things in. It
has native support for pulling secrets
out of things like Key Vault. So if
(16:15):
you're doing the deployment
as an entity
or a user identity that has the ability
to say talk to a Key Vault, there's
a get secret function where you can reach
out to a specific
subscription resource group Key Vault and pull a
particular secret
and even pull a particular secret by its
version, things like that. So it it's
(16:36):
way more powerful at the end of the
day. Like, it's just more expressive.
Yes. A 100%. And that's,
again, JSON, they're pretty
static. You can't there's you can't come close
to doing all that type of stuff,
just writing ARM files to JSON.
So I think now that we've gotten that
out of the way, is maybe getting started
(16:56):
with it. If you wanna set up a
bicep environment,
and
do you wanna jump there? We've got best
practices
with bicep, which we go into next. Install
bicep tools. We should probably start with tools
and installing tools. So this is a little
bit like a programming language again. So just
if you were going to
(17:16):
write dot net code on your,
local PC, you're gonna wanna install the the
dot net framework, and you might wanna install
some helper extensions.
You might wanna have, like, Visual Studio Code,
things like that all stood up and ready
to go.
So I think Bicep Tools
is
a
great place to start. So
(17:37):
first, you're gonna want some things that you
probably already have. And those things are, say,
like the Azure CLI and Azure PowerShell.
That's because, ultimately, at the end of the
day, Bicep is
about manipulating your infrastructure or your resources within
Azure.
Again, it all gets converted into ARM templates
and ARM deployments when you do those submissions.
(17:58):
So the easiest way one of the easiest
ways to do those submissions in that testing
is from the command line with things like
PowerShell
and CLI where you're just going to submit
a new deployment,
but rather
than submitting that deployment against a dot JSON
file and an ARM template,
you would just do a bicep file. And
(18:18):
it's all the same commandlets and same sets
of
command line parameters that you've been using along
the way. So once you've got PowerShell CLI
installed, you're all ready to deploy Bicep templates.
So the next step is, let me go
and create a Bicep template. You're gonna want
some tooling to help you along the way
to do that. Like,
it's just a text file at the end
(18:39):
of the day. Like, it's a dot bicep
file is the extension on it. That being
said, you're gonna want some things like maybe
a linter to help you, something that can
help you auto format.
Helps you have autocomplete
and IntelliSense
as you're authoring these files.
The easiest way and and the way that
I go about it personally
is just using Visual Studio Code, and Visual
(19:02):
Studio Code has a native bicep extension. It's
available in the marketplace.
It's authored and and maintained
and made available from Microsoft.
The other option that's available to you is
to
go out
and leverage Visual Studio.
So that's an option. If you're just a
Visual Studio developer,
(19:23):
totally doable. You can go and make that
happen.
There's also a formal bicep extension for for
Visual Studio full on. I don't know that
you need Visual Studio full on. Like, Versus
Code is free.
The extension that's there is super powerful.
You have native inline terminal support in Versus
Code. Like, I'm just used to it from
working in it over the years,
(19:44):
and that tends to be the place that
I go. Like, there's no other special tool
or thing like that that you have
to go out and grab. There's no, oh,
grab the bicep development studio or anything like
that. Just go grab Versus Code. You probably
already have Versus Code. You probably already have
PowerShell. There's CLI installed already if you're working
with Azure. So really, the only thing you
(20:06):
need is the Bicep extension,
and from there, you're off to the races,
And you can go do what you need
to do. I saw the one for Visual
Studio, and it made me laugh because I
was like, I don't know. I think the
last time I opened Visual Studio was writing
SharePoint 2013
extensions and stuff.
I'm with you. I don't know why you
would use Visual Studio Code for Bicep, but
(20:26):
if you really like visuals or why do
you use Visual Studio? If you really like
it, it's there. But I'm with you. Visual
Studio Code for all these
super simple,
lightweight, works the same,
more or less,
on macOS, Windows,
all of those.
And then that Bicep extension. Yeah. I was
just looking So once you've got all that
(20:47):
installed, I was gonna say that once you
got that installed, your next step is
probably go get hands on with a bicep
file. I know some folks like to watch
videos. You can absolutely go out to YouTube
and
take a look around for these or if
you have a subscription to LinkedIn Learning, things
like that. There's formal classes out there, but
one of your next steps might be to
(21:07):
just go out and
spin up a template in Versus codes. There's
there's a pretty good quick start
on Microsoft Learn
where it just walks you through creating kind
of your first
bicep file
in Versus Code,
and that'll walk you down a path of
working with resources,
(21:29):
going through the general machinations,
and things like that.
And then once you've got a handle on
what a default set or or kind of
a minimal bicep file is, then you can
start thinking about, like, optimizations
or what are some new good next steps
for me to take, things like that. Is
there a good get I'll repo. I was
looking we threw together this Azure quick start
(21:50):
templates, but this is also templates that looks
like for
everything, ARM templates. I was trying to look
through if there's a spot where they consolidated
everything in here
under
some Bicep files. Is this one really all
arm templates? No. It's arm and bicep all
mixed together. That's not helpful.
(22:12):
If you go in and it it it
is helpful though because, again, bicep and arm
are You can see how they relate, how
one leads to the other. Oh, here they
are. 6 to 1, half half dozen of
the other. Right? So as you're going through
the quick starts repo, one of the things
you'll see is that there's dot bicep files
alongside the dot JSON files
(22:32):
that existed out there previously
from the
from the ARM templates that were available for
you.
I know where you say, hey, maybe I
think that's not helpful, but I would make
the argument that it's actually super helpful because
if I'm already familiar with ARM templates and
the construct of those JSON files,
now I can see side by side
and do that mental
(22:54):
mental map and translation in there. I can
see that. And they are sorted by resources.
So if you go out to this GitHub
repo and you start looking through, like, they
have a bunch of other stuff around
demos and modules, but under the quick starts
then it's broken down by things like
app services
on ACR.
You have things in here for
(23:15):
app services with HTTP
scaling rules,
you have automation
accounts
and configuration,
all the things Databricks,
Devices,
HD Insights, Key Vault. And then once you
get down there, they have different ones. Like
under Key Vault, there's,
what, maybe 10 different 10, 11 different samples
(23:38):
of Key Vaults with private endpoints, Key Vaults
with managed identity role assignment,
just creating Key Vaults. And that's
where under certain ones, not all of them,
you will find Not all of them have
it. Yes. Not all of them have it,
but under certain ones, you will have, like
you said, those JSON files and those dot
bicep files that you can
open up, look at, compare,
(24:00):
figure out how to translate from one to
the other. You've got all those out there.
You can also
export
your
existing resources.
So for a long time, you've been able
to
export, like, an ARM template of your existing
resources.
I think it's a little bit of a
misnomer that we tell customers that, like, oh,
you can export it, but you can't actually
(24:21):
run that template and then have it spin
up the same resource again. Yeah. That being
said, like, you at least get it as,
like, a manifestation
or an example
of the things that are sitting out there.
You can export to ARM,
to an ARM template, export to Bicep. They
recently added the ability to export to Terraform
as well. So you mentioned Terraform earlier.
(24:44):
Terraform is all built around HCL.
HCL is a scripting language.
So Terraform is
also a domain specific language. Right? It's another
set of these things where you're doing maybe
a little bit more programming than just generic
generic JSON
kind of thing and JSON validation,
(25:04):
which also shows, hey, Microsoft's moving in the
direction that some of these other things have
been going for a while now, like HashiCorp
with TerraForm. This is one thing. I have
not written much bicep. I will be honest.
It is it's on my list. Remember that
list? I haven't talked about my list in
a while.
Yeah. Yeah. It it is a thing that's
out there. Oh, one other option for you
(25:25):
just while we're talking about, hey, maybe getting
hands on
and finding examples and things like that is
it's also possible
to
so when you execute a bicep
script
and you go ahead and actually do that
deployment again, it's converted into an ARM call
on the back end.
So beyond going from, like, a bicep file
(25:47):
to an ARM template, you can also go
the other way, and you can decompile
an ARM template
and turn that
into
a bicep file as well. So maybe if
you have already an investment, like, you're very
familiar with arm templates and you're like, I
don't know. Just put me on the path
where I can start to figure out how
to translate my existing stuff. You can go
down that path as well and convert back
(26:09):
the other way. Got it. The other thing
I would say getting started, if you are
new to this, is there is also some
learn modules for BICEP 2. Like we talked
about, you can just go read the learn
documentation,
but there is
a learn module
for walking through
how
you can start using Bicep, covering fundamentals.
(26:31):
There's like the fundamentals,
intermediate,
advanced,
going through different
deployments.
Looks like there is some for
there's probably some in here for authoring Bicep
files.
But if you do want a little bit
more of a, let's say, guided approach to
walking through
learning it, writing them, using them in deployment,
(26:52):
pipelines as in here, using it in deployment
stacks. There is also this learn module for
bicep. There are tons and tons of learn
modules out there.
One recommendation
that I would have for folks, and I
keep going
back to
this one, is there's a specific learn module
(27:15):
out there.
Let me pull up a link to it.
So it's called structure
your bicep code for collaboration,
and I think this is a really good
one for a couple of reasons. One is
it starts to walk you down the optimization
path
from the start. So it gives you this
big long bicep file, which is more than
(27:36):
just deploy a storage account, which is one
of my annoyance when you go out and
start with the quick starts and things. They're
usually like deploy a storage account to play
this single instance thing, like, yeah, I get
single instance, but you'll probably want, a little
bit more than that. So the the very
first thing that does is it goes out
and it gives you
a getting started bicep template,
(27:57):
which totally works as is. It's just not
optimized.
It's just not doing all the things that
you might want it to do.
It's got, like, bad names for parameters.
And so that learn module walks you through
things like how to think about naming your
parameters, which the the guidance for naming your
parameters in a bicep file, by the way,
(28:19):
doesn't really differ from the guidance of how
you should be naming your parameters in an
ARM template, but I think it's a good
reinforcement
because
I'm I know I'm guilty of this all
the time where I go out and I
create something and I just go, like, the
easy button. I'm like, oh, I need a
name.
Var name equals blah blah blah. But it
turns out that name was for a specific
resource. It was like a name for a
virtual machine. So what I really should have
(28:41):
done was name that variable, like, var
my
web virtual machine, var my middle layer, my
API layer virtual machine. Like, you should be
far more descriptive, use camel case,
all those kinds of things. Make sure that
your parameters
are typed.
So, integers are integers, strings are strings, objects
(29:01):
are objects. Of course, this is like back
to programming language thing. This helps us leverage
and use all of those later on.
It also walks you down the path of
how to
think about structuring
your bicep files
because
ARM files are very specific where the parameters
are at the top, resources are in the
(29:23):
middle, and outputs are always at the bottom.
Right? It's just gotta follow that flow,
to be able to lint and things like
that's not the case with a bicep file.
You can have a parameter here, a resource
here. You can have an output here. You
can have this other thing. You can have
a function next. Like, you can just go
wild. I think structure that thing however you
want, but that might not be the most
(29:43):
readable thing for the next person. It might
not be the best way to leave your
campground
in a in a good place for the
next camper when they come through. And you
don't want folks having to clean up after
you. So it it it could that module
in particular gives you a sense of what
some of those things are that you would
want to
think about along the way. And, ultimately, what
(30:05):
it does is it walks you down a
couple steps. Let's improve your parameters. Let's improve
your parameter names. Let's make sure we put
comments in. Oh, do you understand the difference
between inline comments versus structured comments versus multiline
comments?
All those kinds of things. Are your
are your templates
annotated
correctly? So
(30:26):
beyond
your things like having comments,
have you put descriptions on your parameters? So
in case you're asked for, like, a parameter
input when you're running a deployment from the
command line, have you thought about how you
commonly structure things like resource tags and governance
constructs?
That's all in there. And, ultimately, it walks
(30:46):
you down this path of, hey, let's optimize
and refactor your bicep file. So it gives
you an a and b, camera 1, camera
2 kind of thing, and it gives you
the flexibility and the freedom to figure it
out your
your yourself along the way.
I think that's super helpful
and
definitely works towards
(31:07):
improving just readability of bicep files and keeps
you on a common path as the way,
like, the creators of that
domain language
intended,
walks you through rationalization
for ordering elements.
I think you also
work with
collections
in that module.
So collections
(31:28):
allow you to have, like, multi propertied
objects
that you can consume in an easier way.
One of the examples that I can think
of again is, like, virtual machines. So virtual
machines have
a SKU, like, hey, I'm deploying a b
one VM over here, but then you also
have things like number of instances of a
VM that you want to deploy, and you
(31:49):
might want to make that a parameter and
dynamic within
within your function. So rather than having a
parameter of
my VM one name dot SKU and my
v one my VM
one dot count,
maybe you have more like a environment
parameter or you have some other parameter that
says, oh,
(32:09):
when parameter is set to prod,
just deploy
d series VMs with this many instances. When
it's set to dev, deploy b series
with this many instances, or deploy this set
of tags or these things over here. So
it it walks you through all of those
constructs as well
in in, I think, a pretty clear manner.
(32:30):
And like I said, that's when I I
tend to find myself, like, going back to
just
the main optimization
article
that Microsoft
has out there. So they have a best
practices
for bicep article.
Between that one and then just revisiting that
learn module occasionally, where I can, again, a
b the starting and the ending template
(32:51):
or the starting and ending bicep file, then
that that generally gives me a good sense
and enough to, like, oh, yeah, give my
brain a kick, and let me remember where
I wanted to be with that particular thing.
Sounds good. I really should go spend some
more time with biceps, Scott. Even though it
is 4 o'clock and Friday, I still have
3 more meetings today. Yuck.
So we should call it a day, get
(33:14):
ready for Ignite.
We will probably we'll probably try to get
some interviews, have some news,
talk about some of the Ignite stuff here
in the next couple of episodes. Yeah. I
am
looking forward to it. Got my plane tickets
booked and everything. I'm all set. Perfect. We
will see you at Ignite, Scott, and hopefully,
we will see a few of, your listeners
at Ignite as well here in a couple
(33:35):
weeks. But for now, enjoy your weekend, and
we will talk to you again later. Great.
Thanks, Ben.
If you enjoyed the podcast, go leave us
a 5 star rating in iTunes. It helps
to get the word out so more IT
pros can learn about Office 365 and Azure.
If you have any questions you want us
to address on the show or feedback about
(33:56):
the show, feel free to reach out via
our website, Twitter, or Facebook.
Thanks again for listening, and have a great
day.
Welcome to episode 388
of the Microsoft Cloud IT Pro Podcast,
recorded live on November 1, 2024.
This is a show about Microsoft 365 and
Azure from the perspective of IT pros and
end users, where we discuss a topic or
recent news and how it relates to you.
It's time to switch back to an Azure
(00:23):
topic this week. In this episode,
we dive into Azure Bicep,
Microsoft's streamlined language for defining cloud and front
infrastructure.
If you are new to infrastructure as code
or looking to simplify your Azure deployments,
listen in to learn how easy it is
for you to get started with Azure Bicep.
(00:44):
We shall be at Ignite for the entire
week doing
podcast stuff. Yes. So if you were going
to be I know I already heard from
one listener that said they're gonna be at
Ignite and they wanna meet up. So all
the rest of you that are gonna be
at Ignite, let us know. We can say
hi. You can be on the podcast. If
you wanna be if you're at Ignite, you
wanna be on a podcast, come find us
and tell us you wanna be on the
(01:05):
podcast. Maybe we'll let you on. Maybe. You're
just giving folks a lot of A lot
of optimism there. We will absolutely
have you on the podcast because we love
inviting our listeners
to participate. No. It would be fun. If
you're gonna be at Ignite, we would love
to see you meet up. We'll be around,
like you said, the entire week. So it
(01:26):
should be fun, Scott. This is the 1st
Ignite I have been to live and in
person
since 2019.
I think so. I was trying to think
back. I was I was talking to my
wife last night at dinner while we were
out about this. She's, oh, you're going back
to that conference, the one that you used
to go to all the time. Yeah. That
that's the one.
But, yeah, well,
(01:48):
it's been a hot minute since we've been
out there and and done this whole thing
and seen people. So I'm looking forward to
it. It also seems like they're expanding
the pool a little bit. I think there
were, like, more in person tickets and things
that were made available for sale this year.
So it's not as big as it used
to be, but it's getting back up there,
(02:09):
like, creeping up slowly.
So that's good to see. I'm very excited
for just a hallway track and a week
of digging in and
seeing what's new and what's coming. Yeah. And
if you are, so not only are we
gonna be there doing podcasts, Scott, I also
these are
I'm not allowed to share these. I did
(02:29):
get confirmation this is no longer under NDA.
I will be helping to proctor a lab
a couple days too. So if you want
to go learn how to supercharge charge your
SOC with Microsoft Defender,
it's lab
4
59 in the session guide. My name is
not on it. The proctors were not cool
enough to get our names on it. Only
the speakers that are leading the lab are
on it, but I will be there helping
(02:51):
to proctor that lab a couple of days
as well. I think there's one on
Wednesday
and one on Friday.
If you're gonna be there, you wanna learn
about SOC and Microsoft Defender, get hands on
with SOC and Microsoft Defender or Microsoft Defender
for a SOC.
Come join me in the lab too. It
should be fun. Although, you told me I
have a sick sense of fun when you
told me when I told you that sounded
(03:12):
like fun. You do have a weird way
of expressing it sometimes, and I'll I'll I'll
leave it at that.
But, yeah, the session guides are live for
Ignite, so that finally lit up. It's always
a confusing experience when you go register for
Ignite before the session guides are live, and
it looks like the entire website's broken and
you can't sign in or you can't do
anything. I really don't understand why it continues
(03:32):
to be that way, but
it does.
But session guides are live, so you can
go through. And if you are going, you
can figure out your week. Certainly, if you're
attending in person or for digital attendees, you've
also got the sessions open as well. So
Ignite is not being gated to an in
person only event. It's also got the digital
(03:53):
component to it. So you got a couple
days of that of being able to follow
along with the sessions
or the recordings if they don't fit into
your time zone
where you happen to reside at the time,
things like that. So
it's all out there and available
and ready to go. Good times.
So with that, announcements
(04:15):
out of the way, I think. No more
announcements. Should we talk about
something
Azure y? That should be a new word.
Something Azure y today. Azure y? Let's talk
about
something Azure y.
Do you feel overwhelmed by trying to manage
your Office 365
(04:35):
environment? Are you facing unexpected issues that disrupt
your company's productivity? IntelliJunk is here to help.
Much like you take your car to the
mechanic that has specialized knowledge on how to
best keep your car running, Intelligent helps you
with your Microsoft Cloud environment because that's their
expertise.
Intelligent keeps up with the latest updates in
the Microsoft Cloud to help keep your business
(04:55):
running smoothly and ahead of the curve. Whether
you are a small organization with just a
few users up to an organization of several
1000 employees,
they want to partner with you to implement
and administer your Microsoft Cloud technology.
Visit them atintelliginc.com/podcast.
That's
intelligink.com/podcast
(05:20):
for more information or to schedule a 30
minute call to get started with them today.
Remember, IntelliJunk focuses on the Microsoft cloud so
you can focus on your business.
So for
our Azure y topic, that should be a
new word. I did not sleep enough last
night, Scott. You're gonna have to try really
hard to keep me focused today.
(05:41):
We have not talked about this a ton.
We had one recording, I think, we did
maybe a couple years, like, ready to go
with AC, mentioned it in passing a lot,
but we decided
to dive into a little bit of
bicep
today, not our muscles because those are sadly
lacking, at least mine are. I will speak
(06:01):
for myself, but the declaratively
deploying Azure resources
by step instead of using JSON templates for
going in, creating resources, deploying resources,
infrastructure
as
as code
type of topics
because infrastructure
guys
(06:22):
now must be developers, Scott. I have resigned
myself to the fact that to some extent,
we are developers now. We're not developers, but
we're still scripters, and I I continue to
maintain that it is helpful to
think like a developer as an IT pro.
Like, there are many constructs of consuming functions,
doing
(06:43):
manipulation between data types, say, casting
integers to strings or things like that.
There are concepts
of object oriented programming inside of some of
the scripting languages, especially PowerShell comes to mind
here as something we work with every day.
If somebody's ever worked with an object in
PowerShell, congratulations.
(07:03):
You too are now a developer.
You've got that going for you. There there's
just a whole bunch going on between casting,
data types,
consumption,
and uses of functions, all these kinds of
things. And I think Bicep,
like, one of the things that can clue
you in that it's maybe a little bit
more than just
(07:24):
declarative
infrastructure as code
is Bicep is a
domain specific language or a DSL.
So when we say domain specific language,
there are other languages out there. So let's
think like programming languages
like
dot net, Python,
(07:45):
Java,
Go, things like that.
And those can all be used across a
bunch of domains. They're more generic. Java runs
on multiple platforms.
It's something that it's meant to pick up
and you put your logic into it and
you go from there. So you could absolutely,
say, pick up, like, the Java management playing
SDKs
that
(08:06):
Microsoft and Azure provide,
and you could use those management playing SDKs
to provision your resources.
Or you can use something like Bicep, which
is this domain specific language. So it means
it's really
a programming language, and it's designed for a
specific application
or a problem domain. And in this case,
(08:26):
the application slash problem domain
is Azure Resource Manager.
And
being able to manipulate Azure Resource Manager and
ultimately, like, leverage the underlying REST APIs that
power ARM
or Azure Resource Manager using
Bicep.
So it goes a little bit beyond maybe
ARM templates in that it is
(08:48):
a little bit more,
it it it is a little bit more
programmer y at the end of the day.
And I think you find that out pretty
quick, especially when you start using
some kinda common things in bicep, say, a
for loop in your bicep template
and consuming custom iterators,
moving into more formal, like, objects,
(09:11):
and
having hash maps available to you. There's just
all sorts of stuff in there that wasn't
available to you in Arm.
Now the interesting thing here is bicep's a
little bit of a programming language, but when
you go to run bicep and you go
to run a bicep template,
it turns out that your
bicep template
(09:33):
or your bicep
files, like your dot bicep file, your bicep
modules, what whatever it happens to be,
is actually converted into a call to Arm
and ultimately submitted as an Arm deployment.
So let's say you create a bicep file
where you want to
create a virtual machine, and a virtual machine
needs its VM, it needs a VNET, it
(09:55):
needs a NIC, all those kinds of things.
So you'll author that in Bicep, which is
its own specific language, but then you'll maybe
go off to, like, the CLI or PowerShell,
and you'll say, hey. Let me do a
new deployment.
And just like you would pass in an
ARM file, like that dot JSON file from
an ARM template deployment, you would just pop
pass in your dot bicep file and under
(10:17):
the hood, that gets translated
into
an ARM template or a set of ARM
templates and submitted to
the deployment engine and then spun up from
there.
And then you can leverage all the same
things as ARM templates do, including things like
outputs on the outside
or outputs from your ARM templates, things like
(10:37):
that.
It's
it takes the
I would say it takes the goodness of
Arm and it uplevels it into just this
very specific language, like less generic JSON,
and being far more opinionated about here's the
things that we're gonna let you do with
a domain specific language
that is focused 100%
(10:57):
on Azure Resource Manager as a domain. Yes.
And I think that's where it kinda I
would say it sits in the middle because
naturally someone will probably ask Terraform, where Terraform,
you probably wouldn't consider it one of those
domain specific languages. Terraform
has modules for Azure, modules for
AWS,
so I think for GCP. I'm not a
(11:18):
100% sure. Where Bicep kinda sits in the
middle of between maybe ARM templates and Terraform
of it's close to Terraform, but it only
works on Azure. I think one thing to
think about too, and I'm curious
on your thoughts, and we've hinted at it
some is we already have ARM templates. We
already have all the JSON.
What are those advantages? If people are looking
(11:40):
to, we're gonna be in Azure, we wanna
use infrastructure as code, we've been using JSON
templates, or
why would we go learn Bicep if we
already know JSON templates?
Why why use Bicep versus
just JSON or ARM deployments or, for that
matter,
I know why you'd use it over the
GUI, but over ARM templates. It's far more
(12:01):
expressive, I I think is the way I
would frame it. So
JSON
as a language for capturing configuration
is
pretty inflexible.
It's not specific to ARM. JSON's just a
thing that's out there, JavaScript object notation.
So there's lots of solutions that leverage JSON,
(12:23):
and you can certainly have, like, rules for
JSON. K. It must pass
this set of linting rules, things like that,
commas in the right places, closing strings, all
the all that kind of stuff. But it's
still just JSON at the end of the
day. Like, there's nothing specific in there that
says, oh, this is ARM specific or Azure
Resource Manager specific, and that's where Bicep's gonna
(12:44):
come in. So it's gonna be more expressive
in that it is ARM specific, and it's
gonna be very geared and opinionated
towards just doing ARM over just straight JSON
and having to figure out the linter and
and things that you're gonna pick along the
way for it. And the other is
it really is like a little miniature programming
language.
Again, things like
(13:05):
native for loops
inside
of your
bicep
your bicep templates or your modules.
You can have custom user defined data types,
which
you can actually have, like, in a Bicep
file, you can have a type that's an
object, and you can have an object with,
like, dot properties on it. So let me
(13:27):
say so so maybe for a virtual machine,
when I spin up a virtual machine, it
has a SKU or a VM family, it
has a name, things like that. So I
would I could absolutely define all those as
individual parameters or things like that, or I
could just group them all into a single
object. I could have, like, my VM, and
then inside that object, I could have a
property called name that's of type string. I
(13:48):
could have a property of SKU of type
string. I could have a property of number
of nicks
of type integer, things like that, and then
I could even set default values around those.
And then I just consume that object and
pass that object around
within
my bicep modules
and and templates and things like that along
the way.
(14:08):
I think that's super powerful for you to
have. There's a ton of
built in functions around things.
So there's a bunch of array functions.
There's way more for dates and times
and kinda date and time formatting.
There are specific functions that you have available
(14:30):
around
numbers. So, say, like, casting something as an
integer, being able to do, min and max.
Say you have an array of items and
you wanna access an array in in items,
you can do things like dot first or
dot last in in a collection as you
pass them through.
There's tons and tons of string functions. There's
(14:50):
30 plus string functions out there. So things
you're used to maybe from Armland, say unique
string, like, unique string still exists over here,
but it's actually way more powerful because it
supports, like, parameters
for
seeding the hash and for length of the
hash. You've got GUIDs. You've got string padding,
string trimming, like trim left, trim right to
(15:12):
upper to lower.
You can pull out like, there there's functions
for manipulating
URLs. Say you're working with, I don't know,
a storage account. 1 of the outputs for
creating the storage account is what the primary
endpoint is. Say you wanted to do something
with that URI as it comes back, there
there's functions available for that.
Lambda functions,
file functions.
(15:34):
Let's see. There's functions specific to parameters
within your templates that you create in Bicep.
So I don't know. Like, one of the
fun things you can do in a Bicep
file that you can certainly do
in, like, a Bash script or a PowerShell
script and pass it in as a parameter
in an ARM template, but you gotta go
(15:54):
through that extra machination,
is
Bicep has the ability to do things like
read environment variables.
That's cool. Right? Like, just have
environment variables spun up within your shell, and
you can actually pull those things in. It
has native support for pulling secrets
out of things like Key Vault. So if
(16:15):
you're doing the deployment
as an entity
or a user identity that has the ability
to say talk to a Key Vault, there's
a get secret function where you can reach
out to a specific
subscription resource group Key Vault and pull a
particular secret
and even pull a particular secret by its
version, things like that. So it it's
(16:36):
way more powerful at the end of the
day. Like, it's just more expressive.
Yes. A 100%. And that's,
again, JSON, they're pretty
static. You can't there's you can't come close
to doing all that type of stuff,
just writing ARM files to JSON.
So I think now that we've gotten that
out of the way, is maybe getting started
(16:56):
with it. If you wanna set up a
bicep environment,
and
do you wanna jump there? We've got best
practices
with bicep, which we go into next. Install
bicep tools. We should probably start with tools
and installing tools. So this is a little
bit like a programming language again. So just
if you were going to
(17:16):
write dot net code on your,
local PC, you're gonna wanna install the the
dot net framework, and you might wanna install
some helper extensions.
You might wanna have, like, Visual Studio Code,
things like that all stood up and ready
to go.
So I think Bicep Tools
is
a
great place to start. So
(17:37):
first, you're gonna want some things that you
probably already have. And those things are, say,
like the Azure CLI and Azure PowerShell.
That's because, ultimately, at the end of the
day, Bicep is
about manipulating your infrastructure or your resources within
Azure.
Again, it all gets converted into ARM templates
and ARM deployments when you do those submissions.
(17:58):
So the easiest way one of the easiest
ways to do those submissions in that testing
is from the command line with things like
PowerShell
and CLI where you're just going to submit
a new deployment,
but rather
than submitting that deployment against a dot JSON
file and an ARM template,
you would just do a bicep file. And
(18:18):
it's all the same commandlets and same sets
of
command line parameters that you've been using along
the way. So once you've got PowerShell CLI
installed, you're all ready to deploy Bicep templates.
So the next step is, let me go
and create a Bicep template. You're gonna want
some tooling to help you along the way
to do that. Like,
it's just a text file at the end
(18:39):
of the day. Like, it's a dot bicep
file is the extension on it. That being
said, you're gonna want some things like maybe
a linter to help you, something that can
help you auto format.
Helps you have autocomplete
and IntelliSense
as you're authoring these files.
The easiest way and and the way that
I go about it personally
is just using Visual Studio Code, and Visual
(19:02):
Studio Code has a native bicep extension. It's
available in the marketplace.
It's authored and and maintained
and made available from Microsoft.
The other option that's available to you is
to
go out
and leverage Visual Studio.
So that's an option. If you're just a
Visual Studio developer,
(19:23):
totally doable. You can go and make that
happen.
There's also a formal bicep extension for for
Visual Studio full on. I don't know that
you need Visual Studio full on. Like, Versus
Code is free.
The extension that's there is super powerful.
You have native inline terminal support in Versus
Code. Like, I'm just used to it from
working in it over the years,
(19:44):
and that tends to be the place that
I go. Like, there's no other special tool
or thing like that that you have
to go out and grab. There's no, oh,
grab the bicep development studio or anything like
that. Just go grab Versus Code. You probably
already have Versus Code. You probably already have
PowerShell. There's CLI installed already if you're working
with Azure. So really, the only thing you
(20:06):
need is the Bicep extension,
and from there, you're off to the races,
And you can go do what you need
to do. I saw the one for Visual
Studio, and it made me laugh because I
was like, I don't know. I think the
last time I opened Visual Studio was writing
SharePoint 2013
extensions and stuff.
I'm with you. I don't know why you
would use Visual Studio Code for Bicep, but
(20:26):
if you really like visuals or why do
you use Visual Studio? If you really like
it, it's there. But I'm with you. Visual
Studio Code for all these
super simple,
lightweight, works the same,
more or less,
on macOS, Windows,
all of those.
And then that Bicep extension. Yeah. I was
just looking So once you've got all that
(20:47):
installed, I was gonna say that once you
got that installed, your next step is
probably go get hands on with a bicep
file. I know some folks like to watch
videos. You can absolutely go out to YouTube
and
take a look around for these or if
you have a subscription to LinkedIn Learning, things
like that. There's formal classes out there, but
one of your next steps might be to
(21:07):
just go out and
spin up a template in Versus codes. There's
there's a pretty good quick start
on Microsoft Learn
where it just walks you through creating kind
of your first
bicep file
in Versus Code,
and that'll walk you down a path of
working with resources,
(21:29):
going through the general machinations,
and things like that.
And then once you've got a handle on
what a default set or or kind of
a minimal bicep file is, then you can
start thinking about, like, optimizations
or what are some new good next steps
for me to take, things like that. Is
there a good get I'll repo. I was
looking we threw together this Azure quick start
(21:50):
templates, but this is also templates that looks
like for
everything, ARM templates. I was trying to look
through if there's a spot where they consolidated
everything in here
under
some Bicep files. Is this one really all
arm templates? No. It's arm and bicep all
mixed together. That's not helpful.
(22:12):
If you go in and it it it
is helpful though because, again, bicep and arm
are You can see how they relate, how
one leads to the other. Oh, here they
are. 6 to 1, half half dozen of
the other. Right? So as you're going through
the quick starts repo, one of the things
you'll see is that there's dot bicep files
alongside the dot JSON files
(22:32):
that existed out there previously
from the
from the ARM templates that were available for
you.
I know where you say, hey, maybe I
think that's not helpful, but I would make
the argument that it's actually super helpful because
if I'm already familiar with ARM templates and
the construct of those JSON files,
now I can see side by side
and do that mental
(22:54):
mental map and translation in there. I can
see that. And they are sorted by resources.
So if you go out to this GitHub
repo and you start looking through, like, they
have a bunch of other stuff around
demos and modules, but under the quick starts
then it's broken down by things like
app services
on ACR.
You have things in here for
(23:15):
app services with HTTP
scaling rules,
you have automation
accounts
and configuration,
all the things Databricks,
Devices,
HD Insights, Key Vault. And then once you
get down there, they have different ones. Like
under Key Vault, there's,
what, maybe 10 different 10, 11 different samples
(23:38):
of Key Vaults with private endpoints, Key Vaults
with managed identity role assignment,
just creating Key Vaults. And that's
where under certain ones, not all of them,
you will find Not all of them have
it. Yes. Not all of them have it,
but under certain ones, you will have, like
you said, those JSON files and those dot
bicep files that you can
open up, look at, compare,
(24:00):
figure out how to translate from one to
the other. You've got all those out there.
You can also
export
your
existing resources.
So for a long time, you've been able
to
export, like, an ARM template of your existing
resources.
I think it's a little bit of a
misnomer that we tell customers that, like, oh,
you can export it, but you can't actually
(24:21):
run that template and then have it spin
up the same resource again. Yeah. That being
said, like, you at least get it as,
like, a manifestation
or an example
of the things that are sitting out there.
You can export to ARM,
to an ARM template, export to Bicep. They
recently added the ability to export to Terraform
as well. So you mentioned Terraform earlier.
(24:44):
Terraform is all built around HCL.
HCL is a scripting language.
So Terraform is
also a domain specific language. Right? It's another
set of these things where you're doing maybe
a little bit more programming than just generic
generic JSON
kind of thing and JSON validation,
(25:04):
which also shows, hey, Microsoft's moving in the
direction that some of these other things have
been going for a while now, like HashiCorp
with TerraForm. This is one thing. I have
not written much bicep. I will be honest.
It is it's on my list. Remember that
list? I haven't talked about my list in
a while.
Yeah. Yeah. It it is a thing that's
out there. Oh, one other option for you
(25:25):
just while we're talking about, hey, maybe getting
hands on
and finding examples and things like that is
it's also possible
to
so when you execute a bicep
script
and you go ahead and actually do that
deployment again, it's converted into an ARM call
on the back end.
So beyond going from, like, a bicep file
(25:47):
to an ARM template, you can also go
the other way, and you can decompile
an ARM template
and turn that
into
a bicep file as well. So maybe if
you have already an investment, like, you're very
familiar with arm templates and you're like, I
don't know. Just put me on the path
where I can start to figure out how
to translate my existing stuff. You can go
down that path as well and convert back
(26:09):
the other way. Got it. The other thing
I would say getting started, if you are
new to this, is there is also some
learn modules for BICEP 2. Like we talked
about, you can just go read the learn
documentation,
but there is
a learn module
for walking through
how
you can start using Bicep, covering fundamentals.
(26:31):
There's like the fundamentals,
intermediate,
advanced,
going through different
deployments.
Looks like there is some for
there's probably some in here for authoring Bicep
files.
But if you do want a little bit
more of a, let's say, guided approach to
walking through
learning it, writing them, using them in deployment,
(26:52):
pipelines as in here, using it in deployment
stacks. There is also this learn module for
bicep. There are tons and tons of learn
modules out there.
One recommendation
that I would have for folks, and I
keep going
back to
this one, is there's a specific learn module
(27:15):
out there.
Let me pull up a link to it.
So it's called structure
your bicep code for collaboration,
and I think this is a really good
one for a couple of reasons. One is
it starts to walk you down the optimization
path
from the start. So it gives you this
big long bicep file, which is more than
(27:36):
just deploy a storage account, which is one
of my annoyance when you go out and
start with the quick starts and things. They're
usually like deploy a storage account to play
this single instance thing, like, yeah, I get
single instance, but you'll probably want, a little
bit more than that. So the the very
first thing that does is it goes out
and it gives you
a getting started bicep template,
(27:57):
which totally works as is. It's just not
optimized.
It's just not doing all the things that
you might want it to do.
It's got, like, bad names for parameters.
And so that learn module walks you through
things like how to think about naming your
parameters, which the the guidance for naming your
parameters in a bicep file, by the way,
(28:19):
doesn't really differ from the guidance of how
you should be naming your parameters in an
ARM template, but I think it's a good
reinforcement
because
I'm I know I'm guilty of this all
the time where I go out and I
create something and I just go, like, the
easy button. I'm like, oh, I need a
name.
Var name equals blah blah blah. But it
turns out that name was for a specific
resource. It was like a name for a
virtual machine. So what I really should have
(28:41):
done was name that variable, like, var
my
web virtual machine, var my middle layer, my
API layer virtual machine. Like, you should be
far more descriptive, use camel case,
all those kinds of things. Make sure that
your parameters
are typed.
So, integers are integers, strings are strings, objects
(29:01):
are objects. Of course, this is like back
to programming language thing. This helps us leverage
and use all of those later on.
It also walks you down the path of
how to
think about structuring
your bicep files
because
ARM files are very specific where the parameters
are at the top, resources are in the
(29:23):
middle, and outputs are always at the bottom.
Right? It's just gotta follow that flow,
to be able to lint and things like
that's not the case with a bicep file.
You can have a parameter here, a resource
here. You can have an output here. You
can have this other thing. You can have
a function next. Like, you can just go
wild. I think structure that thing however you
want, but that might not be the most
(29:43):
readable thing for the next person. It might
not be the best way to leave your
campground
in a in a good place for the
next camper when they come through. And you
don't want folks having to clean up after
you. So it it it could that module
in particular gives you a sense of what
some of those things are that you would
want to
think about along the way. And, ultimately, what
(30:05):
it does is it walks you down a
couple steps. Let's improve your parameters. Let's improve
your parameter names. Let's make sure we put
comments in. Oh, do you understand the difference
between inline comments versus structured comments versus multiline
comments?
All those kinds of things. Are your
are your templates
annotated
correctly? So
(30:26):
beyond
your things like having comments,
have you put descriptions on your parameters? So
in case you're asked for, like, a parameter
input when you're running a deployment from the
command line, have you thought about how you
commonly structure things like resource tags and governance
constructs?
That's all in there. And, ultimately, it walks
(30:46):
you down this path of, hey, let's optimize
and refactor your bicep file. So it gives
you an a and b, camera 1, camera
2 kind of thing, and it gives you
the flexibility and the freedom to figure it
out your
your yourself along the way.
I think that's super helpful
and
definitely works towards
(31:07):
improving just readability of bicep files and keeps
you on a common path as the way,
like, the creators of that
domain language
intended,
walks you through rationalization
for ordering elements.
I think you also
work with
collections
in that module.
So collections
(31:28):
allow you to have, like, multi propertied
objects
that you can consume in an easier way.
One of the examples that I can think
of again is, like, virtual machines. So virtual
machines have
a SKU, like, hey, I'm deploying a b
one VM over here, but then you also
have things like number of instances of a
VM that you want to deploy, and you
(31:49):
might want to make that a parameter and
dynamic within
within your function. So rather than having a
parameter of
my VM one name dot SKU and my
v one my VM
one dot count,
maybe you have more like a environment
parameter or you have some other parameter that
says, oh,
(32:09):
when parameter is set to prod,
just deploy
d series VMs with this many instances. When
it's set to dev, deploy b series
with this many instances, or deploy this set
of tags or these things over here. So
it it walks you through all of those
constructs as well
in in, I think, a pretty clear manner.
(32:30):
And like I said, that's when I I
tend to find myself, like, going back to
just
the main optimization
article
that Microsoft
has out there. So they have a best
practices
for bicep article.
Between that one and then just revisiting that
learn module occasionally, where I can, again, a
b the starting and the ending template
(32:51):
or the starting and ending bicep file, then
that that generally gives me a good sense
and enough to, like, oh, yeah, give my
brain a kick, and let me remember where
I wanted to be with that particular thing.
Sounds good. I really should go spend some
more time with biceps, Scott. Even though it
is 4 o'clock and Friday, I still have
3 more meetings today. Yuck.
So we should call it a day, get
(33:14):
ready for Ignite.
We will probably we'll probably try to get
some interviews, have some news,
talk about some of the Ignite stuff here
in the next couple of episodes. Yeah. I
am
looking forward to it. Got my plane tickets
booked and everything. I'm all set. Perfect. We
will see you at Ignite, Scott, and hopefully,
we will see a few of, your listeners
at Ignite as well here in a couple
(33:35):
weeks. But for now, enjoy your weekend, and
we will talk to you again later. Great.
Thanks, Ben.
If you enjoyed the podcast, go leave us
a 5 star rating in iTunes. It helps
to get the word out so more IT
pros can learn about Office 365 and Azure.
If you have any questions you want us
to address on the show or feedback about
(33:56):
the show, feel free to reach out via
our website, Twitter, or Facebook.
Thanks again for listening, and have a great
day.
Popular Podcasts
On Purpose with Jay Shetty
I’m Jay Shetty host of On Purpose the worlds #1 Mental Health podcast and I’m so grateful you found us. I started this podcast 5 years ago to invite you into conversations and workshops that are designed to help make you happier, healthier and more healed. I believe that when you (yes you) feel seen, heard and understood you’re able to deal with relationship struggles, work challenges and life’s ups and downs with more ease and grace. I interview experts, celebrities, thought leaders and athletes so that we can grow our mindset, build better habits and uncover a side of them we’ve never seen before. New episodes every Monday and Friday. Your support means the world to me and I don’t take it for granted — click the follow button and leave a review to help us spread the love with On Purpose. I can’t wait for you to listen to your first or 500th episode!
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com