VMware Aria Automation Reviews

Integrating this tool with other technologies/third-party tools, that are not part of the VMware family, is the most valuable feature of this solution.

If we have a product that allows us to communicate with different products that are not part of its family and make things happen in their application, it is a wonderful thing.

It resembles the benefits of cloud computing and is achieving more things by using only one product.

We can automate the infrastructure services, which in turn reduces manual work, saves time, and eventually leads to more productivity.

It can be used effectively for IaaS and PaaS. Thus, there is only one type of software to be managed by various departments/teams in the organization.

vRA is a very good product, that supports different vendors connecting to it. Currently, it feels like a complete product and I don’t have any areas that need to be improved.

It automatically becomes large, when we need to connect different vendors to it.

It can be made larger, so that the organizations can also use it for physical infrastructure.

I have used this solution for a year.

We did encounter some stability issues. I found the GUI that we use in vRA to be unstable sometimes. For example, there was no proper update of the tasks that were provided. Sometimes it took a little longer to provide new updates.

I have not approached technical support yet.

It was easy to set up this product.

As soon as I started using this tool, I started seeing results immediately. This product is flexible and easy to implement. Its multi-tenancy support makes it more effective for use with different customers.

• Tool for Infrastructure as Code (IAC)
• Allows you to preserve the status of the target machine
• Allows you to version a target machine as a SaltStack recipe/status “code”
• Versions can be stored and replicated
• Offers immutability, versioning, and state reuse

We can do the following from the same tool:

• Deploy code
• Redeploy code and platform
• Maintain system compliance

• Security
• Privilege separation
• Multi-user capability
• Public audit: There is no public audit of the code. Master/minion connections are subject to hijacking, privilege escalation, and/or information leaks. There is no official statement or study available about this.

• Installations: The installations sometimes need tuning to be secure, as some parts need special privileges.

• There’s no option for multi-user or RBAC. Every user can do everything.

I have been using the solution for two years.

We encountered a stability issue related to the correct master dimensioning.

We have not encountered any scalability issues.

We have not used the technical support.

I am not aware of any previous solutions.

The setup was smooth. We were already acquainted with this kind of tool.

We have no specific comments regarding this issue.

We evaluated Chef, Ansible, and Puppet.

Adopt it in full, including the API.

Configuration management: We were using SaltStack for orchestration in liaison with OpenStack. It was good for Linux machines, but the Windows experience was fragile.

They put in a few patches for Windows machine orchestration, but the experience was still painful.

Hands down, the main thing for improvement is Windows orchestration. Repo is very limited and multiple issues occur when installing vendor products.

Other areas would be to build test cases, with ease, for states. I haven’t found one. SaltStack had a focus only on Linux from the very beginning. Windows has always been a sore point. The repo for Windows was very inadequate and if I am right, I heard a SaltStack guy himself say that he is not very fond of Windows orchestration.

Another area of improvement is stability. Vendor products that required multiple customization had many handicaps, such as lack of LDAP or Active Directory support and, biggest of all, inadequate repo for Windows states.

We have used this solution for almost two years.

There were lots of stability issues, and we did hire a consultant from SaltStack.

We did have to upgrade the infra running salt-master quite frequently.

The setup was complex. The salt-master topography was master-minion, but then expanded to syndic, then back to master-minion. We did have to juggle, but that may be the shifting overall cloud architecture. It looked more like a chicken-egg problem, but we did have to revise the Salt architecture frequently.

I was not in the decision-making process, but I was told they evaluated Ansible. I am not sure the degree of depth in which it was evaluated.

Stay away from Windows orchestration. Have an alternative for orchestrating Windows machines. Think about how to prepare test cases when things change. The breaks spread like wildfire.

• Hybrid/multi-cloud infrastructure automation capability
• Configuration management
• Complex orchestrations
• Imperative programming style
• Declarative “states” DSL
• Simple YAML syntax
• Vitality of open source community involvement
• Infrastructure remote control: This fans out from a single command to many (from a handful to potentially thousands of) target machines or VMs. The fine-grained targeting features make it easy to do just what you want on just the infrastructure you want affected, with mechanical consistency. The complex orchestration capabilities allow smart conditional remote control operations on different targeted infrastructure, driven by either, or both, automatic reaction to events, or manual triggers or commands. These are the critical features needed to implement continuous delivery of anything anywhere.

Preparation of Hybris Commerce HY300 training laboratory environments and Hybris Expert Services demo infrastructure went from days of effort down to hours. Reliability and consistency is no longer a concern.

Code maturity is reaching a point where refactoring some internals will be important to maintain the rate of improvement. The software has evolved at a breakneck pace, and there is a lot of legacy code which needs refactoring and cleanup.

This doesn’t affect the operation of the software as much as it affects the learning curve for the open source community. If the code gets messier and messier, then community involvement will taper off.

Major architectural features, like the transport system for example, have been subsequently refactored. When I wrote the review, SaltStack had decided to replace ZeroMQ for extremely large scale operations, and embarked on a novel approach RAET. This appeared by early estimation over engineered and under tested, and lost momentum. Without missing a beat, SaltStack rolled out an asynchronous TCP transport option that was both simpler and more scalable. This was received well by large operations depending on SaltStack. This is a major refactoring win, and a testament to the maturation of the software.

Contributing to SaltStack could be difficult as their internal development processes matured. One symptom observable from community contributor not long before I wrote my original review, was git history rewriting. I’m not going to go down the rabbit hole about why this is bad, but I will say that this hasn’t to my knowledge happened since. I once worried this difficulty would be a barrier to progress at SaltStack, but I am no longer worried.

In particular, I was working with salt-cloud when I authored that review. Since then I have seen considerable attention paid to refactoring code I thought was problematic. They have a mature API deprecation process, which is not 100% executed (things get deprecation warnings, but the deprecated code can remain longer than declared). Even that has been improved, and in the mean time a lot of new functionality has appeared without affecting the quality of existing code.

Conventions around using salt, like formulas, testing methodology, and new functionality like the Salt Package Manager have added to the maturity of SaltStack. These conventions enable commercial and open source contributions to the SaltStack DevOps ecosystem, increasing the rate that SaltStack accretes capabilities without adding stresses to the core development at SaltStack.

We have used this solution for a year.

I did not encounter any issues with stability.

I did not encounter any issues with scalability.

Technical support is excellent.

I have used Chef. Chef is harder to teach, so it is more difficult to build an internal community around the toolset.

There are multiple ways to do the initial setup. The documentation is clear, but could be better organized.

It’s free until you need support. It will deliver a lot of value prior to production exposure, but you should plan to get an enterprise SaltStack license by the time your DevOps iterations can deliver reliably to QA.

We evaluated Chef, Puppet, and Ansible.

Make sure you have cross-functional collaboration between your development teams and operations teams.

Develop configuration as code in parallel with code development.

Use SaltStack to deploy and control both development sandbox environments and also full scale test and production environments.

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.

States, pillars, and custom modules have all taken us a long way in achieving our goals. There is great depth to it and we're looking forward to exploring all of its features.

We are moving from managing a handful of individual servers to being able to manage large scale collections. If we need to fit a particular use case, SaltStack makes it very easy to provision a new cloud instance quickly and almost effortlessly.

There are a number of bugs and regression errors that can make it frustrating at times, but given the flexibility so far I have found adequate workarounds.

The GITFS is flawed and requires a lot more work. We were able to construct our own workaround with local clones of all git repositories that are refreshed whenever a new commit or merge is made. GITFS is a feature in SaltStack which allows the salt-master to directly interact with git repositories. In theory, this is an incredibly efficient and useful capability. However, when implemented, we found server processes and load would escalate out of control whenever anyone made a git commit to the GITFS repositories. We were using v2015.8.5 at the time.

After researching the problem with the SaltStack community, we learned that there were multiple problems in the implementation of GITFS and what we witnessed was experienced by other users. Several SaltStack users recommended not using GITFS. As a workaround, I set up our salt-master with its own local copy of all of our git repositories and made use of the salt event reactor feature. When a git commit is made on our git server, a git hook triggers a salt event. Salt-master reacts to the salt event by performing a pull on its local repository copy. Its not as slick as the intended design of GITFS, but it works very well and has proven quite stable, completely eliminating the problems we experienced with GITFS.

At some point in the future we will revisit the GITFS feature, but for now we are satisfied with the current solution.

I have been using the solution for six months.

We have encountered quite a few stability issues with the GITFS option, but its been quite stable since we switched to our workaround solution.

We have not yet encountered any scalability issues.

This is an open source tool so we find out about fixes, patches, and other solutions through the online community and other online resources, such as Stack Overflow.

We did not have a previous solution as we are new to using DevOps management tools, but we researched others before we decided on SaltStack as our tool of choice.

Initial setup seemed so easy, but there is an art to designing pillars, writing state files, and other customizable structures.

This is an open source solution, but there is a paid enterprise option. If you plan to pursue the enterprise solution route, contact SaltStack for details. The open source option is very approachable.

We evaluated Puppet, Chef, and Ansible.

If you are planning to use the open source version, plan to allocate more project time than you think you need. However, once it's in place it will save you a great deal of effort.

Execution modules. It is designed for system administrators rather than for developers. It covers maximum functionality and makes automation easy.

As it provides maximum functionality, it keeps automation short and sweet. This helps writing automation in a modular format. SaltStack helped us in optimizing infrastructure related tasks, such as operations.

There should be some mechanism to push agents to the target device. Also, it should focus on managing networking devices.

In order to manage Salt minions from a Salt master, we have to install the Salt agent. As of now, there is no mechanism by which we can push and install this agent on a target machine.

For example:

• A - Salt Master
• B - Windows machine

From A, we want to control B. For this to happen, B should have a Salt agent running on it. There should be some mechanism in which we are able to push and install a Salt agent from A to B. This is assuming that we have to provide an IP address and the credentials of B.

For now, there is concept of Saltify, in which we can partially achieve the above scenario.

We have been using this solution for close to a year.

We found some intermittent issues with the Windows minion connection.

The installation is straightforward and is pretty much a simple setup.

We have used the open source version. In open source, you will get good enough functionality.

We have evaluated this product against Puppet, Chef, and Ansible.

As a DevOps engineer, this CM tool is truly made for system administrator usability rather than for the developer.

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