Viewing Terraform solely through the lens of cloud automation and in comparison with CloudFormation is a shortsighted mistake. Terraform has providers for plenty of other services that don't qualify as "cloud things" and lack proper configuration of their own. In a very general sense, Terraform is a terrific resource management tool with state versioning & locking built in. For example, there's a terraform-kafka-provider[1], which can be used to manage topics in a Kafka cluster. Could shell scripts be written to accomplish the same goal? Of course. Would those scripts inevitably develop in a haphazard, organic way to form a buggy and incomplete implementation of something like Terraform? You bet!
"Cloud" configuration may have been Terraform's proverbial toe in water, but the truly untapped potential lies in the other providers. Anything that can be packaged as a Terraform provider exposing resource abstractions can be easily managed using convenient HCL syntax. This, IMHO, is the unfortunately buried lede.
Someday folks will rediscover the potential of Puppet for these use cases. Until then, I'm content to watch countless alternative implementations come and go.
Before using Terraform I tried to use Puppet to manage AWS infrastructure. It was a fun but short adventure.
The idea of having all your configuration in one tool is nice but Puppet just isn't that tool. The one thing I found lacking the most, which made Terraform the tool for the job, is awareness of state. Having the triangle of what configuration you want (HCL), what configuration you expect to have (state) and what configuration you actually got (real world), with the tools to observe the differences between these and the ability to make careful changes is just what you need for important infrastructure changes.
With Puppet every change felt like Fire-and-pray. Sure you can run a 'noop', but if anything changes in between that and the actual run that could trigger another resource you would be catch by surprise. On OS/App level the impact can often be contained, but on infra, not so much as you would have reduce the powerful features of Puppet to much as to it not being a benefit anymore.
You are implying that people who use Terraform are not aware of Puppet. Puppet is a terribly complicated thing compare to Terraform. We use both on a daily basis and everybody agrees that we need to move away from Puppet. Terraform + Ansible is the way for us to go.
It is nice that puppet defines a graph of dependencies compared to doing this in ansible.
What I find tough is that you have another indirection when using puppet to configure your tools. So you first have to figure out the puppet module’s configuration and how it maps onto the actual tools configuration
Wonder why you got downvoted, as someone who has been using ansible for years to accomplish what was said and what you accomplish with puppet I wonder what I am missing out of terraform
The nice thing about Terraform (and Ansible) imo is that they don't require a daemon but just run locally (or on CI), with some shared state in a object store.
Doesn't puppet only support success/changed/error status for resources? How does it work with AWS infrastructure where you may need to possibly remove dependencies before the change, update the resource in place, or update other resources to point at what you just created? You need at least 5 states, I believe? (That depend on properties, not resources, so notification is not enough)
I wish we could add providers by having terraform load python modules (or tcl, lua, js) and call it a day. Instead they chose to offer a statically-linked binary that forks gRPC plugin servers, and supporting that looks like a hell of a lot more work than writing and running a script.
"Cloud" configuration may have been Terraform's proverbial toe in water, but the truly untapped potential lies in the other providers. Anything that can be packaged as a Terraform provider exposing resource abstractions can be easily managed using convenient HCL syntax. This, IMHO, is the unfortunately buried lede.
[1]: https://github.com/Mongey/terraform-provider-kafka