Simon Gottschlag: 0:00

Welcome to For a Cloudy Day, where we explore the cloud technology industry with insights from industry experts. I'm your host, Simon Gottschlag, CTO of Co-native the home of cloud specialists. In today's episode, we're delving into a topic for Azure users, how to import existing resources using Bicep, an Infrastructure as Code tool. To help us explore this, I'm joined by Carl Lindberg from Xenit, one of the leading cloud experts in Sweden. Carl, it's great to have you here. Could you start by telling our listeners a bit about your role at Xenit and your experience working with Azure and Bicep?

Carl Lindberg: 0:44

Thank you very much for having me, Simon. I sure can. I help customers move to the cloud in a nutshell, but that could mean, it is a green field where customers may not have anything in cloud and we start to build from scratch, essentially, or what is more common is that they already have some sort of infrastructure, maybe they have some on-premises locations, but they also have some resources in the cloud, and they want to either move those resources all the way to the cloud, or they are essentially running a hybrid environment, which is something we see very commonly. So I help them in that journey essentially, we try to use the frameworks that exist, and try to guide the customers and help them interpret those, and make decisions based on those frameworks that exist. And it's a lot of adopting new technology. And like you mentioned, Infrastructure as Code and so that's one of my main focuses.

Simon Gottschlag: 1:48

Let's kick things off with an overview. For those who might be unfamiliar, what is Bicep and why is it becoming such a vital tool for managing Azure resources?

Carl Lindberg: 2:02

Azure Bicep is an infrastructure as code language, and it's a declarative language. And what I mean with that is that, in comparison to a language that is imperative, such as PowerShell, where you're essentially telling the program in sequence, do this, do A, then B, then C. Using a declarative language, such as Azure Bicep, you essentially write the end product. So you tell Azure Bicep, this is how I want my environment to look. It could be, this is how I want my virtual machine to look, or this is how my storage account should look, and it's idempotent, which means that if you run it several times, you should be able to expect the same outcome. And Azure Bicep, that we're talking about today is like a domain specific language to Azure. And, what I mean with domain specific is that you have other tools such as Terraform, which is more cloud agnostic, which, where you can run in different clouds, so you can even run it in your own on-premises data center. But Azure Bicep is specifically for Microsoft Azure. And what it does is, it automates Azure infrastructure, it documents your environment and it lets you declare your environment essentially.

Simon Gottschlag: 3:19

One of the key challenges when adopting infrastructure as code is managing existing resources. Could you walk us through the process of importing these resources into Bicep?

Carl Lindberg: 3:31

I'm a big proponent in using any tool that is available to you. VS Code is, it's a program that a lot of people are familiar with, and I would bet that a lot of people are working with. I use a Visual Studio Code to author my bicep resources and they have, for one, they have great support with GitHub Copilot. So you get a lot of help like auto completion and things like that, which I definitely recommend to take advantage of. But easiest way, and I think in a nutshell is that you almost any resource in, in the Azure portal has like a JSON view button where you can get the resource ID of an existing resource. So you can just copy that ID and VS Code lets you use, if you have the Azure Bicep extension installed, it lets you run it, which is called,"Enter Bicep Resource", I think, or"Enter Resource ID", one of those two, and you just paste the resource ID and, the VS Code will give you like a boiler, or not a boilerplate, but it'll give you the anatomy of the resource. I do that and I do some changes and I make sure to use a what-if deployment, so if you're familiar with Terraform, it will be like a Terraform plan before you do a Terraform apply and just use that to import resources.

Simon Gottschlag: 4:52

What are some good practices you've found when working with Bicep, particularly when importing existing resources? Are there any common pitfalls that teams should be aware of?

Carl Lindberg: 5:06

Yeah, there's a few. the most common one I would say is you try to bite off a little bit more than you can chew. Like I mentioned before, you can enter resource IDs, but you could also run import functions on entire resource groups and entire subscriptions. But I find it very confusing to do that. It's, it'll be a lot of code. So I try to have a strategy and make sure that we try to divide our different resources. Maybe we focus on compute and networking and we focus on individual resources like that. Also because the import function that I mentioned, it's not 100 percent foolproof, so you still have to import the resource, but you will have to go through that resource and update name properties. Some properties read only, but they will get imported as well. So you have to make sure you go in and remove those. And there's, there's some refactoring with every import and there's no way around it so try to keep it, like in smaller batches and make use of the what-if deployments, and then when you feel comfortable in the code you have, you can expand and add more resources as you go along. Don't try to climb everything at once, do it in bits, I would say.

Simon Gottschlag: 6:27

It's single-piece flow in lean manufacturing and make sure that each piece works before you start the next one. At Xenit, how have you been using Bicep for managing Azure infrastructure? Can you share an example where importing existing resources using Bicep had a significant impact?

Carl Lindberg: 6:51

At Xenit and in my team, we use, Azure Bicep, we also use Terraform. We can work with both languages, it doesn't matter to us too much. We find that there are pros and cons with both, but we have usecases where customers are interested in, adopting infrastructure as code, but maybe they feel like, okay, but we've already created a lot of things in the portal. Can we even create, or can we even adopt infra as code at this point? I would say currently that Azure Bicep is a little bit easier than Terraform to import things. You can definitely import things with Terraform and we do. It's not as straightforward as using the extension though in VS Code, but, we have customers where we have, done both. I had one example where we have a customer who had a very old code base, not even that they're running ARM templates, but it's even they're using PowerShell, which we may not recommend it for that purpose is great for other purposes. So that those are things that we do in our team and, why we use it is because we feel if we can use modules we can, it's easier to implement standards so it's both for our customers, but also for our coworkers that we on-board to our team, they can quickly see how we work with resources, how we think about networking when we deliver a landing zone for example, it's all in the code. So it's already documented. The starting curve is not as steep, for both coworkers and customers.

Simon Gottschlag: 8:31

For listeners who are ready to start using Bicep, what steps would you recommend? Any essential resources or tips for beginners?

Carl Lindberg: 8:41

There's a lot, not to mention all the YouTube videos and such that exists. But personally, I used Microsoft Learn a bit. They have learning paths and modules you can just go to the documentation and search for Bicep. What is nice about that is that not only will you get an introduction to the code, but you will also get to work with some DevOps, building some pipelines, which I find very useful. So I would recommend that. And then just like start to work with it, have a safe environment, get like a test subscription, make sure you remove everything when you're finished, so you're not billed for any resources that you shouldn't be billed for and just start creating things. A big hurdle for me in the beginning was that, okay, I, maybe I learned to create, one type of resource, but I didn't know how to create the next type. And I would create it in the portal and I would export the template, I would start working with it that way, seeing how things go together, you will find when you create, for example, virtual machines that the VM is a resource, but the disks is its own resource and has its own API and its own configuration. If you want to maybe try to put a load balancer in front of it, public IP address, try to build the, like those types of things I would say.

Simon Gottschlag: 10:06

All right, it sounds like just getting started is one of the best ways to start learning. And, importing existing resources would be one way to do that.

Carl Lindberg: 10:19

Yeah, I think there's a point in doing both. Find a mix, I would say, like you mentioned.

Simon Gottschlag: 10:31

Thanks for those valuable insights, Carl. To recap, we've covered what Bicep is, how to import existing resources, and some good practices to keep in mind. Carl, before we wrap up, do you have any final thoughts or advice for our listeners who are considering using Bicep for their Azure projects?

Carl Lindberg: 10:53

I would like to echo what you said. Just start. Don't try to make something perfect. Just get your hands dirty. You will find the pitfalls. You will do some mistakes, but you will learn from them. I know I did. So I would echo what you said.

Simon Gottschlag: 11:20

Thank you, Carl, for sharing your expertise today. And thanks to everyone for tuning in to For a Cloudy Day. If you found this episode helpful, please share it with your network. And to our listeners, are there other topics you'd like us to explore in the future, or perhaps you have someone in mind, or even yourself, who would make a great guest on the show? Let us know, reach out to us through our social media channels.