VMware Aria Automation Reviews

The ability to programmatically describe the desired state of a single, or an entire fleet of servers, on-premises, and in a cloud environment.

SaltStack gave us very useful automation tools that allowed us to standardize our environment, move at a much faster pace through repeatable deployments, and self-documentation of our infrastructure.

It allows us to describe the desired state of our entire fleet of servers through simple to understand syntax and templates all available at a single place.

This is great for things like documenting what a single machine or a group of machine does and how they are configured. It is also good in the event that one of them is lost and a new one needs to be provisioned quickly.

Instead of setting it up by hand, we end up telling it "you are this type of machine" and SaltStack will take care of ensuring that the machine becomes what is expected.

It also means that any machine of "this type" will be setup in a consistent manner thus avoiding unexpected surprises that could potentially become the cause of outages.

Each new version seems to bring a new set of bugs to the table and upgrading is risky, especially for a tool at the core of the operations and infrastructure.

A hardened set of tests would be much appreciated.

We have encountered many bugs during upgrades in the past and it seemed to me like those could have been caught by the developers at a much earlier stage then after doing a widespread release.

We have used this solution three years in production

We have encountered several issues when we upgraded to 2015.8. Some of those were eventually fixed by the community and through fixes we submitted to the project.

We have managed a fleet of hundreds of servers without any scalability issues on the horizon.

We have not requested technical support.

We evaluated Chef, CF Engine, and Puppet and we ultimately decided on SaltStack because:

• It is written in Python: Introspecting the code base, committing fixes and improving on the tools were easy for us to do.
• The amount of tools already baked in the product and the extensive list of formulas made available by the community.

The initial setup was simple enough to get started and see the benefits that the solution brings. There are many tutorials available to get someone started.

Unfortunately, our experience is limited to the open-source (community) version. We have no information in regards to the enterprise offering.

We evaluated CF Engine, Chef, Puppet, Capistrano, and Fabric.

Take some time to learn the types of problems it can solve and you will easily see the benefits that it can bring.

The ability to quickly setup the self-provisioning of vSphere VMs was one of the primary drivers for us to use this product over others. Additionally, the product has several plugins and an almost limitless potentional for further automation using vRealize Orchestrator. Lastly, its integration with NSX is superb and very much a critical part of our VM provisioning.

We are using the following vRealize suite products: Log Insight, Operations, Orchestrator, Business for Cloud, and Automation.

We have given internal IT developers the ability to self-provision VMs for development and testing. This has been a hit with our staff. I have talked to several of them involved in the POC and it has drastically increased their efficiency since they do not need to wait on IT Ops. Additionally, the publishing of templates, firewall rules, and software installs in the system has increased the communication and transparency between IT development and IT operations.

As with all recent VMware products, more focus needs to be done on QA. I encountered far too many bugs for an enterprise product. Additionally, more native vRA integration for various parts of the VM lifecycle will take some of the onus off the engineer to learn so much about Orchestrator.

I used version 6.2.0 for five months and version 7.0.1 for 11 months.

We did have stability problems. I encountered several issues with the product after the upgrade from 6.2.0 to 7.0.1. I would highly recommend that anyone looking to move to 7.x from 6.x should do a migration rather than an upgrade. VMware did not do enough QA on the product in order to handle in-place upgrades.

We did not encounter scaling issues because we had a limited release of the product since it was a POC.

Technical support from the frontline technicians is very good, but if your problem has to be routed to “engineering” then be prepared to wait for days (sometimes weeks) for resolution.

We did not have an existing automation product.

We already owned vRealize Automation as part of our suite licensing. We did evaluate the Cisco UCS Director product for one month and found it too complex to setup.

The initial deployment of vRealize Automation was not complex, but it was tedious and error prone. This was the 6.2.0 version and these issues have been fixed in the 7.x versions.

I would advise heavy VMware shops to look into getting suite licensing and leverage the VMware ELA framework if possible. Additionally, I would highly recommend that NSX is purchased in conjunction with vRealize Automation in order to get the most out of the product.

We evaluated Cisco UCS Director.

Do your research ahead of time and try to find others in your area who have already deployed the product. Your VMware rep can usually provide contacts that may be able to provide advice. Additionally, start talking to internal developers at your company and see what pain points they have and how automation can help. This communication will also help when you start publishing catalog items in automation, because a lot of more advanced workflows will require knowledge of Javascript and PowerShell. Lastly, start working with Orchestrator now. It has the steepest learning curve, but it is critical to understand how it works for advanced workflows. Orchestrator is already included with your vCenter licensing.

• Bulk/Remote execution
• Event/Reactor system
• Configuration Management

These features serve as the most critical pieces for automating anything, not just state, but also execution and remediation.

I don’t want to build automation that just does a thing or two. I want to build automation that is intelligent, part of the fabric of our environment, and is somewhat self-sustaining. I think SaltStack can help me do this.

SaltStack provides the capability necessary to truly streamline our SDLC and environment management. From a high level, it allows coders to code, testers to test (automated testing too), and admins to admin in the most inter-connected and effective way possible.

• Web UI
• Maintenance of their code

We have been using this for three years.

There are some issues here and there, such as nuances with Windows and minions ‘falling asleep’, but its manageable.

I did not encounter any issues with scalability.

I would give technical support a rating of 8/10.

I was using more of a Frankenstein automation solution previously, and the reason for switching was the capability of SaltStack, performance, and ramp up time (ease of use).

The setup was pretty straightforward. It took some time getting familiar with all the configuration options and playing around with pillars and grains. On the whole, it was relatively easy to get going.

I think they are going to have a tough time with the Enterprise licensing. So much can be done with the Open Source side, and especially for smaller shops. I personally think the pricing for Enterprise is hard to justify.

We looked at Chef, Ansible, and Puppet.

Do it and take full advantage of its capability. Be creative and automate everything you can with it.

Orchestration capabilities are the most valuable feature of this solution.

Provisioning time is reduced from two weeks to 60 minutes.

• Better integration with the public cloud and DevOps toolset

I have used this solution for three years.

We did not encounter any major stability issues.

There were no scalability issues.

The technical support is very good; they have come a long way in supporting vRA. Now, issues are being resolved in hours.

The installation for vRA 6.x was complex, but for vRA 7.x was simple.

There are so many features that this product has, so evaluate all of them.

From day 1 that it went into production, we started seeing its benefits.

We are using the vRealize Orchestrator heavily.

The most valuable features are the EBS (Event Broker Subscription) and NSX integration with BP designer.

Multiple BPs can be deployed with EBS and PG (Property Group) in a lot less time.

IaaS components: I have an assumption that all the IaaS components will be migrated to a Linux appliance, then I think the communication between the Linux appliance and the IaaS components will happen faster and smoother.

We have used this version for almost 1.5 years. We previously used version 7.0.

Sometimes, we encountered stability issues, but they were negligible.

Sometimes, we encountered scalability issues but they were negligible.

Very Good.

Technical support was good.

This is the first product we used.

Installation was straightforward and simple .

It’s very helpful for us to have this product. We already gained the benefits after installation and configuration.

We did not look at alternatives; this is the ultimate product.

Use it for automation in order to achieve Agility, Efficiency and Control over the IT Service Delivery..

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.