The other thing that should be noted is that ansible feels like (shell scripting)++. Other competitors I've used needed a much heavier cognitive load to get started.
> The other thing that should be noted is that ansible feels like (shell scripting)++. Other competitors I've used needed a much heavier cognitive load to get started.
Having used Chef, Puppet, and Ansible, this is exactly why I prefer Ansible for all my projects now.
If you can write a shell script, you can write an Ansible playbook. It won't be a great playbook, and you get benefits from using their modules instead of shell commands (like idempotency). But you don't have to worry about learning a new DSL just to do write a basic playbook or tweak an existing one.
As a functional programmer, I understand the benefits and appeal of declarative syntax. Unfortunately, systems programming is the one place where it's really hard to be 100% declarative, because systems are inherently all about state[0].
[0] At least in 2015 - perhaps things will change as we move toward better containerization models
The only comparable system that I believe is a match for Ansible is SaltStack.
> As a functional programmer, I understand the benefits and appeal of declarative syntax. Unfortunately, systems programming is the one place where it's really hard to be 100% declarative, because systems are inherently all about state[0].
Have you looked into Nix/NixOS/NixOps? I think they have a really good approach to "functional configuration mgmt".
> perhaps things will change as we move toward better containerization models
I agree. When using scrappable VMs/containers (deploy to a new one, then scrap the old one) that are build from a description, it is in some ways quite close to approach in the Nix-camp.
And it's also not that it's just a /new/ DSL - every so often I find the DSLs annoyingly limited compared to having a full fledged programming language.