Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

All three of those tools immediately felt, to me, like the wrong approach the moment I first experienced Docker. The notion that production infrastructure should be mutable and we use automation to make changes to it just introduces so much more state than is necessary. Immutable infrastructure eliminates so many sources issues.

And I think that's where the comment you're responding to is coming from. Once you've experienced Docker/K8s and, to a lesser extent, IaC tools like Terraform, it's hard to see yourself ever going back to tools like Chef in the same way that tools like Chef made it hard to see going back to a world where we configured servers manually.



Docker, k8s, Terraform etc are nice. I make extensive use of them too. But in my opinion they can't be used for everything, because mutable infrastructure is a reality of the world that must be accounted for at some point. For example, at my employer we have on-prem k3s clusters running on bare metal servers. Chef is a perfect tool to manage those, because they are by their nature not something we can treat as stateless, immutable configurations.

It seems to me that this is kind of like abstraction levels in programming. If you can use a high level language with lots of powerful tools, you do. But some people have to live in the world of C or even assembly, because (as James Mickens said) you can't just place a Lisp book on top of an x86 chip and hope it learns about lambda calculus by osmosis. I view IaC tools in the same way: if you can use Terraform or Docker, great! But someone has to use lower level tools to provide the environment in which those things exist. And that's why people shouldn't look at Chef (or other similar tools) as outdated, any more than assembly is outdated just because Lisp exists. They still very much have a strong use case that won't ever go away.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: