VMware Aria Automation Reviews

Agentless application deployment is the main reason for faster setup and easy deployments.

• It doesn't have a GUI to manage VMs.
• Some Python modules had issues which I think will be fixed in newer versions.
• Other configuration management tools, like Chef and Puppet, have a web interface to perform certain tasks on instances where an application is deployed.
• We can scale and schedule based on traffic. If you want to recreate/add a new instance, you can immediately do it from web interface. This was missing on earlier versions we tried.

We have been using this solution for three months as part of a PoC.

I did not encounter any issues with stability.

I did not encounter any issues with scalability.

We used open source community support.

The installation was straightforward, especially the master and minion configuration. This configuration was time saving and led to a faster, automated application deployment.

We didn't go for pricing model, as we chose to do a PoC using an open source version.

We evaluated Ansible.

This product is in good shape now and the community support is vibrant. I learned a lot from them while implementing it.

We use it for the automation of VMs. It is performing okay.

We use it to deploy databases and testing environments. It spins up quickly and breaks down fast.

The automation is consistent.

The front-end is user-friendly and intuitive.

It is very difficult to make the automation work well. This is not product specific, but more due to environment and procedures that we have in our company.

The back-end has a steep learning curve.

The stability is good.

I used the technical support during upgrades. They came onsite and are very technical. They are very good

I am not aware of a previous solution. We moved to vRA because the business wanted quick, repetitive deployments.

It was a complex setup. We had to use the consultant from VMware to make the solution work well.

The upgrade was a very difficult task. We had to break everything down and build it up new in a new version.

We used a consultant from VMware for the deployment.

• Automation
• Catalog
• Blueprints

Probably more stability and just ensuring everything works out-of-the-box.

There is still a bit of a gap in terms of product maturity based on all the forums and things that we've seen, so we would like it to be much more mature than what we currently have.

There's some issues that we've encountered while standing it up.

As of now, it seems like it does scale. However, we haven't hit the point where we are deploying in a large scale.

So far, we haven't had too many issues reaching out to tech support.

It's fairly complex. The documentation continuously evolves and the product seems to change every couple months. It's trying to piece together different forums and documentations to figure out how to get a working solution.

Most important criteria for selecting a vendor: Brand recognition, but also VMware being the biggest. We thought that might be the best route in terms of support and community.

Multi-machine blueprints.

Prior to the deployment and utilization of vRealize environment infrastructure, deployments (VMs, IPs, DNS, firewall rules, load balancers) would take up to three months. After utilizing vRA we have reduced this to less than an hour for a complete, production-ready infrastructure deployment.

There are a lot of usability issues which I have. Overall, the product feels bloated and cumbersome. It feels like you are very locked in to what VMware has decided is the "way to do things" and you have to spend a lot of time developing custom code and logic to get around these artificial limitations.

Specifically, the blueprint design canvas has had a terrible memory leak error for several versions which makes designing blueprints difficult and time consuming.

One year.

Nothing specific to the product. Due to the complexity of the deployment, there can be issues with stability because you need to keep track of many moving parts.

No. The product is very scalable.

Due to the customizability of the product, support can often be very difficult. However, VMware support is often very helpful and capable.

No, we did not.

The initial setup is very complex. You will deploy at least three VMs, a Linux appliance, a Windows IIS server, and a Microsoft SQL server. If you want high availability, you will deploy two of the appliances and IIS servers. The deployment process requires specific versions of .NET and Java, as well as some specific config file edits. After the actual VMs are deployed and ready to go, you will then be required to set up tenants, and all the associated permissions and groups which are required for this. You will need to set up connections to your vCenter servers, and reservations based on these connections. Creating blueprints can be simple or very complex depending on your needs.

I don't know anything about this.

I was not part of the evaluation process.

vRA is very powerful, but you need to know what you're getting into. You really can do almost anything that you want using the product in conjunction with vRealize Orchestrator, but it requires a lot of knowledge and work.

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

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

The two most valuable features to us are beacon related. We can use the beacons to alert that a service is stopped, and restart it almost instantly. Also, we can use the beacons to alert based on whatever monitoring metric we see fit. For example, if a server is running out of usable RAM, for example, we can alert on that, and react to it in whatever way we see fit. We could in fact automate any aspect of scaling – all because of SaltStack. Also, it enables you to have a remote CLI on every server in your infrastructure and issue a command to it. Within seconds, you will have the results of that command in an organized list.

We use it to automatically install software on servers with the minion installed – based on the server name. So we can bring any machine up to spec by simply changing the host name. We have plans to automate it even further; it is just a matter of time.

The online documentation is lackluster at best. It usually only gives one example of how to do something. If you want to see all possibilities, you have to look at the Python code for the SaltStack modules themselves. They are commented extremely well, and what isn't there you can write yourself! Anything is possible when you edit the code on your own. We have modified many modules to suit our specific needs.

I have used it for 10 months.

I have not encountered any stability issues.

I have not encountered any scalability issues. It has helped us scale other applications.

We are all self-taught on this product. I have not initiated a call to their support. I will say their online documentation leaves something to be desired; however, that is all made up in the code itself. It is commented really well.

We were previously using SCCM and SCOM. We have brought in SaltStack and it is slowly taking over those two spaces. SaltStack is a great orchestration tool, but not intended to be used for monitoring. We are looking at switching over to Zenoss for our monitoring solution.

The initial setup was complex because we did not think it would be as simple as it was. I can build a new SaltStack infrastructure in a matter of minutes now, but initially it took me longer than I would like to admit. Again, it is hard to make your way through the documentation. I was using YouTube videos for instruction.

We use the free, open-source version. I have no information or experience with their pricing.

We looked at Ansible, Puppet, and SCCM. All were really good at what they do, but SaltStack seemed to be much more feature rich than the competition. I am extremely happy with our decision.

Absolutely, positively, go to YouTube first before looking at the documentation. Documentation gives you a great start of what you need, then you look at the code to see the configurable options.