Terraform Enterprise vs Open-Source

I should start off by saying the primary features of Terraform are available in Open-Source. Enterprise provides you with a managed environment and dashboard that you do not have to upkeep. This managed environment provides one of the greatest benefits, collaboration and governance capabilities.

I’ll go through some of the main features of Terraform Enterprise and provide you with its open source alternative.

1. Remotely Managed

Normally with Terraform Open-Source you would run your Terraform files locally with a remote back-end to something like S3. Maybe, you even have a central server that you use to manage your Terraform runs.

However with Terraform Enterpise, there is nothing to manage. This can however be viewed a negative as you would have to go through extra hoops to setup custom abilities, for example – having Terraform trigger Ansible after provisioning an EC2 instance.

* Terraform offers a private install under their Premium account that sits on your private infrastructure in AWS.

2. Team Management

Open-Source Terraform

A possible solution for an open-source environment would be to use your active directory to provide teams and users credentials to access the centralized server. There are many aspects of access you would have to cover from AWS Access, Source Control, etc.. that you would not have to worry about if you went with Enterprise.

Terraform Enterprise

Terraform Enterprise organizational and access control model is split up into 3 units. Users, Teams and Organizations.

Users naturally belong to a Team, which are granted permissions based on an organization’s workspace. Organizations are a shared spaces for teams to collaborate on workspaces. An organization owner can create teams and manage their membership.

The use of Team Management is found in every aspect of Terraform. For example, you can limit access to variables or any type of modification of a production workspace while allowing access to sandbox for a specific team or users.

This provides us with capabilities and ease of user not found within the open-source version of Terraform. It is extremely powerful and makes life easier for management.

3. Workspace Management

Workspaces allow you to reuse the same code across multiple environments. For example you can have a workspace for staging and another for production and keep the code identical. The variable inputs however can differ to your liking.

Open-Source Terraform

$ terraform workspace new bar
Created and switched to workspace "bar"!
You're now on a new, empty workspace. Workspaces isolate their state,
so if you run "terraform plan" Terraform will not see any existing state
for this configuration.

Terraform Enterprise

With enterprise you get a sleek dashboard with the run statuses, when the terraform files were last changed and which repo is it wired to. This type of information is invaluable as your company grows and repositories are added.

4. Version Control Connections

Open-Source Terraform

When using open-source Terraform you still have your repositories are normal. But it becomes a manual process of switching repositories, pulling the latest code, testing it out then applying it to production. Enterprise does this in a fully automated way.

Terraform Enterprise

You can setup Terraform Enterprise with Github, GitLab and Bitbucket providing a fully automated testing run and testing process catching errors and bugs during pull requests before they enter the repository.

Failing Terraform run within BitBucket

5. Secure Variable Management

Open-Source Terraform

There is no secure variable management out of the box with open-source. When you have sensitive variables typically you leave them empty within your terraform.tfvars and leave no default in your variables.tf. When you plan your apply your Terraform files then you would proceed to type in your sensitive value, that way it is not saved within your repository.

Terraform Enterprise

Within Terraform Enterprise’s workspace variable section you can choose what variable is sensitive and what isn’t. They manage everything for you.

Sensitive variables are secured and never shown

6. Remote Runs & State

Open-Source Terraform

Simple, you store your state file in an S3 Bucket, and run your terraform plan and apply commands.

Terraform Enterprise

You are provided with a dedicated page with a history and queue of plans run by specific users. Each run provides deep insight into changes and errors. You can easily queue new plans/runs on the fly. No state file to manage and everything is versioned appropriately.

You are able to view the status of the run, newly committed code associated with the run, how the run was initiated when and which user initiated it. A timeline of events and the output of both terraform plan and terraform apply commands.

7. Private Module Registry

Open-Source Terraform

With open-source it’s up to you how you want to organize your modules. You can create a dedicated repository for modules which is the better option or have unorganized modules in different repositories.

Terraform Enterprise

Terraform Enterprise’s private module registry is extremely effective offering the ability to share it across your organization. It supports module versioning, searching and filtering of available modules similar to Terraform’s own public terraform registry.

Every module as a dedicated page with inputs, outputs, dependencies and the resources that are created. Typically each module’s repository would be a private repository on something like GitHub. Once you commit your changes to master and release it a new version of the module would become available.

8. Configuration Designer

Open-Source Terraform

Manually add modules and components to your terraform main.tf file.

Terraform Enterprise

Using the configuration designer you are able to spin up an entire workspace using your private module registry. This provides huge benefits in creating a landing zone style deployment of environments.

You essentially choose the modules you want for your new workspace, set your variables (you can use interpolation!) and at the end of the process the designer returns a text of a main.tf configuration. You’ll have to copy paste this to create a new repo for workspaces but can safe you a-lot of time!

9. Full API

Open-Source Terraform

None.

Terraform Enterprise

Terraform enterprise provides a way to access many of the items that you use on the dashboard through the API. This can allow for custom solutions integrating into Terraform Enterprise.

For example, if you are on-boarding a user you can have your scripts or a trigger setup to call Terraform Enterprise and add the new user to an existing team.

POST /teams/:team_id/relationships/users

10. Support

Open-Source Terraform

When using the open source version best place to receive support is through the Terraform community. There are active, dedicated people willing to help through various mediums. These include Events, Stack Exchange, Mailing list, gitter, IRC, and the repository GitHub page. Terraform does offer paid HashiCorp training courses near your cities.

Terraform Enterprise

When you use the Enterprise version you get support 9 hours a day 5 days a week on the Silver level. There is a Gold level support with 24×7 coverage. They both provide support SLA’s so if anything where to go wrong you are covered. I wasn’t able to find too much information on the Bronze level support.

Response and resolution times are based on the SLA with HashiCorp but they use the following severities when you open tickets.

Severity 1 (Urgent)

Any error reported by customer where the majority of the users for a particular part of the software are affected, the error has high visibility, there is no workaround, and it affects customer’s ability to perform its business.

Severity 2 (High)

Any error reported by customer where the majority of the users for a particular part of the software are affected, the error has high visibility, a workaround is available; however, performance may be degraded or functions limited and it is affecting revenue.

Severity 3 (Normal)

Any error reported by customer where the majority of the users for a particular part of the software are affected, the error has high visibility, a workaround is available; however, performance may be degraded or functions limited and it is NOT affecting revenue.

Severity 4 (Low)

Any error reported by customer where a single user is severely affected or completely inoperable or a small percentage of users are moderately affected or partially inoperable and the error has limited business impact.