4 ms·

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 pr

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.
        d_watt 4y ago
        It makes sense, and the biggest ways to understand are to do what you're talking about and try and "do it better." As other commenters pointed out, as you make the bash script more and more complicated, you'll see why terraform is the way it is. You may even find ways to do it better, and then you can make your own project/competitor, or submit a change back to the open source project. However, in the mean time, it's always worth coming at these things with the generosity of mind to assume that smart people made tradeoffs for real reasons, and for your "day job" work in the frameworks adopted until you understand the problemspace well enough to give truly informed feedback on why to do something differently.
- 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

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.
      - d_watt 4y ago
        It makes sense, and the biggest ways to understand are to do what you're talking about and try and "do it better." As other commenters pointed out, as you make the bash script more and more complicated, you'll see why terraform is the way it is. You may even find ways to do it better, and then you can make your own project/competitor, or submit a change back to the open source project. However, in the mean time, it's always worth coming at these things with the generosity of mind to assume that smart people made tradeoffs for real reasons, and for your "day job" work in the frameworks adopted until you understand the problemspace well enough to give truly informed feedback on why to do something differently.
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.