VMware Aria Automation Reviews

• Distributed shell: Ability to execute remote commands on all targets at once.
• Package Helper: Upgrades all your machines with one command: The package method of SaltStack allows easy host updates. (See https://docs.saltstack.com/en/... .)

We spent far less time to upgrade and configure all of our hosts. A lot of time was saved.

I'm not aware if a UI exists or not. There are a lot of possibilities, like having a kind of dashboard that would recap all of the states and responses to commands.

I’ve used this solution for four years.

I have not encountered any stability issues.

It is very scalable!

I have not used technical support.

This is the first solution I have used.

The setup was pretty straightforward, especially compared to "legacy" solutions.

It is non-paid product usage.

I evaluated Ansible.

Read the documentation. There is nothing fancy or special to know before using it.

• Simple and flexible YAML/JSON configuration management framework which allows simultaneous configuration of thousands of systems
• “Reactor" for event-driven infrastructure which must be present in any cloud based solutions and in CloudOps itself
• Powerful and flexible DevOps orchestration solution

• We decreased deployment CD times from hours to minutes across different cloud providers on several hundred systems.
• We used a SaltStack agent as a “Convergence” agent which provided us with management, monitoring, and backup capabilities.

• Backward compatibility
• The speed of fixing bugs

We have used this solution for under three years.

With the correct infrastructure design, stability issues probably won’t occur. SaltStack supports several features for high availability and fault tolerance.

In terms of SaltStack code/bug issues, it is a very stable product after four years of development from 12,000 developers.

I did not encounter any issues with scalability.

SaltStack is a very straightforward system with very good documentation. There are different solutions for deployments. Many scenarios and best practices are available publicly on the SaltStack site.

We evaluated Ansible and Puppet. SaltStack provided a much more robust solution.

The most valuable features are:

• Setting configurations options dynamically for servers
• Pulling information about all computers

We are able to control updates on servers to streamline the process

There is still development for states and pillars. The software is open-source so it allows for extreme customizability. If there is something that you think could be improved, you can code it. Our company is currently working on a few projects to help improve and support SaltStack. I would like to see more training on how to use the many different options. There is a lot of of information to go over and it’s hard to keep it all straight. Other than that, if you put the time learning SaltStack, it is a pretty easy and very powerful tool.

We used this solution for a year and a half..

We have not had issues with stability.

We have had no scalability issues so far.

I don’t have experience with their support, but I heard they are helpful. There is a IRC chat that you can join to get help from your peers.

I was not a part of the setup, but from what I have read, it is pretty simple.

The software is open source. One has to pay for support.

Read the documentation to learn as much as you can.

• Minion-less deployment of SaltStack. Minion is the client-side tool for SaltStack.

It’s a configuration management tool. We are using it for system deployment with AWS, patching of OS and applications. Deploying a patch on 200 systems is now just a click.

Minion-based deployment is not very smooth. Most of the time, many minions were in a stale state and didn't respond to the salt-master.

I have used it for two years.

I encountered stability issues. Minions didn’t work well as they moved to the stall state. In that situation, the salt-master can’t connect to the client servers.

I encountered scalability issues.

Community-based technical support is good. I never took it directly from SaltStack.

I previously used Puppet and found SaltStack to be better in terms of configuration. It’s written in Python, which means easy integration, and the structure is YAML, which is very simple.

Initial setup is straightforward.

Before choosing this product, I evaluated Puppet & Chef, but found SaltStack to be better.

I have no advice; it depends on infrastructure & application.

• Interoperability between operating systems with the ability to perform mass automation with triggering
• Integration with many vendors

These features are valuable because I need them to complete the work assigned to me.

The GUI is clunky and hard to use. It could be more user friendly.

• The UI can get complicated very quickly when you start using SaltStack for a large number of machines (100+).
• The organization of the buttons / layout can make it difficult to search for the machine you are looking for. Even with the search function, it's difficult to determine the exact state in the correct order
• The UI should be organized in a more tree-like structure, starting from the initial state (root) with corresponding states being added after (node).

I have used it for six months.

I have not encountered any stability issues.

I have not encountered any scalability issues.

I recommend SaltStack because, for SysOps or DevOps users, automation is a key part of getting your product out and allows for faster time to market.

The most valuable feature of the product is the automation for services; it’s the basis of my work. It is important because nowadays, in this complex world, services have become the base for everything. Having a large base is needed to better build what you need for your pipelines, as opposed to a few years ago, when the application was king.

We created pipelines for all our products.

The base library is missing some key elements such as networking management (mine is lacking on that front) and some more granularity on the apt part.

I have used it for 12 months.

I have not encountered any stability issues so far.

I have not encountered any scalability issues so far.

Technical support is just about right, in the sense that the product is well documented and information is easy to find.

We previously used Puppet, which was not suited for my current workload. We chose SaltStack because Ruby wasn't the language used by my team and we needed a master-client solution as opposed to a master-less one.

Initial setup was very easy.

Pricing and licensing is perfect the way it is.

Before choosing this product, we also evaluated CFEngine.

Read the docs.

• Configuration file templating: limits the amount of copy/pasted configuration across services with minor differences
• Near instant orchestration: no waiting to see if a change worked
• Well-formatted and detailed command output and logs: make troubleshooting easy and break/fix recovery fast

Developers and systems engineers could work together more closely.

Salt does not support performing remote actions that require a sudo password with Salt SSH (agentless Salt execution).

Ansible does support this feature.

I have used it for two years.

I have not encountered any stability issues in the last year.

Official documentation and community support are top notch.

We previously used CFEngine 2 and Chef; both solutions have a steep learning curve that requires a ton of domain-specific knowledge. Salt is configured from the ground up in YAML files and Python, so there's less domain-specific knowledge required and no hidden configuration files.

Salt's initial setup took about two days to go from knowing nothing to having a configured Apache Tomcat server serving our content. That's simple in my book. The complexity comes in when you want to add security policies or routing that aren't ordinary for a horizontally scaling web application; that takes some creativity.

Don't pay for it, use the free licensing options unless you don't have the staff to cover your SLAs.

We also looked at CFEngine 3, Chef, Ansible, and Puppet.

Look at Digital Ocean's guide for initially setting up the Salt server (https://www.digitalocean.com/community/tutorials/saltstack-infrastructure-installing-the-salt-master). Group your configurations by logical components, serve any environment/deployment-specific variables from pillar files, and keep templates as simple as possible (put logic for assigning variables in the *.sls files where there's likely to be other logic).

• Configuration management
• Remote execution
• Grain & mine

I like knowing what state my machines are in, and I like being able to change their state all at once.

Some of what we do, we could not do without SaltStack.

Sometimes it feels like there are more moving parts than is necessary, and maybe something simpler would do.

I have used it for two years.

As long as the versions matched, we have not encountered any horrible stability issues so far. :)

The opposite: It does better with more nodes than it does with fewer, in my opinion.

The docs, though sometimes cryptic, are excellent and thorough. I haven't personally used their technical support services.

I previously used Puppet. I switched because our shop here likes using Python solutions over Ruby ones.

Initial setup was more complicated than Puppet, but the solution was also more comprehensive. Setup was worth the trouble.

SaltStack is completely open source, though you might consider SaltStack Enterprise as a way to get up and running more quickly.

Before choosing this product, Ansible and Puppet were brought up. Ansible seemed too small of a tool for what we needed and Puppet was written in Ruby, so they were discounted.

Thoroughly research how SaltStack works; that knowledge has helped me a lot.
SaltStack is a one-stop-shop for your datacenter's management, monitoring and state control needs. Using it that way allows you to get the most out of the tool. It is configuration management, but also orchestration, monitoring, and has reactive capabilities.