VMware Aria Automation Reviews

• Interoperability between operating systems with the ability to perform mass automation with triggering
• Integration with many vendors

These features are valuable because I need them to complete the work assigned to me.

The GUI is clunky and hard to use. It could be more user friendly.

• The UI can get complicated very quickly when you start using SaltStack for a large number of machines (100+).
• The organization of the buttons / layout can make it difficult to search for the machine you are looking for. Even with the search function, it's difficult to determine the exact state in the correct order
• The UI should be organized in a more tree-like structure, starting from the initial state (root) with corresponding states being added after (node).

I have used it for six months.

I have not encountered any stability issues.

I have not encountered any scalability issues.

I recommend SaltStack because, for SysOps or DevOps users, automation is a key part of getting your product out and allows for faster time to market.

• 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 code execution is the most valuable feature; also some of the configuration automation and the automated deployment possibilities it gives us.

We can now deploy a new (Linux-based) ERP server in 15 minutes; automated, all using the same template and standard. Before this, would take us two hours following a documented procedure.

Overall, the documentation is good but improvements can be made in documenting "real world" examples and practical usage. How to's and "best practices" that go a bit further would be really helpful to make sure you're using the product the best possible way. It's more like… how to "manage" all the configuration you use. Not only at a plain technical level but also at a higher level. Having an overview and managing all this is a bit difficult in the beginning.

It basically comes down to "orchestration"; there is some room for improvement in that.

The more you are experienced with this software, the easier it gets. But it's difficult getting up to speed without having these "real world" examples on managing your own SaltStack infrastructure. Experienced people that can showcase and share their use would help a lot in my opinion.

Some developers and employees are active in the public chat channel.

I have used it for two years.

I have not encountered any stability issues. Just take care when upgrading. Read the release notes and test.

I have not encountered any scalability issues yet.

Technical support for open source software = IRC, mailing list; very good community.

I did not previously use a different solution.

Initial (basic) setup is easy when you follow the docs.

Before choosing this product, we evaluated Chef, Puppet, and Ansible. We found Salt to be closer to us on features and mindset.

Try it out; it won't cost you anything but some time.

Initially, we used it for private cloud. Now, we are trying to go with a hybrid model.

In terms of performance, right now we're making revisions to ensure that it is hybrid-compatible. We have multiple engagements with VMware to facilitate it that.

Productivity has definitely increased. We are not relying on engineers to actually build out the infrastructure anymore. That's the main benefit. From an infrastructure perspective, it has definitely increased productivity, ensuring that the engineers' time is well spent on other, more important tasks, rather than the basic provisioning that they were doing earlier. 

The self-service capabilities are by far the best that we've seen in terms of features. If the user is being able to log in and make requests himself, from the onboarding process all the way to the end, that's very helpful.

I'm curious to test out the features that have been announced. We'll see how that goes from a hybrid perspective. I'm looking forward most to the hybrid capabilities.

The stability needs a lot of work. The troubleshooting component of vRealize is a pain. The administration and the upgrades are not up to the mark. If they were able to improve on that, that would be the best thing and would make it much easier to run it in the enterprise.

Since we are looking at public-cloud scalability, as long as that model works, I think we should be good. We're not too focused on the scalability on-prem but we want to see how it scales out to the public cloud.

Our experience with technical support has not been great. There seem to be multiple rounds of escalations surrounding support for vRealize Automation issues that we have encountered.

I was involved in the initial setup and it was complex. The certificates, the distributed install, wasn't straightforward, I'll just leave it at that. We had Professional Services come in for the first round of install. During the second round of install, when we tried to do the update ourselves, there were multiple points of failure. It was not easy. The install, the upgrade features, are not easy at all. The administration part is what is very problematic with vRealize Automation right now.

The upgrade experience is horrible. It's not straightforward, there are a lot of failures, a lot of support interactions. It's not something that we are able to pull off ourselves. I've been with vRA since it was termed vCSA. We've gone through multiple rounds, and it has never been easy.

We were initially thinking about vCloud Director but we're a VMware shop so we wanted something that is native to VMware technologies. We didn't approach a lot of other vendors. One of the things that is important for us when selecting a vendor is whether it fits in with our footprint or not.

I rate it at six out of ten right now. To get to a ten, they definitely need to improve on the administration and the troubleshooting. From an operations perspective, it is a nightmare. From a user perspective, it is pretty good.

It is used to deploy and manage unified configs in an engineering environment. It has performed pretty well.

It has improved things, absolutely. We had a lot of config drift before, and this really helps us keep it on track.

Speed to provision is probably our biggest, significant gain.

• Integration with Infoblox, for IP management
• Three-tier app deployment as one unified Blueprint

I haven't had any issues with the stability.

We've only used it within our lab engineering environment, which is up to 1,000 VMs at any point, so it's been pretty solid.

I was a VMware consultant for years and I saw successes with it in other people's environments.

The initial setup was very easy. The upgrade was also pretty easy. It was not quite as easy when I piloted it through Lifecycle Manager, but that was in its infancy. It has probably gotten better.

The solution itself has a learning curve to get used to building the Blueprints, but once you've done it, it gets much quicker.

Our time to deliver a fully unified, three-tier app, at the right version, is one-twentieth what it was before. There is no manual intervention. No IP management. It just dramatically simplifies all of our processes.

I haven't had the opportunity to use many comparable products.

My advice would be, use it with NSX and with Infoblox.

I give it an eight out of ten, mostly due to the learning curve to catch up to where you need to be. Some third-party integration, that would still be nice to see.

• The automation, that is, being able to automate server deployment, including the option to do it manually if you want.
• Being able to collect logs and diagnostic information in one central location.

I can build machines quickly and deploy them from a central location to whichever worldwide datacenter we need. Also, we can collect system logs from all clusters and hosts, and then we're able to troubleshoot and view logs in one central location. This is a good thing because it saves time.

They just need to keep expanding it adding additional features.

I’ve been using for just a few months, including Log Insight.

So far so good, it's very stable, rarely any issues.

It’s definitely scalable, and does a lot that we’re not doing yet, but we’ll eventually be there. We’re capturing logs from all over world, and everything is in one location, so we can scale to meet that need.

VMware tech support is excellent. It’s one of the best vendor tech support I’ve found.

It's extremely easy, very straightforward, and has good documentation.

It simplifies daily chores, so go get it.

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.

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