|
People tend to complain about HCL a lot, I think it’s a great language for infrastructure. I don’t want a “real programming language” for provisioning infrastructure. I feel like every time I’ve seen someone “need” a real programming language, that there is a _better_ way to do the task at hand with HCL. That being said, there are some ugly bits. 1. Remote state as a data source means your infra is broken, you just don’t know it yet. Two apply’s have to occur to get your infra in the correct state, but they are separated by an arbitrary amount of time between executions. Even if you automate it with CI/CD, your second root module could be broken until run since it depends on the output of the other module. 2. Public modules are absolute garbage. Go find the best one, it’s trash. Here is why, 10-20 orgs all come in and tweak the module to work for them. You’ll often see 1-10 resources in a module (sometimes more), but the module will end up with more _input complexity_ than the underlying resources. Sometimes even more inputs than all the original resources combined! In the end, you get a module that “works” for everyone, with a half baked “DRY abstraction” for N number of organizations. 3. Organizing code is hard, because we often don’t fully consider environments/workspaces, infrastructure ownership, change management, and other sociotechnical concerns. I think Terraform and IaC in general is the epitome of Conway’s Law and when the (changing) social structure of the organization isn’t followed, the code gets harder to work with. This point is at odds with #1 above. 4. People tend to think “terraform apply” is a magic transactional boundary around your infrastructure. If it applies, it worked!!! But in reality, if modules aren’t crafted correctly they can “apply” cleanly, but still introduce an outage while they are executing. All that said, I’m excited for the 1.0 release. I love terraform. Thanks to all (except module authors) for the hard work. |
Your points would still apply if a resource (e.g. aws_instance.foo) is created in one module and then referenced as a data source (e.g. data.aws_instance.foo) in another module. Are you suggesting remote state is different? Or would you also advise against referencing data source attributes from resources created in other modules?