VMware Aria Automation Reviews

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.

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.

• Configuration management
• Remote execution
• Grain & mine

I like knowing what state my machines are in, and I like being able to change their state all at once.

Some of what we do, we could not do without SaltStack.

Sometimes it feels like there are more moving parts than is necessary, and maybe something simpler would do.

I have used it for two years.

As long as the versions matched, we have not encountered any horrible stability issues so far. :)

The opposite: It does better with more nodes than it does with fewer, in my opinion.

The docs, though sometimes cryptic, are excellent and thorough. I haven't personally used their technical support services.

I previously used Puppet. I switched because our shop here likes using Python solutions over Ruby ones.

Initial setup was more complicated than Puppet, but the solution was also more comprehensive. Setup was worth the trouble.

SaltStack is completely open source, though you might consider SaltStack Enterprise as a way to get up and running more quickly.

Before choosing this product, Ansible and Puppet were brought up. Ansible seemed too small of a tool for what we needed and Puppet was written in Ruby, so they were discounted.

Thoroughly research how SaltStack works; that knowledge has helped me a lot.
SaltStack is a one-stop-shop for your datacenter's management, monitoring and state control needs. Using it that way allows you to get the most out of the tool. It is configuration management, but also orchestration, monitoring, and has reactive capabilities.

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.

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.

We are using it for infrastructure service, automating things in Active Directory, and deploying Microsoft SQL and Oracle databases. We are also using it to automate some scenarios within our infrastructure.

Having a one-stop-shop for our IT services is one of our goals. Exporting and democratizing the tools helps our end users to do their work efficiently and to be more agile. It helps to minimize the time to market for our product.

Using the solution we are able to automate database refreshment. This process used to consume a number of working days. With vRA fully automating this process, it is now down to five or 10 minutes. As a result, we're able to refresh our testing and development environments frequently. When we go with a new deployment in production, the deployment is based on a fresh copy of production. We're able to have multiple environments so that we can test more product concurrently.

We use VMware Cloud Templates and having a standard template to be deployed gives us a standard across our environment and minimizes the time it takes to provide services. Despite having 20 machines, we just do the configuration once and then we can deploy it across the whole infrastructure for all environments: production, testing, and development. And this reduces the time to market for our services. They improve reliability. They give us consistency. Having things assembled and having everything in one image helps us provide reliable services. And they have saved time for our developers.

Having an enterprise service catalog and being able to automate various parts of our infrastructure are among the most important components.

It needs to be more dynamic with variable customization to make new workloads more reliable. It also needs to be faster. We are exploring vRA version 8 right now and maybe what I'm requesting is available in the new version, but we haven't explored it fully yet.

We have been using VMware vRealize Automation for seven or eight years.

VMware's customer support for vRealize Automation is good. They are knowledgeable about the product and have improved their response time. The support is fine.

We did have a previous solution but I am not able to disclose its name. vRA is an end-to-end solution with all the capabilities.

The pricing is very high.