"So your argument is that anybody using Chef or Puppet, or just about any master/agent-based CM shouldn't manage systems. I guess a lot of people would be out o

"So your argument is that anybody using Chef or Puppet, or just about any master/agent-based CM shouldn't manage systems. I guess a lot of people would be out of jobs then." I said nothing of the sort. Please quote me. "There are a number of tools to "bake it" into the original image. Most people don't really "bake it", they bootstrap it using things like cloud-init. And it can most definitively bootstrap itself into an environment." I would be interested to see Puppet/Chef bootstrap its self into an environment. It could be useful for future use cases. "While a novel approach to automatic scaling it seems rather hacky, instead of using the tools provided by whatever provider you're using, that are built for this exact thing. I can see a number of things that can, and probably will, go wrong with that setup. Sensu having a hiccup, f.ex." Because using what your Cloud provider gives you is locking you into that vendor. Amazon and Google both have great offerings when it comes to autoscaling various bits of your estate, but the moment you start using features they offer you, features no one else offers (so virtually all of Amazon's catalog, then), it becomes incredibly difficult to move away from that provider. "And your assumptions about me not trying Ansible is incorrect. I've used it, and I like some of the concepts of it. But for anything other than one-off configurations or smaller environments, moving to Puppet was an easy choice. Speed being one of the biggest factor, and Puppet is slow as fuck compared to say, Chef. How do you do testing in Ansible?" Fair enough. Then I withdraw and apologise for my bad assumption. I've never really found Anible to be slow, because I manage networks in chunks, correctly partitioned, and fenced from each other, which means an update to a product, service, or resource is generally done on only a few servers. If I had an estate with, let's say, 500 web servers in it and those servers were on a flat network (the same VLAN), I wouldn't dream of rolling out a change to their configuration in one big swoop. That would be a mental thing to do. Instead I would do it with chunks of servers at a time, something Ansible can do for you. I would also utilise Ansible's failsafe features, so if there are any or enough errors during a run, it will back off and stop provisioning. I'm sure Puppet/Chef can do this to. "The last remark wasn't an attempt at "school playground", just a factual statement to counter the argument the article raised about old versions of Chef. If you can't upgrade your packages, the why are you even looking at CM?" This is true to a point, but if you're like me, you're probably bored of the OS by now. I am. I don't want to play around with kernel params, disk issues, packages, etc... I want that abstracted away and made easier. Also, I've seen people, friends of mine, successfully take someone from zero to hero with regards to Linux, using Ansible as a learning tool: you do something in Ansible, you look at and understand the result. It complements learning nicely. "I never said that Ansible was insecure, or somehow more insecure than Puppet or Chef, I'm not sure where you even think I wrote that." You said: "Security will always be an issue, thinking that Ansible solves all issues is naive." And my response is: security is a complex matter, but one way to reduce that complexity is through the use of as little software as possible. Ansible introduces virtually ZERO new pieces of software on your network (the actual boxes you're provisioning), Puppet and Chef introduce a lot, way too much, across your entire estate, and thus is less secure by definition.