The biggest problem with puppet/ansible/salt is the automatic retort: “Oh they weren’t doing puppet/ansible/salt/etc correctly”, instead of dealing with actual problems.
I’ve worked too many times with that madness that thinks waiting 30 minutes for all their automation scripts to update things is the best they can do. Or they insist on duplicating infrastructure costs (in our shop: £250k) so they can do blue/green testing they read about in a blog.
I’ve been using a configuration management system for a year now. As a tool, it really saved me: I was having trouble maintaining my machines–like one crisis from disaster trouble. SaltStack turned out to be a ridiculously good fit for me, and it completely obliterated a whole class of problems I was experiencing. This tool has made my life seriously better.
That said, having spent time in the code and dealing with upgrades breaking changes–I have sought to strictly limit the kinds of things I do with SaltStack. Particularly I have avoided all but the most basic modules, but even doing so the control flow provided by Salt is painful to use.
This pain came to a head when minor configuration changes took 10+ minutes to propagate–imagine me sitting on the phone to fix an issue, but then having to tell my user to hang on while the code runs. Absolutely unacceptable.
I found that it is faster to pull the data out of salt, crunch it in a script, and then blast it back out to the minions. Bypassing the whole engine that is supposed to be doing that for me. With a little imagination on my part I could remove salt entirely. I’m not there yet, I get too much value out of it, but increasingly that value comes to me in ways the developers haven’t anticipated. Maybe that’s one reason I’m not having the trouble the author of this piece is frustrated about.
I’m worried that Salt, owing to it’s commercial ambitions, will add even more modules and features to components I neither use nor need, making the pieces I’m interested in (machine targeting and state composition) useless as a result.
I’m worried that Salt, owing to it’s commercial ambitions, will add even more modules and features to components I neither use nor need
This is the basic issue I’ve run into with various CMs. The very nature of them, IMO, is not VC or commercial friendly. It’s kind of like init systems, to me. I like simple and magicless. I haven’t used many CM systems, but the few I have used seem to go in the direction of wanting to make something really easy at the cost of not being able to understand what on earth is going on.
All of these tools are weird impedance mis-matches with what you actually want to do on a machine. They make some things easy (as in, “I only have to write one line in order to execute hundreds of lines of interpreted code to call a native binary”), but in the worst case force you to write sh through multiple layers of indirection.
Sh may be dark and full of dangers, but I’ve also never had a shell script break because all the regexps were suddenly wrong or the expansion rules changed.
The biggest problem with puppet/ansible/salt is the automatic retort: “Oh they weren’t doing puppet/ansible/salt/etc correctly”, instead of dealing with actual problems.
I’ve worked too many times with that madness that thinks waiting 30 minutes for all their automation scripts to update things is the best they can do. Or they insist on duplicating infrastructure costs (in our shop: £250k) so they can do blue/green testing they read about in a blog.
I’ve been using a configuration management system for a year now. As a tool, it really saved me: I was having trouble maintaining my machines–like one crisis from disaster trouble. SaltStack turned out to be a ridiculously good fit for me, and it completely obliterated a whole class of problems I was experiencing. This tool has made my life seriously better.
That said, having spent time in the code and dealing with upgrades breaking changes–I have sought to strictly limit the kinds of things I do with SaltStack. Particularly I have avoided all but the most basic modules, but even doing so the control flow provided by Salt is painful to use.
This pain came to a head when minor configuration changes took 10+ minutes to propagate–imagine me sitting on the phone to fix an issue, but then having to tell my user to hang on while the code runs. Absolutely unacceptable.
I found that it is faster to pull the data out of salt, crunch it in a script, and then blast it back out to the minions. Bypassing the whole engine that is supposed to be doing that for me. With a little imagination on my part I could remove salt entirely. I’m not there yet, I get too much value out of it, but increasingly that value comes to me in ways the developers haven’t anticipated. Maybe that’s one reason I’m not having the trouble the author of this piece is frustrated about.
I’m worried that Salt, owing to it’s commercial ambitions, will add even more modules and features to components I neither use nor need, making the pieces I’m interested in (machine targeting and state composition) useless as a result.
This is the basic issue I’ve run into with various CMs. The very nature of them, IMO, is not VC or commercial friendly. It’s kind of like init systems, to me. I like simple and magicless. I haven’t used many CM systems, but the few I have used seem to go in the direction of wanting to make something really easy at the cost of not being able to understand what on earth is going on.
All of these tools are weird impedance mis-matches with what you actually want to do on a machine. They make some things easy (as in, “I only have to write one line in order to execute hundreds of lines of interpreted code to call a native binary”), but in the worst case force you to write sh through multiple layers of indirection.
Sh may be dark and full of dangers, but I’ve also never had a shell script break because all the regexps were suddenly wrong or the expansion rules changed.