Terraform workspaces vs isolated directories?

Question

I'm reading the "Terraform: Up & Running, 2nd Edition" book by Yevgeniy Brikman, the author is going through a lot of work to NOT use workspaces? Is this sound? It seems like really esoteric. His reasoning is as follows:

"The state files for all of your workspaces are stored in the same backend [...] Workspaces are not visible in the code or on the terminal unless you run terraform workspace [...] Putting the two previous items together, the result is that workspaces can be fairly error prone."

As to the second point, why not just add the workspace to your your PS1 if that's an issue? Using something like ZSH/PowerLevel10k, my prompt shows Terraform workspace information.

As far as the first point, I broke that off into separate question.

Is there anything else that I'm missing in this workspace vs directories for isolation.

Answer 1

Workspaces are an unnecessary complexity which causes the possibility that you destroy your prod environment (or leak secrets). It is a much better practice to switch backends, and that is noted in the docs:
https://www.terraform.io/language/state/workspaces

In particular, organizations commonly want to create a strong separation between multiple deployments of the same infrastructure serving different development stages (e.g. staging vs. production) or different internal teams. In this case, the backend used for each deployment often belongs to that deployment, with different credentials and access controls. Named workspaces are not a suitable isolation mechanism for this scenario.

Instead, use one or more re-usable modules to represent the common elements, and then represent each instance as a separate configuration that instantiates those common elements in the context of a different backend. In that case, the root module of each configuration will consist only of a backend configuration and a small number of module blocks whose arguments describe any small differences between the deployments.

The new hotness is a backend file, which you can choose at init:
https://www.terraform.io/language/settings/backends/configuration#file

Answer 2

Digging down further into the book, the author picks this back up on page 304.

...a 1:1 representation... If I browse your live repository, I should be able to see, from a quick scan, what resources have been deployed in what environments. That is, every resource should have a 1:1 match with some line of code checked into the live repo. This sems obvious at first glance, but it's surprisingly easy to get wrong. [...] A more subtle way to get it wrong is to use Terraform workspaces to manage environments, so that the live infrastructure is there, but the code isn't. That is, if you use workspaces your live repo will have only one copy of the code, even though you may have 3 or 30 environments deployed with it. From merely looking at the code, there will be no way to know what is actually deployed, which will lead to mistakes and make maintenance complicated. Therefore, as described in "Isolation via Workspaces" on page 88, instead of using workspaces to manage environments, you want each environment defined in a seperate folder, using separate files, so that you can see exactly what environments have been deployed just by browsing the live repository.

So it seems one of the author's scruples though described as "not visible in the code or on the terminal" is more general and extends to tooling (like web svc browsers, ex., GitHub) which do not support Terraform workspaces. The author wants to know where the code deployed without pulling it down. Such that he can see what is on development and production without using a "workspace".

He later extends this to the entirety of Git branching which is slightly more bizarre, because his problem there is even smaller (pg 304),

Unfortunately, [branching] only solves part of the problem. Even though the Terraform backends provide locking for Terraform state, they cannot help you with locking at the level of the Terraform code itself. In particular if two team members are deploying the same code to the same environment but from different branches, you'll run into conflicts that locking can't prevent.

But sure, certainly "deploying the same code to the same environment but from different branches" sounds lke a real bad idea.