From the Stage at Microsoft Build 2025: My Story & What’s Coming Next

I had the absolute honor and pleasure of presenting a session at the Microsoft Build 2025 conference in Seattle last month. If you've been following me here, it won’t be a surprise that the topic was Bicep Infrastructure as Code for Azure.

I love a challenge, and this session certainly was one. It was a live demo session, which meant I had just 15 minutes, theater-style, to deliver a clear message, teach something valuable, and tell a compelling story.

Full disclosure: I had some experience with this session format from previous Build and Ignite events. The key is to trim the content to the bare essentials of your message. There’s no time for an extended introduction; demos must be live, fast-paced, visually engaging, and still easy to follow for both in-person attendees and those watching later. Zooming and drawing on your screen effectively can make a huge difference. I've been using ZoomIt for that for years and highly recommend it.

I chose to focus on the reusability aspect of Bicep code. I covered the three types of modules: stored locally, in Azure Container Registries, and Azure Verified Modules, using practical examples to highlight the differences.

Then, I took it a step further by showing how to enhance reusability with the export() decorator for custom types and functions, as well as resource-derived types.

Along the way, I showcased new Bicep features like the onlyIfNotExists() decorator and secure() decorators for module outputs. Whenever presenting Bicep at any event, I always like to demonstrate the Bicep Visualizer and the power of the Bicep extension to improve the overall authoring experience in VS Code.

I always try to build a narrative and begin with something unexpected, usually a personal story, to connect with the audience and capture their attention. So, how did I start my session this time? Watch the video and find out!

https://build.microsoft.com/en-US/sessions/DEM539

I also gave away a few copies of my book Getting started with Bicep: Infrastructure as code on Azure after the session.

Getting started with Bicep: Infrastructure as code on Azure

I had the honor of handing out these Bicep pins on behalf of the Bicep Product team, which were a huge hit!

Bicep pins to hand out as swag

And lastly, I had a great time continuing the conversation on Bicep at the Azure Infrastructure booth in the Hub, where I spent a whole morning answering questions, performing demos, and having great conversations.

Azure Infrastructure booth in the Hub area.

This photo was taken just two minutes before showtime. Check out the sign on the middle-left that says “ARM”, unintentionally hilarious for a session all about Bicep! :) And don’t miss the guy photo-bombing in the back — one of the fantastic A/V crew members who recorded the session. We had a great laugh about it together afterwards!

Photo taken 2 min before showtime.

Statistics shared by the event indicated 142 in-person attendees for my session! I’m truly honored. It’s incredibly rewarding to know that the content resonated with so many people, and I’m grateful for the opportunity to contribute to Build this year.

I'm looking back at a great week in the Seattle Convention Center!

And finally, it doesn't stop there; I will deliver an extended version of this session to upcoming community conferences. More news on those soon!

Bicep Christmas gift: the deployer() function

The Bicep language for Azure Infrastructure as Code (IaC) continues to evolve rapidly, reshaping how developers and cloud architects design, deploy, and manage Azure resources.

In this post, we’ll explore an exciting new function introduced in Bicep version 0.32, highlighting how it enhances the language’s capabilities for Azure Infrastructure as Code (IaC). These additions reflect Bicep’s continuous evolution, making it even more powerful and versatile for developers working with Azure.

A common challenge in Azure Infrastructure as Code (IaC) is identifying and reusing the identity executing a deployment. This capability would enable assigning roles or configuring access dynamically without hardcoding identity details or managing them externally.

Currently, Bicep provides functions like subscription(), retrieving metadata about the subscription in which the deployment is running. However, there wasn’t a built-in way to access details about the principal executing the deployment.

With Bicep 0.32 you now can! The function deployer() is introduced, which allows you to retrieve the object of the principal that is deploying the Bicep file!

The function deployer() allows you to retrieve the objectId of the principal that is deploying the Bicep file

The ability to natively access the deploying principal within Bicep would eliminate the need for additional automation scripts or manual intervention, making deployments more streamlined and robust.

One practical use case for this functionality is generating unique GUIDs for scenarios such as creating role assignments. By leveraging the unique attributes of the deploying identity — such as its Object ID or Tenant ID — along with other contextual details, you can create deterministic and consistent GUIDs.

generating unique GUIDs

The deployer() function also proves valuable in scenarios involving Azure Entra ID. For instance, when creating an Entra group using the new Graph extension, you can seamlessly assign the current user (or deploying identity) to that group. This dynamic capability simplifies group membership management and eliminates the need for workarounds.

Upgrade to 0.32 to get access to the deployer() function!

As we wrap up, it’s exciting to see how features like the deployer() function are expanding the capabilities of Bicep, making Azure Infrastructure as Code more powerful and intuitive.

With the holiday season upon us, it’s the perfect time to reflect. Whether you’re deploying in the cloud or just enjoying some downtime, here’s wishing you a joyous holiday season and a fantastic start to the new year! Looking forward to 2025!

***

Originally posted here: https://www.linkedin.com/pulse/bicep-christmas-gift-deployer-function-freek-berson-a8hye

Introducing Bicep on the Go: a new series of short videos!

Bicep on the Go: a new series of short videos showcasing specific Bicep features, having fun with Infrastructure as Code, and maybe even interviews with #community members! 💪Let me know if you’re interested!

(2) Bicep on the Go — Trailer — YouTube

Bicep on the Go — Trailer

Last weekend, an idea popped up💡… I’ve been presenting on Bicep infrastructure as Code at conferences around the world for quite some time now. Usually, these are 45 to 60-minute break-out sessions. I always prefer doing all demos live, so I was thinking, why not publish these demos as short clips for everyone to consume on demand?

Hence, the inception of Bicep on the Go! Easy-to-digest content designed to help you jump-start your IaC development

Link https://www.youtube.com/playlist?list=PLGLjpco69i8MAIyTX094CtLtNBiW-7iQ4 to the playlist, which already contains episode 1, about #Github #Copilot and the #Bicep visualizer!

📽️Most recently, I presented at the EUC User Group in Stockholm, so this trailer and the first few of on-the-go clips were taken from that event. Special thanks to Kent Söderlund and Gabriel Yttermalm for hosting the amazing End User Computing Sweden event earlier this month and recording!

#Bicep #MVPBuzz #IaC

Publish Bicep modules to registries with the source.

Bicep offers the ability to store your modules in a registry in Azure. This is based on storing them in an Azure Container Registry (ACR).

This approach offers several advantages, especially regarding DevOps practices, version control, shared access, and reusability.

Let’s consider the module below, which creates several Azure Virtual Desktop (AVD)- related resources, such as host pools, workspaces, and application groups.

Publishing your modules to an ACR is quite easy. In this example, I’ll use Azure CLI. First, create an ACR in case you don’t have one yet. Since an ACR is just another resource in Azure, you can use Bicep to create one, as shown below.

Now use the publish command, provide the bicep module you want to publish, and provide the target location, the ACR, and where you want to store it.

The result looks like the below: a container repository is visible under repositories.

You can now start using modules inside your Bicep templates. In the example below, I’m referencing the module stored in the ACR that creates the Azure Virtual Desktop resources.

Today, you already have the ability in VScode to view the source of the module; simply hit F12, and you are provided with the source.

This is, however, the transpiled version based on ARM Templates in JSON. Wouldn’t you rather want to see the Bicep module instead? You now can.

There is an experimental feature called publishSource that you can add to your bicepconfig.json. Afterward, you can add the option — with-source to your publish command.

Based on the header image of this article, what country will I be visiting this month? Reply to this post with your answer to win a copy of my book!

When you now press F12 you can see the original Bicep module containing our AVD resources! 💪 When you hover over the file name, you can see the source location, the ACR, module name, and version.

This makes working with Aure Container Registries a lot more convenient!

📖 Looking to get started with Bicep? I authored and published the book Getting started with Bicep: Infrastructure as code on Azure

Exporting and importing variables between Bicep files: compileTimeImports

 

Infrastructure as Code (IaC) has revolutionized how we manage and provision IT infrastructure. Azure’s adoption of this concept through Bicep, a domain-specific language, has made it easier and more efficient.

In case you’re (still) wondering what Bicep is, it is an open-source language developed by Microsoft for declaratively deploying Azure resources. It aims to simplify the authoring experience and provide a cleaner syntax compared to ARM templates. Bicep files are transpiled into ARM templates, making it a powerful yet user-friendly tool for Azure deployments.

In this blog, I cover how to use a feature (experimental) that allows you to export and import variables, user-defined functions, and user-defined types.

It has been in the Bicep builds for some time, but it’s a very useful feature, and I have never published on this before. Before you dive deeper into the functionality of exporting and importing variables between Bicep files, it’s important to highlight that this feature is currently experimental. To use this experimental feature of exporting and importing variables in Bicep, you need to enable it explicitly. This is done by modifying the bicepconfig.json. The configuration to add or modify is compileTimeImports, which should be set to true.

Now consider the Bicep module below. This module deploys a few Azure Virtual Desktop (AVD) resources like a host pool, application group, and workpace.

Note that you can use the @export() decorator. This makes the variable ‘prefix’ importable by other Bicep files or Bicep modules. As a result, we reuse the value without declaring it across multiple files. This is a simple example, but you can imagine adding multiple variables or even user-defined functions and user-defined types.

You can now use the exported variables in other Bicep files in a couple of different ways. To import a single value, use the import state as shown below. You use the keyword Import, followed by the name of the variable, followed by the source Bicep file. Super easy, right? You can now use the ‘prefix’ variable inside this Bicep file. In this example, we use it in line 23 to generate a name for the network interface.

If you want to import it using another name or alias, simply use the method below. You can now use the variable by referring to the alias you defined. In this case, ‘i_prefix’.

You can, of course, also import multiple variables at once using the code above by referring to them all individually.

Finally, an even easier way is to import all exported variables by using the ‘*’ sign as shown below. You can now use ‘imported’ as the name and specify the variable after the ‘.’ sign, and the Bicep VSCode extension even picks up on this, providing you with an auto-complete.💪

The great thing is you can also import inside .Bicepparam files in the same way. In the example below, I import the values and use them as values for my parameter files. If you are new to Bicepparm files, follow a previous article where I explain how this works.

It might seem like a simple feature, but to me, it is a super welcome addition to the language. It avoids declaring certain variables or types multiple times and improves reusing code. I like it, and the possibilities and use cases are endless! What do you think?

📖 Looking to get started with Bicep? I authored and published the book Getting started with Bicep: Infrastructure as code on Azure