Terraform Cloud Alternative: A Difference of Opinion

At this point, if you’re familiar with Infrastructure as Code, you surely know what Terraform is. If you’ve used Terraform CLI and tried to manage it at scale, you’ve probably heard of Terraform Cloud. If you’re reading this, you may or may not have heard of env0 before. Today we’re going to go over some of the differences between the two offerings, and highlight some of the key value adds env0 can bring to your Infrastructure as Code workflows.

Beyond CI/CD - Infrastructure Provider Platform Differences

Terraform Cloud/Terraform Enterprise and env0 are both automation platforms that go beyond CI/CD for provisioning infrastructure.

Let’s start with the biggest difference. Because it is a Hashicorp platform, Terraform Cloud only provides native first-class support for Terraform runs.

We believe that developers should be free to use the Infrastructure as Code tool that best suits their needs.

So whether you're using Terraform, Terragrunt, Cloudformation, Pulumi, Kubernetes, ARM, or any other tool, we've built env0 to natively support your infrastructure tool of choice and automate and provisioning of deployments. In our near future we expect to also add support for Serverless and helm charts.

Furthermore, Custom Flows allows you the extensibility to customize the platform for your specific deployment, which we will cover in more detail in the Intergrations/Interoperability section.

env0 uses a hierarchy of Organization > Project > Environment (actual workspace deployment ) . We are not focused on the Workspace construct. This allows you to be dynamic and flexible with your Role Based Access Control (RBAC) privileges, cloud credentials and policies.This way you are not stuck associating these two constructs with just a single workspace or even just the entire organization.

Also, we understand users would like to deploy the same Infrastructure as Code stack for different environments, for example, I want to create a production and development application, for that in terraform cloud you’ll need to configure the same repository, folder and variables, in env0, you can create a “Template” which is Infrastructure as Code configuration, and you can deploy it multiple times and override some of the configuration for the specific deployment, such as revision or variables - This essentially allows you to create a self-service “catalogue” for your deployment applications

A benefit of this approach is that once the templates are set up, human intervention (aka opening up a ticket or asking the DevOps team) is no longer required to provision cloud resources, yet, you can still require approval for new deployments or limit number of environment per user.

Additionally, you can define variables for each hierarchy - Organization, Project, Template and Environment. Those variables can be either free text or drop-down variables, with additional settings such as regex validation. this enables you to DRY your configuration, instead of specifying the same variable for each environment, you can do it once for your entire project or template. Unlike Terraform Cloud which does not have the ability to set variables outside of the Workspace scope and does not have the easy ability to clone or copy variables to other Workspaces.

Furthermore, in env0 you can dynamically load all terraform variables from your code, so you won’t miss any of them.

Because of the way we create templates, we can work with a multi-repository, or a mono-repository strategy, with no editing or restructuring of code.

Both Terraform Cloud and env0 have deep integrations with some of the leading Version Control Systems - Github, GitLab, Bitbucket and Azure DevOps. and their on prem versions. We can also both provide benefits such as Delivery on Continuous Deployment and Plan on Pull Request for these systems.

‍

Infrastructure Automation Extensibility through Integrations and Interoperability

But, this is roughly where the integration similarities end.

Here at env0, we know that your deployments are much complex than running “terraform apply”. 

After deployment, the next step in the infrastructure development process is to install and configure your application. Or, maybe you want to do some security or policy compliance checks before the actual deployment.

This is where our Custom Flows feature comes in. Custom Flows allows you script pretty much anything you want, into any part of the deployment process that you want. It works by simply by including an ‘env0.yaml’ file in your repository.

• Do you want to use Checkov by Bridgecrew to scan for misconfigurations before they’re deployed?
• How about running Ansible (or Chef, Puppet, etc.) on the infrastructure you just deployed to configure your application?
• Or even build your frontend before upload it to S3?

All of this is possible using Custom Flows. We have a robust runtime environment that has a ton of tools natively built-in, but you can also Pip install or curl|bash anything else you need, and execute it at any step.

The extensibility is endless. For more information on Custom Flows, check out the documentation here.

Provision Infrastructure using Cloud services credentials

One key difference that has made a huge difference for the env0 users is the ability to utilize the AWS Assumed Role functionality.

This way, you do not have to provide a static set of AWS Access Key and Secret Access Key pairs. AWS Assumed Role will dynamically create credentials as they are needed.

(For users on Google Cloud, the equivalent is a Service Account. For users on Azure, the equivalent Service Principal)

Self-service infrastructure provisioning

Properly enabling developer self-service isn’t simply giving people the ability to deploy whatever they want whenever they want.

It is about enabling the ability to deploy, while also staying within the guardrails set forth by the DevOps or infrastructure engineers.

Making sure you are enabling agility, without sacrificing control, can be difficult.

env0 helps you achieve this balance with features such as Time To Live (TTL), environment scheduling and limiting the number of environments per developer / project. This ensures that environments which may no longer be needed are destroyed to save on cloud costs. Environment scheduling enables a cron-syntax for deploy and destroy processes so that you specify the exact times in which your environments will be available. For example, only during business hours Monday — Friday, and by limiting the number of environments per user you can make sure they won’t spam your cloud.

How do you manage cloud costs? Cost estimation vs Cost monitoring

This is a very big differentiator between env0 and Terraform Cloud.

Both platforms offer Cost Estimation so that when you run a plan, you can have a rough estimation of how much the deployment will cost you. This is important for DevOps Engineers, Managers, and Infrastructure teams who are mindful of cloud costs when approving deployments.

However, if you’re trying to keep track of the cloud spend for your projects, wouldn’t you rather know the exact cost based on your cloud bill, rather than just a guess?

Terraform Cloud is only able to estimate your cost. Note that this is just an estimate; some resources don’t have cost information available or have unpredictable usage-based pricing. Supported resources are listed in this document’s sub-pages.

Cost Estimation alone is good enough if you are just using constructs such as VM’s that do not vary in costs.

But especially in a production environment, you probably use fewer VM’s now and are using cloud computing resources such as Auto Scaling Groups, Kubernetes Clusters, Lambda/Serverless, or RDS/BigQuery. These are consumption based and you cannot estimate their cost.

The solution is to implement tagging and actual cost monitoring in order to make smart IT decisions.

The env0 platform is doing something very unique for cost monitoring. We created and open-sourced Terratag. This process runs during the deployment process, and recursively checks all of your Infrastructure as Code files for taggable resources. This is important to note because not all resources are taggable.

Once we do this, we can then use read-only credentials to your cloud provider and show you the actual cost over time, correlated to deployments. Not just a guess. The actual cost on your bill.

Granular Role Based Access Controls for Enterprise Security and Compliance Guardrails  

Following the Principle of Least Privilege, it's important to offer different access levels depending on the user or service.

This is a pretty big feature that is part of the free tier with env0, but is a paid feature with Terraform Cloud Teams and Governance.

You can manage users with Role Based Access Controls (RBAC) either individually or in Teams. Free.

This is one of the most basic use-cases for customers that are looking for a platform to manage IaC deployments, so we felt it necessary to have it available to all users, free or paid.

Policy-as-code using Open Policy Agent (OPA)

Next is Governance and Compliance guardrails through policy enforcement.

Terraform Cloud offers Sentinel as their primary policy enforcement, and has only recently announced support for industry-leading Open Policy Agent (OPA). Sentinel is a policy-as-code tool, and is also locked into Terraform Cloud. This means if you leave Terraform Cloud, you can’t take your Sentinel policies with you, and it is also only available in the paid tiers of the product.

env0 gives you the ability to use whatever policy tool you like using our Custom Flows, even in the free tier. Most of our customers are using OPA to create policies, run automated tests, and enforce policy checks to prevent unapproved configurations before they start.

And with our new plugins feature you can deep integrate other tools to your deployment process. This is an example of the  Open Policy Agent plugin.

‍

‍

SaaS and Self-Hosted Agent --- Hybrid deployment model

Both env0 and Terraform Cloud Business offer the ability to operate in a hybrid cloud model. So you can have infrastructure as code automation, integration, and continuous delivery whether you're in public or private clouds.

This means that there is a SaaS front-end, and a self-hosted agent on the back-end for on-premises infrastructure. This allows the customer to keep their secrets and source code secured in their cloud account, as opposed to the SaaS platform.

Of course, both of our offerings have SOC 2 Type II reports available to validate that we are doing everything we can to keep that data secure if the customer chooses to go with the SaaS platform.

Unlimited Concurrent Runs

Concurrency is important for terraform runs. Your team of developers want to collaborate on their terraform infrastructure in real time. Terraform Cloud customers are limited to one concurrent Terraform run unless they upgrade to the "Team & Governance" or Business plan. We know how important this is for organizations as they scale their terraform infrastructure practices, so we've made unlimited concurrent runs free for all env0 users.

To learn more about the advantages of migrating from Terraform Cloud to env0, check out our Terraform Cloud Alternative page.