VMware Aria Automation Reviews

vRA's Orchestrator allows you to connect to a huge ecosystem with a huge number of third-party systems to automate any and every IT process that you can think of. It makes it very flexible. Makes it really adaptable as opposed to some other systems.

It allows people to move into orchestration and automation, and most customers want to get into that but they don't really know how. vRO and vRA gives them a step through the door to allow them to start building upon. It gives you a framework, it gives you a baseline to let you build from there.

They are doing well as far as iterating quickly, iterating by often adding small things. I think there should be even more integrations with third-party systems. You have Infoblox and Puppet which great. Let's add Chef to the mix and just keep them coming.

So far so good.

Everything is much improved, especially with vRA's automation 7 and newer, as they move more things into virtual appliances and out of Windows. That's a win for everybody. It's a win for the customers. It's a win for us deploying it. It's a win for manageability, scalability, everything.

Tech support is usually great. As soon as you get a live person you're good. It just depends on the level of support that the customer is paying for. Sometimes that's nothing that we can control, it's just what they have.

It's much more straightforward now that it was in version 6.x., to the Nth degree. They have made it so that you can do either a proof of concept or fully distributed version of vRA with a wizard-driven GUI, which is amazing. Now, there are still some little quirks with that wizard, but it being there makes it much simpler than going it manually and installing each component and linking them all together after the fact.

For me, being a consultant, vendor selection isn't what matters. I want to use whatever is best for the customer. So whatever fits their business use case best is what I'm going to go with, what I'm going to recommend.

vRA does most things really well. There are still some issues such that, if you are going to go 100% cloud, if you don't want anything on-premise, there are some other solutions that might have a leg up.

Use vRA, but it's more about the process than it is about the product. You have to make sure that the users, who are going to be internal IT most of the time, that their expectations are set appropriately. Make sure that you have buy-in from the higher-ups as far as automating processes. You have to make sure you have by-in at all levels.

It's cut our server deployment times down from weeks to an hour.

Because we're running on the older version, we've actually had a lot of stability issues. We're currently evaluating either upgrading or integrating the new version, but we haven't made the decision yet.

Because we're on the older version, the scalability is a lot more complex than the newer version. We actually built bigger than we needed when we deployed it. I do know from testing it in our lab that the scalability in the newer version is pretty robust.

Excellent. They're knowledgeable and you're able to reach the right person.

No, we were just doing manual builds and manual deployments. Our management said that we needed to do something, so we invested in vRealize Automation.

I was involved in the initial setup of the older version. It was extremely complex and difficult to get right.

In evaluating the newer version, it's super simplistic, and they did a fantastic job of all the changes made to automate the automation pool.

The corporate government works a little differently. We had put out a set requirements and other vendors come and bid on it, then we pick the vendor who best met our requirements and has the lowest cost.

No, we were just doing manual builds and deployments. We did not consider any other vendors that I'm aware of.

Make sure you deploy the latest version.

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.

I think the ability to create blueprints and define our lab environments and vRAs. It's really easy for anyone to use it. Just drag and drop VMs and all these other components into the Blueprint Composer.

I think having the ability to create different tenants, having a catalog items, and having a different user base go in there and having them pick from the specific items that they want; have them be more living in control.

The additional features I would like to see are better integration with Horizon, or actually integration with Horizon since it doesn't seem to be existent, more integration with NSX, and also better integration with Code Stream.

So far, it's been stable. Although, we have a few issues with it. Mostly, the issues that we encounter have been integrations with Horizon, integration with NSX, and a little bit the integration with Code Stream as well.

Scalability is great. They allow you to deploy in different situations and scale up. If you want a bigger vRealize Automation installation, you just spin up more of these appliances.

They are very responsive, but I for one of the issues that I had, they were not able to answer my question. I had to get into more of the low level of the application and try to figure out a solution for it.

It was somewhat complex. The documentation is very long, and I was able to install it based on a blog that I found online. Someone had already previously installed it. They went step-by-step. I thought that was more useful than the documentation.

No, we were happy with what they demoed, and what they showed us.

I think the support and the feedback that we got from the salesperson, the response time that we got, we were really happy with it.

I give it a six out of 10 because we still haven't met what we intended it for.

It works very well just spinning up VMs, creating blueprints, for doing some of the basic stuff. But doing some of the more advanced stuff, it still needs a little bit more work.

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.

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.

We have used it mostly for our internal IT. We haven't really published it for customers or other groups to be able to use it. But we've actually just hit the surface. We've used it for rebooting servers, adding applications, automating some scripts; general things like that.

It has improved our organization by automating some of our processes. Automating processes saves us time. If we are able to schedule, say, a server reboot, instead of actually having to log in at 8:00 at night, when we wouldn't normally be on our network - scheduling a reboot after, say, a patch or something. It just allows us to not have to work. It does it automatically.

The most valuable feature of vRealize Automation is being able to - as the name says -automate VMware executions, to be able to automatically reboot; servers, power them up; add applications. That's useful to us in IT.

To improve the product, possibly the interface could be more informational. There's a nice tree structure on the left, but being able to know what to do with that tree structure could possibly be improved a little bit with right-click menus or more information. I'm sure the Help menu is fine, but just more intuitive, maybe.

We haven't really had any problems with stability. Usually, for what we use it for, it has been very stable, very dependable. I feel like it's done a good job.

I feel vRA is scalable. Being able to develop it more, and get more installations, more things to use it for, will be able to help us scale it out and use it for more people.

I have not had to use tech support for vRA, so I don't really have any experience with that. But I'm sure it's wonderful.

I personally have not upgraded the program, but the people that actually manage it have not had any issues with it. That being said, it's still a fairly small installation, or a very small group of people that use the product. We haven't expanded it to be able to know, with the installation, how it has gone.

The solution is user-friendly, to a degree. I feel like you still have to know a little bit of the ins and outs of how to get into it, some of the commands to use for what, exactly, you're trying to do. But besides that, it's pretty user-friendly.

In terms of increasing infrastructure agility with it, we have, maybe to a small degree. I don't feel that, with our implementation of vRealize Automation, we have really gotten very far. We've only scratched the surface. Like I said, we only use it for our internal IT, and we're just being able to save a little bit of time by the things that we do. We haven't really dug deep into what it's capable of.

It has made it easier for IT to support developers but I don't feel like we're at that point yet where the developers are involved. We have it as a future (goal) to involve our developers and have them be able to get on a webpage, and be able to do things automatically, without them having to put in a ticket or request us to do something for them; just making it automated. As we get to that point, though, I think it will be very useful.