One of the most popular approaches to handling developer operations (DevOps) in software development today is infrastructure as code (IaC). IaC is the process of managing and provisioning infrastructure using configuration written as code. Instead of performing the work manually, teams write code to provision infrastructure components and use that code to automatically deploy applications.
There are multiple benefits to IaC:
- Faster deployments: IaC allows faster provisioning of infrastructure, and infrastructure can be managed more easily.
- Improved productivity and accountability: IaC ensures that engineers spend less time performing manual tasks so they can dedicate more time to higher-value tasks.
- Consistent infrastructure configuration and setup: Because infrastructure configuration is stored as code, it can be more easily kept the same across all environments.
- Less human error: Manually provisioning infrastructure can lead to more mistakes. With IaC, automated provisioning reduces human error.
This article will delve into IaC practices and how they can help developer teams. You'll also learn more about the two most common IaC tools, Terraform and AWS CDK, and how each might benefit your projects.
Why Should You Use IaC Practices?
Previously, teams had to manually set up servers, install and update the needed software, and configure storage and other infrastructure components before deployment. This required much more time and effort, and it left more room for error, compared to using IaC to handle DevOps.
IaC practices rely on configuration files to automate the server setup and installation of components. These files can serve as a single source of truth, and they can be versioned to track changes. This significantly reduces stress on the development team, and it ensures a more stable, scalable environment. It also helps reduce costs, because resource usage is based on demand and not constant.
There are multiple IaC tools available, but the most popular choices are Terraform and AWS CDK.
Using Terraform for Infrastructure as Code
Terraform configurations are maintained in <span class="code-exp2">.tf</span> files and use HCL syntax. HCL, or HashiCorp configuration language, is a declarative language for configuration files that helps define the desired state of infrastructure.
Terraform can deploy and manage infrastructures across public cloud providers (such as Amazon Web Services, Microsoft Azure, and Google Cloud Platform) as well as on-premise solutions (such as VMware).
How Terraform Works
Terraform consists of two main components:
- Terraform Core
- Terraform Providers
Terraform Core is responsible for the entire lifecycle management of infrastructure. It checks the current state of the infrastructure and compares it against your desired configuration.
Terraform Core suggests a plan to create, update, and delete infrastructure components as provided in the configuration file, then figures out the provisioning or decommissioning of resources if the plan is to be applied.
Terraform providers are plug-ins that enable Terraform Core to interact with your infrastructure or SaaS providers and other APIs. The providers give you the resource types to manage either cloud or on-premise infrastructure.
There are three basic execution commands when working with Terraform:
- <span class="code-exp2">terraform refresh</span> queries the real-world infrastructure provider to get the current state of the infrastructure. It's automatically run by the <span class="code-exp2">plan</span> and <span class="code-exp2">apply</span> commands.
- <span class="code-exp2">terraform plan</span> creates an execution plan that helps to determine the necessary actions or changes needed to get the infrastructure to its desired state.
- <span class="code-exp2">terraform apply</span> executes the plan in the target environment to bring it to the desired state. If one of the resources being provisioned is mistakenly deleted, <span class="code-exp2">apply</span> can be run to provision the resource and get the infrastructure back to its desired state.
Once you're done with the infrastructure provisioning and you want to destroy resources that are no longer in use, the <span class="code-exp2">terraform destroy</span> command deletes the infrastructure. Use this command carefully and target the resources or the module in case you don't want to delete the entire infrastructure.
One of Terraform's key benefits is that different cloud services (Google, AWS, and Azure) offer recommendations on how to use them with Terraform. You can find these recommendations in the official Terraform registry.
Before you can use a provider, you must declare it in your configuration, run the <span class="code-exp2">terraform init</span> command, and install the provider binary.
Using AWS CDK for Infrastructure as Code
The Amazon Web Services Cloud Development Kit (AWS CDK) is an open-source software development framework created by Amazon that helps define code infrastructure in your preferred language: Python, JavaScript, Java, or TypeScript. Infrastructure resources are provisioned by AWS CloudFormation.
How AWS CDK Works
Internally, AWS CDK uses CloudFormation, an infrastructure automation platform for AWS that helps to deploy and manage Infrastructure efficiently. It converts your code written in TypeScript, JavaScript, Java, or Python into a CloudFormation template.
The basic building blocks of AWS CDK apps are constructs, which can be found in the AWS constructs library. AWS CDK constructs are cloud components used to define the desired state of the infrastructure, and they can consist of single or multiple resources. When using AWS CDK, you implement a composition pattern for constructs, and then you use it to define your specified resources.
All constructs defined in an AWS CDK application are referred to as CDK stacks.
Comparing Terraform vs. AWS CDK for Infrastructure as Code
Each of these tools offers different features and benefits. The following is a comparison of the two.
Comparing the Performance of Terraform vs. AWS CDK
It's important to consider performance when selecting an IaC tool, because the time it takes for a tool to deploy resources is significant, especially for larger organizations.
Terraform deploys may execute faster than AWS CDK as Terraform calls the AWS APIs directly. AWS CDK must convert code into CloudFormation templates first, then apply these templates to deploy the resource.
Partitioning Environments in Terraform vs. AWS CDK
Partitioning is an important benefit of Terraform. Environments are separated, so you can easily identify the configuration in each one. This means you can apply the same configuration to your development environment, and it will not change or destroy the infrastructure in your staging or production environment.
Though Terraform allows configuration files to be the same in structure, the variables will be different between each environment. Partitioning Terraform folders is the preferable strategy because if you make changes in the configuration file in a development environment, the configuration files for the production environment are not affected.
In AWS CDK, configuration files have environment variables that specify the target environment. If you have three environments, you will have three arrays specifying each environment in your configuration, but you will only have one configuration file, which can make AWS CDK harder to work with than terraform.
Provider Compatibility in Terraform vs. AWS CDK
Terraform uses plug-ins, called providers, to interact with cloud services (AWS, Azure, Google Cloud Platform), on-premise infrastructure (OpenStack, VMware), platforms as a service (Heroku, Kubernetes, AWS Lambda), and software as a service (Datadog, CDNs like Fastly, GitHub teams).
Several providers enable Terraform to be compatible with different servers. <span class="code-exp2">The terraform init</span> command searches the registry for the providers specified in your configuration file, downloads them, and then installs them for use.
Unlike Terraform, AWS CDK uses templates to specify infrastructure resources and their properties. The <span class="code-exp2">aws-cdk init --list</span> command shows all the programming languages available for use in your application as well as all of the available templates.
Cross-Platform Compatibility of Terraform vs. AWS CDK
Terraform is a cloud-agnostic IaC tool, meaning you can use it with AWS, Azure, and Google Cloud Provider (GCP). This is one of the major benefits of using Terraform. You can easily deploy the infrastructure resources you have on AWS and then replicate the same resources to Azure or GCP using a single configuration file.
In comparison, AWS CDK allows you to deploy resources with cloud formation to AWS Cloud only. It does not deploy resources to other cloud platforms, which is more limiting than Terraform.
Collaboration Across Teams With Terraform vs. AWS CDK
As your infrastructure expands, the ability to collaborate among different teams becomes even more necessary in order to ensure proper version control.
Terraform connects to version control systems like GitHub, GitLab, and Azure DevOps to ensure consistency across all systems. Different teams or users can pull or push the latest code changes, make changes to the code, and apply these changes to deploy new infrastructure.
Before code changes are applied, and the new infrastructure is deployed, Terraform ensures that the changes are approved by another team member. This helps maintain a single source of truth for your infrastructure across the organization.
These features for collaboration are also available in AWS CDK. It can connect to version control systems, and CDK configuration code can be stored in a code repository like GitHub.
Declarative Approach vs. Imperative Approach
There are two general paradigms for software development, the declarative approach and the imperative approach. In the declarative approach, you say what you want, while in the imperative approach, you say how you want it.
For the declarative approach, the resources and properties of the infrastructure to be provisioned are specified, and the IaC tool determines how to achieve the desired end state. In the imperative approach, you specify a list of instructions to provision new resources.
For example, if you have five virtual machines (VMs) and you want to scale up to eight, a tool using the imperative approach will create eight VMs from scratch instead of adding three to the existing infrastructure. Using the declarative approach, the tool only needs to add three VMs to get to the desired state.
AWS CDK, which uses the imperative approach, allows engineers to provision infrastructure in Python, Java, TypeScript, or JavaScript. The DevOps engineer or site reliability engineer (SRE) needs to specify the list of instructions to provision the infrastructure resources using code.
Terraform uses the declarative approach, meaning you use your configuration file as code. You specify the resources you want in a configuration file, and Terraform provisions and configures the resources automatically.
As you can see, Terraform provides multiple ways for you to optimize your IaC practices. One of the many tools Terraform integrates well with is Propel.
IaC with Propel
Adopting the IaC approach helps organizations improve performance and more easily provision and maintain infrastructure. Propel understands the importance of embracing IaC to give organizations greater control of their cloud infrastructure. You can find the documentation for Propel’s terraform provider in the links below:
Propel's GraphQL API enables you to build fast and custom-looking customer-facing analytics that integrate seamlessly with your existing data stack. Propel aligns with the IaC approach in order to ensure better performance and easier maintenance.
Conclusion: What Is Infrastructure as Code?
Just as with other aspects of DevOps, IaC can revolutionize how an organization creates and deploys applications. IaC tools can help you more easily build, maintain, and scale your infrastructure by relying on configuration files, rather than the sometimes difficult and costly process of configuring physical infrastructure or deploying virtual infrastructure by hand.
With the greater flexibility, collaboration, and cost savings of IaC, you can focus more time and resources on releasing high-quality applications.
