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 our last discussion on Pulumi vs. Terraform, we explored the intricate world of Infrastructure-as-Code (IaC) tools, delving into how these technologies streamline the deployment and management of cloud environment resources.

Continuing on this path, today we're comparing two other IaC giants: Terraform and CloudFormation. Both tools have established substantial footholds within their respective areas, becoming the preferred options for developers aiming to automate their cloud infrastructure.

In this post, I’ll compare the tools, discuss their pros and cons, and demonstrate how they can be used with env0, leveraging the platform’s multi-framework support, which makes it compatible with any IaC tool.

What is Terraform?

Terraform, developed by HashiCorp, excels as an IaC tool facilitating the provisioning and management of AWS resources, as well as infrastructure resources across different cloud providers, embodying a cloud-agnostic approach with native support for Google Cloud, AWS Cloud, and more.

Historically speaking, Terraform's open-source roots encouraged a vibrant community contribution, leading to an extensive provider ecosystem that spans beyond cloud providers to include SaaS and PaaS offerings. One of Terraform's unique features is its ability to manage resources declaratively, allowing users to define their infrastructure in code that can be versioned, reused, and shared.

Note: Following the license change in August 2023, all future releases of Terraform will adopt the BUSL license, while all versions prior to 1.5.x will remain open-source.

After the shift, OpenTofu emerged as an open-source alternative to Terraform. Originating from a fork of Terraform as a drop-in replacement for Terraform version 1.6, OpenTofu preserves all of the core functionalities that have endeared Terraform to developers, including the use of all providers and Terraform modules.  As such, all of the points raised about Terraform in this article equally apply to OpenTofu. 

What is AWS CloudFormation?

On the flip side, CloudFormation is Amazon Web Services' (AWS) native IaC service, designed to seamlessly integrate with AWS's vast array of services. 

As a managed service, AWS CloudFormation allows users to define their AWS resources with JSON or YAML templates, automating the provisioning and updating processes. Its deep integration with AWS ensures that users can leverage the full spectrum of AWS features and services with minimal hassle, making it a powerful tool for those heavily invested in the AWS ecosystem.

What are the differences between Terraform and CloudFormation?

To compare Terraform and CloudFormation side-by-side, let's look at several key aspects:

Terraform vs CloudFormation: Pros and Cons

The answer is “it depends,” as each tool has its strengths and weaknesses. Here is the TLDR:

Terraform Pros and Cons

Pros:

• Terraform is renowned for its flexibility and support for multiple cloud providers, offering a consistent syntax and deployment strategy across various environments. While it's true that you can't directly transfer the same codebase from one provider to another, Terraform offers consistent syntax and deployment techniques across different clouds.
  
  For many organizations, this consistency is a major advantage, as it allows for the use of familiar syntax and deployment strategies when managing resources across multiple cloud environments, which is undoubtedly beneficial.

Cons:

• The versatility and multi-cloud capabilities of Terraform, while beneficial, can complicate state management and configuration across diverse environments. Tailoring deployments to suit each provider's unique requirements may raise the risk of errors and demand a comprehensive grasp of each cloud platform's specific characteristics, posing challenges for teams less experienced with multi-cloud strategies. 
  
  In this context, platforms like env0 emerge as invaluable allies, offering targeted support that can streamline and simplify the scaling process for organizations looking to expand their Terraform implementations.

• Furthermore, Terraform relies on providers that connect to the APIs of the cloud vendors. There is usually a delay between when a service or feature is released in the cloud and when it gets supported by the Terraform provider.
  
  This is in contrast to AWS CloudFormation which, being a native AWS service, seamlessly integrates with AWS offerings faster.

CloudFormation Pros and Cons

Pros:

• CloudFormation stands out in AWS-centric environments, providing deep integration and a managed service experience that simplifies the management of AWS resources. Its native design for AWS ensures that users can fully exploit the capabilities of the cloud service, streamlining the deployment process and reducing the overhead typically associated with infrastructure management. The service's direct integration with AWS also means that users can rely on AWS's robust support structure and continuous updates.

Cons:

• The primary limitation of CloudFormation is its exclusive focus on AWS, which can be a significant constraint for organizations with a multi-cloud strategy or those looking to avoid vendor lock-in. Additionally, while CloudFormation simplifies AWS resource management, it may not offer the same level of flexibility or community support as Terraform, potentially limiting its adaptability to complex or highly customized deployment scenarios.

Use Cases

Scenario 1: Multi-Cloud Management

Terraform shines in scenarios where organizations aim to leverage the strengths of multiple cloud platforms, such as AWS, Azure, and Google Cloud. 

By offering a single configuration language (HCL) and workflow, Terraform simplifies the complexity of managing diverse cloud services and infrastructure. This unified approach enables teams to maintain consistency in infrastructure provisioning and management practices across different clouds, reducing the learning curve and operational overhead associated with using distinct tools or interfaces for each cloud provider. 

Furthermore, Terraform's extensive provider ecosystem allows organizations to easily integrate with a wide array of cloud services, APIs, and custom in-house solutions, facilitating a cohesive and flexible infrastructure strategy that can dynamically adapt to changing business requirements and technological landscapes.

Scenario 2: AWS-Specific Projects

For AWS cloud-centric projects, AWS CloudFormation stands out, offering a managed AWS service experience with deep integration and native support for efficiently deploying custom resources within the AWS environment. It leverages AWS's native integration to offer a seamless and optimized experience for defining, deploying, and managing AWS resources. 

With CloudFormation, users can utilize AWS-specific features and services to their fullest potential, taking advantage of AWS's scalability, reliability, and security features without the need for bridging tools or external dependencies. 

This deep integration simplifies the process of configuring complex AWS environments, enabling automatic handling of dependencies between resources, rollbacks on failures, and updates to existing stacks. CloudFormation's template-based configuration, using either JSON or YAML, also ensures that infrastructure as code (IaC) practices can be easily adopted, promoting version control, collaboration, and repeatability in AWS-focused development projects.

Scenario 3: Compliance and Governance

In environments where compliance and governance are critical, Terraform's ability to integrate with policy-as-code tools like Open Policy Agent (OPA) allows organizations to enforce policies and ensure that infrastructure deployments comply with internal and external regulations.

This use case is particularly relevant for enterprises that need to adhere to stringent security standards, audit requirements, and governance policies across their cloud infrastructure, regardless of the cloud provider. 

Terraform's state management and planning features also contribute to a transparent, auditable, and controlled infrastructure management process, making it easier to track changes, review impacts before applying them, and ensure consistency across environments.

A Practical Demo

Let's take a look at a simple demo to show how to create an S3 bucket in AWS using these two tools. We will use env zero for this task, leveraging its multiple-framework support, which makes it compatible with any IaC tool, Terraform, OpenTofu, Cloudformation, Pulumi, etc.

Video Walkthrough

‍Requirements

• A free GitHub account
• Access to an AWS account
• A free env zero account

TLDR: You can find the main repo here

Terraform Demo

Per the video above, let's first start with Terraform.

1. Create an env zero Template for Terraform

Start by creating a template in env zero that connects our GitHub repo. Make sure to select Terraform as the template type and give it a name as shown below:

Now it's time to connect our template with our GitHub repo. The Terraform configuration is in the TerraformS3.tf file and is written in HCL (HashiCorp Configuration Language). You don't need to specify the Terraform folder or branch since TerraformS3.tf is in the main branch at the root of the repo.

No variables are necessary for this deployment, so the final step for the template is to associate it with our project.

Now we're set to establish a new environment. Navigate to the Project Environments tab on the left and proceed to initiate a new environment, choosing the template we've recently crafted. The deployment will commence, allowing you to monitor the logs.

2. Terraform Plan Log

Take a look at terraform plan log in env zero below.

Terraform gives you a dry-run of your plan when you run either [.code]terraform plan[.code] or [.code]terraform apply[.code]. Check out this blog post to learn about Terrform CLI commands and examples.

Terraform Apply Log

Once you confirm that you'd like to proceed, you will see the output below.

4. View the Output in AWS

In the AWS console, we can now see the resulting S3 bucket with all the options that we requested.

Notice how bucket versioning is enabled along with a tag that shows we built this with Terraform.

Next, you can see the permissions and how we block public access to this S3 bucket.

Finally, you can see the lifecycle of this S3 bucket.

5. Destroy the S3 Bucket with Terraform

Once you're done examining this S3 bucket, you can destroy it by clicking the red destroy button in env zero inside the environment.

The Terraform plan log will show you what is about to be destroyed.

Finally, the Terraform Destroy log will show you that the resources were destroyed.

AWS CloudFormation Demo

Let's move on to our second demo to build the same S3 bucket using AWS CloudFormation.‍

1. Create an env zero Template for CloudFormation

We need to create a Template in env zero similar to the template we created for Terraform, except now we select CloudFormation as our template type, as shown below.

Next, we need to select the same GitHub repo as we did for Terraform. Please note that you need to specify the AWS CloudFormation template file name – in our case, CloudFormationS3.yaml.

Next, add the AWS region as a variable and add this template to either all your projects or the one you created for this demo called: Terraform vs CloudFormation.

We are now ready to create a new environment. From the Project Environments tab on the left, go ahead and create a new environment and select the template we just created. The deployment will start running and observing the logs.

2. CloudFormation Describe Change Set

The first log I captured for you is the one showing what will change, similar to the Terraform plan we saw before. You can see it below.

Cloudformation parameters: {}
> awsv2 cloudformation deploy --stack-name tf-vs-cloudformation --template-file CloudFormationS3.yaml --no-execute-changeset $ENV0_CF_CLI_ARGS_deploy

Waiting for changeset to be created..

Changeset created successfully. Run the following command to review changes:
aws cloudformation describe-change-set --change-set-name arn:aws:cloudformation:us-east-1:706933696988:changeSet/awscli-cloudformation-package-deploy-1707149843/fa8066ab-00ae-4004-af27-419c6eddd1c0

> awsv2 cloudformation describe-change-set --change-set-name arn:aws:cloudformation:us-east-1:706933696988:changeSet/awscli-cloudformation-package-deploy-1707149843/fa8066ab-00ae-4004-af27-419c6eddd1c0
{
    "Changes": [
        {
            "Type": "Resource",
            "ResourceChange": {
                "Action": "Add",
                "LogicalResourceId": "DemoStorage",
                "ResourceType": "AWS::S3::Bucket",
                "Scope": [],
                "Details": []
            }
        }
    ],
    "ChangeSetName": "awscli-cloudformation-package-deploy-1707149843",
    "ChangeSetId": "arn:aws:cloudformation:us-east-1:706933696988:changeSet/awscli-cloudformation-package-deploy-1707149843/fa8066ab-00ae-4004-af27-419c6eddd1c0",
    "StackId": "arn:aws:cloudformation:us-east-1:706933696988:stack/tf-vs-cloudformation/0b641ca0-c442-11ee-8712-12bde5a0d6ff",
    "StackName": "tf-vs-cloudformation",
    "Description": "Created by AWS CLI at 2024-02-05T16:17:23.098906 UTC",
    "Parameters": null,
    "CreationTime": "2024-02-05T16:17:23.382000+00:00",
    "ExecutionStatus": "AVAILABLE",
    "Status": "CREATE_COMPLETE",
    "StatusReason": null,
    "NotificationARNs": [],
    "RollbackConfiguration": {},
    "Capabilities": [],
    "Tags": null,
    "ParentChangeSetId": null,
    "IncludeNestedStacks": false,
    "RootChangeSetId": null
}

Once you've gone through this, you can now accept the changes to move on to the next stage.

3. CloudFormation Deploy

The second log to pay attention to is the actual deployment. Below is what it will look like.

Cloudformation parameters: {}
> awsv2 cloudformation deploy --stack-name tf-vs-cloudformation --template-file CloudFormationS3.yaml $ENV0_CF_CLI_ARGS_deploy

Waiting for changeset to be created..

Waiting for stack create/update to complete

Successfully created/updated stack - tf-vs-cloudformation

The S3 bucket is created similarly to what happened with Terraform. CloudFormation adds some tags to the bucket, as shown in the AWS console Tags section:

Below is a screenshot of the events from the AWS console for the CloudFormation stack:

Finally, you can view the S3 bucket resource created:

4. Destroy the CloudFormation Stack

To destroy the CloudFormation stack, simply click the red Destroy button in env zero inside the environment you would like to destroy.

CloudFormation List Stack Resources

You will see env zero run the following command:

> awsv2 cloudformation list-stack-resources --stack-name env0e0d312 $ENV0_CF_CLI_ARGS_list_stack_resources
{
    "StackResourceSummaries": [
        {
            "LogicalResourceId": "DemoStorage",
            "PhysicalResourceId": "env0-demo-cloudformation-storage",
            "ResourceType": "AWS::S3::Bucket",
            "LastUpdatedTimestamp": "2024-02-05T16:48:33.037000+00:00",
            "ResourceStatus": "CREATE_COMPLETE",
            "DriftInformation": {
                "StackResourceDriftStatus": "NOT_CHECKED"
            }
        }
    ]
}

CloudFormation Delete Stack

Finally, env zero will delete the stack.

> awsv2 cloudformation delete-stack --stack-name env0e0d312 $ENV0_CF_CLI_ARGS_delete_stack
> awsv2 cloudformation wait stack-delete-complete --stack-name env0e0d312

Conclusion

Choosing between Terraform and CloudFormation depends largely on your specific needs and cloud strategy. If your environment spans across multiple cloud providers, Terraform offers the flexibility and ecosystem to support your projects. Conversely, for AWS-centric deployments, CloudFormation's native integration and managed service benefits are hard to beat.

At env0, we understand that different teams have different preferences and requirements. That's why the platform is designed to support all IaC frameworks – including both Terraform and CloudFormation, giving you the flexibility to choose the right tool for the job without compromising on functionality or efficiency. 

Whether you're leaning towards the open-source community of Terraform or the AWS-native capabilities of CloudFormation, env zero facilitates a collaborative and efficient infrastructure management process across your organization.

Frequently Asked Questions

Q: Can Terraform and CloudFormation be used together?

Yes. Although they serve similar purposes, some organizations use both to leverage Terraform's multi-cloud capabilities and CloudFormation's deep AWS integration.

Q: Is Terraform more difficult to learn than CloudFormation?

The learning curve for each tool depends on the user's background. Terraform's HCL is intuitive for those with coding experience, while CloudFormation's template-based approach may be simpler for users familiar with JSON or YAML.

Q: How do Terraform and CloudFormation handle state management?

Terraform maintains state files to keep track of resource deployment, while CloudFormation relies on AWS to manage the entire infrastructure and the state of resources.

Q: Are there any costs associated with using Terraform?

While Terraform itself is free, users may incur costs from the cloud resources provisioned through Terraform. Additionally, third-party state backends or enhanced security features may involve extra costs.

Q: How does CloudFormation integrate with other AWS services?

CloudFormation integrates natively with almost all AWS services, allowing users to define a wide range of AWS resources and configurations within its templates.

‍

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.

‍

For any infrastructure or cloud service deployment, organizations need a way to make the entire deployment process repeatable. Not just for automation purposes, but to create a true standard that teams can use to be more efficient and keep multiple services running as expected.

In this blog post, you’ll learn how to combine AWS CloudFormation and envzero to create a production-driven experience for AWS Elastic Container Service Amazon ECS.

Why CloudFormation and Infrastructure as Code instead of ClickOps?

Let’s say you want to deploy a new service in AWS using ECS. What are the steps?

First, you’d have to log into the AWS console, then, you’d need to search for the right AWS service. Next, you’d go through three to four pages of the UI clicking drop downs and entering information to define your configuration. Finally, the ECS cluster will begin to deploy.

In short, without IaC, it’s a manual and cumbersome process. There’s no way to set a standard around it because even though it’s the same screen/UI that every engineer will see, there’s no way to determine that the same configuration is entered into the UI by each engineer. For example, one engineer might add one VPC and another might accidentally add a completely different VPC. There's no control to automate the process and make it repeatable for each team within the UI.

That’s where IaC, and in this example, CloudFormation comes into play.

CloudFormation is an Infrastructure as Code (IaC) tool designed to allow engineers to create AWS services as code. Instead of clicking around a UI, developers can define the individual services they’re using in a CloudFormation template called a stack (configured in a JSON or YAML file), upload the configuration to source control (like GitHub), and share it across teams. Using the AWS Command Line Interface (AWS CLI) to create AWS resources using Cloudformation stacks enables better collaboration, scale, and more secure deployments because developers in an organization can work together to create standardized practices. Platform Engineering (or DevOps, if you’d prefer)  teams are then able to turn their existing AWS environments into scalable, repeatable offerings to the business units they support.

What’s ECS?

Amazon Elastic Container Service (AWS ECS) is a fully managed container orchestration service. It allows you to run and manage Docker containers on a cluster of Amazon Elastic Compute Cloud (Amazon EC2) instances. With ECS, you can deploy and manage your containerized applications easily, without the need to manage the underlying infrastructure.

Amazon ECS runs as a service in AWS cloud and is AWS specific. It allows you to deploy a container from a container image and run it with full scalability and scheduling capabilities. You can either run Amazon ECS with an AWS Fargate profile (no EC2 instance backend) or with Amazon EC2 instances running as the Amazon ECS backend.

Although Kubernetes is a great orchestration platform—and to be honest, it’s the most popular right now which means more support options and more tooling options—it’s not the only orchestration platform out there to manage your containerized workloads.

Amazon ECS is what some engineers like to call “Kubernetes lite.” It has all of the orchestration, scheduling, and scalability features that Kubernetes has for containers. It just doesn’t have as many customizable features, which is sometimes good for organizations. Especially if they have limited resources, or a relatively small set of requirements for their containerized applications.

‍

Now that you have some theory behind AWS CloudFormation and Amazon ECS, let’s jump into the hands-on piece of this blog post.

Prerequisites

To follow along, you will need the following:

• An envzero account (free trial signup)
• A source control repo such as GitHub to store the code in for deployment purposes (demo repo)
• An AWS account (you can sign up for a free trial/tier here)

Before deploying the AWS CloudFormation code to create an ECS cluster, you’ll first need to authenticate to AWS via env0.

First, ensure that you either have:

• An AWS Assume role - docs
• AWS access/secret keys - docs

These are the two options available to authenticate envzero to deploy AWS Services.

For the purposes of this blog post, you’ll learn how to utilize the “AWS access/secret keys” method.

Log into the AWS portal, choose a user that has appropriate access, and generate an access/secret key underneath Security credentials.

Next, log into envzero and under Project Settings, click on CREDENTIALS and choose the AWS option.

Click the green + Add Credential button.

Under the Add New Cloud Credential page, give your credential a name (this is anything you want it to be). Then, add in your access key and secret key.

You’ll now see your credential as an option.

Click the green Save button.

The AWS CloudFormation code

Now that the AWS credential is added, you can start thinking about the code that you want to deploy with env0.

Before showcasing the CloudFormation all together, let’s break down our example.

First, you have the resource that you’re creating.

AWSTemplateFormatVersion: “2010-09-09”
Resources:
   Cluster:
       Type: AWS::ECS::Cluster

Next, you have the resource properties for the cluster name.

Properties:
   ClusterName: ecsclusternv0

After you define the key properties, you can set up the log group.

LogGroup:
   Type: AWS::Logs::LogGroup
   Properties:
       LogGroupName: ecs-log-group

The last step is to configure the IAM role and policies needed to run ECS.

ExecutionRole:
    Type: AWS::IAM::Role
    Properties:
        RoleName: ecs-deployment-role
        AssumeRolePolicyDocument:
            Statement:
                - Effect: Allow
                  Principal:
                    Service: ecs-tasks.amazonaws.com
                  Action: sts:AssumeRole
        ManagedPolicyArns:
            - arn:aws:iam:aws:policy/service-role/AmazonECSTaskExecutionRolePolicy

All together, the code looks like the below.

AWSTemplateFormatVersion: “2010-09-09”
Resources:
 Cluster:
   Type: AWS::ECS::Cluster
   Properties:
     ClusterName: ecsclusternv0
 LogGroup:
   Type: AWS::Logs::LogGroup
   Properties:
     LogGroupName: ecs-log-group
 ExecutionRole:
   Type: AWS::IAM::Role
   Properties:
      RoleName: ecs-deployment-role
      AssumeRolePolicyDocument:
        Statement:
          - Effect: Allow
            Principal:
              Service: ecs-tasks.amazonaws.com
            Action: sts:AssumeRole
      ManagedPolicyArns:
        - arn:aws:iam:aws:policy/service-role/AmazonECSTaskExecutionRolePolicy

Ensure you save the code to your Git repo that’ll be used for the deployment with env0.

Deploy AWS ECS Resources with CloudFormation and env0

Now that the code is defined, you can deploy it via env0.

First, create a new environment.

Next, choose the VCS option to specify a source control path. (This convenient option allows you to spin up a new resource on demand simply by referring to infrastructure code you've already written, instead of creating a new template.)

Ensure that you choose CloudFormation as the VCS environment.

Add in your Git repo and where the CloudFormation template exists.

When specifying the CloudFormation template file, ensure that you add the `capabilities` flag. The reason is that you have to explicitly tell CloudFormation that you are OK with create the new permissions.

Give your new AWS environment a name.

As in the screenshot below, you should see that the CloudFormation stack has started.

If you have an approval workflow, inspect the details in the CloudFormation Describe Change Set output, then approve the stack creation.

Once complete, you should see that the stack has been successfully deployed and the Amazon ECS cluster is now created.

Deploy AWS ECS With CloudFormation and env0. Back in the AWS console, we can see the instances have been deployed. now we’re ready to deploy infrastructure and applications into our ECS cluster.

For more information check out this blog where we compareTerraform vs Cloudformation and show how they can be used with envzero platform.

CloudFormation drift detection is one of the most practical guardrails you can use to catch unmanaged infrastructure changes in AWS. In real environments, it's common for resources to be modified outside of CloudFormation, whether through console changes, CLI/API updates, or automation that runs independently from your stacks. This process is crucial for maintaining infrastructure consistency and preventing configuration drift in your infrastructure as code (IaC) deployments.

AWS defines drift as a mismatch between the expected configuration in your CloudFormation template and the actual configuration of deployed resources. When at least one resource in a stack is out of sync, CloudFormation treats the entire stack as drifted too. That gap between declared and real state is what teams typically refer to as cloudformation drift or stack drift.

This matters because unmanaged drift can introduce reliability risk, break repeatable deployments, and create gaps between what teams believe they have deployed and what is actually running in AWS. Effective infrastructure management relies on accurate resource tracking and maintaining resource compliance.

In this guide, we'll break down how cloud formation drift detection works, what it can and cannot detect, and how to operationalize it so it becomes part of your day-to-day infrastructure workflow.

The Basics of CloudFormation Drift Detection

At a high level, aws cloud formation drift detection compares your deployed AWS resources against the properties defined in your CloudFormation template. This drift detection process involves a comprehensive scan of your stack resources to identify any discrepancies.

A drift detection scan can report the following resource drift statuses:

• IN_SYNC: the resource matches the template configuration
• DRIFTED: one or more properties differ from what the template defines
• DELETED: the resource no longer exists
• NOT_CHECKED: CloudFormation did not evaluate drift for that resource (often because the resource type is unsupported)

When CloudFormation detects drift at the property level, it can also describe the type of change using these property difference values:

• ADD: a property exists in the actual configuration but not in the template
• REMOVE: a property exists in the template but not in the actual configuration
• NOT_EQUAL: the property exists in both places but has different values

Image source: AWS Docs

What CloudFormation drift detection actually compares

A critical detail: while drift detection primarily focuses on properties defined in your template, it can also detect additional properties that have been added manually to CloudFormation resources.

That means:

• If you rely on AWS defaults and don't declare them in the template, drift detection typically won't flag differences for those values.
• If you want a property to be drift-aware, you should explicitly define it in the template (even if you're matching the default).

When drift detection can run

Drift detection can only be performed when the stack is in a stable state (for example: CREATE_COMPLETE, UPDATE_COMPLETE, UPDATE_ROLLBACK_COMPLETE, and UPDATE_ROLLBACK_FAILED). If a stack is mid-operation, drift detection is not available. This limitation ensures that the drift detection operation doesn't interfere with ongoing stack updates.

Where results can be confusing (real-world edge cases)

Even when drift detection is supported, there are scenarios where results may be incomplete or misleading, for example:

• resources that have dependencies across stacks
• properties that CloudFormation cannot reliably read back from the live resource state
• properties whose values are functionally equivalent but represented differently (causing noise)

This is why teams often treat AWS drift detection as a signal that triggers investigation, not an automatic drift remediation mechanism by itself.

Common Causes of CloudFormation Drift in AWS

Cloudformation drift rarely happens because teams don't care. It happens because production systems move quickly and changes happen under pressure. Infrastructure drift can occur for various reasons, impacting overall infrastructure consistency.

Here are common causes of drift that show up across AWS environments:

1) Console changes during incident response

Someone tweaks a security group rule, modifies an IAM policy, or changes an ALB listener to stop an outage. The fix works, but the template is now behind, creating a discrepancy in resource configuration.

2) Automation that bypasses CloudFormation

A script or pipeline updates AWS resources directly through the individual service APIs (e.g., EC2 or S3). The stack still exists, but the live state no longer matches the declared state in the infrastructure as code template.

3) "Temporary" changes that become permanent

Teams sometimes treat resources as temporary, especially in dev or staging, then the environment sticks around long enough to accumulate unmanaged changes, leading to significant configuration drift over time.

4) Cross-service changes and integrations

Even when CloudFormation created the resource, other services can update properties later, depending on the resource type and integrations in use. This can lead to unexpected changes in resource properties.

Tools and Services for AWS Drift Detection (Beyond the Console)

CloudFormation drift detection is the baseline, but most teams need more than "run it once and look at the results." Here are common ways to operationalize aws drift detection so it fits into modern workflows.

Amazon EventBridge (for event-driven workflows)

CloudFormation emits events related to stack operations and drift detection activity. EventBridge rules can route those events to targets such as:

• SNS for notifications
• AWS Lambda function for automated workflows
• SQS for buffering and processing

This is useful when you want drift detection to plug into a broader automation and alerting model.

AWS Config (for compliance-oriented tracking)

AWS Config includes a managed rule called:

cloudformation-stack-drift-detection-check

This is a strong option if you want drift to show up in compliance dashboards and reporting. It's also useful for organizations that need structured evidence of configuration monitoring and resource compliance.

Amazon CloudWatch + SNS (for notifications and visibility)

Amazon CloudWatch does not detect drift by itself, but it is commonly used as the monitoring and alerting layer in workflows that react to drift detection results or related stack events. It can be particularly useful for tracking the drift status of critical resources.

CloudFormation StackSets (for multi-account drift detection)

If you manage infrastructure across accounts and regions, StackSets can run drift detection across stack instances. This is often the most practical way to run aws cloud formation drift detection at scale in multi-account AWS environments.

Best Practices for CloudFormation Drift Detection

Here are best practices that hold up in production environments and scale across teams, ensuring effective infrastructure management and maintaining infrastructure consistency.

Run drift detection on a schedule

A practical approach looks like this:

• production: daily or multiple times per week
• staging: weekly
• dev/test: weekly or monthly

The exact cadence depends on change frequency and how strict your governance needs to be. Regular drift detection scans help maintain ongoing resource compliance.

Run drift detection before high-impact stack operations

If you're about to run a risky update, drift detection can reduce surprises by showing where the stack has diverged from what CloudFormation expects. This practice can prevent unexpected issues during stack updates.

Treat drift as a workflow problem, not only a technical problem

The strongest drift prevention strategy is process-based:

• keep infrastructure changes flowing through IaC
• restrict direct console changes in sensitive environments
• require template updates when changes must be made urgently

Make permissions explicit

At minimum, users and automation that run drift detection will need permissions such as:

• cloudformation:DetectStackDrift
• cloudformation:DetectStackResourceDrift
• cloudformation:DescribeStackDriftDetectionStatus
• cloudformation:DescribeStackResourceDrifts

Exact needs depend on how you run detection and where you store results. Proper permissions management is crucial for maintaining secure drift detection processes.

Limitations of AWS CloudFormation Drift Detection

Even when you implement cloud formation drift detection, it's important to be clear about limitations so teams don't overestimate coverage.

Not every resource type is supported

Unsupported resources are typically returned as NOT_CHECKED, which can create blind spots in your drift detection tool.

Drift detection coverage is property-based

CloudFormation only checks drift for properties it can evaluate and that are explicitly defined in the template. This means some aspects of resource configuration may not be covered.

Nested stacks require extra attention

Nested stacks can add operational complexity. Fortunately, initiating drift detection on a root stack now automatically includes all nested stacks in the check.

Drift detection is detection, not remediation

CloudFormation will tell you something changed. It will not automatically revert those changes or reconcile your template and live state for you. To resolve drift, you can either manually revert the change or use the Resource Import feature to update your template to match the current state.

Conclusion

CloudFormation drift detection is one of the fastest ways to identify unmanaged infrastructure changes across AWS environments. It gives teams a practical signal when reality diverges from what the stack template declares, which is exactly how cloudformation drift becomes an operational problem.

For most organizations, the best results come from treating drift detection as a repeatable workflow: run it regularly, monitor results, and ensure every intentional change is reflected in IaC. This approach helps maintain infrastructure consistency and prevents long-term configuration drift issues.

Drift Detection and Remediation with env zero

CloudFormation drift detection is a solid way to identify drift in AWS stacks, but drift management typically also includes analysis, prevention, and drift remediation workflows across IaC and cloud resources. For a broader reference on drift detection and remediation practices, see env zero's guide: https://www.envzero.com/blog/the-ultimate-guide-to-terraform-drift-detection-how-to-detect-prevent-and-remediate-infrastructure-drift

‍

Introduction

One of the growing challenges in DevOps and cloud adoption is the inevitable toolchain sprawl. The variety of projects and tools available to help us manage and deploy better software faster leads to complexity. That complexity becomes a bottleneck which slows down delivery.

So the question is, how do we simplify our toolchain and manage resources more efficiently?

Enter env0, with support for multiple infrastructure as code frameworks such as Terraform, CloudFormation, Kubernetes, Terragrunt, and Pulumi. Whichever framework you’ve adopted, we help you automate, govern, and manage the entire stack.

CloudFormation is here!

We’re excited to announce the release of CloudFormation support in env0.

With AWS having the lion’s share of the cloud provider market, it’s no surprise that AWS CloudFormation is one of the most commonly used infrastructure as code frameworks.

CloudFormation allows you to provision and manage AWS resources like EC2, EBS, SNS, and ELB through code. With CloudFormation, your stack and its dependencies are managed in a single template file.

We see that many of our customers use multiple IaC frameworks, such as Terraform, Terragrunt, and Pulumi. Especially in complex enterprise environments, different teams can have different needs which are best served by a different IaC framework. As the platform to manage your entire infrastructure as code, it was a simple choice for us to support CloudFormation.

Instead of using multiple tools to manage the different frameworks in your cloud environment, envzero makes it easy to automate and govern your whole infrastructure. We can now mix and match Terraform, CloudFormation, and the different cloud providers. 

For example, we can use Terraform to provision resources in GCP or Azure, with CloudFormation managing AWS infrastructure.

This makes all the features we need to automate and manage infrastructure at scale available to your CloudFormation deployments:

1. Approval flow and RBAC
2. PR Plan and continuous deployment
3. Drift detection
4. Scheduling and TTL
5. Cost monitoring

How to use CloudFormation in env0

How to use CloudFormation in envzero using a template

When creating a new template in env0, select the CloudFormation template type.

It’s just as easy setting up your CloudFormation templates as it is adding your Terraform modules or Kubernetes yaml.

How to run CloudFormation envzero without a template

To use CloudFormation 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 CloudFormation type:

In step 2, choose your VCS, select the repository, branch, and define the path to your CloudFormation folder and template file name:

In step 3, define the ‌variables. When creating an environment directly from the VCS, variables in envzero are inherited from the Organization and Project layers. This allows us to reuse common variables, such as VPC IDs and API keys, securely: 

Finally, name your environment and enable your desired envzero features. For example, “Run CloudFormation Change Set on Pull Requests” will comment the results back to your pull requests, and continuously update the summary as changes are committed.

Deselect “Approve plan automatically” to implement an approval step in between merge and deploy to satisfy governance and compliance requirements:

Conclusion

We often find multiple infrastructure as code frameworks when dealing with complex environments. Whether primarily just using CloudFormation, or using it alongside Terraform or Kubernetes, this release makes it easy to automate, orchestrate, and govern the entire infrastructure stack. Instead of relying on manual deployments in AWS, we can define all infrastructure as code, and even combine different frameworks to manage dependencies between resources.

It would be great to get your feedback on this implementation of CloudFormation support, so give it a test and get in touch with your thoughts!

Also, for more information check out this blog where we compareTerraform vs Cloudformation and show how they can be used with envzero platform.