Apr 26, 2021
env0 and Terraform Cloud: A Difference of Opinion
We are delighted to sponsor Microsoft Build
Learn More
At this point, if you’re familiar with Infrastructure as Code, you surely know what Terraform is. If you’ve used Terraform 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.
Let’s start with one of the biggest differences. env0 is not tied down to just Terraform. Obviously, because it is a Hashicorp platform, Terraform Cloud only supports Terraform. We at env0 have taken a neutral stance toward Infrastructure as Code frameworks. We know that customers may be using other frameworks like Pulumi, Terragrunt, ARM, or CloudFormation, so we have the ability to support all of these frameworks. Natively, we support Terraform and Terragrunt right now, but with the power of our Custom Flows, you can use any framework you like. We’ll talk more about the Custom Flows in the Integrations/Interoperability section.
Because env0 takes a framework-neutral approach, enabling you to choose which IaC framework you want to use, we are not inherently bound by Terraform constructs. env0 uses a hierarchy of Organization > Project > Environment (actual deployments) and is not focused primarily on the Workspace construct. This allows you to be dynamic and flexible with your RBAC privileges and the way you assign your cloud credentials. This way you are not stuck associating these two constructs with just a single workspace or even just the entire organization. We also have a 4-tier scope for our Variables. You can create either free-text or drop-down variables at the Organization, Template, Project, and even individual environment level. This enables you to not have to copy and paste variables that are needed across multiple projects or environments. Terraform Cloud 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.
env0 utilizes the Template construct to create your environment deployments. This essentially allows you to create a “catalog” of your apps to use for deployment. 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, etc. We can also both provide things like Continuous Deployment and Plan on Pull Request for these systems.
But, this is roughly where the integration similarities end. Here at env0, we know that your deployments don’t end after the Infrastructure is deployed. Then you have to install and configure your application. Or, maybe you want to do some security configuration checks before the actual deployment. This is where our Custom Flows feature comes in. This allows you to create a file inside your repository called ‘env0.yml’ in which you can script pretty much anything you want, into any part of the deployment process that you want. Do you want to use Checkov by Bridgecrew to check for misconfigurations before they’re deployed? Or how about running Chef / Puppet / Ansible on the infrastructure you just deployed to configure your application. 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 almost endless. For more information on Custom Flows, check out the documentation here.
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.
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), and environment scheduling. This way, you can ensure that environments that may no longer be needed are destroyed to save budgetary waste. 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.
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 trying to make informed decisions when approving deployments.
Though, if you’re trying to keep track of the budget 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. It’s important to note that usage-based resources are not included in this according to their documentation:
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 you probably use fewer VM’s now and are using resources such as Auto Scaling Groups, Kubernetes Clusters, Lambda/Serverless, or RDS/BigQuery. You cannot estimate their cost. It depends on the usage. you need tagging and actual cost monitoring in order to make smart IT decisions. The env0 platform is doing something very unique for cost monitoring. We are utilizing a module we created, and open-sourced, called Terratag. This process runs during the deployment process. We recursively check 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.
Let’s start with 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 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. This also comes with unlimited concurrent runs, which is important to point out.
Next is Governance using Policy as Code. Terraform Cloud uses Sentinel. This is a policy-as-code framework, but is also locked into Terraform Cloud. This means if you leave Terraform Cloud, you can’t take your policy with you. It is also only available in the paid tiers of the product. env0 gives you the ability to use whatever policy framework you like using our Custom Flows, even in the free tier. Most of our customers are using Open Policy Agent to create and enforce policy checks to prevent unapproved configurations before they start.
Both env0 and Terraform Cloud Business offer the ability to operate in a hybrid deployment model. This means that there is a SaaS front-end, and a self-hosted agent on the back-end. 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.
