4 ms·

Go down the path of rolling your own shell scripts and if you do a world class job you'll end up reimplementing the functionality and architecture of Terraform.

Go down the path of rolling your own shell scripts and if you do a world class job you'll end up reimplementing the functionality and architecture of Terraform. Also, as a commercial open source project, you have the benefit of an entire community using and extending the tool in their own use cases. Read through Terraform release notes, you will see the amount of work & experimentation writing and maintaining a provider can be.

impoppy 4y ago
Username checks out.
- awsanswers 4y ago
  Ok here's a less friendly version: "The way AWS is implemented doesn't work for me" is a nightmare attitude for everyone on your team and an affront to your productivity. Look at the early (mid 2000s) AWS customer success stories and think about what it did for those companies. Accept the model and get your undifferentiated systems work done quickly.
  - impoppy 4y ago
    I failed to express my take against Terraform: instead of fighting indeterministic nature of infrastructure, it was created to work around it. Why far more experienced engineers than I am came to the conclusion that playing along is better than actively fighting?
    - awithrow 4y ago
      Infrastructure by it's nature won't be deterministic. Fighting it to me sounds like wanting to use "assume a frictionless plane" in a real world physics solution
    - d_watt 4y ago
      I feel like your question is like "Why are there flathead screwdrivers? Shouldn't craftsmen only accept phillips head screwdrivers, since they're superior?" The reality being there are a lot of flathead screws out there. An engineers job is to get stuff done and not fight an ideological battleground. The world is impure, and requires impure solutions. Terraform is a tool to get things done, and given the realities of managing stateful infrastructure it does a pretty good job of addressing the failure states of it.
      - impoppy 4y ago
        Exactly. Explain me why do flathead screwdrivers exist, if there are phillips head screwdrivers. I don't have a problem with mastering a new tool, but I do have a problem with mastering a tool purpose and idea of which I do not fully understand.
        d_watt 4y ago
        > but I do have a problem with mastering a tool purpose and idea of which I do not fully understand I would suggest that the onus of learning this isn't on other people though. You can start with a baseline assumption that there is a reason these decisions are made. Assume other people are smart, rational actors, and that certain pressures and tradeoffs lead to the belief that the current strategies are the best we have for the state of things overall. The reason I say this, in particular, is that you questions and answers in this topic have felt close minded and defensive. I say this not as an insult, but highlighting that this is often how I approached things when I was early on in my career. I felt overwhelmed by all the things I needed to know, and wasn't even close to having a mental model of how all the things in a fully working piece of production software fit together. That imposter syndrome led to me discounting things I didn't understand because it was emotionally safer to feel like I knew better than to accept I was barely floating along. Was this thread about a good faith effort to understand why terraform is needed, or is it a rant for why you're mad you have to learn it?
        impoppy 4y ago
        I dunno, I have this problem all the time. I feel powerless being presented to all those enormous pieces of software I have no idea how do they work. I guess it’s a form of procrastination, as the moment I stop thinking, investigating and learning beforehand and start actually working with the input I have — the actual progress starts. Edit: Phrasing.
    - dragonwriter 4y ago
      You could code a set of scripts to create a set of resources from scratch. Then another set to tear them down. And maintain and rub those as the resources change. And make sure they have options so that you can only tear down and re-set up the resources necessary when you have isolated changes abd don’t want to destroy the whole stack. And do ad hoc one time scripts every time you you want to make a change that doesn’t require tearing resources down, but also make sure the changes are reflected in the build (and, if necessary, take down) scripts. Or you could just describe and maintain the desired state in cloudformation, terraform, etc. and let the associated runtime handle termining the changes to apply. I know which I prefer, but you do you.

impoppy 4y ago

Username checks out.

awsanswers 4y ago
Ok here's a less friendly version: "The way AWS is implemented doesn't work for me" is a nightmare attitude for everyone on your team and an affront to your productivity. Look at the early (mid 2000s) AWS customer success stories and think about what it did for those companies. Accept the model and get your undifferentiated systems work done quickly.
- impoppy 4y ago
  I failed to express my take against Terraform: instead of fighting indeterministic nature of infrastructure, it was created to work around it. Why far more experienced engineers than I am came to the conclusion that playing along is better than actively fighting?
  - awithrow 4y ago
    Infrastructure by it's nature won't be deterministic. Fighting it to me sounds like wanting to use "assume a frictionless plane" in a real world physics solution
  - d_watt 4y ago
    I feel like your question is like "Why are there flathead screwdrivers? Shouldn't craftsmen only accept phillips head screwdrivers, since they're superior?" The reality being there are a lot of flathead screws out there. An engineers job is to get stuff done and not fight an ideological battleground. The world is impure, and requires impure solutions. Terraform is a tool to get things done, and given the realities of managing stateful infrastructure it does a pretty good job of addressing the failure states of it.
    - impoppy 4y ago
      Exactly. Explain me why do flathead screwdrivers exist, if there are phillips head screwdrivers. I don't have a problem with mastering a new tool, but I do have a problem with mastering a tool purpose and idea of which I do not fully understand.
      - d_watt 4y ago
        > but I do have a problem with mastering a tool purpose and idea of which I do not fully understand I would suggest that the onus of learning this isn't on other people though. You can start with a baseline assumption that there is a reason these decisions are made. Assume other people are smart, rational actors, and that certain pressures and tradeoffs lead to the belief that the current strategies are the best we have for the state of things overall. The reason I say this, in particular, is that you questions and answers in this topic have felt close minded and defensive. I say this not as an insult, but highlighting that this is often how I approached things when I was early on in my career. I felt overwhelmed by all the things I needed to know, and wasn't even close to having a mental model of how all the things in a fully working piece of production software fit together. That imposter syndrome led to me discounting things I didn't understand because it was emotionally safer to feel like I knew better than to accept I was barely floating along. Was this thread about a good faith effort to understand why terraform is needed, or is it a rant for why you're mad you have to learn it?
        impoppy 4y ago
        I dunno, I have this problem all the time. I feel powerless being presented to all those enormous pieces of software I have no idea how do they work. I guess it’s a form of procrastination, as the moment I stop thinking, investigating and learning beforehand and start actually working with the input I have — the actual progress starts. Edit: Phrasing.
  - dragonwriter 4y ago
    You could code a set of scripts to create a set of resources from scratch. Then another set to tear them down. And maintain and rub those as the resources change. And make sure they have options so that you can only tear down and re-set up the resources necessary when you have isolated changes abd don’t want to destroy the whole stack. And do ad hoc one time scripts every time you you want to make a change that doesn’t require tearing resources down, but also make sure the changes are reflected in the build (and, if necessary, take down) scripts. Or you could just describe and maintain the desired state in cloudformation, terraform, etc. and let the associated runtime handle termining the changes to apply. I know which I prefer, but you do you.