5 ms·

I would phrase almost the same idea from the opposite angle: focus on the fundamentals that never change, and view the trends in terms of how they relate to tho

I would phrase almost the same idea from the opposite angle: focus on the fundamentals that never change, and view the trends in terms of how they relate to those fundamentals. But also, those are some pretty odd comparisons. For sure Ansible and Terraform aren't directly comparable. If anything they're complementary. Terraform provisions machines (and also infra, etc), and Ansible configures provisioned machines.

kitd 3y ago
Lord, teach me to accept the things I cannot change, And use version control for the things I can ...
hardwaresofton 3y ago
> I would phrase almost the same idea from the opposite angle: focus on the fundamentals that never change, and view the trends in terms of how they relate to those fundamentals. Definitely -- I'd say that these questions force the understanding of the fundamentals, because that's what you get down to ("fundamental"/irreconcilable differences). The problem is that fundamentals can be similar, and sometimes the difference is elsewhere (UX/DX/perf for example). > But also, those are some pretty odd comparisons. So they are odd comparisons, in some sense -- but the point was to reflect the kind of questions someone who didn't know the answer would ask. Ansible and Terraform (and Salt/Puppet/Chef) are often presented in similar context and they're often confusing precisely because they are so close but different. The other example (CGI vs Serverless) is situation that's somewhat more targeted towards the age discussion -- did we churn over the years for churnings' sake? > For sure Ansible and Terraform aren't directly comparable. If anything they're complementary. Terraform provisions machines (and also infra, etc), and Ansible configures provisioned machines. What you've said is the usual rebuttal (and it's mostly right!), but did you know that Ansible did/does provisioning?[0] The lines aren't drawn as neatly as they seem to be. You can build a Terraform-like experience out of Ansible, if you wanted to, and it's important to know that and why you choose a tool like Terraform instead of traveling deep into Ansible land. All that said, if you prefer, replace "Ansible" with "Pulumi" (Full Disclosure: I'm firmly on the Pulumi side in the Terraform vs Pulumi debate). [0]: https://docs.ansible.com/ansible/latest/collections/index_module.html https://docs.ansible.com/ansible/latest/collections/index_mo...
- 28304283409234 3y ago
  A better comparison would perhaps be “ansible” vs “puppet” vs “chef”. I wrote everything in shell, then puppet, then chef, then ansible. Doing literally the same thing. Because fads.
  - hardwaresofton 3y ago
    Taking this comment in good faith, because HN... Do you really not see any difference between Ansible and a shell script? Even just the move between shell and bash/csh/tcsh/zsh whatever else can make a marked difference in productivity and ergonomics.
    - TeMPOraL 3y ago
      > Do you really not see any difference between Ansible and a shell script? Surely they do, but how much those differences matter depends on where those tools sit in relation to what you're trying to achieve. For example, I could write essays about the differences between bash and PowerShell, and about differences in productivity their various facets create, in both abstract and concrete terms. However, when my task is not about shell scripting per se, and the script plays only a minor role in the solution ("oh, but we can make the button launch a script that launches X"), and my main concern about that stage is to convince the team to use Bash and/or PWSH instead of making Python a dependency in the project - then bash and PWSH are really the same thing to me - any difference in productivity for that use case is dominated by one's familiarity with the tool, and none of it matters anyway if my co-worker succeeds slotting in Python for that use case. Similarly, there are many differences between bare shell scripts and Ansible, and there are differences between Ansible and Puppet and Chef too. But they're also close to each other, so if your use case doesn't hinge on those differences, you can be excused for wondering why can't we just keep using a Makefile for this.
    - allarm 3y ago
      I mean, yeah? Ansible has roles, collections and a great inventory system. There's a lot of extra steps if you want to use a shell script instead, to i.e. install Docker on multiple hosts running different OS versions. I don't really like Ansible, but I think it's quite good for provisioning. It's also super easy to write filters and plugins for extra functionality.
coldtea 3y ago
>Terraform provisions machines (and also infra, etc), and Ansible configures provisioned machines. Each of such tools expands to take the role of the other (and also read email)...
- CraigJPerry 3y ago
  Hmmm i feel like those tools naturally railroad you into a certain split of responsibilities. Sure - you could use tf’s local/remote-exec to do the stuff you’d normally do with ansible but man that would be annoying and slow going when you know you can reach for ansible. Vice versa, you could have an ansible playbook to call the cloud provider’s api and cook up some kind of approval workflow / state management but man that would be annoying and slow going when you know you can reach for terraform.
  - TeMPOraL 3y ago
    Do they integrate that well? I don't have much experience with either, and until this moment I understood them to be substitutes - but still, I thought that: > you could have an ansible playbook to call the cloud provider’s api and cook up some kind of approval workflow / state management Was generally what people did before Terraform, and they be reluctant to add another complex tool, significantly overlapping with the current complex tool, just to simplify a part that already works OK. Conversely, if Terraform is really so amazing as one would believe reading HN, then some amount of "local/remoe-exec" pain seems justified if it lets you avoid bringing in Ansible with all its complexity? All these tools cost not just storage and processing, but also brain space. A Makefile in a cron, running some shell scripts, may be more brittle than whatever cookbooks or playbooks or ${what's the name for Terraform's flavor of makefiles}, but is also might be easier to fix when something breaks.
xorcist 3y ago
> Terraform provisions machines (and also infra, etc), and Ansible configures provisioned machines Ansible can provision virtual machines as well, and from my experience it is better suited for it too, since it doesn't save state outside the system. So there's lesser chance for it to get out of sync. It's mostly culture. People these days learn GKE or Kubernetes first, and their tutorials mention Terraform so that's what they'll use. It used to be managed VMs and that culture was around Puppet, Ansible or Salt.
- sofixa 3y ago
  > Ansible can provision virtual machines as well, and from my experience it is better suited for it too, since it doesn't save state outside the system. So there's lesser chance for it to get out of sync. State serves a purposes, it's not just there for fun. Ansible will lose track of your VM if you rename it (and can barely handle you renaming it with itself), and won't delete it if you just delete it from the configuration file.
  - xorcist 3y ago
    > State serves a purposes, it's not just there for fun The system has state. The question is how we want to manage it. The design in this case chooses to opimize to lessen the impact of errors. All real world systems are prone to errors in the long run. If real world parables are excused: If the map (serialized state) and terrain (system state) differs, is it a good idea to insist on following the map? > Ansible will lose track of your VM if you rename it Sure, but so will Terraform. Or worse. > won't delete it if you just delete it from the configuration Sure it can. There are no limitations there. The only questions are whether you want it to, and how you want it to. Ansible is a superset of Terraform. It's mostly a matter of culture which tool people choose, and which you think is the easiest to use.
    - sofixa 3y ago
      > If the map (serialized state) and terrain (system state) differs, is it a good idea to insist on following the map? If you're doing landscaping and the map is your requirements, yes. And that's what infrastructure is comparable to (hence Terraform's name btw) > > Ansible will lose track of your VM if you rename it > Sure, but so will Terraform. Or worse. No it won't, because Terraform stores the underlying platform ID in it's state. It will just know there was a rename, and will inform you it plans on rolling it back to what you have requested in the configuration. It won't delete it. Ansible will want to recreate it, with all conflicts this could bring. > Ansible is a superset of Terraform. It's mostly a matter of culture which tool people choose, and which you think is the easiest to use. It's a different tool for a different job (at which it isn't great due to using a markup language which really doesn't lend itself to templating with lots of templating, and a dynamic language that suffers from version and dependency hell).
jerf 3y ago
A great example of the narcissism of small differences [1]. Locally in the space of management tools, terraform and ansible are very different beasts, in that they can hardly even manage the same tasks. Globally, if you plot all software in the world on some big graph, they are right next to each other and indistinguishable on a plot that has "video games" and "databases" and "routing software" and "spacecraft code", etc. [1]: https://en.wikipedia.org/wiki/Narcissism_of_small_differences https://en.wikipedia.org/wiki/Narcissism_of_small_difference...
pizzafeelsright 3y ago
I did a 3x of my career by doing this. Now everything thing looks like a shell script or json exchange. Ansible is a bunch of scripts. Terraform is a bunch of json exchanges.

kitd 3y ago

Lord, teach me to accept the things I cannot change, And use version control for the things I can ...

hardwaresofton 3y ago

> I would phrase almost the same idea from the opposite angle: focus on the fundamentals that never change, and view the trends in terms of how they relate to those fundamentals. Definitely -- I'd say that these questions force the understanding of the fundamentals, because that's what you get down to ("fundamental"/irreconcilable differences). The problem is that fundamentals can be similar, and sometimes the difference is elsewhere (UX/DX/perf for example). > But also, those are some pretty odd comparisons. So they are odd comparisons, in some sense -- but the point was to reflect the kind of questions someone who didn't know the answer would ask. Ansible and Terraform (and Salt/Puppet/Chef) are often presented in similar context and they're often confusing precisely because they are so close but different. The other example (CGI vs Serverless) is situation that's somewhat more targeted towards the age discussion -- did we churn over the years for churnings' sake? > For sure Ansible and Terraform aren't directly comparable. If anything they're complementary. Terraform provisions machines (and also infra, etc), and Ansible configures provisioned machines. What you've said is the usual rebuttal (and it's mostly right!), but did you know that Ansible did/does provisioning?[0] The lines aren't drawn as neatly as they seem to be. You can build a Terraform-like experience out of Ansible, if you wanted to, and it's important to know that and why you choose a tool like Terraform instead of traveling deep into Ansible land. All that said, if you prefer, replace "Ansible" with "Pulumi" (Full Disclosure: I'm firmly on the Pulumi side in the Terraform vs Pulumi debate). [0]: https://docs.ansible.com/ansible/latest/collections/index_module.html https://docs.ansible.com/ansible/latest/collections/index_mo...

28304283409234 3y ago
A better comparison would perhaps be “ansible” vs “puppet” vs “chef”. I wrote everything in shell, then puppet, then chef, then ansible. Doing literally the same thing. Because fads.
- hardwaresofton 3y ago
  Taking this comment in good faith, because HN... Do you really not see any difference between Ansible and a shell script? Even just the move between shell and bash/csh/tcsh/zsh whatever else can make a marked difference in productivity and ergonomics.
  - TeMPOraL 3y ago
    > Do you really not see any difference between Ansible and a shell script? Surely they do, but how much those differences matter depends on where those tools sit in relation to what you're trying to achieve. For example, I could write essays about the differences between bash and PowerShell, and about differences in productivity their various facets create, in both abstract and concrete terms. However, when my task is not about shell scripting per se, and the script plays only a minor role in the solution ("oh, but we can make the button launch a script that launches X"), and my main concern about that stage is to convince the team to use Bash and/or PWSH instead of making Python a dependency in the project - then bash and PWSH are really the same thing to me - any difference in productivity for that use case is dominated by one's familiarity with the tool, and none of it matters anyway if my co-worker succeeds slotting in Python for that use case. Similarly, there are many differences between bare shell scripts and Ansible, and there are differences between Ansible and Puppet and Chef too. But they're also close to each other, so if your use case doesn't hinge on those differences, you can be excused for wondering why can't we just keep using a Makefile for this.
  - allarm 3y ago
    I mean, yeah? Ansible has roles, collections and a great inventory system. There's a lot of extra steps if you want to use a shell script instead, to i.e. install Docker on multiple hosts running different OS versions. I don't really like Ansible, but I think it's quite good for provisioning. It's also super easy to write filters and plugins for extra functionality.

coldtea 3y ago

>Terraform provisions machines (and also infra, etc), and Ansible configures provisioned machines. Each of such tools expands to take the role of the other (and also read email)...

CraigJPerry 3y ago
Hmmm i feel like those tools naturally railroad you into a certain split of responsibilities. Sure - you could use tf’s local/remote-exec to do the stuff you’d normally do with ansible but man that would be annoying and slow going when you know you can reach for ansible. Vice versa, you could have an ansible playbook to call the cloud provider’s api and cook up some kind of approval workflow / state management but man that would be annoying and slow going when you know you can reach for terraform.
- TeMPOraL 3y ago
  Do they integrate that well? I don't have much experience with either, and until this moment I understood them to be substitutes - but still, I thought that: > you could have an ansible playbook to call the cloud provider’s api and cook up some kind of approval workflow / state management Was generally what people did before Terraform, and they be reluctant to add another complex tool, significantly overlapping with the current complex tool, just to simplify a part that already works OK. Conversely, if Terraform is really so amazing as one would believe reading HN, then some amount of "local/remoe-exec" pain seems justified if it lets you avoid bringing in Ansible with all its complexity? All these tools cost not just storage and processing, but also brain space. A Makefile in a cron, running some shell scripts, may be more brittle than whatever cookbooks or playbooks or ${what's the name for Terraform's flavor of makefiles}, but is also might be easier to fix when something breaks.

xorcist 3y ago

> Terraform provisions machines (and also infra, etc), and Ansible configures provisioned machines Ansible can provision virtual machines as well, and from my experience it is better suited for it too, since it doesn't save state outside the system. So there's lesser chance for it to get out of sync. It's mostly culture. People these days learn GKE or Kubernetes first, and their tutorials mention Terraform so that's what they'll use. It used to be managed VMs and that culture was around Puppet, Ansible or Salt.

sofixa 3y ago
> Ansible can provision virtual machines as well, and from my experience it is better suited for it too, since it doesn't save state outside the system. So there's lesser chance for it to get out of sync. State serves a purposes, it's not just there for fun. Ansible will lose track of your VM if you rename it (and can barely handle you renaming it with itself), and won't delete it if you just delete it from the configuration file.
- xorcist 3y ago
  > State serves a purposes, it's not just there for fun The system has state. The question is how we want to manage it. The design in this case chooses to opimize to lessen the impact of errors. All real world systems are prone to errors in the long run. If real world parables are excused: If the map (serialized state) and terrain (system state) differs, is it a good idea to insist on following the map? > Ansible will lose track of your VM if you rename it Sure, but so will Terraform. Or worse. > won't delete it if you just delete it from the configuration Sure it can. There are no limitations there. The only questions are whether you want it to, and how you want it to. Ansible is a superset of Terraform. It's mostly a matter of culture which tool people choose, and which you think is the easiest to use.
  - sofixa 3y ago
    > If the map (serialized state) and terrain (system state) differs, is it a good idea to insist on following the map? If you're doing landscaping and the map is your requirements, yes. And that's what infrastructure is comparable to (hence Terraform's name btw) > > Ansible will lose track of your VM if you rename it > Sure, but so will Terraform. Or worse. No it won't, because Terraform stores the underlying platform ID in it's state. It will just know there was a rename, and will inform you it plans on rolling it back to what you have requested in the configuration. It won't delete it. Ansible will want to recreate it, with all conflicts this could bring. > Ansible is a superset of Terraform. It's mostly a matter of culture which tool people choose, and which you think is the easiest to use. It's a different tool for a different job (at which it isn't great due to using a markup language which really doesn't lend itself to templating with lots of templating, and a dynamic language that suffers from version and dependency hell).

jerf 3y ago

A great example of the narcissism of small differences [1]. Locally in the space of management tools, terraform and ansible are very different beasts, in that they can hardly even manage the same tasks. Globally, if you plot all software in the world on some big graph, they are right next to each other and indistinguishable on a plot that has "video games" and "databases" and "routing software" and "spacecraft code", etc. [1]: https://en.wikipedia.org/wiki/Narcissism_of_small_differences https://en.wikipedia.org/wiki/Narcissism_of_small_difference...

pizzafeelsright 3y ago

I did a 3x of my career by doing this. Now everything thing looks like a shell script or json exchange. Ansible is a bunch of scripts. Terraform is a bunch of json exchanges.