Something about Salt has always rubbed me the wrong way. I'd rather stick with Puppet, Chef, or CF Engine if I was considering this tool.
Now, nine months after dropping SaltStack, my colleagues are editing the docs I've created, and more importantly, they're also writing their own. That's a huge win. What I've lost in terms of personal productivity, I've regained in terms of wider participation in our standardization and documentation efforts.
I might slowly re-introduce IT automation technologies, maybe something more popular like Ansible or Docker, but only after making sure the rest of my team has a solid understanding of general IT automation concepts. I think we're on the right track. I had a colleague today ask me about what Python programming certification they should get, so I pointed them toward Google's Python-based IT automation course on Coursera. I supported another colleague's efforts to create a library of standard server images based on our internal deployment standards for one of our private clouds, and I'm encouraging them to expand that work to our other data centers. And so on. The team as a whole works better together, so that's where I'm staying focused.
The reality is that devops toolchains are really complex. For example, to use SaltStack the way I had things set up, it meant learning:
- SaltStack's domain-specific programming language, which amounts to writing Python in YAML
- their macro preprocessor, Jinja, which has completely different syntax and semantics than their DSL
- a programming text editor that supports YAML and Jinja
- Git and GitHub
- secrets management (and there were huge risks here)
- the general concepts of IT automation and infrastructure-as-code
Learning (never mind teaching) that tech stack is really hard. For example, the Google IT Automation with Python certification on Coursera is an 8-month-long course. That's just one bullet point on the above list, and that list doesn't include all the things I wanted to do on top of SaltStack, namely the continuous integration/continuous testing stuff, which would involve learning:
- the Chef InSpec DSL, which is based on Ruby
- branching and tagging
- release engineering
- test-driven development as a software engineering methodology
- software engineering methodology in general
We were struggling with even just writing good documentation, but there I was asking everyone to write good code. That's orders of magnitude harder. It was too much, like asking somebody to run a marathon without any training. I don't care how fit you are. That's just not going to happen.