VMware Aria Automation Reviews

• Reactors, because of the automation help they provide (reacting to custom events).
• State dependency trees, because a state can be linked to the status of another state, allowing you to particularize the behaviour of the software in some cases. The result of the execution of a system_state can be linked to different other states. For example, you can say: IF Upgrade_Apache is OK then Restart_Apache else Rollback_Upgrade. In that manner, you can create a sort of dependency among multiple desired states.

For example, with automation, before SaltStack, user management to access servers by SSH was done "by hand". The risk was leaving life-long access for some users, who were no longer with the company.

Integration in BASH Scripts: Maybe I’m just lazy, but I've not been able to find a mapping between state execution success/failure and Salt command return codes.

I have used it for 1.5 years.

I have encountered stability issues; they are always resolved by new releases of the software.

I have not encountered any scalability issues.

Technical support is excellent, even by chat.

I did not previously use a different solution.

Initial setup was simple.

I use the community edition, so it is free.

Before choosing this product, I did not evaluate other options.

• Extensibility and flexibility
• Open source
• Active community

Also, the text-based configuration is very important to discern differences in version control. It also means it is easily configured with templates, and easily edited.

Salt lets you run commands on hundreds of servers at once; and sync up software, tools, and scripts across your infrastructure.

The flexibility can hurt sometimes, as there are so many ways to accomplish the same task. I don’t want to give the wrong impression; the flexibility helps more often than it hurts. However, when there are multiple choices to a complex software problem, one can make mistakes, and with a configuration management system, a mistake can get pushed to an entire infrastructure automatically.

I have used it for one year.

Salt has been remarkably stable, and it is simple to send metrics to an external source like Elasticsearch.

I haven’t had any scaling issues.

I would rate technical support very high. Personally, I have posted issues to GitHub that have been responded to the same day or the next day, and closed within a week.

This was our first foray into the configuration management space. Previously, it was a bunch of PowerShell scripts.

Salt has a very straightforward installation.

Salt is free.

Before choosing this product, we were looking at PowerShell DSC, because we were all PowerShell anyway. It was too unpolished; did not seem to fit properly with what we had in mind.

Have a good plan about how you are going to target your infrastructure; a solid naming convention helps a lot.

• Remote execution.
• SaltStack being so fast makes it very convenient and practical; allows me to get information about my servers in no time.

SaltStack allows me to answer user requests in a very efficient manner.

I guess the only downside of SaltStack is the limited user base, which leads to poorer documentation because of the lower use.

On a features side, maybe some more security around the API would be good, so it can be used as a central automation tool.

I haven't kept up with latest releases for a while, though, so don't quote me on that.

I have used it for two years.

I have not encountered any stability issues.

I have not encountered any scalability issues.

It's open source and the community is very helpful as usual.

I previously used multiple solutions combined; harder to manage. Salt is easy to use and manage.

Initial setup was straightforward; worked out of the box .

It's open source.

Before choosing this product, I evaluated Puppet and Ansible.

Just install it and use it for remote execution at first. You'll see how powerful it is.

The Salt Formulas are very, very helpful, as they help to get the configuration needed to install any new package and configuring the same; very, very simple and easy.

We have scaled from two servers to about 140 servers in a very short period of time. This would have been a nightmare had it not been for the SaltStack configurations.

I think debugging can be improved. In case of errors, the devOps team finds it difficult to read the Python stack traces at times.

Although the Salt Formulas have matured recently, they still have some glitches. They are open-source contributions. Every Salt Formula has two parts: 1) pillar data and 2) Salt configuration. Both have to go hand in hand.

Sometimes the Salt configuration was found to have a few bugs that do not align with the pillar data. The stack traces thrown do not help much and require a bit of experience to deal with those situations. We end up correcting either the pillar data or the Salt configuration.

This is by no means an issue with the SaltStack software. Since it’s written in Python, the stack trace thrown for any error needs some level of expertise to deal with.

One example we found was that one of the Salt Formulas was using a Salt module in a particular version. Upon upgrade, the Salt module was no longer part of the default package. It took my team some time to realize what had happened, because the Python stack trace was not pointing to the exact problem in hand but would point to a random Salt configuration location.

I have been using this solution for more than two years now.

I have not encountered any stability issues.

I have not encountered any scalability issues.

We did not use technical support. As it was open sourced, we developed the required technical support in-house.

We were not using any other solution for our configuration management.

The initial ramp-up period to understand the concepts took time. Post that, it’s a very easy-to-use solution, especially after the Salt Formulas have matured.

Its open-sourced, so we do not use licencing, and its free to use.

We evaluated Puppet and Chef before deciding on SaltStack.

Ansible and SaltStack are very good solutions. I prefer SaltStack as its been developed from the ground up and is a lot better than Puppet and Chef.

The initial learning curve is low. I had a working configuration building fairly complex proprietary Internet servers within a couple of months, well before the rest of our server team was ready for production builds.

The developers are very quick to respond to reported issues and offer advice to deal with them (or correct something you are not using well). The couple of times I had to deal with them were actually very pleasant.

The relationship between the state files and the actual filesystem being served by the master is as simple and elegant as the way *NIXes treat everything as a file.

The execution capability both in a shell on the Salt master and using cmd.script within state files allows even a novice to make things happen the way they want until they learn to use all of the available modules the right way. This, for me, was part of getting up and running fast. This reduced the learning curve for me tremendously, as I got my initial server build framework running. I have been able to continue refining the system in stages since then and it is easy because of the relationship between the state files and the files they serve.

We have developed a complete, multi-tiered, stable build system for our Internet servers with SaltStackas the base of the build system. It is stable and easy to modify as we grow and change our needs.

We currently use the Salt Cloud module for integration with Amazon Web Services, but I would like to see more integration with AWS, specifically an ability to stably control an ever-expanding and contracting cloud of EC2 instances in a sane fashion.

SaltStack has many community-maintained modules available. One of the modules is called EC2 Autoscale Reactor and it's function (alongside the Salt Cloud module) is to control an autoscaling group's instances as they are added and removed. I found this module difficult to configure and unreliable, as far as getting and maintaining control of new instances as they were created by the autoscaling group. In fact, the developers even labeled it "experimental." I would like to be able to reliably control all instances in an expanding and contracting autoscaling group without manual intervention.

For the record, our cloud has moved away from needing this as a requirement. We use SaltStack and Salt Cloud strictly as a build management system and have moved towards our Internet servers being strictly "hands-off," except for developer instances. I want this feature as an improvement because the ability to manage a dynamic cloud of Internet servers adds a lot of power to SaltStack and to me.

I have been using it for 1.5 - 2 years.

I mentioned the initial learning curve elsewhere in this review. Of course I encountered issues with deployment of SaltStack. I had never used an infrastructure management system prior to this, so the concepts were a bit foreign. I put in a ticket or two as I initially learned to get the system running. I found that across Linux systems, there were sometimes version differences in the repositories and began building a specific Git revision of SaltStack on all systems as a result.

The only stability issue I encountered in almost two years of use had to do with a different version of SaltStack being served on the repositories for an Ubuntu Salt Master and Amazon Linux minions. I have since migrated to using all Amazon Linux instances for everything and always building the same Git revision on all instances and have never had a bit of instability in the SaltStack system since then.

I have encountered no scalability issues with SaltStack. In fact, I haven't stretched the system very far, but because it supports multiple masters, Syndic, and minions as "runners", the scalability and high availability looks to be amazing.

A+ for the little time I have spent dealing with support. They were quick to respond and the technical expertise was fantastic.

A+ because the developers are directly involved in the support.

SaltStack was my first choice because it is open source and was reviewed extensively as a good choice because of the low learning curve.

The hardest parts of initial setup for me were learning some of the intricacies of YAML and Jinja, and figuring out the moving parts on the master so I could get the system to reliably create the minions I wanted. Later, learning to configure Salt-cloud was a bit tough because of the configuration files required to work with resources on Amazon Web Services. None of these issues were "showstoppers", though, as the amount of online documentation and configuration examples for other users is excellent.

An in-house team implemented it.

The only calculation I can make on ROI is the countless hours I have NOT spent configuring and deploying servers. I now issue a few commands on the Salt Master as my build server, and the servers are built, Amazon Machine Images are created, and they are blue-green deployed. All I have to do is check the various stages for completion and occasionally check build logs for errors and make corrections. I have a lot more time to focus on the rest of DevOps.

As a small start-up, we have not gone to a licensed model yet.

The only evaluation I did was to spend lots of time reading reviews and asking questions of people I know who are already using configuration management and execution tools. SaltStack was my first choice.

I spent my time learning Saltstack through trial and error, researching the online document system as needed. If you decide to use SaltStack, buy the O'Reilly book called Salt Essentials first. It is not very big, but it explains the concepts required to get a working system very well. I think if I had gotten the book first, I would have cut my initial time spent learning in half.

Cross-platform Windows and Linux support: We run a Windows infrastructure within AWS with several key services deployed on Linux instances.

We have been able to integrate with AWS to deploy continuous delivery services with an extremely quick turnaround time. Salt lets us manage those instances, and control the deployment seamlessly.

Windows support and support in general: Getting responses to problems can take weeks or months in my experience. Windows support is advertised as a first-rate supported platform; however, it is ripe with issues that have added countless hours to our roadmap. Documentation is also severely lacking for much of the Windows platform support, and in many cases I have had to resort to third-party blogs and tutorials for resolving problems.

I have used it for nine months.

I have encountered stability issues with Windows support in AWS/EC2.

I have not encountered any scalability issues so far.

I rate technical support as 3/10. The only support we get is through the mailing list or through GitHub. They have offered a higher level of support for $20k, but we haven’t seen anything to indicate the value in doing that when the platform as a whole has issues that should have been tested before being deployed.

This organization I work for used Altiris before, but we switched to Salt to scale into AWS.

Initial setup should have been straightforward; however, documentation issues and bugs in general caused this to take a very long time.

The software is open source and free; however, things that should be tested for stability (like Windows support) are not fully vetted, and it’s unclear if a paid support offering would actually resolve those problems.

Before choosing this product, I evaluated Chef, Ansible, etc.

Don’t rely on the SaltStack documentation alone; use Google and other resources to find help, if you are not going for paid support. Windows support is lacking but you can overcome the issues with a bit of ingenuity.

Remote code execution is the most valuable feature; also some of the configuration automation and the automated deployment possibilities it gives us.

We can now deploy a new (Linux-based) ERP server in 15 minutes; automated, all using the same template and standard. Before this, would take us two hours following a documented procedure.

Overall, the documentation is good but improvements can be made in documenting "real world" examples and practical usage. How to's and "best practices" that go a bit further would be really helpful to make sure you're using the product the best possible way. It's more like… how to "manage" all the configuration you use. Not only at a plain technical level but also at a higher level. Having an overview and managing all this is a bit difficult in the beginning.

It basically comes down to "orchestration"; there is some room for improvement in that.

The more you are experienced with this software, the easier it gets. But it's difficult getting up to speed without having these "real world" examples on managing your own SaltStack infrastructure. Experienced people that can showcase and share their use would help a lot in my opinion.

Some developers and employees are active in the public chat channel.

I have used it for two years.

I have not encountered any stability issues. Just take care when upgrading. Read the release notes and test.

I have not encountered any scalability issues yet.

Technical support for open source software = IRC, mailing list; very good community.

I did not previously use a different solution.

Initial (basic) setup is easy when you follow the docs.

Before choosing this product, we evaluated Chef, Puppet, and Ansible. We found Salt to be closer to us on features and mindset.

Try it out; it won't cost you anything but some time.

The most valuable feature is Salt Cloud due to its ability to tie into VMware, as well as Salt Orchestration, because it allows us to script the process of setting up an entire infrastructure.

This product has saved us time in standing up new servers, as well as allowed us to automate the deployment of these servers and the applications that run on them.

• Documentation can be hard to find and examples aren't as detailed. In Salt, you can use modules in an SLS file, as well as via command line. A lot of the time, the official documentation only has a command line example and you've got to dig around through third-party sites to find examples of using modules in an SLS file. It can also be difficult to find documentation on Jinja templating through Salt’s website, as well. Basic examples are given but anything more complex is lacking.
• Salt Cloud Windows support isn't that mature.
• Salt Orchestration lacks logging when states are nested.

I have used it for 1.5 years.

Occasionally minions would time out and not return a response, although the Salt state would still run. Increasing the timeout helped, but this is more of a design concern than an overall stability issue.

So far no issues with scalability were encountered.

I haven't utilized technical support. The forums seem to be somewhat helpful in suggesting workarounds to issues caused by lack of features, but more detailed steps on implementing those workarounds would be helpful (e.g., setting a static IP on Windows VMs setup with Salt Cloud).

I've used Puppet at a previous job. Salt is the tool that was in place at my current job.

Salt is open source.

The product was already in use.

Define the scope of what you need a configuration management tool to use and then look at all available options and the potential drawbacks of those options. Nothing can beat hiring a sys admin with experience in different technologies.