Terraform Workspaces Are Bad Actually, And Here's Why.

The workspace feature in Terraform OSS seems like a great solution for managing multiple environments with the same body of code. But appearances can be deceiving! There's a reason third-party solutions like GitHub Actions, Azure DevOps, and env0 exist to help manage Terraform infrastructure as code deployments. One of the primary reasons is handling the integration between your Terraform configuration, your infrastructure environments, the input values you want to use, and the state data storage for each instance.

Once you start thinking through how to promote code changes from one environment to another, how to secure your Terraform state data, and how to implement a policy of least privilege access with your developers and CI/CD pipelines; you'll quickly discover that Terraform OSS workspaces are just not up to the task.

That's not to say that Terraform OSS workspaces are always bad! They certainly have their place, for use with short-lived, testing environments that live outside your regular CI/CD processes. But once you start working with long-lived, shared environments like Staging and Production, it's time to find another solution.

In the video we'll cover the following:

🌮 The problem Terraform workspaces are meant to solve
🌮 How Terraform workspaces work
🌮 The shortcomings of Terraform workspaces
🌮 Alternatives approaches to using Terraform workspaces

Thank you so much for watching! Subscribe if you think I’ve earned it. Hit the bell as well if you’re feeling swell.❤️&🌮

▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
🌮 Other videos to check out:

▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
🌮 Timestamps:

⌚ 0:00 Intro
⌚ 1:31 Terraform workspaces background
⌚ 2:21 What problem are we trying to solve?
⌚ 4:35 What solutions are available?
⌚ 5:56 How do workspaces, er, work?
⌚ 7:46 Shared codebase issues
⌚ 10:22 Shared state data issues
⌚ 13:49 env0 Sponorship
⌚ 15:08 Shared providers and modules issue
⌚ 17:06 Are workspaces actually bad?
⌚ 19:08 Conclusions

▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
#terraform #hashicorp #devops #cloudengineer #techlearning
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
⭐ CONNECT WITH ME 🏃🦖

▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

🌮 About Me 🌮

Ned is a curious human with a knack for creating entertaining and informative content. With over 20 years in the industry, Ned brings real-world experience to all his creative endeavours, whether that's pontificating on a podcast, delivering live instruction, writing certification guides, or producing technical training videos. He has been a helpdesk operator, systems administrator, cloud architect, and product manager. In his newest incarnation, Ned is the Founder of Ned in the Cloud LLC. As a one-man-tech juggernaut, he develops courses for Pluralsight, runs two podcasts (Day Two Cloud and Chaos Lever, and creates original content for technology vendors.

Ned has been a Microsoft MVP since 2017 and a HashiCorp Ambassador since 2020, and he holds a bunch of industry certifications that have no bearing on anything beyond his exceptional ability to take exams and pass them. When not in front of the camera, keyboard, and microphone, you can find Ned running the scenic trails of Pennsylvania or rocking out to live music in his hometown of Philadelphia. Ned has three guiding principles: Embrace discomfort, Fail often, and Be kind.

[NedintheCloud]

Are you using Terraform OSS workspaces for today? Do you agree with HashiCorp's guidance?

[Max-cqhl]

Thanks for explanation. So in regards to possible alternatives, you mentioned a few. Would really love to hear your vision on best alternative. What is the best practice for separating environments when not using workspaces?

[KenWMacLeod]

We use an artifact and per-env tfvars. Our source code tree is identical for all environments, with separate tfvars with the different env configuration. Our CI in dev creates a new artifact after each merge to main and the code automatically applied in dev (CD). Once approved for staging, the artifact is copied to the staging binary artifact repo and the terraform applied in staging using the staging.tfvars. Same pattern when promoted to production using prod.tfvars. We chose this method because all of our other components use the same binary artifact promotion procedure to copy artifacts from dev to stage to production. We have per-env separate state.

We also share modules between applications using the same artifact tooling for each module. Modules can be pinned per application as needed.

[neilmcalister]

Using an Azure Storage Account for a backend - I have...

1 - A different Storage Account for each ENV
2 - Use the same TF code and modules for all ENVs
3 - Use TFVARS files for each ENV
4 - Submit changes to a repo that triggers a CI/CD pipeline that does a PLAN for each ENV
5 - Have a approve/deny CI/CD pipeline stage to APPLY

No one user can access the backend Storage Account for any ENV - only the Azure Service Connection/Principal the pipeline runs as can access the backend

The only issue I have is, as the video highlights, when your PRD ENV is mixed quite differently from the others - e.g. load balancers and resources where they just aren't used in the other ENVs. It's a constant churn to work out shared code and modules to adapt to all of this

[Amit-ofcq]

On AWS with s3 backend, each workspace creates a separate folders based on the key provided in the provider block, inside one bucket.

[RodneyMcKee]

Hope your going to cover those other options in a future video. This was great content.

[runtcpip-morganlucas]

Drift and workspaces really threw me for a loop with my first Terraform file. That's a lesson you only learn once, but I don't find myself paying much attention to workspaces anymore.

[Liam.Stevens]

Can you link/reference the part where Terraform state workspaces are not ideal for production?

Also, does the same apply to Workspaces when using Terraform Cloud? I have previously used multiple branches with multiple workspaces - each branch linked to a particular workspace so all merged PRs for that branch automatically open a plan for that workspace on TF cloud.

[ronaldonazo]

Also not forget that in test you will use a shared RDS for cost optimization, and on prod you will have your own RDS, do that with workspaces xD!

[ChristopherKMEtou]

I simply keep my various environments in separate backend storages.

[haythamsalhi]

Agreed. We would like to know about whether TFC workspaces can resolve those issues in Terraform OSS workspaces? And can we achieve the DRY principle using TFC?

[RobertLachner]

nice video but video and audio are out of sync wich drives me crazy

[IoanaAndone]

Disagree.

Have tried all ways and:
- writing the configuration in a way that can be customised between environments +
- splitting resources between workspaces with separate management
is the Best implementation we have seen.

Otherwise, you're basically assuming that:
- people will perfectly maintain all the different code versions; they won't - leading to having wildly different dependencies and resources managed in each environment
- people will want or have the inclination to write rego rules for each environment separately
- there is no benefit to be gained by dev fully or mostly emulating prod for continuous integration and staging type testing purposes (or that your use case won't require it)
- running your whopper of a plan/apply (that you will likely evolve towards) won't exceed time limit and the number of resources won't kill the underlying engine
... and you're encouraging everyone to push to the same default workspace, meaning that now all teams have to review ALL possible changes... which is a nightmare when you're just updating a small part of the system as part of a routine change and have to unpick all the previous discarded/buffered plans and failed applies or drift realignments.

From the pov of a company with literally hundreds of AWS accounts, countless repositories applying across accounts, areas and teams, it is SUPREMELY impractical. Workspaces are the way forward. Just pray your TF Cloud provider doesn't charge by them!