What is infrastructure as code?

- [Instructor] What is infrastructure as code? Let's say, you want to deploy some resources to Azure. Often you will need more than one resource. Maybe you want a virtual machine and then a network and a network interface. Or maybe you're creating a web application where you will need a web app, an app surface, and maybe a private endpoint. You can deploy these resources manually through the portal and it works very well for a single deployment. But if you are using this in an enterprise environment, you might need an development environment next to your production environment and that would consist of the exact same resources. So, now you have to click twice through the portal to create the same resources. At this point, it might be easier to consider infrastructure as code, where you have one file where you describe the resources you want to create and you can keep deploying it again and again. Let's look at an example of infrastructure as code. This is a storage account and the code that you see in this case is Bicep. Now, on the first line, there are some parameters defined. In this case, a storage account name. And on line four, the resource itself is defined, a storage account. All the properties that are relevant are defined here. I cannot view, of course, use of multiple parameters if I want more flexibility. By using the parameters, I could deploy this resource twice but use unique storage account names each time I do it. So let's move back to that resource group we were creating. We already had multiple use cases because we want development and production, so we're already deploying this more than once. But in an enterprise environment, maybe at some point some team comes and says, we need the exact same resources. We are also creating a web app or a virtual machine and we want the exact same resources. So, now you can deploy their environment maybe with the same template, maybe just the name needs to be changed. And if they need development as well, you can deploy that as well from your template. But now what happens if another team comes up and they need the same resources, but something is different? Maybe they don't need that private endpoint, or maybe they don't need a virtual network for the virtual machine because they already have deployed that one. So this is where you need to consider how you work with your infrastructure as code files. We could create three files here, three different templates for each of the resources. In this case though, the first two resource group are pretty much identical. Only the names will be different. We can catch that with parameters. So we might decide to use one template for these two resources. If we use the same template for both the resources, that means we only have to manage one piece of code. But could we take this further? These three deployments are pretty similar. Maybe we can catch them under one template where we use a condition to help out with that one resource that we don't need. But then again, if we do it like this, we will need more parameters when we deploy it because more flexibility is needed. So each time we deploy this template, we need to consider more parameters. So it's a little bit more work and it requires maybe a little bit more knowledge. There is no right or wrong answer here whether you have three different templates or one template for all these resources. It depends on what you need for your environment. It's just important to consider this balance, flexibility versus usability. If you have more flexibility in templates, often the usability goes down and the other way around. Like I said, there are no right or wrong answers. It's just important that you consider this. One more concept that I want to mention is declarative code versus imperative code. Declarative code describes the expected result so you make a description of the results that you want to get. It doesn't matter what steps need to be taken to get to that result, because the code will take care of that for you. Examples of the collaborative technologies are ARM templates, Bicep and Terraform. The other way to go is with imperative code. And in imperative code, you do describe the steps. You don't describe the end result, you describe the steps to get there. So maybe multiple commands are needed to get to a certain result. Examples for these are PowerShell, Azure CLI, or REST API. Both of these technologies have their use case. With declarative code, what is handy is that it's very transparent, it's more predictable as you can see exactly what the end result will be which can be a little bit less clear when you use imperative code. But imperative code then again, can give you a bit of flexibility. Because with imperative code, you can decide to only run part of the code if you have different needs at that point. So, both of them have their use cases and you are also able to combine them, for example, in a pipeline when you deploy stuff to Azure. It is good to be conscious of the differences between the two.