VMware Aria Automation Reviews

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.

• 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.