My team have been using terragrunt and aside some other limitations, we found that their run-all command that for instance tries to apply all dependencies is broken (documented in https://github.com/gruntwork-io/terragrunt/issues/386#issuecomment-358306268) since it cannot resolve an output of a module that was not applied first. There are some workarounds, like using mock_outputs, or deploying some stacks individually.
I was wondering if the “all up” terraspace command suffers from the same problem… Or is it another advantage of using terraspace instead of terragrunt?
Both terragrunt and terraspace, when applying multiple stacks will have limitations. Of course, there’s bias here since I am the author of Terraspace.
Some Thoughts
Generally speaking, think terraspace all can be used for infrastructure designs that are kept simple. It’s a beautiful thing when it does work! But don’t think terraspace all can be elixir and a be-end-all-end solution for everything.
Did an interview with Anton B, he explains it pretty clearly: “We still have makefiles, we still have shell”. Here’s the video at the specific time: https://youtu.be/J_-XPfFlsbU?t=6420
As the infrastructure grows in complexity, maybe orchestrating multiple stacks with your own pipeline is a better option. Makefile is a lower-level of simple orchestration. Something like codepipeline with multiple codebuild projects calling terraspace up and or terraspace all is a high-level version of orchestration.
Also, the terraform SAAS-like services like TFC, Spacelift, env0, and scalr have a notion of connecting multiple stacks through more webhook-like triggers. Got mixed feelings about that also. Sometimes there’s more clarity with a centralized pipeline orchestrating all in one place. Distributed systems can sometimes be harder to follow and debug. It might depend on the complexity of the infrastructure code itself. And there may be ways to simplify the code to reduce its complexity. Sometimes it’s possible, and sometimes not.
But don’t think