Comment by hardwaresofton | Hacker News Reader

Comment by hardwaresofton | Hacker News Reader

Parent Full thread

While I'm not a proper sysadmin, Ansible is what I gravitated towards (and use for my own projects) and always seemed like the best choice out of Chef, Puppet, and Saltstack.

Ansible is/was straight forward to use and understand, very F/OSS, relatively easy to orchestrate (even without tower), and had a nice ecosystem. Ansible always won for me because it was simple, and had just enough (though I always felt that the roles/tasks analogy was kind of awkward) and was easy to hack. These things were mostly true about Chef, but outside of being "ansible, but ruby", I don't remember distinctly what made Chef worth doing other than if it was there before you got there.

Someone please correct me if I'm wrong but IIRC Salt was one of the first to start venturing into the infrastructure provisioning realm and ansible went there too relatively easily though it's somewhat obscure[0]. Ansible and Chef (and presumably puppet) were quick to follow/build similar tooling but we all know who won that race -- Terraform.

Funnily enough, Terraform is now making it's way back around to eat the post-deploy logic as well with it's provisioners[1]. Can't wait to see HCL grow into an even more grotesque monster.

[0]: https://www.ansible.com/use-cases/provisioning

[1]: https://www.terraform.io/docs/provisioners/

Another approach that we have been exploring with Terraform is to treat the machine configuration as resources[1]. It works pretty well when most of the system is vanilla with a few additions to it (like installing Docker).

[1]: https://github.com/numtide/terraform-provider-linuxbox

Thanks for making this available as open source -- I was about to note that this is exactly what providers are for, then read the use-cases and the support/API surface you've crafted, this looks super useful.

I was anti-HCL/Terraform for a long time due to issues with state files, but lately I honestly prefer it over Ansible whenever possible.. although I'm still not happy with the way cloud-init works on various cloud providers.

I'd like to recommend that you try pulumi. Terraform is definitely a fantastic tool, and it really does have just about everything you want (and is extremely google-able with easy to find experts), but I think the bring-your-own-language paradigm is better for this particular use case if a few things are true:

- Your team is comfortable with at least one of the languages Pulumi has native support for, ideally your codebase/infrastructure repo is already written in it.

- Someone on your team isn't going to hang everyone else and themselves with the wide open nature of a fully featured programming language at their fingertips

- You've got some innovation tokens to spend

I think HCL is going to get more and more like a fully featured language as time goes on -- if they ever lean in to it (and introduce support for alternative "language runtimes" or something) then I would go terraform and never look back.

It's hard to recommend pulumi over terraform because of momentum, ecosystem, etc, but it does seem like a better base to start off of (and it's what I use for my own stuff).

And also because terraform is also working on enabling other languages on top of it: https://www.hashicorp.com/blog/cdk-for-terraform-enabling-py...

Thanks so much for the pointer, didn't know this existed -- it's exactly what I was hoping they might do.

> Today, we are pleased to announce the community preview of the Cloud Development Kit for HashiCorp Terraform which allows users to define infrastructure using TypeScript and Python while leveraging the hundreds of providers and thousands of module definitions provided by Terraform and the Terraform ecosystem.

> CDK for Terraform is in alpha and is in the early stages of development. This project is another way to interface with Terraform using languages like TypeScript and Python. We are working to support additional languages such as JavaScript, Java, and C#. In addition to language support, we plan on expanding the scope of CDK for Terraform project to support other first-class commands to provide a user experience similar to the AWS CDK.

This has to be a shot across the bow at pulumi, glad Pulumi innovated and took this direction (maybe CDK was on the roadmap at Hashicorp, not sure) and seemingly spurred TF taking the turn as well.

HCL, Jinja, Go Templates, etc are much easier for people to read and understand than standard programming languages. If you're going to use a standard programming language to write your IaaS then you might as well just use the native SDKs rather than an overlay.

Reply on news.ycombinator.com