As a .NET developer, I host most of my applications on Microsoft Azure. I have a few simple web apps, and I also run a SaaS product on Azure.
It includes an Azure SQL Server instance and multiple Web Apps running on an App Service Plan. It also uses Azure Functions and therefore needs a Storage account.
Besides the production environment, I also have the same resources for the test and development environment. Overall for such a simple product, I already have about ten different Azure resources I need to manage.
As a developer, I don’t know much about managing infrastructure. I use the Azure portal to create and configure new services and change settings on existing services.
I don’t like that work because it’s not repeatable, and I also don’t like navigating the ever-changing Azure Portal with thousands of functions that I don’t need.
As a developer, I always ask myself: How great would it be if I could create and manage my Azure resources using code?
Well, it turned out, you can actually do that with something called Infrastructure as Code (IaC).
As said earlier, I’m a .NET developer with a lot of experience on the .NET platform, but I am not an operations person.
I recently got into Infrastructure as Code, and this article is the first in a series where I will share what I learned about Infrastructure as Code and how we can apply it in the .NET world to make our cloud deployments simpler, repeatable, reliable, and a lot faster compared to using the Azure Portal.
What is Infrastructure as Code?
Let’s start by looking at a few definitions of what Infrastructure as Code is.
“Infrastructure as Code (IaC) is the process of managing and provisioning computer data centers through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools.” – Wikipedia
Redhat provides a simpler definition:
“Infrastructure as Code (IaC) is the managing and provisioning of infrastructure through code instead of through manual processes.” – Redhat
Last but not least, let’s read the Microsoft definition:
“Infrastructure as Code (IaC) uses DevOps methodology and versioning with a descriptive model to define and deploy infrastructure (…). Just as the same source code always generates the same binary, an IaC model generates the same environment every time it deploys.” – Microsoft
In my own words, Infrastructure as Code lets me use program code or configuration files to create my Azure resources instead of using interactive tools like the Azure Portal.
And similar to source code compiling to the same DLL, Infrastructure as Code allows me to always create the same infrastructure with the same configuration.
What Types of Tools Exist?
Let’s take a look at what tools exists in the world of Infrastructure as Code. There are two main groups:
- Declarative (functional): It uses a defined syntax to describe the desired state of the resources. The system will figure out how to get to that state. This approach usually uses configuration files such as YAML or JSON.
- Imperative (procedural): It uses a step-by-step definition to define the resources. We describe what the system needs to do to get to the desired state. This approach usually uses program code, such as C# or other programming languages.
What Are Popular Tools for .NET Development on Azure?
Let’s look at what popular tools for the .NET world and deploying resources on Azure are available and what category they fall into.
- Azure Resource Manager (ARM): Azure Resource Manager, often called ARM Templates, was introduced by Microsoft in 2014. It’s Azure-only and uses the JSON format for its definitions and the Azure CLI for its execution.
- Bicep: Bicep was created by Microsoft and became generally available in mid-2021. It’s pretty new, and adoption is currently less than ARM, but it is intended to be its successor. It uses a domain-specific language and compiles its definitions into ARM templates using the JSON format.
- Terraform: Terraform is an established tool and widely used. It was introduced in 2014 by HashiCorp and uses a domain-specific YAML format to define and configure cloud resources.
- Pulumi: Pulumi was created by a company with the same name in 2018. It allows us to use our favorite programming language, including C#, to define and configure infrastructure.
Infrastructure as Code for .NET – Tooling Overview
Let’s quickly look at those four tools. As you can see, there are different levels of abstraction, declarative and imperative tools using different configuration formats such as JSON, YAML, a popular programming language, or a DSL.
Some of the tools keep the state, meaning they know what was deployed, and others are stateless.
There are many more tools available, but I wanted to quickly show different types of tools here to provide an overview.
Each tool uses a unique approach to Infrastructure as Code, and it depends on many factors on what tool is suited best for a given scenario.
In a future article in this series, I will take a closer look at those four tools and use them to create and configure Azure resources.
Let’s step back and talk about the benefits of using Infrastructure as Code.
What are the benefits of Infrastructure as Code?
Infrastructure as Code has several benefits compared to manually creating and configuring cloud resources:
- It saves time. We don’t have to navigate the Azure Portal, find the right service, and click through the configuration wizard. All we have to do is to run the script defining the infrastructure. The more we need to create the resources, the more time we will save. We write it once and apply it as many times as we need it.
- It acts as a documentation. I have to be honest. I don’t have documentation of all my resources that don’t use infrastructure as code. They might need a connection string here and a feature flag there, all configured in the Azure Portal. Infrastrucure as Code forces us to define those configurations in the definition. As a result, we get documentation of what the different resources need to work as intended.
- It makes it reliable and repeatable. Imagine you have a few resources, all configured using the Azure Portal. For whatever reason, you happen to accidentally delete those resources. It could take you a long time to create those resources and figure out how to configure them. If you have an Infrastructure as Code definition, you simply run the script, and you have everything you need in place again.
- Version your infrastructure changes. With Infrastructure as code, we either have program code or configuration files, but both can be checked into our Git repository. It allows us to keep track of infrastructure changes. We can even document what requirement or new feature triggered a change in the infrastructure by linking the commit to our issue-tracking system, such as Jira, ClickUp, or whatever we use.
- Process automation. We can include infrastructure creation and configuration in our CI/CD pipeline. For example, we can create and configure a test environment before deploying our application to that test infrastructure – all without touching a single resource ourselves.
Conclusion
We learned what Infrastructure as Code is and its benefits compared to manually creating and configuring Azure resources using the Azure Portal.
Everything stated here also applies to other clouds and other development stacks. However, as a .NET developer using Azure, I’m most familiar with those tools and therefore use them as examples.
In future articles of this series, we will explore different tools for using Infrastructure as Code as a .NET developer. We will learn about ARM Templates, Bicep, Terraform, and Pulumi.
Check out my Infrastructure as Code playlist on YouTube and consider subscribing to my newsletter.
