Terragrunt Tutorial: Examples and Use Cases

What is Infrastructure-as-Code

Infrastructure-as-Code (IaC) is a method of automating the management and provisioning of infrastructure resources. Instead of manually clicking buttons on a web console, IaC enables organizations to describe their system architecture using code, allowing them to store, version, and track changes to their systems and application infrastructure. 

The goal is to automate the process of setting up, configuring, deploying, and managing applications. IaC is a powerful technology that allows you to provision and manage any cloud resource in an automated, declarative way. Infrastructure-as-Code is now the de facto standard for new projects and the focus of many organizations is now migrating from legacy architecture to IaC.

Before Infrastructure-as-Code: Pre-IaC Architecture

IaC’s major transformation was that developers could now create a consistent, repeatable workflow, bringing about wider-scale deployments across a range of resources, environments, and locations.

Delving a bit deeper, how did it achieve this? IaC provisions infrastructure and application resources through machine-readable definition files instead of through physical hardware configuration or interactive configuration tools. 

Before, infrastructure management was a costly, manual process that hindered scale and availability. There was extreme variability in infrastructure largely due to manual configuration. Manual processes were more error-prone and could not be scaled, much less standardized. Remote access tools slowly entered the market, but system administrators (sysadmins) still had to provision new hardware and resources manually by connecting to remote cloud providers via APIs.

Environment drift: When infrastructure for an application's software development process – development, staging, and production environments falls out of sync. Environment drift, or configuration drift, causes inefficiencies and can be expensive in direct cost and potential user experience impacts. If your app’s development environment varies from the production environment, this can lead to failure in production or bugs, and even prevent recovery in the event of disaster.

Automation changed that, reducing the problem of forgotten tasks, automating configuration drift detection, and allowing other features to automatically manage infrastructure problems or remedy issues. Among those revolutionary features were version control systems (VCS), configuration management tools, and orchestration capabilities.

Infrastructure-as-Code Benefits

Now, IaC has made IT more efficient than ever before, solving numerous IT challenges and enabling new capabilities such as:

Recreating environments

It used to be challenging to recreate an identical environment after deployment because the systems it interacted with also had to be updated.

With Infrastructure-as-Code, users can recreate infrastructure from scratch, and on-demand, simply by replaying code. The pipeline uses a prescribed set of parameters for deployment and creates a new environment that is identical in terms of the number of hosts, networks, data centers, clusters, data stores, etc., every time that it runs. The infrastructure code can even be versioned with the product, making it easy for engineers to recreate the infrastructure as it was when a previous version of the product was released.

Minimizing errors

IaC minimizes the need for manual infrastructure management, reducing the risk of human error. Rather than depending on engineers to remember past configurations or respond to failures, everything is in the code, under your source control system.

When changes go to production, the infrastructure code is checked in a code review or in a review by a gatekeeper.

Supporting teamwork and collaboration

Using IaC, engineers don’t have to deal with problems caused by conflicting changes in a shared environment. Infrastructure-as-Code makes it easier to work as a team and to share code with colleagues and other teams, so they can utilize it to set up their own environments. Using a VCS, different teams can each work on a separate piece of the infrastructure, rolling out their changes in a controlled manner.

Reducing cloud expenditure

The shift from bare metal infrastructure investments to the cloud reduced CapEx, and IaC has reduced them even further by enabling auto-scaling capabilities. With IaC, a software developer writes code and configuration management instructions that trigger actions according to actual needs and accurately reflects the structure of the real operating environment. Infrastructure-as-Code lets you manage your environments easily and automatically deactivates environments you no longer need.

DevOps and Infrastructure-as-Code

DevOps emphasizes automating manual tasks that typically take up a lot of software developers’ and IT operators’ time. IaC is one of the key technical practices that enable DevOps within an organization, by automating the provisioning and management of IT infrastructure. With IaC, developers can self-serve the provisioning of environments, saving time for them and the operations team.

How Infrastructure-as-Code Works

Key Concepts

1. GitOps – This involves integrations between your IaC tech stack and the infrastructure itself via your Git repository (on GitHub, GitLab, Bitbucket, etc.). This includes streamlining changes as much as possible, such as embedded PR commands.
2. Version Control – This is related to GitOps, where you will want to have a firm grasp on what versions of a framework, module, provider, or code you are using for your current work or for a specific kind of deployment.
3. State Management – This refers to the storage and maintenance of your desired state. Some IaC tools do not encrypt state files by default. For example, Terraform does not encrypt (it’s a premium feature in Terraform Cloud) while OpenTofu does. 
4. Registry – A registry is a marketplace for finding add-ons, integrations, packages, and policies. It often refers to the Terraform Registry. 
5. Templates – Templates refer to reusable packages of code or files that provision resources in certain configurations. They should be git-based.
6. Modules – This is the term for a configuration package, or collection of config files, in Terraform.
7. Providers – This is the term for an integration mechanism, akin to an API, between Terraform and a third-party app.
8. FinOps – This refers to the automation of cost monitoring, spending projections (cost estimation), and budget notifications/alerts so users can track the expense of their cloud deployments (in IaC and other sectors of DevOps).
9. IaC Pipelines – This is an ordered sequence of common or repetitive tasks that is configured to run automatically so as to save teams time with projects.
10. IaC Workflows – This refers to the sequence of status changes of infrastructure within a pipeline.

Declarative vs. Imperative Approach for Infrastructure Configuration

As with other subjects in DevOps, infrastructure has declarative and imperative approaches. Think of it like a means to an end; or rather, the imperative approach defines the means and the declarative approach defines the end. 

The imperative approach focuses on the sequence of commands needed to reach the desired state of your application, specifically in this case your infrastructure. In contrast, the declarative approach is becoming more popular thanks to better automation tools, as devs can define the endgame state and a given tool will configure an environment to reach that stated goal. 

Chef is the most prominent tool relying on imperative programming for IaC. Some have a mix of imperative and declarative implementations, namely Pulumi, Salt, and Ansible. However, declarative is gaining traction and effectiveness thanks to advances in automation. Declarative IaC tools include OpenTofu, Terraform, AWS CloudFormation, and Puppet.

Challenges and Best Practices 

Many best practices for IaC overlap with DevOps best practices in general. However, there are caveats specific to maintaining code-based infrastructure. 

Idempotency

Yeah, read that word carefully. This refers to being able to reapply code multiple times while getting a consistent result every time. This is as much a principle as it is a requirement to automate infrastructure, and templating will reduce or outright eliminate errors in many use cases. The goal of consistency also relates to testing, making sure that a deployment works in multiple environments and avoids the ‘it works on my machine’ problem.

CI/CD & Testing

Many teams have not instilled continuous integration and continuous deployment into their infrastructure deployments. CI/CD should be standardized in all layers of development and operations, including IaC. Constant changes to infra require testing and full VCS integration.

Observability – Logs & Debugging

Depending on the kind of deployment, you should have logging configured across your entire tech stack. Additionally, consider metrics and tracing to monitor every level of your infrastructure. Finally, debugging should be standard protocol with any code changes, especially if you’re changing code within a resource instead of switching out resources.

Immutability (when applicable)

Immutability refers to making code unchangeable. In such cases, changes mean replacing a resource entirely rather than editing its internal code. This is not always practical, but when it is, it eliminates an area prone to frustrating errors.

Version Control (including environmental parity)

As mentioned with CI/CD, VCS can protect you from influencing the wrong environment or pushing changes that aren’t applicable in some versions of your Infrastructure-as-Code framework. This is even more essential when dealing with multi-framework deployments, which get confusing.

Cost Management/FinOps

Cost management and cost projection/prediction are getting better with newer tooling available to all classes of developers, and the same with IaC FinOps for system architects. Tracking cloud spending gets tricky,  especially with the long list of internal features that cloud providers like AWS or Azure offer.

State Management

Storing the state of your IaC framework is fundamental. With many tools moving toward declarative programming, keeping that well-defined state protected is crucial.

Modularization

Relating to templates and paralleling containers, IaC frameworks like Terraform and OpenTofu rely on modules to organize resources defined by configuration files in the same directory. In the case of Terraform, they will be .tf or .tfjson files. There are three primary reasons behind using a Terraform module: 1) packaging resources together that will be used together in a reusable configuration, 2) sharing standardized configurations across organizations, and 3) don’t-repeat-yourself programming (DRY).

Access (Roles and Users)

This is part of the security concerns of an IaC setup. You want to manage and allow access to as many people in your organization as possible, but make sure that levels of access are well-defined in specific roles. This makes RBAC, role-based access control, as essential in IaC as any other sector of DevOps. 

Watch out for these IaC Pitfalls...

While IaC has clear advantages, it also presents unique challenges that usually emerge as you scale.

1. Integration with management tools

To harness the full benefits of IaC, it must be integrated into all processes, including CI/CD workflows, notification tools like Slack, security tools, system administration, IT operations teams, and DevOps teams, with well-documented policies and procedures. Without full integration, errors can quickly spread across the system.

2. Longer turnaround

When using IaC, every change has to be coded, tested, and reviewed before it is applied. Changes are more complex and must be planned carefully to avoid significant downtime. Learn more: Video: Top IaC Challenges

3. Lack of cloud expense oversight

Since IaC deploys infrastructure components automatically, it can be hard to keep track of expenses. Development teams are often unaware of the financial ramifications of their code, and expenses can build up quickly without monitoring tools that are designed for IaC.

That’s why some would explicitly include FinOps in the rubric of IaC. Regardless, it’s an essential part of managing complex infrastructure.  For instance, env zero includes cloud cost monitoring and optimization in its feature set.

IaC Toolchain Sprawl

One of the primary benefits of adopting Infrastructure-as-Code is consistency, which is only possible if teams across your organization are using different IaC tools and approaches. In many cases, implementing IaC requires a cultural shift in addition to the technical one to ensure success. The advantages far outweigh any overhead associated with implementing and managing IaC.

We’ll try to make some sense of that tool sprawl with the following section, covering the major frameworks and associated platforms in the world of infra.

Infrastructure-as-Code Frameworks

IaC’s major tools are frameworks that incorporate multiple functions into a single platform. The list below starts with those assets and then continues with IaC tools that are popular for one or multiple functions within IaC tech stacks. The following Venn diagram shows what kind of features go into a complete IaC framework, but note its complex structure that shows some tools can cover much of what you need for a deployment, but not everything.

Terraform & OpenTofu

Terraform is an IaC tool created and maintained by HashiCorp; it is currently the most widely used Infrastructure-as-Code tool in the industry. It is widely credited with creating common best practices including arguably the use of declarative programming.

In Summer 2023, Terraform moved away from Open Source licensing. As a response, several companies (including env0) collaborated to create an open-source, alternative known as OpenTofu. OpenTofu is currently managed by the Linux Foundation. Its initial release, v1.6.alpha, seeks to be a drop-in replacement for the Terraform version of the same number.

Terragrunt

Terragrunt is a thin wrapper for Terraform that provides additional tools for deploying hooks, managing dependencies, remote states and multiple environments, as well as keeping your Terraform configuration files DRY (Don't Repeat Yourself). Terragrunt is open-source and a popular choice for Terraform users looking for ways to keep their codebase efficient, clean and well-organized.

AWS CloudFormation

CloudFormation is the AWS service for IaC. It uses JSON or YAML to define resources. Its added advantage is that it works seamlessly with other AWS tools. On the flip side, its main disadvantage is that it only handles AWS infrastructure resources. Additionally, it limits templates to only 500 resources apiece, arbitrarily still keeps some processes manual, and has confusing documentation.

Pulumi

Pulumi is an open-source IaC framework that uses common programming languages to configure and provision resources rather than a domain-specific language like HCL. That also allows it to take advantage of inherent features of languages like Python, JavaScript, C#, and Go among others, as well as various implementations of those languages like TypeScript, Node.js, .NET, etc. 

Like Terraform and OpenTofu, Pulumi supports major cloud providers - AWS, Azure, and GCP cloud providers. It also features its own state management and language hosting, plus a command-line interface (CLI).

Crossplane

Crossplane is an open-source IaC framework managed by the Cloud Native Computing Foundation (CNCF) with a specific focus on managing Kubernetes infrastructure. It keeps application and infrastructure configuration in the same control plane (Kubernetes application layer), and uses other common k8s tools like Helm or Kustomize to launch IaC templates. 

Atlantis

Atlantis is a GitOps-focused tool that often acts as an add-on to basic IaC frameworks. It applies infrastructure automation with Terraform actions by use of commands embedded in pull requests (PRs) and to work from within their VCS. It still uses the webhooks native to Terraform to manage this, trying to get more done in Terraform by working through comments and PRs from GitHub, GitLab, and other version control systems.

CI/CD & Configuration Tools Used for IaC

Ansible

Ansible is an open-source CI/CD application that applies automation to pipelines but also functions as a configuration manager and orchestration tool. It is often compared with Jenkins, though the two tools can also function together in certain environments. In addition, Ansible integrates with Terraform. It is written in Python and works from the command line/terminal.

Argo CD

Argo CD is an open-source continuous delivery tool focused on Kubernetes that uses declarative programming. It monitors activity in Kubernetes clusters and compares infrastructure there to the version stored in a specified git repository. It will resolve any differences between the two versions to maintain the desired state. ArgoCD is commonly used in conjunction with IaC tools for managing and orchestrating applications alongside infrastructure.

Jenkins

Jenkins is mainly an open-source continuous integration tool. It automates testing, packaging, building, and deployment. It is more broadly considered a CI/CD tool, as it also handles continuous delivery. It supports several VCSs from the most popular to more niche options: GitHub, GitLab, Bitbucket, Git, Mercurial, Subversion, etc. Many developers use Jenkins to deploy infrastructure components, but it has limitations relative to fully IaC-dedicated frameworks. It can run multiple jobs through multi-threading.

CircleCI

CircleCI is, despite the limiting name, a full CI/CD tool for automating builds, testing, and deployments. Through its integration with a VCS, any change in a repository will trigger a CircleCI run job and run jobs simultaneously through parallelism/parallel processing (in contrast to Jenkins’ multi-threaded approach).

SaltStack

SaltStack, also known as the Salt Project or simply Salt, mainly serves as an orchestration and configuration tool. It has an emphasis on automating repeated DRY tasks. It uses the push method to make changes to code.

Chef

Chef is usually defined as a configuration management tool, which automates – writes, tests, and deploys – code. It can also be defined broadly as an infrastructure-as-code framework and automation platform. Its DSL is based on Ruby. To draw an analogy with Terraform’s modules, Chef’s “cookbooks” package together multiple “recipes,” e.g. config files that cover which resources to manage and in what order to execute them. As mentioned above, Chef relies mainly on imperative programming. Its client-side server architecture is known to support popular operating systems like Ubuntu and Windows.

Puppet

Puppet is a configuration management tool for automating code; it is often directly compared with Chef. It can also be defined broadly as an IaC framework with uses for orchestration, CI/CD, and monitoring. It mainly supports declarative programming. It supports different implementations of Linux in addition to other operating systems (MacOS, Windows, Ubuntu, Debian, etc.). It relies more on the pull method to make changes.

Infrastructure Management at Scale with env0

env zero is a self-service automation platform and management layer that sits above an IaC framework. It provides a simplified user interface for administering environment templates, controlling access roles, managing variables, defining policies, overseeing FinOps mech anisms, setting parameters for different developer environments (including ephemeral), and more.  

All in all, env0’s product reflects what the company sees as best practices for Infrastructure-as-Code, and therefore offers a suite of services:

Infrastructure Automation

env zero extends the creation of pipelines and workflows to Infrastructure-as-Code, using what are now established best practices in other segments of DevOps. env zero integrates with tools from different parts of the IaC tech stack – version control systems, configuration managers, orchestration tools, and CI/CD platforms – to create a consistent workflow with persistent changes pushed/pulled to your infrastructure.

Self-Service & Visibility

The emphasis on self-service leads to an emphasis on ‘granular RBAC’, where admins can add numerous specifications to custom roles in order to extend secure access across an entire organization as widely as possible. Utilizing Policy-as-Code and integrations with tools like OPA or Checkov, you can be confident that the right people have the right amount of access and let teams function independently to push/pull their changes to code.

With that, teams do not have to wait for someone else’s okay to be productive. Organization members can achieve that by using ephemeral environments (with time-to-live settings) to test new features, automated scheduling, and configurable templates.

Additional features like dashboarding and audit logs, plus available integrations with several major observability platforms, give admins even more data to adjust those policies in the long-term.

Covering All Frameworks

env zero is framework-agnostic. In other words, env zero covers Terraform, Pulumi, CloudFormation, Terragrunt, and others. While some companies (HashiCorp, AWS) provide a premium service on top of their IaC frameworks, they often encourage vendor lock-in and cover their own frameworks at the expense of others. 

Fair Pricing, FinOps Built-in

env zero encourages scale by using deployment-based pricing. However, other services such as Terraform Cloud price by RUM – or resources under management. RUM guarantees a higher bill for companies month to month, as teams are always adding more complex code and configuration changes. 

Deployment pricing provides flexibility to team managers to customize their environments in such a way to be smart with their cloud spending. env zero encourages this further with its slew of FinOps features like cost management, budget notifications, and project-based calculations. Those analyses inform future policies to limit or increase budgets for users, teams, specific resources, or particular deployments.

In the fast-moving world of Infrastructure as Code, staying ahead of the curve means more than just knowing how to write a resource block. As we enter 2026, the ecosystem of terraform tools has evolved into a sophisticated landscape of specialized utilities designed to solve the growing pains of enterprise-scale automation. Whether you are managing complex state or integrating AI-native security into your CI/CD pipelines, the modern infrastructure stack is now a powerhouse of efficiency and resilience.

Today, we’ll explore the most essential terraform tools for 2026: solutions that have become mandatory for engineers who need to go beyond basic provisioning. We will dive into the top utilities for:

• Infrastructure Testing: Moving from "trial and error" to robust, automated validation.
• Linting & Security: Enforcing best practices and identifying vulnerabilities before deployment.
• DRY Principles: Leveraging advanced wrappers to keep your code clean and modular.

From established industry standards to emerging AI-driven scanners, these are the terraform tools you need to master to build a future-proof cloud strategy this year.
‍

Terraform Code Editing and Enhancement Tools‍

1.) VSCode Extensions

Two of the most favored extensions for Terraform include the official HashiCorp Terraform extension for Visual Studio Code and the Terraform extension by Anton Kulikov.

These extensions transform VS Code into a powerful IDE for Terraform, providing features like syntax highlighting, auto-completion of code, and integrated debugging, which streamline the development process and increase efficiency.

2.) TFlint

‍TFLint is a Terraform linter focused on possible errors, best practices, and style conventions in your Terraform code.

‍When to use TFLint:

You can run TFlint before the [.code]terraform plan[.code] command to detect issues early.

‍Major reasons why you should use TFLlint:

• Error detection: Detect errors before running [.code]terraform plan[.code] or [.code]apply[.code]
• Best practices: Checks your code against a set of Terraform best practices
• Custom rules support: Write your own custom rules, adhering to organization policies

For example, say you define an AWS EC2 instance in your Terraform configuration and mistakenly refer to an AMI that doesn't exist.

TFLint can flag the AMI ID issue before you execute the [.code]terraform plan[.code] or [.code]terraform apply[.code]:

$ tflint main.tf
1 issue(s) found:
Error: "ami-12345678" is an invalid AMI ID. (aws_instance_invalid_ami)
on main.tf line 2:
   2:   ami           = "ami-12345678"

‍

Terraform Scanning, Security and Compliance

3.) Open Policy Agent (OPA)

A popular Policy-as-Code tool for Terraform is OPA, everyone's favorite versatile open-source policy engine that enforces security and compliance policies across your cloud-native stack, making it easier to manage and maintain consistent policy enforcement in complex, multi-service environments.

‍When to use OPA:

OPA policies are usually run after running [.code]terraform plan[.code] to validate the policy rules.

Major reasons why you should use OPA:

• Enforce compliance: Ensures adherence to organizational, industry, or legal standards in Terraform configurations
• Shift-left security: Identify security vulnerabilities early in development
• Automate governance: Embed policy checks within CI/CD pipelines to minimize manual governance efforts

Here is an example OPA policy that checks whether an S3 bucket has public access enabled:

 package aws.s3
default allow = false
allow {
    not bucket_is_public
}
bucket_is_public {
    input.bucket_acl == "public-read"
}
bucket_is_public {
    input.bucket_policy.allows_public_read
}

For more information, check out this guide for Terraform and OPA or this tutorial for using env zero and OPA for granular policy management. 

4.) Terrascan

‍Terrascan is a static code analysis tool that scans your Infrastructure-as-Code (IaC) for security vulnerabilities and compliance violations. It supports multiple platforms like (AWS, Azure, GCP, K8s, Atlantis, etc), including Terraform. Terrascan allows you to enforce security best practices, compliance policies, and governance across your IaC deployments.

‍When to use Terrascan:

Terrascan can usually be run locally or in CI/CD before terraform plan to identify security issues.

Here is an example of running Terrascan against an AWS security group defined in Terraform:

 $ terrascan scan -t aws -i terraform
Violation Details -
   Description:  Ensure no security groups allow ingress from 0.0.0.0/0 to ALL ports and protocols
   File:  main.tf
   Module Name: root
   Plan Root:  .\
   Line: 9
   Severity: HIGH
…

Check out this in-depth Terrascan guide for more information.

5.) Checkov

‍Checkov is another great tool that examines your Terraform files (.tf), parsing the configurations and evaluating them against a comprehensive set of predefined policies. It scans Terraform-managed infrastructure and detects misconfigurations that could lead to security issues or non-compliance with best practices and regulations.

‍When to use Checkov:

You can run Checkov locally or in CI/CD before running terraform plan to detect potential security issues.

Below is an example of how Checkov detects security violations for an AWS security group, allowing traffic to all ports defined in the Terraform (.tf) file:

 $ checkov -f main.tf
Check: CKV_AWS_277: "Ensure no security groups allow ingress from 0.0.0.0:0 to port -1"
        FAILED for resource: aws_security_group.allow_all
        File: \main.tf:9-19
        Guide: https://docs.prismacloud.io/en/enterprise-edition/policy-reference/aws-policies/aws-networking-policies/ensure-aws-security-group-does-not-allow-all-traffic-on-all-ports

Read this guide for Checkov examples, use cases, and best practices.

6.) Tfsec

‍Tfsec acts as a Terraform scanning tool. It is a security-focused linter for Terraform that scans code for security flaws, offering an additional layer of security assurance and helping to maintain a strong security posture.

Tfsec allows you to create policies in multiple formats like JSON, YAML, and Rego Policies.

‍When to use Tfsec:

Tfsec can either be run locally or in automated CI/CD environments before terraform plan.

Taking the same example of the AWS S3 bucket with encryption disabled, let's observe how Tfsec detects the vulnerability:

 Result #3 HIGH Bucket does not have encryption enabled
  .../main.tf:20-32
   20  ┌ resource "aws_s3_bucket" "tfsec" {
   21  │   bucket = "tfsec-bucket"
   22  │   acl    = "private"
   ….
     ID aws-s3-enable-bucket-encryption
    Impact The bucket objects could be read if compromised
   Resolution Configure bucket encryption

Learn more in this Tfsec guide.

‍

Terraform Testing and Verification

‍7.) Terratest‍

Terratest is a Go library that provides tools and patterns for testing infrastructure, with first-class support for Terraform, Packer, Docker, Kubernetes, and more. It's used to write automated tests for your infrastructure code.

There are 4 steps to test Terraform IaC using Terratest.

‍When to use Terratest:

Run Terratest after running [.code]terraform apply[.code] in your CI/CD or locally to validate your infrastructure's behavior and ensure that your Terraform code functions as expected.

‍Why use Terratest:

• Automated testing: Embed automated tests in CI/CD pipelines for early issue detection
• Programmatic testing: Use Go for detailed, code-based Terraform resource testing
• Comprehensive test coverage: Offers broad-ranging validation from unit to end-to-end infrastructure tests

Here is a sample test that checks if an AWS EC2 is accessible over SSH:

 package test
import (
    "testing"
    "time"
    "github.com/gruntwork-io/terratest/modules/aws"
    "github.com/gruntwork-io/terratest/modules/terraform"
    "github.com/gruntwork-io/terratest/modules/test-structure"
)
func TestEC2Instance(t *testing.T) {
    t.Parallel()
    // Define the folder where the Terraform code is located
    terraformDirectory := "../examples/aws/ec2"
    // At the end of the test, run `terraform destroy` to clean up any resources that were created
    defer test_structure.RunTestStage(t, "cleanup", func() {
        terraform.Destroy(t, terraformOptions)
    })
    // Deploy the infrastructure with Terraform
    terraformOptions := terraform.WithDefaultRetryableErrors(t, &terraform.Options{
        TerraformDir: terraformDirectory,
    })
    test_structure.RunTestStage(t, "deploy", func() {
        terraform.InitAndApply(t, terraformOptions)
    })
    // Get the public IP of the created EC2 instance
    publicIp := terraform.Output(t, terraformOptions, "public_ip")
    // Test if the EC2 instance is accessible over SSH
    test_structure.RunTestStage(t, "validate", func() {
        aws.CanSshToEc2Instance(t, publicIp, "ec2-user", nil)
    })
}

For more, check out this Terratest vs Terraform/OpenTofu Test comparison.

8.) Terragrunt

‍Terragrunt is a thin wrapper that provides extra tools for keeping your Terraform configurations DRY (Don't Repeat Yourself), working with multiple Terraform modules, and managing remote state. It's particularly useful in managing large-scale infrastructure deployments with Terraform.

These are some reasons why to use Terragrunt:

• DRY Terraform configurations: Reduce code redundancy in your Terraform projects
• Manage remote state easily: Centralize and streamline remote state management for modules
• Handle dependencies gracefully: Seamlessly orchestrate module dependencies for orderly operations

For more, check out this in-depth Terragrunt tutorial.

Terraform Infrastructure Cost Management and Optimization

9.) Infracost

‍Infracost is a cost estimation tool that generates cost estimates for Terraform projects, which is crucial for budget planning and cost optimization, especially in cloud environments where resource costs can vary significantly.

‍When to use Infracost:

Infracost is usually run after you provision your resources through Terraform to detect the cost of resources.

Here is the output generated by Infracost detailing the cost of provisioning an AWS EC2 instance, an RDS instance, and an S3 bucket:

For more about InfraCost, check out this episode of The IaC Podcast featuring co-founder and CEO Hassan Khajeh-Hosseini:

‍

Terraform Drift Detection, Synchronization and Management

10.) Driftctl

‍Driftctl is an open source Terraform drift detection tool that tracks and warns about infrastructure drift. Driftctl scans your infrastructure, compares it with your IaC configurations (like Terraform), and reports discrepancies.

‍When to use Driftctl:

It's useful to run Driftctl before [.code]terraform apply[.code] to understand if there are any drifts in your environment.

This output clearly shows that the ‘driftctl-app-bucket’ has drifted. The ACL has changed from private (as defined in Terraform) to public-read (current state in AWS).

 $driftctl scan
Scanned resources:    (1)
Found unmanaged resources:
  aws_s3_bucket:
    - driftctl-app-bucket
Found drifted resources:
  - aws_s3_bucket.driftctl_bucket:
      ~ acl: "private" => "public-read"

11.) Terraformer

‍Terraformer is a CLI tool developed by Google that generates Terraform files from existing infrastructure (reverse Terraform), simplifying the process of adopting Terraform in existing environments and speeding up the initial setup process. Terraformer supports multiple cloud providers, including AWS, Google Cloud, Azure, and others.

‍When to use Terraformer:

Generally, Terraformer is used in a local environment because it's an initial step to bring unmanaged resources under Terraform management.

‍Why use Terraformer:

• Save time and effort: Streamline IaC adoption by automating Terraform configurations
• Ensure visibility: Enhance infrastructure visibility by incorporating unmanaged resources into Terraform

For example, you can use Terraformer to import your S3 buckets into Terraform configuration:

 terraformer import aws --resources=s3 --regions=us-east-1

Terraformer will scan your AWS account for S3 buckets in the [.code]us-east-1[.code] region and generate corresponding .tf files and a terraform.tfstate file.

‍12.) Pike

‍Pike is a tool that analyzes Terraform managed resources and automatically generates the necessary IAM permissions, improving security by ensuring that only the minimum necessary permissions are granted.

‍When to use Pike:

You can run Pike before running the [.code]terraform plan[.code] locally, in order to generate the least privilege permissions for your infrastructure.

‍Why use Pike:

• Security: Enhances security by enforcing the least privilege principle in IAM roles
• Efficiency: Streamlines permission management by automating IAM policy creation

You can use Pike to scan a directory containing Terraform files, and it generates the necessary IAM policies.

 $pike scan -d /terraform-infra/
{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Allow",
        "Action": [
            "ec2:MonitorInstances",
            "ec2:UnmonitorInstances",
            "ec2:DescribeInstances",
            "ec2:DescribeTags",
     ...

13.) Terratag (by env zero)

‍Terratag is a tool designed to assign tags or labels to a complete collection of Terraform or Terragrunt files. It enables applying tags or labels to resources within AWS, GCP, and Azure.

‍When to use Terratag:

Use Terratag when maintaining your tags becomes challenging through manual work, and you believe in automating this process.

‍Why use Terratag:

• Scalability: Streamlining tagging across applications at scale.
• Accuracy: Minimizing human error in tag addition.
• Retrospective Tagging: Enabling retrospective tagging of previously deployed IaC resources.
• Management and Reporting: Supporting cost management, organization, and reporting through tagging.

Check out this post to learn more about Terratag.

‍

Terraform Visualization and Understanding

14.) Blast Radius

‍Blast Radius is a tool designed to provide interactive visualizations of Terraform dependency graphs. It's particularly useful for understanding and communicating the architecture and potential impact of changes in Terraform-managed infrastructure.

‍When should you use Blast Radius:

Run Blast Radius locally when planning or reviewing changes (after running [.code]terraform plan[.code]) to understand the potential impact before applying the changes with Terraform.

‍Why should you use Blast Radius:

• Understanding complex dependencies: Visualizes Terraform resource connections for clearer representation
• Risk assessment: Evaluates potential impacts of changes across your infrastructure
• Optimization: Uses visual insights to pinpoint and address inefficiencies in Terraform configurations

Below is a typical graph of Terraform configuration, enough to launch a single EC2 instance (running a web server) and elastic load balancer.

‍

‍

15.) Terraform Visual

‍Terraform Visual is a tool that generates a visual representation of your terraform plan, making it easier to understand the structure and changes of your Terraform-managed infrastructure.

‍When to use Terraform Visual:

Use Terraform Visual when reviewing your [.code]terraform plan[.code], especially when complex changes in the Terraform codebase are involved.

You can follow the steps on how to use Terraform Visual.

Here is a sample graph of the Terraform visual that depicts AWS EC2, security groups, and an S3 bucket.

‍

16.) InfraMap

Like Blast Radius, InfraMap generates visual graphs of your infrastructure based on Terraform state or configurations, offering a visual overview of your infrastructure, which is especially helpful for large and complex environments.

‍When to use InfraMap:

Use InfraMap when planning new infrastructure or when reviewing changes to understand the architecture and how resources interrelate.

Learn more about InfraMap here.

‍

Documentation and Terraform Workflow Management

‍17.) Terraform-docs

‍Terraform-docs is a tool that automatically generates documentation from Terraform modules in various output formats, including markdown, JSON, and others. It's particularly useful for maintaining up-to-date documentation of your Terraform modules' inputs, outputs, providers, and resources.

‍When to use Terraform-docs:

Run Terraform-docs locally whenever you update your Terraform modules to keep the documentation in sync with your code.

‍Why use Terraform-docs:

• Automated documentation: Automates the process of generating documentation
• Improved understanding: Clear documentation of modules enhances team collaboration
• Efficiency: Streamlines processes and minimizes errors in large projects with multiple modules

18.) TFSwitch

‍TFSwitch is a CLI tool that allows easy switching between different Terraform versions, simplifying workflows in environments where multiple Terraform versions are used.

‍When to use TFSwitch:

Use TFSwitch locally when you're working across multiple Terraform projects that require different Terraform versions. 

‍Why use TFSwitch:

• Ease of use: Effortlessly switch between Terraform versions
• Project-specific versioning: Define Terraform versions per project to maintain consistency

You can run the [.code]tfswitch[.code] command to display all the versions like so:

 $ tfswitch
Use the arrow keys to navigate: ↓ ↑ → ← 
? Select Terraform version: 
  ▸ 1.1.7 *recent
    1.1.6
    1.1.5
    1.1.4
    1.1.3
    …

19.) Terramate

‍Terramate is an open-source IaC orchestration tool for Terraform, OpenTofu, Pulumi, Cloudformation, and others, that streamlines and scales your IaC workflows.

‍When to use Terramate:

Use Terramate when managing similar infrastructure across multiple environments (dev, staging, production) to ensure consistency and reduce duplication. 

Check out Terramate documentation for more information.

20.) Atlantis

Atlantis automates reviewing and deploying Terraform via pull requests, streamlining collaboration and ensuring consistency across Terraform deployments.

‍When to use Atlantis:

Whether it’s a local or a CI/CD environment, Atlantis handles the Terraform part, ensuring that plan and apply are executed in response to VCS events.

‍Why use Atlantis:

• Automated workflows: Streamlines Terraform processes by auto-running terraform [.code]plan[.code] and [.code]apply[.code], with results ready for review
• Collaboration and review: Enhances team collaboration by integrating code changes review into the pull request workflow
• Security and control: Provides a detailed audit trail of who did what and when

Read this Atlantis guide for more information.

‍21.) Terraform Cloud (IBM HCP Terraform)

‍Terraform Cloud (a.k.a. TFC or IBM HCP Terraform) is a HashiCorp-managed service that provides collaboration features, governance, and automated workflow management, making it ideal for teams looking for a scalable, cloud-based Terraform solution.

‍When to use Terraform Cloud:

Terraform Cloud is useful for enabling teams to collaborate on infrastructure and ensure that everyone works off a consistent set of configurations and that changes are reviewed and applied in a controlled manner.

‍Why use Terraform Cloud:

• Collaboration and governance: Offers a collaborative platform with access controls, private modules, and shared configurations
• State management: Securely handles Terraform states, offering version history, locking, and drift detection
• Secrets management: Securely stores and manages sensitive data
• Cost estimation: Provides cost estimations for your infrastructure

For more information you can also check out our analysis of Terraform Cloud pricing or guide to Terraform Cloud alternatives.

22.) env zero

env zero is an advanced IaC management platform designed for seamless collaboration and automation in complex deployments at scale.

‍When to use env zero:

On top of the Terraform Cloud features mentioned above, env zero also provides dynamic cost and access controls, enhanced security features, collaborative tools, and support for multiple frameworks such as OpenTofu, Pulumi, and AWS CF.

Moreover, env zero utilizes a deployment-based pricing structure, making it more suitable for many large-scale operations, compared to TFC’s Resources Under Management (RUM) pricing.

Visit here to see what makes env zero a better Terraform Cloud alternative.

‍Why use env zero:

• IaC-centric pipelines: Seamlessly integrate various tools into env zero using your preferred tooling in custom flows
• Unlimited concurrency: Enables executing unlimited simultaneous runs without extra costs for concurrent executions
• IaC FinOps: Provides cost monitoring dashboard, and the ability to set granular budget thresholds, alerts, and policies
• Flexible workflows: Offers adaptability with PR planning, continuous deployment, and custom policies for team-specific needs
• Managed self-service: Streamlines operations with managed self-service and Policy-as-Code, simplifying infrastructure deployment
• Continuous IaC visibility: Ensures ongoing insight into your infrastructure, featuring automated drift detection

‍

Frequently Asked Questions/FAQs

For additional context, here is a list of questions that will help you understand the need and use cases for the tools I’ve described above. 

‍Q. What is the difference between Terraform lint and validate?

terraform validate checks whether Terraform configurations are syntactically valid and consistent. Meanwhile, linting tools like TFLint extend validation by enforcing best practices and conventions in writing an IaC. 

‍Q. How do you integrate OPA with Terraform?

On a high level, once you’ve installed OPA on your local machine, you write the OPA policy in Rego and generate a JSON output of your terraform plan. After that, you run the OPA policy against that terraform plan JSON to validate the policy rules you defined. You can check the step-by-step tutorial here.

‍Q. What is the difference between Checkov and Tfsec?

There are a few key differences between the two. The first one is Checkov, which supports a wide range of integrations like Terraform, AWS Cloudformation, Helm Charts, and others, while Tfsec just supports Terraform. To find an in-depth comparison between these two, check out this blog.

Q. Can you run Terragrunt with Terraform Cloud?

Terragrunt indirectly runs Terraform commands, while Terraform Cloud executes them directly, disallowing Terragrunt usage within Terraform Cloud. However, you can use Terragrunt via CLI to trigger Terraform runs on TFC using a remote backend, where runs and state are managed in TFC, but Terragrunt can't be run from the TFC UI.

Q. Can Terraform detect drifts by itself?

Terraform itself does not inherently detect drifts; it primarily manages infrastructure as defined in the IaC. For more robust and automated drift detection, third-party tools like env zero, TFC, Terrateam, Driftctl (and others) are designed to track and manage drifts in Terraform-managed resources specifically.

‍

What is Terragrunt?

Terragrunt is a thin wrapper for Terraform that provides extra tools for keeping your Terraform configurations DRY (Don't Repeat Yourself). With Terragrunt, you can easily manage remote states and multiple environments. It also helps you keep your codebase clean and organized.

Why use Terragrunt?

There are several reasons to use Terragrunt over just using pure Terraform code. Below is a list of these and we will elaborate more under the Terragrunt Features section.

1. DRY code and configurations
2. Versioning and environment management
3. Dependency management
4. Hooks for custom actions
5. Keep your remote state configuration DRY
6. Keep your CLI flags DRY
7. Execute Terraform commands on multiple modules at once
8. Work with multiple AWS accounts

Getting Started with Terragrunt

Video Walk-through

‍Requirements: A GitHub account (all the hands-on sections will utilize GitHub’s Codespaces so you won’t need to install anything on your machine)

TL;DR: You can find the repo here.‍

Installing Terragrunt

To install Terragrunt, download the binary for your operating system from the Releases Page and add it to your PATH. Alternatively, you could use a package manager as shown here. If you're following along with us with codespaces, you will have all the binaries already installed for you.

Basic Terragrunt Commands

Instead of running Terraform commands directly, you run the same commands with Terragrunt:

• terragrunt init -> equivalent to terraform init
• terragrunt plan -> equivalent to terraform plan
• terragrunt apply -> equivalent to terraform apply
• terragrunt output -> equivalent to terraform output
• terragrunt destroy -> equivalent to terraform destroy

These commands will call the corresponding Terraform commands, with Terragrunt performing additional logic before and after the Terraform calls.

Using Terragrunt for Infrastructure Management

Terragrunt can be used to manage your infrastructure configurations, plans, and Terraform backend. You can define your Terragrunt configuration in a terragrunt.hcl file, which allows you to reference specific versions of your Terraform modules and fill in variables specific to each environment. We will see an example later.

Terragrunt Features

Let's now elaborate more on the key features that Terragrunt offers:

1. DRY code:
   Terragrunt helps you avoid duplicating code by allowing you to define common input variables and environment-specific variables.
2. Infrastructure management:
   Terragrunt simplifies the management of multiple environments by providing a clear separation between them.
3. Versioning:
   Terragrunt allows you to reference specific versions of your Terraform modules for each environment, making it easier to manage and roll back changes.
4. Hooks:
   Terragrunt supports hooks that can be used to perform actions before or after Terraform commands.
5. Keep your remote state configuration DRY:
   ‍Terragrunt allows you to define your backend block once in a root terragrunt.hcl file and inherit it in all your Terraform environments. Terragrunt can also automatically create the remote state and locking resources (such as S3 buckets and DynamoDB tables) for you.
6. Keep your CLI flags DRY:
   You can configure Terragrunt to pass specific CLI arguments for specific commands using an
   ‍ block in your terragrunt.hcl file.
7. Execute Terraform commands on multiple modules at once:
   Instead of manually running [.code]terraform apply[.code] in each of the subfolders corresponding to different environments and waiting for them to complete, you can use Terragrunt with the [.code]run-all[.code] command to deploy multiple Terraform modules at once.
8. Work with multiple AWS accounts:
   Terragrunt allows you to work with multiple AWS accounts by letting you specify the IAM role to assume for each account. You can use the [.code]--terragrunt-iam-role[.code] command line argument or the TERRAGRUNT_IAM_ROLE environment variable to tell Terragrunt which role to use. Terragrunt will then call the sts assume-role API on your behalf and expose the credentials it gets back as environment variables when running Terraform. This way, you can manage your infrastructure in different accounts without having to store your AWS credentials in plaintext on your hard drive, without having to manually call assume-role every time, and without having to modify your Terraform code or backend configuration

Terragrunt Workflow and Best Practices

To make the most of Terragrunt, follow these best practices:

• Structuring Configurations: Organize your Terraform code into modules and use Terragrunt to reference these modules with specific versions.
• Managing Dependencies: Use Terragrunt to manage dependencies between your infrastructure components.
• Using Terragrunt Hooks: Utilize hooks to perform actions before or after Terraform commands.
• Automation with CI/CD: Integrate Terragrunt with your CI/CD pipeline for automated infrastructure deployment.

Terragrunt Benefits and Drawbacks

While Terragrunt offers many benefits, it also has some drawbacks, such as:

• It adds an additional layer of complexity to your infrastructure management and may require more initial setup.
• It is also another tool to manage
• Doesn't work with Terraform Cloud

However, if you are using env0, you can make full use of Terragrunt's benefits because env zero is one of the few tools that support Terragrunt.

Yevgeniy Brikman, who is the co-founder of Gruntworks (the company that brought us Terragrunt), makes a great comparison between using Terraform workspaces, Git branches, and Terragrunt. He summed up his comparison with the table below:

Terragrunt Use Cases and Examples

Terragrunt can be used in various scenarios, such as managing infrastructure for different environments like development, staging, and production. In our example, we will see how to use Terragrunt to DRY out our Terraform configuration. We will first run everything with pure Terraform only then we will see how to improve our configuration using Terragrunt.

Furthermore, to keep things simple, we will only consider two environments: dev and prod.

Our WordPress Module

We will use an example WordPress application to showcase the difference between using pure Terraform only and using Terragrunt. This example was taken from this repo, but modified slightly to fit our needs. The WordPress Terraform module creates the following resources:

• A VPC
• 1 Public Subnet for the EC2 instance
• 2 Private Subnets for the RDS
• An Internet Gateway
• A route table
• Security groups for EC2 and RDS
• EC2 instance for the WordPress application
• RDS instance for the MySQL database for WordPress

You can check the Terraform code in our repo.

Terraform Only Scenario

Below is the folder structure when using Terraform only.

├── environments
│   ├── dev
│   │   ├── main.tf
│   │   └── outputs.tf
│   └── prod
│       ├── main.tf
│       └── outputs.tf
└── modules
    └── wordpress
        ├── aws_ami.tf
        ├── main_script.tf
        ├── outputs.tf
        ├── user_data.tpl
        ├── userdata_ubuntu.tpl
        ├── variables.tf
        └── versions.tf

Under each environment folder, you can see that we're duplicating code in both the main.tf and the outputs.tf files. Even though we are using a terraform module structure, we still duplicate the code unnecessarily. Recall that using terraform modules is a great way for code reuse.

Below is the content of the main.tf file for the dev environment.

 terraform {
  backend "s3" {
    bucket         = "tekanaid-terragrunt-demo"
    key            = "wordpress/dev/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "my-lock-table"
  }
}

module aws_wordpress {
    source              = "../../modules/wordpress"
    database_name           = "wordpress_db"   // database name
    database_user           = "wordpress_user" //database username
    database_password = "dev-PassWord4-user" //password for user database
    region                  = "us-east-1" 
    IsUbuntu                = true             
    AZ1          = "us-east-1a" // for EC2
    AZ2          = "us-east-1b" //for RDS 
    AZ3          = "us-east-1c" //for RDS
    VPC_cidr     = "10.0.0.0/16"     // VPC CIDR
    subnet1_cidr = "10.0.1.0/24"     // Public Subnet for EC2
    subnet2_cidr = "10.0.2.0/24"     //Private Subnet for RDS
    subnet3_cidr = "10.0.3.0/24"     //Private subnet for RDS
    PUBLIC_KEY_PATH  = "./mykey-pair.pub" 
    PRIV_KEY_PATH    = "./mykey-pair"
    instance_type    = "t2.micro"    //type of instance
    instance_class   = "db.t2.micro" //type of RDS Instance
    root_volume_size = 22
}

Below is the content of the main.tf file for the prod environment.

terraform {
  backend "s3" {
    bucket         = "tekanaid-terragrunt-demo"
    key            = "wordpress/prod/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "my-lock-table"
  }
}

module aws_wordpress {
    source              = "../../modules/wordpress"
    database_name           = "wordpress_db"   // database name
    database_user           = "wordpress_user" //database username
    database_password = "prod-PassWord4-user" //password for user database
    region                  = "us-east-2" 
    IsUbuntu                = true             
    AZ1          = "us-east-2a" // for EC2
    AZ2          = "us-east-2b" //for RDS 
    AZ3          = "us-east-2c" //for RDS
    VPC_cidr     = "10.10.0.0/16"     // VPC CIDR
    subnet1_cidr = "10.10.1.0/24"     // Public Subnet for EC2
    subnet2_cidr = "10.10.2.0/24"     //Private Subnet for RDS
    subnet3_cidr = "10.10.3.0/24"     //Private subnet for RDS
    PUBLIC_KEY_PATH  = "./mykey-pair.pub"
    PRIV_KEY_PATH    = "./mykey-pair"
    instance_type    = "t2.small"    //type of instance
    instance_class   = "db.t2.small" //type of RDS Instance
    root_volume_size = 22
}

There are two main factors to notice between the two main.tf files:

1. The backend configuration is different and it is quite error-prone to copy and paste the key in this configuration. You may accidentally use the prod state file in dev and vice versa. You may also override an existing state file. Variables are not allowed to be used in the backend configuration block.
2. Some of the input variables to the aws_wordpress module are duplicated. In this example, it might not be a big deal, however, when you have multiple terraform modules you will start to see the difference.

Now let's take a look at the output variables in the outputs.tf file for the dev environment:

 output "IP" {
  value = module.aws_wordpress.IP
}

output "RDS-Endpoint" {
  value = module.aws_wordpress.RDS-Endpoint
}

output "INFO" {
  value = module.aws_wordpress.INFO
}

Notice that they are exactly the same. So again this is violating the DRY principle and it becomes worse when you have many other environments and applications.

Deploy with Terraform only

Follow the instructions below to deploy the WordPress application using pure Terraform code only.

In the Terraform_Only/environments/dev folder create a private/public key pair with an empty passphrase:

ssh-keygen -f mykey-pair
sudo chmod 400 mykey-pair

In order to create a remote backend to store Terraform state files, you will need to create an S3 bucket and a Dynamo DB table in AWS. This is a good guide.

Run these Terraform commands:

terraform init
terraform plan
terraform apply

To deploy the production Wordpress application, run the same steps above but in the Terraform_Only/environments/prod folder.

Here is the output of the [.code]terraform apply[.code] command:

And going to the 'http://54.167.129.51' address shows you the WordPress setup screen:

Terragrunt Scenario

Now let's take a look at how Terragrunt can improve our Terraform code structure.

Below is the folder and file structure in our local file system, when using Terragrunt. Notice that we have a root terragrunt.hcl configuration file and a terragrunt.hcl configuration file per environment folder.

├── environments
│   ├── dev
│   │   └── terragrunt.hcl
│   ├── prod
│   │   └── terragrunt.hcl
│   └── terragrunt.hcl
└── modules
    └── wordpress
        ├── aws_ami.tf
        ├── main_script.tf
        ├── outputs.tf
        ├── user_data.tpl
        ├── userdata_ubuntu.tpl
        ├── variables.tf
        └── versions.tf

The Root Terragrunt Configuration File

Now let's take a look at the main or root Terragrunt configuration file called terragrunt.hcl just under the environments folder.

remote_state {
  backend = "s3"
  config = {
    bucket         = "tekanaid-terragrunt-demo"
    key            = "terragrunt/wordpress/${path_relative_to_include()}/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "my-lock-table"
  }
}

inputs = {
  ami_id        = "ami-0c55b159cbfafe1f0" # Amazon Linux 2 AMI
  database_name = "wordpress_db"          // database name
  database_user = "wordpress_user"        //database username
  IsUbuntu          = true 
  PUBLIC_KEY_PATH  = "./mykey-pair.pub" 
  PRIV_KEY_PATH    = "./mykey-pair"
  root_volume_size = 22
}

Notice how the [.code]key[.code] in the remote_state block is parameterized. Each environment folder will have its own key without us worrying about copying and pasting. So the dev environment's key will be:

terragrunt/wordpress/dev/terraform.tfstate 

‍Whereas the prod environment's key will be:

terragrunt/wordpress/prod/terraform.tfstate 

The second thing to notice is that we define the input variables that are common to all our environments here. Once again this shows how we are following the DRY principle.

Now let's take a look at the dev Terragrunt configuration files under both the environments/dev and the environments/prod folders.

Below is the terragrunt.hcl file under the environments/dev folder.

include {
  path = find_in_parent_folders()
}

terraform {
  source = "../../modules//wordpress"
}

inputs = {
  database_password = "dev-PassWord4-user" //password for user database
  region            = "us-east-1"
  AZ1              = "us-east-1a"       // for EC2
  AZ2              = "us-east-1b"       //for RDS 
  AZ3              = "us-east-1c"       //for RDS
  VPC_cidr         = "10.0.0.0/16"      // VPC CIDR
  subnet1_cidr     = "10.0.1.0/24"      // Public Subnet for EC2
  subnet2_cidr     = "10.0.2.0/24"      //Private Subnet for RDS
  subnet3_cidr     = "10.0.3.0/24"      //Private subnet for RDS
  instance_type    = "t2.micro"    //type of instance
  instance_class   = "db.t2.micro" //type of RDS Instance
}

and below is the terragrunt.hcl under the environments/prod folder.

include {
  path = find_in_parent_folders()
}

terraform {
  source = "../../modules//wordpress"
}

inputs = {
  database_password = "prod-PassWord4-user" //password for user database
  region            = "us-east-2"
  AZ1             = "us-east-2a"       // for EC2
  AZ2             = "us-east-2b"       //for RDS 
  AZ3             = "us-east-2c"       //for RDS
  VPC_cidr        = "10.10.0.0/16"     // VPC CIDR
  subnet1_cidr    = "10.10.1.0/24"     // Public Subnet for EC2
  subnet2_cidr    = "10.10.2.0/24"     //Private Subnet for RDS
  subnet3_cidr    = "10.10.3.0/24"     //Private subnet for RDS
  instance_type   = "t2.small"    //type of instance
  instance_class  = "db.t2.small" //type of RDS Instance
}

In both the dev and prod Terragrunt configuration files you can see that we're including the inputs from the root Terragrunt config file using the [.code]find_in_parent_folders()[.code] function.

We're also including the input variables that are specific to each environment. This is as DRY as it gets.

The second thing to notice is the source attribute inside the terraform block. Here we are referencing the Terraform module Wordpress that exists two levels above inside the modules folder. It's also possible to reference a terraform module that lives in a git repository, which is actually a more realistic pattern. In this case, another benefit of using Terragrunt is that you can source different versions of all the Terraform modules for different environments. For example, the dev environment may be running on version v0.0.2 of our Wordpress module whereas the prod environment is still on version v0.0.1. Once the dev environment has been properly tested you can then upgrade the prod environment to version v0.0.2. With pure Terraform, you can't parameterize the source block rendering all environments running with the same version of the module unless you hard-code the version values.

Deploy with Terragrunt

Follow the instructions below to deploy the WordPress application using pure Terraform code only.

In the Terragrunt/environments/dev folder create a private/public key pair with an empty passphrase:

ssh-keygen -f mykey-pair
sudo chmod 400 mykey-pair

Then run the following Terragrunt commands:

terragrunt init
terragrunt plan
terragrunt apply

Terragrunt sets the AWS remote backend for you. It will create an S3 bucket and a Dynamo DB table.

To deploy the production WordPress application, run the same steps above but in the Terragrunt/environments/prod folder.

Here is the output of the [.code]terragrunt apply[.code] command:

Notice the Terragrunt output is exactly the same as the previous Terraform only scenario except that we didn't need to define an outputs.tf file to output the variables from the module. Terragrunt did it for us for free.

And going to the URL shows you the same WordPress setup screen that we saw earlier.

Terragrunt Cache

The Terragrunt cache is a folder that Terragrunt creates in the current working directory to store the downloaded Terraform configurations, modules, providers, and backend settings. Terragrunt uses this cache to avoid downloading the same code multiple times and to speed up the execution of Terraform commands. You can safely delete this folder at any time and Terragrunt will recreate it as necessary. You can also change the location of this folder by setting the [.code]TERRAGRUNT_DOWNLOAD[.code] environment variable. Here is what it looks like

Cleanup and the run-all command

Terragrunt has a neat feature that allows you to run commands across multiple folders. In our case we will run the following command to destroy the dev and prod environments in parallel from within the Terragrunt/environments folder:

terragrunt run-all destroy

Below is the output showing both the dev and prod environments destroyed successfully.

Terragrunt with env0

As we've seen, Terragrunt offers several benefits over Terraform and helps to address some of the challenges inherent to Terraform implementations. Since Terragrunt is built on top of Terraform, it also benefits from env zero management.

When you use env zero in conjunction with Terragrunt, you get the following benefits:

• Automate your Terragrunt deployments in CI pipelines for Infrastructure as Code.
• Manage your Terragrunt variables centrally and securely.
• Integrate your Terragrunt-based environments with other environments managed by different IaC tools.
• Combine multiple Terragrunt deployments to create more sophisticated environments.
• Use [.code]Terragrunt run-all[.code] to execute commands on multiple modules efficiently and reliably.
• Manage your underlying Terraform state safely and easily.
• Increase the reusability and extensibility of your Terragrunt deployments.

Key Takeaways

Terragrunt is a powerful tool that enhances the Terraform experience by providing DRY code, versioning, dependency management, and hooks, among other features. By following best practices and leveraging Terragrunt's features, you can create a more efficient and maintainable infrastructure management process in large-scale deployments. Combine env zero with Terragrunt and you can unleash the full potential of your Infrastructure as Code strategy.

References

• https://terragrunt.gruntwork.io/docs/getting-started/quick-start/ 
• https://blog.gruntwork.io/terragrunt-how-to-keep-your-terraform-code-dry-and-maintainable-f61ae06959d8 
• https://jhooq.com/terragrunt-guide/ 
• https://github.com/orgs/gruntwork-io/discussions/92 
• https://blog.devops.dev/a-complete-overview-of-terragrunt-fbebb53fbd42 
• https://itnext.io/structuring-terraform-project-using-terragrunt-part-i-4c6e936c4858 
• https://github.com/gruntwork-io/terragrunt-infrastructure-live-example 

‍

The Problem

You asked, we listened. This has become the most requested feature we’ve ever had.

That’s right, we’re finally launching the Terragrunt run-all functionality.

We’ve had Terragrunt support since December 2020, with that initial release supporting running a specific folder at a time. Terragrunt, however, has a neat capability to execute multiple Terraform modules at once, with the bonus of being able to define module dependencies too.

With this new release, it’s now possible to run parallel folders of Terraform modules. Admins can configure the template to `run-all` modules, with users able to toggle the functionality when they run the template.

What is Terragrunt? Why use Terragrunt run-all?

Terragrunt is an excellent solution for keeping your infrastructure configurations DRY (Don’t Repeat Yourself), managing multiple Terraform modules, and managing remote state. It allows us to define Terraform code only once, irrespective of how many environments we’re running.

By using Terragrunt, we’re able to eliminate duplicate backend code. Instead, we can manage Terraform state once in the root directory, and it’s inherited by all child modules.

Finally, Terragrunt allows us to execute Terraform commands on multiple modules. We only need to run one command for all modules, instead of executing for each independent module.

This is the convenience of Terragrunt “run-all”.

With “run-all”, not only do we run the Terraform command on multiple modules, it creates a dependency graph between those modules, and allows the passing of outputs as inputs to different modules.

How to use Terragrunt run-all in env0

How to use Terragrunt in env zero using a template

Here’s how to enable “run-all” in the UI when creating your Terragrunt template

When creating a new template in env0, first select the Terragrunt template type. Next, expand the “Advanced” options and click the check box to “Execute run-all commands on multiple modules”.

How to execute Terragrunt run-all in env zero without a template

To execute Terragrunt run-all without creating a new template in env0, select “Create new environment” from within your project.

Choose the VCS option to “Create an environment from a VCS integration.” This allows us to create a new environment directly from your source code repo.

Select the Terragrunt template type. Expand the “Advanced” options. Click the checkbox to “Execute run-all commands on multiple modules”

In Step 2, you’ll choose your VCS, select the repository, branch, and folder which contains your Terragrunt files.

In Step 3, define the ‌variables.

Finally, name your environment, and select your desired env zero features, like Drift Detection or Plan on Pull Requests.

Deployment Example

Here in the deployment logs we can see the results of the `run-all plan`. Expanding to dive deeper will show whether or not the configuration is valid, as well as any changes that were committed in a human readable format for ease of troubleshooting. Depending on whether we prefer to apply before or after merge, we can also insert an approval step to satisfy governance and compliance requirements.

After our changes have been approved, we can view the logs for `run-all apply`

Since Terragrunt run-all environments will include output from each Terraform module, we’ll list the outputs in the UI by presenting them as a separate group for each module folder.

Terragrunt and env zero - Manage your infrastructure at scale

Rejoice all ye Terragrunt users, for the day has come that Terragrunt run-all has come to env0! This allows you to execute Terraform commands on multiple modules, with the added ability to define dependencies. This is perfect for creating more complex Terraform environments with multiple modules, setting up the dependencies between them, and for keeping your Terraform code DRY!

By using Terragrunt with env0, you’ll also get approval flows, plan on pull request, continuous deployment, ephemeral environments, scheduling and drift detection. This provides the robust functionality needed to automate, manage and govern Terragrunt at scale.

‍

A new year and tricky economic times seemed like the perfect opportunity to gather some IaC experts for a conversation about hiring challenges, where we’re headed, and doing more with less.

In case you missed our infrastructure as code webinar, here’s a bit of what I learned in my conversation with Brandt Meyers, enterprise architect with MGM Resorts International, Kat Cosgrove, lead developer advocate at Dell, and Chris Short, senior developer advocate at AWS.

Code once, reuse often

Market research firm Gartner Group says infrastructure as code will be the most in demand skill this year, so how can teams handle this? One great option, suggested by Brandt, is to change the corporate mindset, moving from prescriptive code creation for a single use to subscriptive coding where code is created to be reused within an organization and perhaps beyond. While hiring and retaining still remain challenging, changing the code creation strategy could make a difference.

The continuing power of automation

Also making a huge difference, particularly to job seekers in this uncertain market, is a deep understanding of automation. “There is always a need for people who know how to automate,” Chris said. “If you’re good at automating you’re going to have a job.” Chris said he thinks a lot of small startups are continuing to hire and that they’re looking for people with infrastructure as code or platform engineering expertise. I agree with that, but in my experience those skills continue to be difficult to find. 

Start with infrastructure as code

It’s Kat’s hope for 2023 that teams will finally think infrastructure as code *before* they even start to build a proof of concept. “At this point in the industry IaC is no longer an afterthought,” she said. “It’s time for everyone to accept IaC as a requirement when building an app.” Those who ignore that advice will find “bolted-on-later” IaC difficult to do, she warned. 

Want collaboration? Try Everything as Code

One of Brandt’s team goals for the year is increased collaboration and his approach is novel: put code at the center. “It really goes back to the fact that IaC is evolving into EaC (Everything as Code),” he explained. “You want to maintain the configuration and make everything consistent. Code is a way for us to collaborate and have a common language.”

How to do more with less? Cross-train

We all agreed that, thanks to the uncertain economy, many many teams will be trying to figure out how to be more productive with fewer resources. And a good place to leverage that is with infrastructure as code, Chris said. “We need the consistency that IaC brings. The more people who adopt it the better,” he said. To ensure all team members can appreciate the benefits, Chris suggested cross-training. “Learn a bit about infrastructure if you’re a dev, and if you’re on the infrastructure side get familiar with GitHub or Python. The more we have crossover like that the better things will get. We need to share these best practices more.”

Stick to what you do well

And finally, it’s always important to remember that there is not one magic tool…for anything. “I want to see more companies not trying to be like a pocket multi-tool, because there isn’t one tool that is the best for all these specific things,” Kat said. Her take, and I agree with it: Specialize in what you’re good at and actively collaborate with other tools that fill in the gaps, or in other words, “stop trying to force it.”

Watch the full 2023 Infrastructure as Code roundtable

Webinar Transcription:

Justin Nemmers: 00:02:28

‍All right, hello. Welcome. Good morning, good evening. To everyone today, I'm really excited to be bringing a fantastic panel of, uh, folks here to talk about infrastructure as code 2023. You know, what are we seeing? What lies ahead? Uh, and like, why is it a big deal? So, uh, before we get into the actual webinar itself and the panel discussion, I want to go over a little bit of housekeeping. Of course, all of your microphones and cameras have been muted. Um, it's not that we don't wanna see or hear you, but, uh, you know, it's just kind of chaotic, uh, moving forward. If you have a question, please use the q and a button on your, uh, zoom webinar panel there, and you should be able to post a question. Um, some of those will be able to get in line. Most of them we will, uh, likely end up answering at the end of the actual discussion. And so with that, uh, by all means, let's get into the main program. So for starters, introductions, who are we even talking about here? Who, who's on the panel? Uh, who are they and why they important. So let's get that part underway. So Brandt, why don't you, uh, tell everyone a little bit about yourself?

Brandt Meyers: 00:03:32

Sure. Yeah. So I'm with MGM Resorts International and Enterprise Architecture Group. I'm responsible for our cloud reference architecture, our DevOps practice and automation. And I'm working on our, in my journey. I'm working on my fifth generation of infrastructure code with MGM.

Justin Nemmers: 00:03:55

‍Fantastic. Thank you. Uh, Chris,

Chris Short: 00:03:58

‍Everyone. I'm Chris Short. Uh, I'm a senior developer advocate at AWS on our Kubernetes service EKS, um, because our acronyms are easy to remember. Um, the <laugh> I've spent the past 23 years now in tech. It feels like something like that longer probably. But, uh, a big background in DevOps, and I'm a Kubernetes contributor as well.

Justin Nemmers: 00:04:24

Awesome. Awesome. Kat?

Kat Cosgrove: 00:04:27

‍Hello. Hello. Uh, my name is Kat Cosgrove. I'm a lead developer advocate at Dell in our brand spanking a new, uh, super fancy DevOps team. Um, I have been around for a while, but mostly, um, in not DevRel. DevRel thing is, uh, relatively new to me over the last, they've been doing that for like four years, but I used to be an engineer. Um, I live in Seattle with my two cats, one of whom is with me on this webinar. Her name is Espresso, um, <laugh>, and I am also a Kubernetes contributor alongside Chris.

Justin Nemmers: 00:05:05

‍Awesome. Thank you. Uh, and awesome guest appearance by, uh, Espresso there. Ohad.

Ohad Maislish: 00:05:12

‍Hi everybody. Ohad Maislish, co-founder and CEO at env0. If you've not heard about env zero yet, we care about infrastructure as code is this, uh, this panel we provide management solution on top of the frameworks on top of Terraform, Pulumi, CloudFormation, and, uh, and others. I'm originally an engineer, uh, moved to, uh, be founder and I like to talk about tech. I'm still always was Geek <laugh>.

Justin Nemmers: 00:05:41

‍I love it. And, uh, the interesting part about this is we are all either current or recovering engineers on this, uh, on this panel. So, uh, very true. It's fantastic recovering, always recovering <laugh>. Awesome. Um, alright, well thank you so much for joining us. So let's just go ahead and dive into it. We've got a, uh, I think a pretty good set of discussion topics here that we're gonna dive into. And, and I'll set the stage a little bit at first and then we will have, um, have some around the horn here. Uh, so for starters, as server automation adoption accelerated largely thanks to tools like Ansible, the workplace demand for automation talent significantly outpaced the supply. And now for the first time ever, we're beginning to see that same trend happen with infrastructure as code. So Gartner is predicting that IaC will be the most in demand skill in 2023. And the question ultimately is how can you prepare for this? Uh, we all have teams that we need to do and work with. Um, and when that skills gap is present, it, it makes things especially challenging. So, to get started here, why don't I pass it over to you, Brandt, for some of your thoughts.

Brandt Meyers: 00:06:45

‍Yeah, so I think, um, you know, a couple opportunities there is, is working with our existing engineers and, and giving 'em opportunity to learn and, um, you know, really supporting that, um, bringing in talent is, is a challenge in keeping talent. I think all companies are working on that. Um, and um, I think another piece too is with an infrastructure as code changing a mindset from prescriptive to subs descriptive where, um, when we build code that's prescriptive, it's, um, it's for a particular use case and it's not really reusable, but, um, building code that's more extensible and that can be, uh, reusable across an organization first. Um, instead of teams building specifically for their use case, they build for the organization where you can reuse with an organization and then maturing to a point as an industry where we can reuse and, and leverage, um, our talent collectively.

Justin Nemmers: 00:07:53

‍Fantastic. Now, you know, Chris, I'd imagine in your role you end up seeing a pretty broad, uh, number of just customers and organizations that, uh, that in some cases are, are, are trimming some folks, and we're, we're gonna talk about that momentarily, but it seems like for every one company that you're hearing about layoffs from, there are five more that are, that are doing a, a wild amount of hiring. I mean, so how do you, how do you think the dynamic that brand is talking about really will continue to play out?

Chris Short: 00:08:21

‍I mean, there's always gonna be a need for people that can automate things, right? Like, if you're good at automating things, you have a job, right? <laugh> just, just understanding what it takes to automate a business logic in applications or infrastructure is gonna take you a long way. But yes, there is this odd economic situation that we're kind of toiling with right now, uh, especially in large tech companies. Um, but it seems all the small startups that I've talked to are still hiring, which is interesting. And those startups are looking people with infrastructures as code skills or, you know, platform engineering type skills, I think is what it's being referred to a lot where there's a developer platform that a team maintains and, you know, that can be a team of SREs or whatever. Um, those skills are gonna continue to be in demand. And what we're gonna start seeing now, especially with like the downturn in ed revenue, is that information is gonna be like a key thing, um, that you're going to have to maybe struggle to find. Or in the past it was kind of pushed into your face. So being able to discover trends and new tooling or new best practice, not best practices, but new practices that, uh, improve on your existing ones will take you a long way no matter where you go. Now, companies finding those people, that's hard because normally, I mean, I, I speak, I'm speaking for myself here, after about 10 years in tech, you're referring to your network mostly, um, to get jobs and not necessarily like trolling the internet for 'em or job boards especially. So yeah, it's, it's hard to get influence with these people to a say, use our tool, let alone get them to actually come on board, right? Like, that's a whole nother challenge in and of itself. And I'm sure Ohad has all kinds of stories about that.

Justin Nemmers: 00:10:24

‍Yeah. Well, I mean, great pitch over. So Ohad, you know, what, what are some of the, the things that you've seen regarding this? I mean, we, we've clearly, everyone has a need for personnel on some level, uh, and when the, the skills don't meet, meet the, the actual requirements, what, what do you do?

Ohad Maislish: 00:10:40

‍You have, you have a problem? I, I remember, uh, one thing I'll never forget when, Omry and I started env0, we started, uh, to do some market research and we, uh, scheduled a meeting with a friend of mine who is a VP engineering in, uh, in a big company managing, uh, about 100 engineers. And the meeting was for like one hour and he just, uh, allocated more time to talk with us. It was like close to two hours. He had a big office, uh, big shot. Uh, and then when he started asking more and more questions, he said, I, I don't know those answer. He's or, uh, Head of DevOps, Head of SRE, he can answer those questions. And then I will never forget that we ask him, can you bring him to the room for like five minutes so we can ask him? He said, oh, no, no, he's, he's busy. Don't interfere with, uh, with his time. And I'm like looking that you're managing like 100 people and eventually the bottleneck is your, uh, is your DevOps team. So there's definitely a clear <laugh> a clear problem here that those skills are both needed and difficult to, to find the relevant people that can actually do this job. The need for automation constantly increases. Chef, Puppet, and as you mentioned, Ansible was one generation of configuration management. Now we see, uh, similar and probably a bigger thing with infrastructure as code. And the problem is still very much existing out there, in my opinion.

Chris Short: 00:12:12

‍And Kat, I think you can talk to how the <laugh> the, the landscape has changed over those years, right?

Kat Cosgrove: 00:12:19

‍Yeah. So when things like Ansible and Chef first came out, you know, um, we, we called that configuration management and it was, um, configuration management at the time. The, the term infrastructure as code didn't really exist, even though we've had things that do kind of that for, um, literally decades. We've, we've had something like automated configuration management as long as we've had computers longer than we've had computers. Um, where things changed is when we started, um, lumping more pieces of automation in with just managing configuration. And now we have a term for that infrastructure as code, but, um, configuration management tools like Ansible, although they predate infrastructure as code as a term, they are infrastructure as code tools now, right? Like we consider them that now we didn't used to, but, um, configuration management is now just like a, a subset of infrastructure as as code. Like it's just become an umbrella term for you're automating anything to do with, uh, the infrastructure that an application is running on, whether that is standing up the entirety of the infrastructure or just configuring additional infrastructure that was stood up with something else. Um, which is like the, the issue with hiring, um, and the, the, the lack of people that have these skills, even though we increasingly need these skills, I think is why we're seeing more products like Pulumi and CDK, um, rising to popularity. It allows you to get your engineering team more easily onboarded onto the concept of infrastructure as code than if they had to learn like Terraform or something. If they're not used to slinging YAML or like writing HCL, then maybe writing Python is a little bit easier. Like, I know Chris came from a more ops background than, than I did. So I'm way more comfortable with like, Pulumi, CDK, it was way easier for me to transition into doing infrastructure as code with those tools than it was with Terraform. But I bet Chris had the opposite experience.

Chris Short: 00:14:40

‍I mean, I remember reading the original YAML spec cuz we were switching over to Puppet, right? And then, uh, quickly discovering how awful Puppet was, um, at the time. At the time, yeah. It required so much resources, you know, back now it's like, oh, it's just Puppet, it just, it has a box by itself somewhere kind of deal. And, but back then it required a ton of infrastructure. So, you know, managing that aspect alone was hard. But yeah, slinging and YAML was what, you know, my bread and butter was for many, many years where Yeah.

Chris Short: 00:15:14

‍Was more slinging structures and functions. Right. <laugh>.

Justin Nemmers: 00:15:18

‍So I'm kinda curious, you know, Brandt, how does this play out on your team? So, you know, you've, you've indicated that you've dealt with, uh, four now five completely different generations of, uh, of Terraform implementation. You know, presumably you didn't magically just grab a team that suddenly was all known around Terraform in this case, although as great as that would be, like, you know, you just press a button or, you know, run a YAML file and, and magically new new resources appear <laugh> in the form of humans to jam out more. Terraform clearly doesn't work like that. So how, how have you seen this practically play out?

Brandt Meyers: 00:15:54

‍So yeah, it's kind of, um, working out a facilitating relationship for the need and, and, um, one of the, one of the things we've done is we've partnered with, um, like Ohad with env zero right? To, um, to help facilitate those, uh, fundamental capabilities that we need to be able to, um, to drive the solution. And so having that foundation of, um, you know, those, those value adds that, um, you can get right out of the gate is really important. But also being able to have, um, collaboration, um, there, there's, there's, there's four Cs that I've, are, are in my mind at this point that are, um, are focused for 2023. There's, there's cost collaboration, there's um, there's the consistency and um, there's, there's the, uh, I'm trying to remember what the fourth one is now. There's, there's also the, um, kind of the, there's continual improvement. Um, but just, just kind of having those elements in mind this year is really important. And we kind of get that with having a facilitating partnership with, with env0, but also within our company, creating a DevOps organization and facilitating across teams to build a common practice.

Justin Nemmers: 00:17:27

Brilliant. Yeah, I mean, as much as we would always like to say that there's gonna be one magic tool that's going to solve everything for everyone, the reality is, is definitely not the case.

Kat Cosgrove: 00:17:36

‍It doesn't exist,

Kat Cosgrove: 00:17:38

‍Vendor, it doesn't exist in any category of technology. Like full stop, there is no one best cloud provider. There is no one best programming language. There is not and never will be one best IaC tool.

Justin Nemmers: 00:17:49

‍Oh yeah, there was a world's best programming language and it's called Perl. Um, alright, thank you very much everyone. This is. No totally kidding.

Chris Short: 00:17:57

‍Please. Oh my gosh. As someone that maintain a CMS completely written in Pearl for a newspaper company, I disagree. Yeah,

Justin Nemmers: 00:18:04

‍That's right. Um, alright, so like, all kidding aside, let's, uh, let's just kind of dig into this a little bit. So, you know, we, we've talked a bit about like, how do we handle this, like glut of resource, or not glu, but a a really a glut of need. Everyone has need for more talent on this front. Uh, so that's a trend clearly that's going to predictably continue. I mean, what else? Like, what else do you, do you think that's gonna become more prominent around IaC uh, over time and like for instance, uh, and we might actually just end up asking this as a poll, I think, but, but you know, we've seen over the past couple of years, Kat, you did a great buildup to this talking about how Ansible originally was being used basically as a, an IaC tool. Yeah. Uh, although there was no such thing as IaC initially. Over time we've begun, begun to see many, many more options. You know, in the end, in the beginning it was, it was pretty much just Ansible, you know, maybe Chef and Puppet, uh, then, um, Terraform, and now they're kind of a bunch of choices. So we're actually kind of curious as to what, uh, the audience here is running. So let's go ahead and publish that poll and then we will kind of continue to, to talk through this as, uh, as, as votes come in. Yeah. So what are some of the trends that we're gonna see kind of continue to, uh, to increase here? Ohad, what do you think?

Ohad Maislish: 00:19:20

‍No, I just wanted to comment that if I remember correctly, Puppet was recently acquired and if, if I remember correctly, I think the headline in TechCrunch or another place was infrastructure company Puppet got acquired by such and such. So that's, uh, an interest thing how to, to look at the old configuration management frameworks as, as Kat mentioned earlier, of, uh, of the first version of infrastructure as code in a way, eh,

Kat Cosgrove: 00:19:45

‍Puppet did get acquired, but I don't remember by whom.

Chris Short: 00:19:50

‍Yeah, it was like an investment firm

Kat Cosgrove: 00:19:51

‍Or something, wasn't it? And also, uh, Ansible wasn't the first. Um, like you ages before we had the Lake, Ansible, Chef, Puppet wars, um, everybody used CF engine, um, which still exists.

Justin Nemmers: 00:20:06

‍Yes, it does.

Kat Cosgrove: 00:20:07

‍Uh, crazy. Yeah, still exists, still exists really hard to use. Learning curve is outrageous. Um, but at the time it was absolutely revolutionary.

Justin Nemmers: 00:20:21

Oh, I, I remember it well, <laugh> user, and they, uh, like we'd go into an account when I was back with Ansible and like, oh, what are you using? And yeah, we heard that one a lot. Uh, follow by a groan because yeah. Uh, if you don't like writing HCL, imagine writing C to define your configurations. Definitely a blast.

Kat Cosgrove: 00:20:41

‍Yeah. I never had the pleasure, fortunately,

Justin Nemmers: 00:20:46

‍Yeah. So, you know, but on that note, Ohad, uh, to kind of continue on. So, so what, what are some of the things that you think are gonna continue to be prominent within the IaC community in 2023?

Ohad Maislish: 00:20:57

‍I think Terraform is, uh, having a lot of, a lot of success. Um, when we started env0, we didn't know where the focus, when the focus will with Terraform customers or maybe Pulumi later. We haven’t heard more about Crossplane coming up in this conversation today. Uh, but I can, my, my feeling is that Terraform continues to, to be that defacto leader in, uh, in the IaC world. Uh, although the, you know, the, the issues we talked earlier about how to open, uh, you know, the ability to write infrastructure as code to wider audience of engineers, uh, the fact that he has has such a wider, wide ecosystem with, uh, so many providers and models and community, uh, is really helpful to look at that as an end-to-end solution. And when we even talk with single cloud customers like AWS customers or Azure customers, I think like three, four years ago we heard more CloudFormation, we heard more ARM templates. Uh, you know, I, I wanna share that I think like two years ago I had the honor to talk with CTO of Azure, uh, about ARM versus Terraform. And ah, well Terraform went doing very well on the poll. Uh, and he was very much focused on, on ARM. And he said that Azure customers will just use ARM and they don't need Terraform. And I think like three, four months ago, um, they released a very interesting open source like Terraformer, but specifically for Azure, which basically takes all of your, uh, Azure Cloud resources and automatically generates Terraform code. So even Azure team, uh, has realized that their customers pay a lot of attention to Terraform, not necessarily for ARM, and their HCL based version named Bicep. Not sure if people here know about Bicep, it's a more HCL version of, of ARM, but it's not Terraform. So eventually even Azure customers probably use more and more Terraform. We see that with CloudFormation being less used, more, more Terraform. So I think what I'm trying to say here, I've mentioned the word Terrafom like 10 times in the last three minutes. So that's, I think is a multicloud open source with a huge, uh, ecosystem of providers, public providers, and public models. I think it's, uh, it's the clear trend that we continue to see over and over.

Justin Nemmers: 00:23:29

‍Yeah. And you know, it's interesting. So the one thing I, I was wondering if you could possibly say a couple of words about Terragrunt. So I know that we see a fair amount of that at env zero as well. Uh, and clearly it's, it's pretty prominent in their response here. I think most people probably know what CloudFormation is Terraform, uh, but Terragrunt might be the outlier there where, you know, there's a total percentage of usage out there. It's pretty small, but we see, I think a lot of it growing. So, Ohad. What, what are your thoughts on that?

Ohad Maislish: 00:23:54

‍Terragrunt is always there. I don't remember how old Terragrunt is, but, uh, it's a more advanced, uh, flavor. Sometimes I say it's the cousin of, of, of Terraform in a way, uh, do not repeat yourself kind of framework. And we see a lot of, DevOps engineers that try to understand how to map everything to infrastructure as code when they have the nuance of, uh, choosing either Terraform or Terragrunt, very often trend towards, uh, Terragrunt I do have a feeling that it becomes less crucial as it used to be a few years ago, because the Terraform framework has evolved with some of the key things that Terragrunt and had while Terraform still didn't have. But still, we very often see, uh, Terragrunt users, uh, having some additional capabilities that Terraform is, uh, is lacking. And I think in general, Gruntwork is doing a, a very, very good job, both the Terragrunt and their, uh, the other solutions of Terraform models that they, that they provide. And maybe that's yet another reason why Terragrunt is doing successfully, uh, thanks to the great local, uh, Gruntwork.

Justin Nemmers: 00:25:09

‍Excellent. Kat, what do you think is gonna increase in 2023?

Kat Cosgrove: 00:25:13

‍Uh, um, I think hopefully we'll see more people thinking about infrastructure as code from the outset rather than trying to shoehorn it in later on. Um, that, that is hard to do and it introduces more problems than are, are necessary, I think. Um, so, so hopefully we see people just like day one consideration is we are going to use an infrastructure as code approach to build and deploy this application. Um, rather than building a proof of concept on manually configured, uh, infrastructure and then trying to switch over later on, uh, in a scramble to find people to hire to do it for them. Um, it's just, it kind of feels at this point, um, in the industry, like infrastructure as code is no longer an afterthought. It is just a given. That is the way we operate now. Um, standing up and configuring infrastructure by hand is, uh, inefficient, slow, and dangerous, and everybody kind of just like seems to accept that now. Um, so hopefully this is the, the beginning of us just accepting it as a default, just a requirement of building an application.

Justin Nemmers: 00:26:31

‍Yeah. So Brandt, it seems like you typically agree with that, given the head nods, but, you know, I guess I'm just kind of curious for 2023, you talked about your four Cs, you know, is there any one of those between, uh, let's say I wrote 'em down, cost consistency and continual improvement? Um, as a marketing guy, I definitely, um, re recovering engineer, but marketing guy, I definitely love the, uh, <laugh> nice bite size components there. Which of those do you, do you think is gonna be most important for your team? And, and how does IaC play into it?

Brandt Meyers: 00:27:01

‍I think collaboration is key. And, and really it is, it goes back to like, I think it's just IaC is gonna evolve into EaC. Everything is code. Um, and, and, and it's not just, and it doesn't stop at cloud. It's, it's everything. It's even SaaS. Um, it's, it's maintaining a configuration of everything consistently and, and being able to bring back together, uh, a technology organization. Um, what I've seen is, and, and I've experienced this, you know, a number of times where it's just, um, we, we have this radical shift and some teams focused on that shift, and other teams are focused on sustainment or iteration, not necessarily innovation. And so, you know, I think, I think organizations this year are gonna come back to how do we come together again, as, as a, as an organization and, and code, you know, as a way for us to collaborate and have a common language. And we need to decide what that language is and, and how we use that effectively.

Ohad Maislish: 00:28:06

‍I have to say, Brandt, um, I'm a close friend of, uh, founders of the company named Salto, and not sure if you've heard about Salto. Uh, they're backed by, uh, Accel and some other great, great investors. And they, the first time I've heard the term Company is Code, you mentioned everything is code, and they say company is code. And, uh, you've mentioned the, the increase of, uh, providers and SaaS and not just the actual cloud vendors. We see that with the Okta, New Relic, and Datadog. Even env zero has its own Terraform provider. But what Salto is trying to push towards is becoming fully managing everything with code, including things like Salesforce and Zendesk and your, uh, financial, uh, internal tools. Uh, that's really interesting to see how you no longer, uh, click a button to change some configuration of your business, but instead you write code. So that's, I think, uh, a trend that continues to happen.

Chris Short: 00:29:09

‍I think Linux  just opened up that realm of doing things to everyone finally, right? We had years of Windows dominance, and then finally you could, like, the common person could build a Unix like system and touch config files on a regular basis. And that made more sense to them than clicking through a bunch of check boxes. And that evolution has continued on since the nineties, it feels like.

Justin Nemmers: 00:29:35

Yeah. And I think, you know, ultimately it's a, uh, it's a great one. So, you know, for every point there's a counterpoint, and I guess I'm, I'm kind of curious as what you all think, what's gonna go away, what are we gonna see less of, if anything in, in 2023? And you should know that, um, the, the, uh, opposite of the answer you already provided will not be acceptable <laugh>. Um, so yeah, I mean, what, Kat what do you think in 2023, what are we gonna see less of? What is gonna be less prominent or maybe you hourly disappear.

Kat Cosgrove: 00:30:07

‍There's, there's what I want to see less of and what I think we'll see less of, um, what I, what I want to see less of is I, I want to see less of, uh, vendor lock in. I, I hate it. I'm allergic to it. Um, I don't like using tools that force me to use a specific vendor. Um, which is, which is why I will prefer things like Terraform, Pulumi over a cloud provider's, like specific tooling. Um, I don't like that. I think it is, uh, unsafe. Um, that's not necessarily to say that I think that multi-cloud or hybrid cloud is the right answer for everybody, because that does introduce a ton of extra work also. But, um, I would like to see people more carefully choosing their tooling to leave the option open to not be locked in to something forever. Um, cause it, it is just, I don't know,

Chris Short: 00:31:11

‍I would even expand on that, Kat. You know, I feel like some engineers are gonna have tools of choices. Right. For sure. And I feel like we'll see maybe a stacking up of tools that become your holistic IaC thing. Someone mentioned in the q&a, IaC, Terraform and Ansible working together from time to time. I feel like that's gonna happen with the Pulumis and all the other things of the universe, Terraform, um, kind of in mass. Like people will have their tool and just as long as they can automate the tool doesn't matter as much.

Kat Cosgrove: 00:31:47

‍Yeah. And honestly, the thing that like, kind of worries me is, um, that like the, the core of DevOps is though we want development teams and operations teams to be like working together, right? We want them to be working in sync, we want them to be working together, we want them to be talking to each other. And, um, I kind of worry sometimes that, um, the way some IaC tools market themselves is trying to, like king, make only ops people or king make only engineers. Yeah. And, uh, putting one or the other up on a pedestal like that is kind of like antithetical to the, the core of DevOps to me. So, um, I, I would like to see people be able to use the tools that work best for them, um, regardless of whether it's like YAML or a programming language, I wish that they alongside each other more often than like mm-hmm. <affirmative> being like super divisive about it. Cause I think it's dangerous to put ops people on a pedestal or put developers on a pedestal. Cause like, it's the tech industry, Lord knows we're already all on a pedestal.

Justin Nemmers: 00:32:54

‍The, uh, so Brandt, uh, one of the things you wanna stop doing in, uh, in 2023,

Brandt Meyers: 00:33:01

‍Um, let's see. I wanna stop thinking about lift and shift <laugh> <laugh>.

Kat Cosgrove: 00:33:09

‍Yeah.

Brandt Meyers: 00:33:11

‍Um, yeah, I want to, uh, I wanna stop, um, I think stop the, the, the siloed, um, approach in, in practice. I, I think back to Kat's point, like having, having the, the ability to support the diversity within our, uh, discipline is important and that drives innovation and we should collaborate more.

Justin Nemmers: 00:33:43

‍Fantastic. And, you know, I'm actually kind of reminded in our, one of our previous chats you were talking about this kind of core continuum and like how, and this is a a little bit off topic, but I think it's relevant and interesting, so we'll bring in about it anyway, uh, it's nice thing to get to do when you're the moderator. <laugh>. So you were talking about just like open source in general and the whole kind of paradigm of open source and  innersource. So like how do you, how do you take a team that is like broadly adopting new technologies and how do you, how do you turn that into that collaborative thing that, that we're all search, like really searching for, how do you turn that into a, a net gain for your team versus a, like a, either a neutral or a net loser?

Brandt Meyers: 00:34:26

‍Yeah. So yeah, there's very much this continuum of, um, something, something can change at any point within this relationship of things that are just fundamentally a framework versus, you know, some industry, um, sourced capability, um, to something that's very much intellectual property, specific to, um, a use case. And these things are all related, and companies have gotten very used to, uh, leveraging open source, um, or, you know, industry capability that's out there, um, to deliver, uh, requirements specific to product teams. But there's, there's this continuum where there's feedback across the board, right? We might, we might develop something that's maybe, um, specific to a product, digital product, and it's very much, um, relevant core to a business case, but that might impact, that might influence something that we use in the industry. And so maybe we want to, we want to suggest a change to a library or a, a reasonable component that's out there, a provider or something. And, and we need to be, we need to build that relationship back into the community to, to be able to move these things forward, both for our intellectual property and and for our industry.

Justin Nemmers: 00:35:51

‍Yeah, I think that's a really good, kind of an interesting point. I mean, I'm curious as to what you think when it comes to IaC specifically. You know, do you, do you feel like that like there even could be a lot of reuse for, for most organizations, IaC components outside of their own organizations? I mean, it feels to me that, that increasingly the infrastructure is the application, right? So it, if, if doesn't matter what cloud you're pro you're building on, you've made a bunch of infrastructure decisions and you codify them. The question is like, is that useful outside of what it is you're doing? You know, what, what do you think about that?

Brandt Meyers: 00:36:28

‍Absolutely. It's, um, you know, I, I think infrastructure as code has a huge opportunity for that. It's, we, we've started with, um, building the libraries, right? And the fundamental components that are needed to describe the configuration we need. But then, you know, we can also provide baked configurations, um, that are reusable. And those, those baked, um, you know, reusable components then can, are, are very much relevant in the industry, right? If, if you're working on some, some basic, you know, blob storage component or, or secrets management component, um, that's very relevant to everybody. And it's not quarter of your business, it's quarter industry. And so, you know, we, we talk about in our industry, we're struggling with, um, with talent and, and getting these things done, but part of the problem with our industry is we're all doing the same thing at the same time. So, you know, if, if we can focus on, as an industry figuring out how do we collectively do the same thing, uh, that's gonna be far more efficient to get things done.

Chris Short: 00:37:43

‍I would like to see more companies open sourcing what they're doing, right? Because we've gotten to this point now where we all agree infrastructure code, infrastructure as code is the right way. But it always feels like everybody, every place I've ever gone has to reinvent the wheel, right? Like after, yeah. Like,

Kat Cosgrove: 00:38:01

‍Go ahead. Why, why is it a, a secret how, like what Terraform or Pulumi code you're using to stand up the infrastructure necessary to deploy a serverless application on AWS. Like that should just be like a, a module that you feel comfortable publishing and open source, because it's not like, it's not mission critical. Nobody, nobody cares. Like, just don't publish your secrets, right? And, you know, make it clear.

Ohad Maislish: 00:38:34

‍Say, yeah. You say just,

Kat Cosgrove: 00:38:36

‍Just, just like, it's so easy. It's, it's so easy to not commit your secrets. Um, not, this

Ohad Maislish: 00:38:41

‍Is not necessarily GitHub necessarily. I, I've seen some weird things

Kat Cosgrove: 00:38:44

‍People. Yeah, for sure. Oh, it happens all the time. I used to teach at a bootcamp and like every single time there was at least one student that, that committed a secret to GitHub. It always happens, but like, seriously, like, it, it is possible to like modularize your infrastructure as code in such a way that the configuration that's application specific is just drop in and everything else shouldn't be proprietary. It's just like, would you consider it proprietary to like, I don't know, write a, an entry level tutorial with, with screenshots of how to like click through the AWS UI to stand stand up an S3 bucket? No. So why is the infrastructure as code portion not often open sourced? Right? Like

Ohad Maislish: 00:39:34

‍I have to mention that env0, we, we developed a feature that automatically tags your resources re conclusively and knows which resources are taggable and not taggable. And then the second when the developer finished that feature, he said, Hey, I think we should just, we should just open source it. Uh, it's not just for, uh, for us. Anybody can use it without being an env zero customer. And, and so we did. So I think it has And, and if that developer would not have said that,

Kat Cosgrove: 00:40:02

‍Probably wouldn't have thought of it. Well,

Ohad Maislish: 00:40:03

‍Yeah, it would not be, uh, some, some, some, uh, focus of us. Mm-hmm. So I think eventually the, the great things that happen are eventually go, from the developers, the ideas from the developers. And I think if we look now compared to five years ago, I'm sure that five years ago we would not have thought about let's open source that because it was not something that people used to do. Uh, but, but now I think it's just, it's, it is increasing. I think that trend of open sourcing some modules, some frameworks, any reusable code, I think it's a good opportunity. There is the GitHub style. Uh oh yeah, I don't remember the title GitHub, or GitHub style. I don't remember the, uh,

Kat Cosgrove: 00:40:49

‍GitHub Stars.

Ohad Maislish: 00:40:50

‍Yeah. GitHub stars. Yeah. So it's kind of, uh, an incentive now for, for developers, eh, to do those, those kind of things. And you can also, um, um, give money and donate to mm-hmm. <affirmative> to a successful developer and GitHub. And now also a company can do that and not just an individual user. So I think all in all the right things are happening in order to promote and advocate in, in that direction. But some things take, take time, I guess.

Justin Nemmers: 00:41:17

‍Yeah, I mean, it's an ecosystem thing. And we saw this, uh, in spades in the earlier days of Red Hat where we had, we would enter into a, a discussion with the company. And some of these are, are huge multinational global organizations that had active policies against open source. Now that's, this is a whole, a whole different podcast, <laugh>, this is a whole different, uh, webinar discussion.

Kat Cosgrove: 00:41:36

‍Yeah. That's just, that's a thing that feels very legacy to me though. That's just like a absolutely a big old company vibe. Like any big old company. I expect, like getting them involved in open source and an authentic way that doesn't involve, like, fighting with legal for six months. I expect that to be a battle with any like sufficiently large, sufficiently old company or with like, literally any company in some specific industries, like, like banking, right? Mm-hmm. <affirmative> like in that space. I expect it to be a, a fight every time. But, you know, we're seeing more and more companies with OSPOs, uh, open source program offices for those listening who do not, uh, know what an OSPO is. And I know more and more authentic participation. So I, I agree. I think the, the tide is turning.

Justin Nemmers: 00:42:20

‍Yes. Ohad, I think that we've struck a nerve, and that would be a really interesting topic for one of your, uh, future infrastructures, code, uh, podcasts.

Chris Short: 00:42:28

‍You can sign me up for that if you want. Yep. I'm also in the

Justin Nemmers: 00:42:31

‍Meantime, um, Let's, uh, let's try to, to reign this back in a little bit. Now, we'd started to talk about this kind of at the, the head of this discussion. Uh, and the good news is we do have a bunch of, uh, excellent questions. So we'll try to kind of keep this last question a bit a bit concise, but, uh, so we talked about, you know, what's upcoming, what we think we're gonna see less of, um, in 2023. And now, you know, it, it bears without saying that there's, there's a lot of turmoil in the industry, right? So at the end of 2023, uh, excuse me, at the end of 2022 <laugh>, uh, we've seen just a, a tremendous, and, and certainly continuing into 2023, tremendous number of, uh, of large and wide reaching layoffs, right? So, you know, the, the question is, is it, do we, is this having a real and direct impact on your teams today? Uh, and then how do you, how do you see it affecting teams that, that really are already stretched pretty thin? I mean, that was the, the story of automation back in the day was that some people were afraid of automation because they thought that if, well, if I automate my job, like I'm not gonna have a job. Uh, Chris, you hit the nail on the head earlier that, that it doesn't work that way, right? Like, in the end, there's always gonna be enough work, there's always gonna be more work than we can reasonably get done, even with automation. So we can kind of push that, that part aside, but it, um, it, it seems kind of like a weird paradox. So we're starting 2023 with a, a reduced workforce. The expectations and requirements are continuing to increase. Like what happens? We're gonna have to do more with less. Like how, how does that look? How, how do teams adjust to that?

Chris Short: 00:44:06

‍I think you hit the nail on the head, right? Like, do more with less. And that is something that, you know, I've been telling people we have to do with all manner of technology. Um, not because I think we need to eliminate headcount or anything like that. I think it's because we need consistency. It's because we need the things that IaC brings. And the more people that are doing that, the better. Now, like to folks that got laid off, I really feel bad for you. I would say, like, if you're a developer, learn a little bit about infrastructure while you're, you know, spending your time applying for new jobs or whatever it is you intend to do. And vice versa, if you're an infrastructure person, spend some time picking up some code, or at least get familiar with GitHub

Kat Cosgrove: 00:44:56

‍And pick up some Python. Yeah. You know, there's like, Python is superhuman, readable. Just, just pick up some Python.

Chris Short: 00:45:02

‍Yeah. And the more that we have crossover like that, the better things we'll get. Because I've worked with the large development teams and they don't necessarily know anything about infrastructure. So sometimes they do commit a secret to GitHub or something to that effect where it's definitely damaging to the company, and it's just because they didn't know better. And like I said, information's gonna be harder to come by. So we have to share these best practices more.

Justin Nemmers: 00:45:34

‍So, so Brandt, let me ask you this. In a, as a, as a, a leader in a, uh, business oriented, kind of consumer oriented industry, you clearly have many more demands on your team than you have ability to, to rapidly solve those problems. So I guess, yeah, how, what are some of the things you're doing today in order to do, to do less with or do more with less? That almost sounded backwards. Do less with more. Yeah. <laugh>, so basically like you have a bunch of requirements and you have a, you have a limited team no matter how, how big the funding looks like. What, what are some of the things that you're doing to, to assist with that?

Brandt Meyers: 00:46:13

‍So our, our automation approach is community automation. That's, that's the, the name of the program. And so I think it goes back to influencing the practice of engineering that, uh, we, we can work together and leverage, um, reusable components that, uh, that all teams need, you know, and, and that helps accelerate, um, the engineering process. Um, yeah. And, and it's, and and rethinking about what, what's our approach? Where's our opportunity? Um, there, there's some thoughts even around, you know, I see, I've seen some recent articles about repatriation. I think that was a big topic in 2020. Um, but that's coming up again for cost, right? So looking at, um, ways to, um, provide value, provide a, a cost effective, um, solution, something that's more efficient, uh, helps with, uh, with delivering on the, the business need.

Justin Nemmers: 00:47:22

‍Absolutely. Ohad, what do you think, I mean, you, you ultimately lead a, a large engineering team that, uh, we always have more feature requests and things that need to get fixed and tech debt and all of that. What, what do what do you see happen here?

Ohad Maislish: 00:47:38

‍Definitely there are some, uh, obviously there are tons of layoffs recently. Uh, but the first thing, uh, that, that I always think in the last few months is that it's, it's, it's not really layoffs. It's more like a correction. If we look at two or three years back, all in all technology, uh, has grown dramatically, probably too much, uh, a year ago. And so far it's still, uh, a correction. But I think in any case, the, in order to be successful, as we mentioned earlier, you need to do more with less. You, you hear me very often say Justin, uh, the phrase lean and mean, and I really mean that is, uh, is the DNA of, of every company should, uh, persuade and specifically about, about engineers. As, as Chris and Kat mentioned earlier, I think engineer with skills 10 years ago, like 30 years ago, compared to 20 years ago, 20 years ago, compared to 10 years ago or now compared to 10 years ago, even five years ago. You cannot assume that the knowledge and the experience that you have is, is still relevant. And you always need to, to think about your next, next steps and how you, how you improve yourself. And that's maybe why the engineers at env zero make fun of me because they say that I'm, I'm no longer a good engineer because my knowledge is somewhere a bit stuck five or 10 years ago when they really stopped programming hands on. And I think they're really, uh, they have a point. So I think every engineer should realize what they do best. If it's more backend or front end or mobile or kernel or infrastructure, what they like doing and keep improving themselves in, in that direction, um, they, they, they should do well. And for organizations always try to optimize. And if somebody becomes less relevant, you need to make the difficult decision and, and optimize your organization accordingly. You cannot assume that the things that work well three years ago should continue to work well now.

Justin Nemmers: 00:49:52

‍Fantastic. Uh, alright. So we are I think, rapidly approaching some, some Q&A and we've got a lot of good questions queued up. Uh, any, any parting comments from, um, from the panel here on, uh, on that last point about doing more with less?

Brandt Meyers: 00:50:09

‍I'll say, I'll say one thing. The other side of it is, um, it's exciting to be a technologist. It always has been. Um, and it still is. And so there's always opportunity, um, even, even with, um, things that can be discouraging. There's always opportunity in our field and that's, that's a pretty cool thing to be a part of.

Kat Cosgrove: 00:50:29

‍Um, I, I will say that I think that some, um, startups are about to have access to some incredible talent that they might not have had access to otherwise with the number of people that large tech companies have laid off that have a decade or more of experience with some of the most cutting edge technology the world has ever seen. Um, and that's, that's fantastic for those startups. But I will say that, um, watching things like this happen at such a large scale is, um, emotionally difficult even if you're not impacted by it yourself. So it's important to, you know, watch your, watch your own attitude and like, be be careful about are you okay? Right? And times like this also unfortunately, give us a very harsh reminder that our employers are not our friends and they are not our families. Even if they say we're a family here, no, we're not because they like the, these kinds of things do happen. We are watching it happen. And that is, that is upsetting. So it's a good thing to remember so that maybe if you are made redundant and laid off, it is a little bit less emotionally devastating. Maybe it doesn't feel as much like a, like your dad kicking you outta the house or whatever, right? Um, a business decision was made. And, um, so that is also why I don't like it when employers pulled a, uh, wear a family here card. It feels manipulative in the face of things like this happening. But, you know, this is difficult for all of us to watch and all of us to be involved in. So take care of yourself. You know,

Ohad Maislish: 00:52:04

‍I fully agree and I want to give another example that I personally, uh, uh, face from target time when investors, uh, pitch me and they sometimes say we're like family or we're in the same boat. But, but even, but eventually it's, you want to be as close as possible. You wanna work together, you want to make everybody feel well, but eventually it's not the exact same situation. Yeah. In,  our case, uh, investors have preferred stocks, they have voting rights that we founders don't have, and

Ohad Maislish: 00:52:42

‍It’s okay. The structure is okay, but let's not fool ourselves that, uh, it's the same exact same thing as, uh, as a family. Again, everybody has, or almost everybody has good intentions and we're trying to, to do our best. But I I, I fully agree with you, Kat, eventually it's, uh, it's not, it's not the same thing.

Justin Nemmers: 00:53:08

‍Awesome. Um, alright friends, so we do have a number of good questions. Uh, and some, I think humorous quips. So, so Basil initially, uh, suggested that, uh, we should have a, a Terraform provider for Windows, uh, to which I, I cheekly responded, pull requests likely welcome <laugh>, I dunno, we accepted, but, cause it's not my, you know, Hashi not your goal. None. Yeah, you can certainly always try. Uh, but let's kinda dive in. I think there's some really interesting ones here about, uh, just IaC and, and I think we, we struck a bit of a nerve talking about like what is IaC versus not a IaC. So, so Basil continues and he says, why would you consider config management tool as part of iac? From what I've seen, there are always teams who do iac ie. Provision infrastructure to level of VMs, and then a separate team who actually does VM configuration using something like Ansible puppet, et cetera. So what, um, what are some of the thoughts that, uh, you have on that one? I'm actually, um, primarily interested in branch's thoughts on that. So how, how do you guys handle it?

Brandt Meyers: 00:54:13

‍Um, it's a good question. So we do have, uh, Ansible or maintaining configuration. I think runtime configuration is separate from IaC, um, not to say you can't do it, right, but it's <laugh> there. There's, I think it goes back to Kat's point of there are, there are tools that are specific to use cases and they're, they, they all have their benefits and so making sure that you have a robust toolbox that has, that can accommodate the capabilities that you need.

Justin Nemmers: 00:54:51

‍Yeah, I mean, it comes down to kind of using the best tool for the, for the job ultimately. Mm-hmm.

Chris Short: 00:54:55 Yeah. I think I, I really wanna see the, we're a Terraform shop or we're an Ansible shop, or we're a one tool shop kind of die this year because you can't, it's just not feasible.

Kat Cosgrove: 00:55:06

‍Yeah. I mean, like, you can do it, but it's not like, it's not the best way to do it. No. Right. Like, it, it does introduce some difficulties, but I think that was in, uh, response to my assertion that, um, configuration management is a type of infrastructures code, um, to clarify that we only had configuration management for a long time. That is what we called it. But we were automating things in a code like way, like if you, yeah, you can very easily make an argument that a make file is infrastructure as code, that that's configuration management. It's not, not a, I mean, you gotta squint at it a little bit, but you can 100% make that argument <laugh>. But, um, infrastructure as code is just like now an umbrella term that happens to include configuration management and configuration management tools are now starting to do things in a more code like way. Um, so it's, it's kind of just a semantics thing at that point. 

Justin Nemmers: 00:56:10

‍No, I mean, and so this is actually interesting. I think, um, a, uh, a follow on to that and I think it's, it's appropriate for you again, Kat is, uh, where's cross plane? So where's Crossplane in this entire equation? You know, we did the, we did the poll, uh, looks like some, some folks had responded about, uh, about Crossplane, um, but not many. I think one, one person said that they were either using or looking at that. So how, how do you feel like this fits into the overall mix here?

Kat Cosgrove: 00:56:37

‍You know, I don't actually hear about it all that often. Um, and I only hear about it in the context of shops that are like fully 100% cloud native, like, that's, that's about the only time I ever hear of cross plane being used. Um, I have never worked in a like fully cloud native environment, so I've never actually used Crossplane myself. Um, however the people I know who do use it are like super passionate about it being like the one and only true way to, uh, to do what it does. Oh yeah. It's like may as well be like from on high at this point. Um, it's community is pretty, pretty big and active. A friend of mine, um, used to be a, uh, a Crossplane maintainer and so I, I've never used it personally, but I only hear about it in like a hundred percent cloud native shops.

Chris Short: 00:57:30

‍Yeah. I think that's a fair assessment, Kat. I think a lot of teams that are spinning up cloud native resources are saying, oh, Crossplane’s probably are Terraform here. Yeah. Um, pretty much. But yeah, it's, I, I hear about it at KubeCon. I hear about it at the occasional, you know, customer site, but it's, it's few and far between right now. But yeah, they are trying to like expand their breath outside that Kubernetes world,

Kat Cosgrove: 00:57:55

‍Right? Like, I think it'll, it'll, I think it'll gain traction. I don't think we're gonna see it like disappear and it's entirety, but it is certainly not going to and, uh, as popular as like Terraform,

Chris Short: 00:58:06

‍Right? No, I don't, I don't think it's, it's, yeah. I mean, unless it does some magic trick here soon.

Ohad Maislish: 00:58:12

I fully agree and I think I have a, I have my own explanation of whats, what's happening here. Most of the DevOps engineers, not most, but a lot of the DevOps engineers I talk to say things similar to what Kat reference of something like CDK and, and Pulumi. So they prefer Pulumi over Terraform if it was just about, you know, writing code, writing the infrastructure as code, but then when they're looking at the, uh, overall solution that they need to provide to, to their companies and, uh, we are using also, uh, Auth0, so we need, uh, to work with that. Mm-hmm. And where is the Pulumi provider for Auth0?

Ohad Maislish: 00:59:00

‍I think one of the reasons that Terraform is doing much better than Pulumi, it's not because it's a better framework, but it's more about the ecosystem and the timing. The timing of when Terraform started in great work by HashiCorp, obviously when they started, um, educating the market in that direction, later came Pulumiand later came Crossplane. So I think Crossplane their main, uh, issue is not the technology is the time to time when they enter the market. Why now slide for if you're familiar with investors who's a pitch

Ohad Maislish: 00:59:37

‍Yeah. It's, it's why now? Why start Crossplane now when the Terraform is already, uh, with such strong partnerships with so many, uh, yeah. vendors

Kat Cosgrove: 00:59:48

‍And I, I think you have to consider the, like the applications community to be part of the ecosystem because the, the community around something like Terraform with that maturity is a super valuable resource to your engineers because when they run into a problem, they're gonna run into a problem, right? When they run into a problem with Terraform, that issue is Googleable. Somebody else has run into that problem and somebody else has documented the solution

Ohad Maislish: 01:00:14

‍I think, I think it's way more than Googleable Googleable, uh, it's not, it's not just that. Let's, let's talk for a moment about what Terraform provides with site Terraform the, uh, the framework. So you need to have policy as code boom, OPA, okay? And you have policy as code for Terraform, but not for Pulumi. Crossplane. You need some, uh, uh, static

Kat Cosgrove: 01:00:35

‍Pulumi does have a policy is called code tool, it's called crosswalk. But uh,

Ohad Maislish: 01:00:39

‍Is it just the Pulumi, is it just for the Pulumi service or is it open source? Like open policy agent?

Kat Cosgrove: 01:00:46

‍It is not open source, I think. Okay.

Ohad Maislish: 01:00:48

‍So, so that's, as you mentioned, as you mentioned,

Kat Cosgrove: 01:00:51

‍I don't work there anymore, so I'm not sure.

Ohad Maislish: 01:00:53

‍Open, open Policy agent is the, the defacto start out today for, for policy code and it works very well with, with Terraform. And let's talk about the security and static analysis. You have Checkov, you have Terrascan, you have TFsec, uh, you have Kicks. All of those work very well with Terraform. If you look at cost, uh, you have Infracost that does the uh, cost estimation for, uh, for core request you have Docs, automatic Docs. For, for Terraform you have TF Flint. Uh, you have so many other great things that you can use. Um, and even in env0, we started with support for Terraform. Only later on we added a support for Pulumi and uh, and CloudFormation and others because it makes sense to focus, well, both of the market is, uh, what most of the market is using. So Terraform and its, uh, peripheral tools is super powerful compared to just Crossplane.

Kat Cosgrove: 01:01:56

‍So cross guard, I was, uh, I was initially wrong. Crossguard, um, is Pulumi policies code tool, and it is open source. Um, so, but it looks, uh, looks like they added, um, providers for other cloud providers after I left, cuz it, it now does support things other than AWS.

Ohad Maislish: 01:02:13

‍Oh, awesome, glad, yeah,  glad to hear. But I can assume that open policy agent has much bigger community

Kat Cosgrove: 01:02:19

‍Than, oh, yeah. OPA is almost certainly like way more mature. Way more mature. Um, and also like, I'm just like functionally more familiar with opa, so mm-hmm.That's, that's still like probably what I would use, um, just due to being more, more familiar with it. 

Justin Nemmers: 01:02:38

‍Fantastic. All right. So I'm gonna do one last, it's kind of a question, kind of a comment. Uh, and then we'll go ahead and wrap this up as we are a couple minutes over here. Uh, Diego asks, how do you see the specific services like provision, orchestration, configuration today? I see the Terraform Ansible working together, uh, impossible for only one platform to provide all modern infrastructure services like provisioning, cell healing, continuous compliances, code, uh, and others. So I think that actually summarizes it quite nicely. Uh, any, any kind of party comments on, uh, on that one from the, the panel here?

Chris Short: 01:03:13

‍I think policy is gonna become a big thing this year, right? Like gone are the days where you're allowed to have a S3 bucket that gets kicked over or compromised somehow, right? 

Chris Short: 01:03:27

‍AWS does a proactive job and we're changing the defaults on S3 now in April, I think, to make it so you can't, like the default is not going to be publicly exposed to ever

Chris Short: 01:03:40

‍And that I think is, you know, it's overdue, but it's a hard change to make. Yeah. For as many customers as we have. So addressing that, and then, you know, companies like AWS, IBM, Microsoft, you know, Google, we're gonna have to get a lot better at handing people good policy, right? Yeah. Like, oh, you're using this service, this is the policy we recommend and here's why. Right? Like, we need to develop more materials around that specifically.

Kat Cosgrove: 01:04:12

‍Yeah. I would like to see, um, more, more companies not, not trying to be like a pocket multi-tool, right? Like, because that, like Diego is right there, there isn't like, there, there isn't one tool that is like the best thing at all of these, like very different, very specific things, right? So maybe stop trying to be a multi-tool cause like you're really good at the one thing, but then you're like kind of mediocre to actively not good at all of this other stuff. And then trying to lock people into using like what is in aggregate a subpar solution at that point. So, uh, specialize in what you're good at and, you know, actively collaborate with other tools that fill in the gaps that are really good at provisioning or are really good at policy instead of like trying, trying to force it, you know? Um, and if, if you are a company that is looking into the use of these tools, again, don't, don't try to use a multi-tool just because it's really good at one thing. If it's really bad at all of the other stuff that you need to, like, it's, it's okay to have more than one solution. Sometimes. There, there is a way to smooth out the friction there. You, you really do not having one tool that is, is bad at most of what it does, but hey, it's only one tool that also introduces a ton of problems.

Justin Nemmers: 01:05:39

‍Yeah. This is great. So, I mean, I think that that actually is a great summation because in that little equip, Kat, you, you touched on a lot of points that we talked about today. Uh, how do you get team members up and functional? How do you, uh, effectively collaborate by, by kind of using the right tool for the right job? Um, how do you have a culture of innovation that enables you to, um, to rapidly adopt these new tools and actually do real things with them that are still backed by policy on some level? Uh, all of which are, are certainly, I think we can all agree will become more and more important as, um, as IaC adoption, uh, continues to grow within, within organizations. So with that, uh, I want to thank everyone for joining us today. Um, now this recording will be made available to all of the registrants, so we will be emailing you a link to it. You can download it and then I'm sure we'll do lots of little, uh, clips and snippets from, from here with some nice, uh, some nice points on 'em. But, um, there are some existing questions that we did not get to. I apologize for running out of time on that. However, if, uh, they're ones that do necessitate a direct answer, we'll be more than happy to provide those via email after the fact. Uh, with that, thank you very much. Have a wonderful rest of your day and a special thank you to, to all of our panelists.

‍

How many of you have started with Terraform and discovered you need the same code to build multiple environments? Perhaps a dev, stage, and production environment? After researching Workspaces, Branches, and Terragrunt, you aren’t completely satisfied and want to know if there is another way. If you are here, I’ll assume that’s you!

Workspaces

Workspaces are a native Terraform construct, offering a reduction in duplicate code and methods of configuring environments differently based on the Workspace name. However, there are obstacles in navigating between environments, backend segregation, and versioning between Workspaces.

Not to mention, Hashicorp themselves do not recommend using Workspaces for managing environments:

“Workspaces alone are not a suitable tool for system decomposition, because each subsystem should have its own separate configuration and backend, and will thus have its own distinct set of workspaces.”

Branches

Branches are a native VCS (Version Control System) construct and allow for versioning to be part of your deployment model. A step up from Workspaces, Branches allows you to configure environments using [.code].tfvars[.code] files, configure different backends and configure versions. However, there is a huge duplication of code, and depending on your development strategy; propagating changes can be difficult.

Terragrunt

Terragrunt is a Terraform wrapper that solves many of the native Terraform pain points. Environment segregation is easier by using a standard folder structure and variable files which can differentiate not only the resources being deployed but also the segregation of remote backends. Not to mention, versioning within the environments is also a lot easier than in either the Workspace or Branch model.

That said, this is a new tool that has its own method of operation. This has to be learnt and understood along with Terraform, as Terraform is run under the hood. There is slight code duplication, but nothing as bad as branches.

There is a great article by Gruntwork that we’d recommend reading, that goes into greater detail on the above points.

Easier with env0

We covered three methods of how to manage different environments using Terraform and Terragrunt. While they all work, it can become complex when working in larger teams. Here at env0, we want to empower your team with all the options previously discussed, but make it simple and easy to use and consume.

First, let’s recap the major pain points we are trying to solve:

• How best to segregate environments.
• How best to reuse code without duplication.
• How best to tackle dependencies in code stacks.

Projects

In envzero we have a three-tiered application structure, organization, project, and environment (think workspace). In most cases, our customers will use one organization and name it after the company, and then choose to use multiple projects. An example of project segregation would be dev, pre-production, and production.

This is all well and good, but how does this help with my code? Good question.

Templates

envzero has a concept of a template, which is described as a self-service mechanism. This provides several key benefits both from a coding and reusability perspective.

Let’s take an EC2 instance as an example. When writing code for an EC2 instance, a common number of variables need to be changed per environment or scenario. Imagine a developer who wants to test new application code on an EC2 instance. What do you do? Copy existing EC2 instance code to spin up the instance, or better yet, reference a module to spin up the desired EC2 instance. Let’s make life easier for you, let’s use an envzero template that references your code in your VCS (private or public). Here we can import variables from your code at the click of a button and change them as we prepare the template. We can even make cool changes like adding drop-down menus, for example, sizing.

This allows non-Terraform experts to spin up an EC2 instance, using Terraform code while changing the desired name and instance size through a UI.

This concept of templates allows you to reuse the same code in dev, pre-production, and production while changing a few key variables through a UI (or via code if you prefer). You can also use the same code to spin up multiple instances in a single area (i.e. dev). What’s really useful here is, a change to the template code can trigger a plan or apply to all environments (EC2 instances) using this template. 

envzero takes advantage of Terraform workspaces behind the scenes and helps you easily manage the use of workspaces while giving you the ability to see what is deployed where.

Note: A single template can be the source for more than one environment (EC2 instance).

Furthermore, the power of templates is not subject to small objects, such as EC2 instances. Templates can be used to spin up VPCs or even full infrastructure stacks.

Variables 

The variable importing and editing is a cool feature, but what else can it do? In envzero you can define variables at any level of the application structure. This means you can define a variable in the project to specify the region you want the resources deployed within the environment (workspace). Furthermore, you can mark this as a read-only variable, so users of the template can’t change this variable and even mark it as sensitive should you be adding a project token for example.

During the template run, you will clearly see which variables have been inherited by the template and which have been inherited by the project.

Revisions

I hear what you are saying, that’s all well and good, but what about versions or branches of the same code? Don’t worry, we have you covered. Our templates can pull code from any branch or tag in your VCS. You can update the branch both at a template level or an environmental (workspace) level.

Intrigued yet? Keep going, it gets better.

Workflows or Terragrunt Run-All

The final feature we’ll discuss today is envzero workflows. We see users move from Terraform to Terragrunt (both of which are supported as first-class citizens in env0) to help with the build of IaC stacks. No one wants to run code to deploy a VPC, move to the security folder, run the security code, and so on. We are in full agreement, Terragrunt can help, and this is the reason we not only support Terragrunt code but also the all-important Terragrunt run-all feature.

All this Terragrunt talk is exhausting, so let's see how envzero can help. Whether you are writing in Terraform, Terragrunt, Pulumi (yes, we support Pulumi too) or even creating Kubernetes manifest files, envzero can execute the code in order depending on your dependencies defined in an env.yaml file. I think images paint a thousand words, so below we have our envzero workflow that will execute from left to right, not moving forward until the parent has successfully deployed.

We know, it’s pretty cool, right?!

Conclusion

We started this blog with three issues.

We solved environment segregation using our three-tiered application structure.

We solved code reusability with templates, variables, and revisions.

We solved dependencies using envzero workflow logic.

What next?

We would love to hear what you think, about the approaches here, or even how you tackle your environment management.