4 ms·

Well, maybe there's some terraform jedis out there but I have seen the same problem at four companies so far, and at this point I keep my nose right out of it b

by hobs 3y ago

Well, maybe there's some terraform jedis out there but I have seen the same problem at four companies so far, and at this point I keep my nose right out of it because its always a chore treadmill.

JohnMakin 3y ago
Much of the consulting work I do surrounds terraform and most people are doing it very poorly or incorrectly. I do not think this is a fault of terraform. For instance, not going all in on IAC and having mixed/poor practice around automation and click-ops'ing things for "speed" is a great way to have inconsistent terraform states. As far as a flat out state corruption, I've only seen that one time in ~6 years working with terraform, and it was due to the mechanism locking the state file failing during simultaneous updates. In today's version I'm not even sure how I'd go about corrupting a terraform state file sanely. There are a lot more guard rails and QoL stuff since the pre-1.0 version days.
- hobs 3y ago
  As a database person this pains me to say, but if the people keep using the tool wrong you may want to start fixing the tool.
  - tekla 3y ago
    You can't stop people from doing dumb things if they don't want to learn.
  - acdha 3y ago
    The problem is that the domain requires flexibility. If you aren’t allergic to the documentation, the problems described are exceedingly uncommon (or entirely self-inflicted like the “gets mad” bit) but there are a lot of people who treat infrastructure as somewhat beneath them and get upset when it doesn’t work like other things they know. That’s a really hard problem for a tool developer because people who do know what they’re doing often need odd configuration points. I think the general answer is to push the first group up the stack: you get fewer choices but also fewer decisions you need to understand the consequences of. As a database analogy, most of the problems I’ve seen are similar where people chose not to learn how their tools worked and then said it was the database’s fault that they were making billion-row joins or O(n) queries because they knew what they wanted and the database should have had Do What I Meant mode.
MaKey 3y ago
I've been using Terraform for 4 years with Azure and compared to the alternatives (ARM templates or Bicep) it's definitely a win. When you run into issues Terraform is usually very transparent about them and its source code is readable. Even when something is not supported by a provider (yet) you have the local-exec escape hatch to deploy and tear down a resource.

by hobs 3y ago

Well, maybe there's some terraform jedis out there but I have seen the same problem at four companies so far, and at this point I keep my nose right out of it because its always a chore treadmill.

JohnMakin 3y ago

Much of the consulting work I do surrounds terraform and most people are doing it very poorly or incorrectly. I do not think this is a fault of terraform. For instance, not going all in on IAC and having mixed/poor practice around automation and click-ops'ing things for "speed" is a great way to have inconsistent terraform states. As far as a flat out state corruption, I've only seen that one time in ~6 years working with terraform, and it was due to the mechanism locking the state file failing during simultaneous updates. In today's version I'm not even sure how I'd go about corrupting a terraform state file sanely. There are a lot more guard rails and QoL stuff since the pre-1.0 version days.

hobs 3y ago
As a database person this pains me to say, but if the people keep using the tool wrong you may want to start fixing the tool.
- tekla 3y ago
  You can't stop people from doing dumb things if they don't want to learn.
- acdha 3y ago
  The problem is that the domain requires flexibility. If you aren’t allergic to the documentation, the problems described are exceedingly uncommon (or entirely self-inflicted like the “gets mad” bit) but there are a lot of people who treat infrastructure as somewhat beneath them and get upset when it doesn’t work like other things they know. That’s a really hard problem for a tool developer because people who do know what they’re doing often need odd configuration points. I think the general answer is to push the first group up the stack: you get fewer choices but also fewer decisions you need to understand the consequences of. As a database analogy, most of the problems I’ve seen are similar where people chose not to learn how their tools worked and then said it was the database’s fault that they were making billion-row joins or O(n) queries because they knew what they wanted and the database should have had Do What I Meant mode.

MaKey 3y ago

I've been using Terraform for 4 years with Azure and compared to the alternatives (ARM templates or Bicep) it's definitely a win. When you run into issues Terraform is usually very transparent about them and its source code is readable. Even when something is not supported by a provider (yet) you have the local-exec escape hatch to deploy and tear down a resource.