3 ms·
I'm all about IT automation and like the tech a lot, but after running SaltStack for 5 years, I decided to transition to plain old written documentation. When
by xenophonf 6y ago
I'm all about IT automation and like the tech a lot, but after running SaltStack for 5 years, I decided to transition to plain old written documentation. When you consider everything that underlies the "infrastructure as code" tech stack, it ends up being an extremely steep learning curve. I was very productive with SaltStack but turned into the only person who could write or edit our deployment scripts. It was a bad situation.
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.
- chucky_z 6y agoSo you went from full automation to... Copying and pasting by hand?
- rexarex 6y agoAre you seriously telling me that you went from infrastructure as code to doing things by hand!?
- xenophonf 6y agoWe were always doing things by hand. I was the only one doing any kind of IT automation, and I failed to account for the learning curve of my tooling when trying to expand its use. At least now, the entire team—not just me—is doing a better job of documenting what they're doing by hand. 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.