5 ms·

Meh. I used terraform for a few years and every time it didn’t work the way I wanted I found a ignored github issue. Vaporware as far as I am concerned.

• diminoten 7y ago
  Luckily you're not the only consumer of Terraform...
• deleted 7y ago
  [deleted]
• Thaxll 7y ago
  "vaporware" you mean the most popular tool to deploy on cloud platforms.
  • t34543 7y ago
    I prefer cloudformation
    • erik_seaberg 7y ago
      My biggest issue with CloudFormation is that it absolutely refused to start managing any resource it didn't create. "terraform import" is clumsy but better than nothing. I always thought CloudFormation was also less extensible, but it looks like they have Lambda-based macros now, which might actually be less hassle than writing gRPC plugin servers for Terraform. Now I need to look up how to extend Pulumi. I'm reluctant to use anything that will require generating a lot of Go code.
      • t34543 7y ago
        If you create resources outside of terraform/CF your doing it wrong. This is a feature, not a bug.
        • mooreds 7y ago
          That's a beautiful statement of purity, but my reality has been different. Even with the best of intensions sometimes resources are created outside of an IaC solution and you want to bring them in. On the other hand I hear that CF's rollback is better at not leaving things in a busted state.
        • erik_seaberg 7y ago
          We don't seem to have used Terraform for everything since day one. Even if we had, we can't migrate to CloudFormation without abandoning our Terraform-created datastores and live-migrating to new ones. (Not that we necessarily want to, at this point.)
        • auslander 7y ago
          This. It takes years to learn good architecture, and Cloudformation nudges you to make it right. Thats why you need senior infrastructure engineers.
          • jen20 7y ago
            This is 100% unrelated to “senior infrastructure engineers” (most of whom I’ve seen end up building pure crap), and import is simply a matter of practicality. If we followed the (patently poor) advice above, CF users would not have been able to use NAT Gateways - to take one of several prominent examples - for many months following their launch. Terraform was substantially faster to support them, but being able to import resources created outside the normal mechanism for _any_ reason is an essential part of any IaC tool.
            • deleted 7y ago
              [deleted]
        • quickthrower2 7y ago
          > If you create resources outside of terraform/CF your doing it wrong. But at least you're doing it! There are sometimes holes in Terraform coverage.
        • 7y ago
    • dkersten 7y ago
      And outside of AWS?
      • erik_seaberg 7y ago
        Terraform supports multiple vendors, but your templates are not vendor-neutral, you have to rewrite them all. I don't see it as that big a win over using each vendor's native tools, as long as they all support a config managed in git.
        • dkersten 7y ago
          With terraform, I at least only have to learn one syntax, so there’s at least that, if noting else.
          • scarface74 7y ago
            Which does little good if you still have to learn the provisioner, the terminology and the idiosyncrasies of the platform. And good luck using your business support plan with AWS when something goes wonky and you’re using Terraform.
            • sciurus 7y ago
              It does plenty of good. I have software that spans AWS, Azure, and GCP (don't ask me why). I can easily manage it as a cohesive whole, e.g. using an ip address provisioned in GCP as the target of a DNS record provisioned in AWS. I can spin it all up in a single call to a single tool. Under the hood, terraform is just using the AWS APIs. If an error occurs with them, getting support isn't an issue.
    • dangus 7y ago
      me too } } } } }