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 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. 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 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
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, 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, 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 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 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 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 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 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 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 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
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 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. 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 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 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 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. 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 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, 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 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, 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 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, 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 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 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 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 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% 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 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 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 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, 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
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 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 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 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. 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 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 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 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. 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 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 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 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 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 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 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.
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 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 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 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,
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, 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 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 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 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 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, 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 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.
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 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 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 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 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, 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 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.
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, 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 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 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
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. 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, 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 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 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, 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, 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 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 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 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 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 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 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 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 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 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 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, 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. 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 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 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 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 the show, feel free to reach out via our website, Twitter, or Facebook. Thanks again for listening, and have a great day.