Infrastructure as Code

Azure Verified Modules are a new initiative to create a library of verified, well-designed and supported infrastructure as code modules for Azure. Let’s take a look at what they are and why you might want to use them.

One of the benefits of using a multi-cloud Infrastructure as Code tool like Pulumi or Terraform is that you can easily transition between layers in different providers. For example, you can deploy a Kubernetes cluster in Azure with AKS, and then using the same IaC deploy pods and services into that cluster. To do this, the IaC tool needs to retrieve some credentials in the form of a Kubeconfig file, from the cluster it has just deployed.

Pulumi recently announced the beta release of their Azure Native provider. This provider allows the creation of Azure infrastructure using Pulumi, with the native part meaning that this is auto-generated from the Azure APIs, rather than hand-crafted like some of the Terraform-based providers. Upgrading to v2 should be a fairly easy process, there are no huge tasks to undertake, but there are some things to be aware of, which we will look at in this article.

Pulumi recently announced support for using OIDC to authenticate to Azure when deploying your resources. This is separate from the Pulumi service supporting this, which it has done for a while, and means you can use OIDC from any supported deployment mechanism, you don’t have to use the Pulumi service to get this. Let’s take a look at what that means and how to do it. Why use OIDC? When you deploy resources to Azure, you need to provide some sort of credential to do the deployment.

When you first start with Infrastructure as Code, it can be tempting to create one template to rule them all™ where you can deploy your whole infrastructure in a single deployment. If you’re only deploying a few resources, then this can be fine, but once you get beyond that and are deploying complex sets of infrastructure, it’s important to consider your blast radius. So what do we mean by blast radius?

Absolutely nothi… oh wait, they might have some uses. When choosing an Infrastructure as Code (IaC) tool, there are many differentiating factors among the options available, but one that often comes up in this conversation is whether or not they use a state file. Some languages, such as Terraform and Pulumi, use a state file to track what has been deployed outside the cloud provider’s system. In contrast, other languages, like ARM templates and Bicep, don’t have a state file and rely on the actual state of the resource.

Have you ever wondered why you can’t create some Azure resources using ARM or Bicep, or it’s not present in the Pulumi API, but sometimes you can do it in Terraform, or just not? If you work with Infrastructure as Code, you need to understand the difference between the Control Plane and Data Plane. These two planes represent two different types of operations in Azure. Control Plane Most top-level Azure resources fall under the control plane.

How to use the Visual Studio debugger to investigate issues in your Pulumi Infrastructure as Code projects

Project Bicep is a new Microsoft DSL for deploying resources in Azure, built on top of ARM tempalets

Pulumi is an Infrastructure as Code tool that let’s you use real programming languages. Let’s look at how it works.