6 ms·

Terraform is quite generic in its nature. At the end of the day it's just a state management tool. We decided to start there as it's the de facto IaC tool, but

Terraform is quite generic in its nature. At the end of the day it's just a state management tool. We decided to start there as it's the de facto IaC tool, but we are planning on launching a web portal soon and offer other ways to interact with Multy in the future such as an SDK and a CLI tool.

latchkey 4y ago
If TF was generic, your tool wouldn't be needed. My experience with TF is that it is a terrible SMT because they did non-backwards-compatible upgrades to the state file... which made it impossible to redeploy and I had to not only start over with the state file but also recode a bunch of my TF code to support the underlying plugin changes. Of course this was long ago before it was a final 1.0 version so I'm supposed to give some flex there, but it put me off badly enough that I'd never consider TF a SMT. At the end of the day, as long as your tool is on top of TF, it will always be a function of the developer to understand all of the idiosyncrasies of not only the different cloud layers, but also the underlying tool. I think you're trying to solve a great problem, but basing it on TF doesn't help. You asked for feedback... don't use TF.
- 0xbadcafebee 4y ago
  Or at least use CDKTF which allows you to code around problems, rather than bash your head against TF's awfulness. https://www.terraform.io/cdktf https://www.terraform.io/cdktf
  - latchkey 4y ago
    Wow, that's kind of cool. Didn't know about that. It is me, or is it weird that this has a hard constructor dependency on Constructs[1], which is pretty much undocumented? At least in golang, this brings in some other dependencies and golang init() reflect code [2], which then depends on interacting with javascript!? [3]... something smells odd here. [1] https://github.com/aws/constructs-go https://github.com/aws/constructs-go [2] https://github.com/aws/constructs-go/blob/main/constructs/constructs.init.go https://github.com/aws/constructs-go/blob/main/constructs/co... [3] https://github.com/aws/jsii/ https://github.com/aws/jsii/
    - 0xbadcafebee 4y ago
      "CDKTF uses Typescript types to generate an assembly file that jsii uses to generate the code bindings for the other supported languages." Yep, sounds like Terraform-level awfulness. Although they actually took the design from AWS CDK, so I guess we can blame AWS for it.
- NotTameAntelope 4y ago
  This just sounds like you don't like TF, and no matter how well executed this tool would be, you'd always criticize it for using TF. I wouldn't really call that feedback, just a luddite-esque bias on your part. I'm pattern matching your "feedback" as "New thing scary, don't use!"
  - latchkey 4y ago
    Correct, I don't like TF, based on some real world experience using it. I also think it is fair to say that my complaint is valid. Luddite? The 20k+ servers that I manage disagree with you. =)
    - NotTameAntelope 4y ago
      You even admit you haven't used TF in a long time, and when you did use TF it hadn't been 1.0 yet, which means you should fully expect breaking changes to take place. In no way is your complaint valid for a technology that hadn't even been released yet, and you should know that. And a "luddite" is just "a person opposed to new technology or ways of working." How many servers you do or don't manage is totally irrelevant to that. Terraform is new, you dislike it because it's new (my guess), therefore you are a luddite. Did you think I was claiming you belonged to the group of 19th century English mill workers who destroyed factory machinery to protest those machines taking your job?
      - latchkey 4y ago
        fool me once, shame on you; fool me twice, shame on me.
        NotTameAntelope 4y ago
        Yes shame on you for not realizing a 0.x versioned technology would make breaking changes on minor version updates. Given: 1) Terraform uses Semantic Versioning [0] 2) Semantic Versioning specifically states that 0.x APIs are not stable [1] Therefore: Your complaint that a 0.x versioned tool wasn't stable is not valid. Conjecture: Your complaint exists as an excuse to remain ignorant of a new tool or technology simply because it is new. This makes you a luddite. [2] [0] https://www.terraform.io/plugin/sdkv2/best-practices/versioning#versioning-specification https://www.terraform.io/plugin/sdkv2/best-practices/version... [1] https://semver.org/#spec-item-4 https://semver.org/#spec-item-4 [2] https://www.google.com/search?q=define%3A+luddite https://www.google.com/search?q=define%3A+luddite
- yunohn 4y ago
  > If TF was generic, your tool wouldn't be needed. This is unclear to me, and seems easily false. The problem lies with cloud provider idiosyncrasies, not the configuration layer.
  - latchkey 4y ago
    It is a fundamental issue with TF. It wasn't designed to support that. It isn't generic, it is very specific with the providers. Bolting a generic provider running on top of that isn't going to solve the underlying problems with TF/HCL.

latchkey 4y ago

If TF was generic, your tool wouldn't be needed. My experience with TF is that it is a terrible SMT because they did non-backwards-compatible upgrades to the state file... which made it impossible to redeploy and I had to not only start over with the state file but also recode a bunch of my TF code to support the underlying plugin changes. Of course this was long ago before it was a final 1.0 version so I'm supposed to give some flex there, but it put me off badly enough that I'd never consider TF a SMT. At the end of the day, as long as your tool is on top of TF, it will always be a function of the developer to understand all of the idiosyncrasies of not only the different cloud layers, but also the underlying tool. I think you're trying to solve a great problem, but basing it on TF doesn't help. You asked for feedback... don't use TF.

0xbadcafebee 4y ago
Or at least use CDKTF which allows you to code around problems, rather than bash your head against TF's awfulness. https://www.terraform.io/cdktf https://www.terraform.io/cdktf
- latchkey 4y ago
  Wow, that's kind of cool. Didn't know about that. It is me, or is it weird that this has a hard constructor dependency on Constructs[1], which is pretty much undocumented? At least in golang, this brings in some other dependencies and golang init() reflect code [2], which then depends on interacting with javascript!? [3]... something smells odd here. [1] https://github.com/aws/constructs-go https://github.com/aws/constructs-go [2] https://github.com/aws/constructs-go/blob/main/constructs/constructs.init.go https://github.com/aws/constructs-go/blob/main/constructs/co... [3] https://github.com/aws/jsii/ https://github.com/aws/jsii/
  - 0xbadcafebee 4y ago
    "CDKTF uses Typescript types to generate an assembly file that jsii uses to generate the code bindings for the other supported languages." Yep, sounds like Terraform-level awfulness. Although they actually took the design from AWS CDK, so I guess we can blame AWS for it.
NotTameAntelope 4y ago
This just sounds like you don't like TF, and no matter how well executed this tool would be, you'd always criticize it for using TF. I wouldn't really call that feedback, just a luddite-esque bias on your part. I'm pattern matching your "feedback" as "New thing scary, don't use!"
- latchkey 4y ago
  Correct, I don't like TF, based on some real world experience using it. I also think it is fair to say that my complaint is valid. Luddite? The 20k+ servers that I manage disagree with you. =)
  - NotTameAntelope 4y ago
    You even admit you haven't used TF in a long time, and when you did use TF it hadn't been 1.0 yet, which means you should fully expect breaking changes to take place. In no way is your complaint valid for a technology that hadn't even been released yet, and you should know that. And a "luddite" is just "a person opposed to new technology or ways of working." How many servers you do or don't manage is totally irrelevant to that. Terraform is new, you dislike it because it's new (my guess), therefore you are a luddite. Did you think I was claiming you belonged to the group of 19th century English mill workers who destroyed factory machinery to protest those machines taking your job?
    - latchkey 4y ago
      fool me once, shame on you; fool me twice, shame on me.
      - NotTameAntelope 4y ago
        Yes shame on you for not realizing a 0.x versioned technology would make breaking changes on minor version updates. Given: 1) Terraform uses Semantic Versioning [0] 2) Semantic Versioning specifically states that 0.x APIs are not stable [1] Therefore: Your complaint that a 0.x versioned tool wasn't stable is not valid. Conjecture: Your complaint exists as an excuse to remain ignorant of a new tool or technology simply because it is new. This makes you a luddite. [2] [0] https://www.terraform.io/plugin/sdkv2/best-practices/versioning#versioning-specification https://www.terraform.io/plugin/sdkv2/best-practices/version... [1] https://semver.org/#spec-item-4 https://semver.org/#spec-item-4 [2] https://www.google.com/search?q=define%3A+luddite https://www.google.com/search?q=define%3A+luddite
yunohn 4y ago
> If TF was generic, your tool wouldn't be needed. This is unclear to me, and seems easily false. The problem lies with cloud provider idiosyncrasies, not the configuration layer.
- latchkey 4y ago
  It is a fundamental issue with TF. It wasn't designed to support that. It isn't generic, it is very specific with the providers. Bolting a generic provider running on top of that isn't going to solve the underlying problems with TF/HCL.