Seasoned advice about SaltStack
May 01, 2017

Seasoned advice about SaltStack

Jeremy McMillan | TrustRadius Reviewer
Score 10 out of 10
Vetted Review
Verified User

Software Version

SaltStack (legacy)

Overall Satisfaction with VMware vRealize Automation, with SaltStack Config

We use SaltStack to orchestrate and configure complex integration lab environments for instructional workshops. We are developing a full-cycle cloud portable/agnostic DevOps workflow template for Hybris Commerce projects to support full velocity distributed development efforts with CI and CD pipeline.
  • One tool to provide both configuration management and orchestration at any scale.
  • Modular and extensible code (modules, formulas, packages) with a very active community promotes community-style development within your own organization.
  • Great documentation has made massive strides in the past two years.
  • Masterless (serverless) and salt-ssh (agentless) features are not as well documented or easy to use as other competitive technologies (ie. Ansible).
  • Debugging YAML+Jinja templated configuration is getting better, but is still occasionally frustrating. Diligent testing on small changes helps, but it's easy to get lost doing too much too fast.
  • Best practices and features have improved a lot in the past year, but much of the community code needs to be updated to take advantage of them.
  • Combined orchestration and configuration management allows one or two engineers to manage all of the Hybris Sysadmin Workshop lab infrastructure for multiple concurrent workshops combined.
  • SaltStack provides in one tool, configuration management which serves the functions of systems management, audit, and change management.
  • Getting ROI from SaltStack or any DevOps tool requires a cultural ambassador to build and develop process requirements and DevOps architecture, and while this can have dramatic bottom line results, people often struggle to adapt, so implementation can be stilted by lack of leadership.
  • DevOps in general should not be pursued as a way to recover operational costs on its own, but rather to use operational savings to subsidize increased quality. SaltStack requires infrastructure investments, and development investments, and time investments for additional testing cycles in the pipeline. The ROI it produces is enabling more, faster parallel development, without sacrificing the ability to maintain testing and quality, or to increase testing and quality while maintaining or reducing the cost of quality process. If you just want more for less and you're willing to ship broken product to get better short term bottom line: just ship broken product, skip the DevOps investment.
I've used shell scripts over ssh, custom in-house deployment tools, Chef, and SaltStack. I've evaluated Ansible, but I was never happy with performance over SSH. Chef's loose configuration data model and lack of philosophy and conventions around use makes it difficult for a team to share responsibility for configuration code. Needing to use additional tools to do orchestration for cross-host/agent dependency relationships made me look for more. SaltStack, while not as mature when I first tried it, impressed me with its speed and elegant design.
SaltStack is a very well architected toolset and framework for reliably managing distributed systems' complexity at varied scale. If the diversity of kind or number of assets is low, or the dependencies are bounded and simple, it might be overkill. Realization that you need SaltStack might come in the form of other tools, scripts, or jobs whose code has become difficult, unreliable, or unmaintainable. Rather than a native from-scratch SaltStack design, be aware that SaltStack can be added on to tools like Docker or Chef and optionally factor those tools out or other tools into the mix.