For one you can't set a variable in the terraform backend. So if you want to reuse the same module without different terraform blocks, you would want to switch to a workspace.
Some people will use a single storage account for all their state. Use the key to define the project. The backend will take care of keying the state into a separate location based on the workspace name.
This is descent for smallish projects when driving the terraform command manually. You can also reference terraform.workspace in your code to have conditionals.
The biggest downside is dealing with authentication and variables. If you are using different subscriptions and logged in with the state of another subscription you get terrible news that everything needs replaced. So situational awareness needs to be heighten.
Tracking the values for input needs to be stored somewhere. When I used to do this, I ended up storing the variables as locals with a conditional on the workspace name.
▶ cat .\main.tf
variable "environment" {
type = string
}
terraform {
backend "azurerm" {
resource_group_name = "tfstate"
storage_account_name = "account"
container_name = var.environment
key = "terraform.tfstate"
}
}
~\projects\test\t8 ◷ 9:32:49 AM
▶ terraform init
Initializing the backend...
Error: Variables not allowed
on main.tf line 9, in terraform:
9: container_name = var.environment
Variables may not be used here.