VMware Aria Automation Reviews

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.

Remote execution in itself is a big time saver at any scale.

For example, a particular incident happened at one of my previous organizations. We had to do a PoC on a lot of servers, where traffic was to be generated from a few hundred machines (something like 'bees with machine guns') and would allow us to benchmark one of internal components.

So, before we began working on it, I suggest the use of SaltStack because of its remote execution. They could easily start generating traffic from a few or all these servers and then get a good feel of a Flash Sale in Ecommerce.

Eventually, one of my colleagues was assigned this task and he used SaltStack. He liked the way SaltStack (on the entire cluster) was up and running in a few minutes, and also gave him flexibility to generate traffic, make config changes, etc. on the fly.

Currently, most of our configuration is in SaltStack, so scaling up when necessary with or without Salt Cloud would be real easy.

Traditionally, the team here expects the use of Golden AMIs for scaling up the infra, which, though useful, has its limitations:

• Security updates to the OS are the biggest concern.
• Non-standard configuration on one server would also cause some serious issues if its AMI is used by mistake in scaling up.

If, instead, we push configuration to new servers during scaling up, then we fix those issues.

And, I was also considering the fact SaltStack gives near flat-line performance (for both remote execution and pushing changes through states), whether the infra size is 10 servers or if it has grown beyond a few hundred. So, that is at least one area that we need not be worried about.

The configuration management is at least one aspect that would take care of itself (not considering redundancies, reporting, etc. required for SaltStack here at the moment).

Personally, I feel that SaltStack has many renderers, but the documentation was a bit lacking (in particular, for Py it was close to nothing) when I was studying it up a few months back.

Salt supports multiple renderers Py, PyObjects, etc. (https://docs.saltstack.com/en/latest/ref/renderers/index.html#multiple-renderers). These allow users to write states in JSON, Mako, MsgPack, etc. Py renderer allows us to write states in Pure Python.

I had many scenarios where SaltStack didn't have enough functionality at the time (it has been added in recent releases). For instance, I was trying to add an instance into ELB as the last step of orchestration. But, Salt didn't have anything to support it. So, instead I went ahead and wrote a small state in Py renderer.

There are also cases where Jinja + YML is not enough and to DRY up the states, one has to use either the Py or PyObjects renderer. I prefer Python, as you then don't have to look up the syntax of a particular renderer and a simple Python script would suffice. The catch here is that Salt expects output in a particular format and initializes its internal variables in a specific format, too.

I spent most of my time figuring out how to make this Python script work with SaltStack. Any such functionality that’s missing from SaltStack can be easily implemented using the Python (Py) renderer. So, if the documentation around renderers is improved, it will help anyone with a very specific use case.

I have used it continuously for the last year, and sporadically for the last three years.

Sometimes, salt-minions do start consuming very high memory, but I've generally seen this to last just a few moments or at most a minute. On a production system, this might cause an impact on serious loads.

Additionally, if many of the servers in infra are down, and you bring all of them up simultaneously, it used to bring down salt-master. This happened until last year, when I was working at scale. Since then, I have switched from that job; it’s difficult to test this pain point now.

I haven't tried technical support.

I did not previously use a different solution.

Learning SaltStack did seem a bit daunting at the moment I was learning it. The concept of creating a top.sls with references to various states and their targets, then creating corresponding files in YML, took a day or two; beyond that, it was real easy.

If someone is using it for an infra consisting of a 1000 servers or more, then support would be real useful. Others can go through the documentation and learn from forums or SO posts.

I tested Puppet and Chef, but could never get around to using them in production or at work.

Salt was more of a Swiss Army knife. And our work at the time was more focused on rapid manual changes.

Create valid states for all environments and keep the difference between these environments minimal. Use test cases as much as possible.

Jinja/Python + wide range of embed functions for various platforms and purposes.

Jinja is based on Python, which is a fairly handy and comfortable programming language. They make it simple to create Python-based templates and, when necessary, create functions for actions that are not covered by the Jinja engine.

Centralized administration and orchestration of severs and services.

Support: It's not bad or poor, but there are some issues. On the one hand, it's about development and progress; on the other, there were some issues that took too long to get fixed by the SaltStack team and forced users to invent workarounds.

Documentation: I'd say it's a little bit complicated for beginners, some topics are not clear and so on. So, one will have to massively use search engines when it comes to complex setups and solutions.

I have used it for ~7 months.

I have encountered any stability issues.

I have not encountered any scalability issues.

Technical support is good (4 of 5).

I did not previously use a different solution.

The initial setup was neither straightforward nor complex; it required some effort.

It's OSS.

Before choosing this product, I evaluated Ansible and Puppet.

Be patient and you'll get a great solution.