VMware Aria Automation Reviews

• Automation
• Ability to deploy heavy workloads quickly
• Ease of use and the flexibility

• Ability to mimic more VCD functionality.
• Ability to share blueprints among tenants, or have a master blueprint repository, so you don't have to move the stuff between tenants. That's probably the number one feature.
• Improve functionality that we're looking for longterm.

It is very stable. It works well. It is easy to use once it's deployed, and is also easy to deploy.

We're starting small, but we see the ability to scale quickly and easily.

It's very good. I noticed with vRA, they are starting to ramp up more support. It started off slow, but it seems to be getting better.

Early on with version 6, it was very complex. When 7 was released, it was easier. Now, with 7.3 and cloud foundations (and everything), it's a lot easier.

Most important criteria when selecting a vendor:

1. Reputation.
2. Support, reliability, and longevity of the company.

We use it as a self-service customer portal, for all of our present customers. So far, it's going pretty well.

There are a lot less tickets, and we get more people onboard much faster.

Between I think 7.0 and 7.1, when we first had it, the IDM Appliance had a lot of issues with SSL. Upgrade has been a issue, we always have to call in and open up the ticket for assistance. It's just not been that good. I think 7.2 to 7.3, which one of our engineers just did, was actually the only time we've actually been able to do an upgrade well.

Also, there's a couple of UI things that we'd like to see improved, but we'll put in future requests for those.

It's been better, but it did not start off so well. We've been using it since 6.0, and 6.0 had a lot of issues. Early 7.x versions had a lot of issues as well.

We're actually not that big, so we do a simple deployment.

We use them for all our issues, though it took awhile. It seems like we're getting the right people now.

The CIO asked us to set up self-service for visiting. We looked at a couple other things. We actually bought a different product first and it did not work at all. It was a Abatix. We did that for about a year and a half, but it just didn't work like it was supposed to.

Then, we came up with a requirements document for what we're actually trying to achieve for that project. Afterwards, we start evaluating the various metrics.

It was complicated. 7.0 was a lot easier.

We're doing cross-training now, so the guy that actually took over for 7 is cross-training the rest of us, and it's been a lot easier for us.

With 6.0, it's just less Windows machines.

It's a product worth looking at.

The self-service portal, as well as the Orchestrator. They are important, because now, especially, I'm getting a lot of public cloud deployment. So the orchestration piece is really handy for day-to-day operations. I'm doing different item consultation management, as well as directly deployed in the public cloud. So those are the two most important features, they are very helpful.

Added features have improved it a lot recently in version 7.03, so you can deploy Azure VMs directly and you can do config management, or you can run scripts. It's really better than it used to be.

Starting from vRA 7, deployment, such as an upgrade. It's so simple, so easy, so interactive. In the past, we had to go through a bunch of operations, but now it's just one click and it can update the vRA client at the back end.

One thing I have seen, although it might just be my personal experience, it's the High Availability. I get a lot of requests and in two different models, the simple model and distributed. With distributed, installation is a pain. I have always gotten into errors when employing a distributed environment, which provides High Availability. So on that, improvements can be made so the process can go more smoothly.

Another thing that's not the best, during deployment, is if we have to integrate managing physical servers. Right now, it's limited to a mature VM environment only. Physical would be helpful.

Four to five years.

No, it is definitely stable.

It is scalable, I haven't see any problem. I haven't done much, but I know that the distributed model is highly scalable and I have deployed that. In the simple model, something like 10,000 operations simultaneously, which is more than enough for most people.

I have called multiple times. I have been using this product for a while, in terms of deployment. I have managed some improvements as well. We are a big VMware partner shop, so we have provided feedback in a lot of processes.

I would rate them as nine out of 10. I don't want to give a 10 because nothing is perfect, but my experience has been really wonderful where the issues have been raised and have been addressed. I have gotten really good technical staff most of the time.

We have tried Cisco UCS Director, which is an equivalent product and we had a hard time. They haven't matured at all. They have so many issues: bugs. We do a lot of deployment as VMware partners so we have done some deployments where the customer initially thought of going with UCS Director, then they changed their mind because of ongoing issues. Then, they finally went ahead with vRA.

vRA setup now is pretty straightforward in a simple deployment. I do most of the functionality, then you just do service mainly. There was one time where I was working and I had to rip out the whole deployment, but I was able to rebuild the whole deployment within a day. That's pretty awesome.

It's very simple, in a very time efficient manner. It deploys the whole environment infrastructure.

UCS Director is the other main product I have used, but it's always vRA that I go to.

From my experience, people think of a High Available, then they plan to deploy a distributed environment, but I don't see much value. Because if they've got a distributed environment, it gets complex and there are more issues and sometimes people run out of patience. So I advise: Go for a simple environment that does 99% of the workload, then, if needed, you can scale it.

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.

• Configuration file templating: limits the amount of copy/pasted configuration across services with minor differences
• Near instant orchestration: no waiting to see if a change worked
• Well-formatted and detailed command output and logs: make troubleshooting easy and break/fix recovery fast

Developers and systems engineers could work together more closely.

Salt does not support performing remote actions that require a sudo password with Salt SSH (agentless Salt execution).

Ansible does support this feature.

I have used it for two years.

I have not encountered any stability issues in the last year.

Official documentation and community support are top notch.

We previously used CFEngine 2 and Chef; both solutions have a steep learning curve that requires a ton of domain-specific knowledge. Salt is configured from the ground up in YAML files and Python, so there's less domain-specific knowledge required and no hidden configuration files.

Salt's initial setup took about two days to go from knowing nothing to having a configured Apache Tomcat server serving our content. That's simple in my book. The complexity comes in when you want to add security policies or routing that aren't ordinary for a horizontally scaling web application; that takes some creativity.

Don't pay for it, use the free licensing options unless you don't have the staff to cover your SLAs.

We also looked at CFEngine 3, Chef, Ansible, and Puppet.

Look at Digital Ocean's guide for initially setting up the Salt server (https://www.digitalocean.com/community/tutorials/saltstack-infrastructure-installing-the-salt-master). Group your configurations by logical components, serve any environment/deployment-specific variables from pillar files, and keep templates as simple as possible (put logic for assigning variables in the *.sls files where there's likely to be other logic).

Our primary use case is for our QA department. They use it to deploy machines when they need to test something out. It has performed well. They are able to spin up a new instance of Windows virtual machine and test whatever use case they have, then turn it back down whenever they are done. 

The infrastructure has helped us to greatly increase our agility.

The most valuable feature is that I do not have to create a virtual machine for these people and have them do a small task with it, then dispose of it. 

I find the solution to be intuitive and user-friendly for the end user. For the administrator, it can be a little challenging. For the administrator, there are a lot of moving parts. It is fine once you figure out where the knobs are you need to twiddle, but it can be a challenge to get it up and running.

There are a lot of moving parts. It could be improved if the solution were more consolidated.

The stability is good.

The scalability is fine when you go with the high availability deployment.

I have had to use tech support, and they are really good. 

I was not involved in the initial setup. I was involved in the upgrade, which was fine with support.

I would rate the solution as an eight out of ten. It has been extremely useful for our end users. To administer, it has been a bit more difficult.

We use it for server deployments, typically. It's mostly for managing our own private cloud, for infrastructure-as-a-service deployments. It has performed well. We just recently went through an upgrade that had some hiccups to it, but it's been performing well for us.

It allows us to deploy servers on a much faster basis. Instead of deploying a VM from a template and going through the process of configuring that VM, with vRA we're able to click once and it does everything: grabs an IP, joins it to the domain, loads whatever configuration agents are needed. It does all of that without manual intervention.

It has definitely improved the speed of provisioning over the old-school way of deploying a VM from a template.

Ease of use, the GUI, is probably the best feature, so that really anybody can use it. You don't have to be technical to be able to deploy a VM.

I find it to be intuitive and user-friendly. Regarding some of the files that you feed it, you don't have to do a ton of development. You can feed it pretty standard configuration files. You don't have to be a developer, you don't have to know C# or Java or the like to get it going.

An improvement - and maybe this is already a feature that I don't know about - would be to be able to deploy to public cloud. Deployments to the public cloud would probably be a good feature if it's not already there, to be able to deploy to AWS or Azure, etc.

My impression of its stability is "middle of the road." We've had some issues where it seems to be a little bit sensitive, where deployments fail and we don't really know a specific reason why. We'll dig through logs and try to figure out what's going on, but it's not always apparent why it failed. And you can kick it off again and it'll succeed. So stability could be better.

The scalability is okay. You can't, to my knowledge - and I could be wrong - tell it to deploy like this: "I want 20 VMs all configured this way," and have it go ahead and spin them off. You have to do them one at a time. So, from a scalability standpoint that's not great, but it could also be that we're just not using it correctly. We don't actually have the need to do that very often, but from time to time we'll get a request such as, "We need five SQL Server VMs." It would be nice to be able to do it once and be done with it, rather than repeat that process five times.

To my knowledge, I don't think there was a previous solution.

I wasn't involved in the initial setup but we just went through an upgrade. It was not without its challenges. Some of the challenges were probably on our side, being able to support the newer infrastructure. But I seem to recall there being some issues importing some of the old settings and from vRA 6 into vRA 7 so that you could destroy VMs that were built in 6 from within the 7 UI. There were some challenges in getting that done. It's done, but I believe that there were some speed bumps to that.

I rate vRA at seven out of ten. There's some room for improvement, but it's better than the old way that we used to do things. It's a good product, it could just use some ironing out.

The most important criterion when selecting a vendor, to my mind, is support: a support network, whether it be knowledgebase articles online, forums online, or calling into actual, paid support.

Everything that takes away from my having to do my own tasks is a very big plus. With Automation and a lot of the components we are looking at right now, I will be able to template everything out and streamline the process, which is going to save me a lot of time. My main focus is COOP sites and disaster recovery, so automating those makes my job easy.

It decreases a lot of manual labor involved in the initial deployment of systems. Instead of my having to go deploy a template and join it to the domain and add software to it, all that is pre-staged once and never done again.

It has also increased the infrastructure agility a lot. A perfect example is that I use Veeam Backup, so I deploy additional proxies whenever our network changes. I don't have to go out and sign in to the vSphere host because I have a different location. I can add additional resources from one location to my disaster recovery management console.

I find the system to be intuitive and user-friendly. In general, I'm quite happy with the entire setup. Once you configure the system, navigating the portal is pretty simple. They use a lot of the vSphere UI interface structure so it's intuitive, especially if you have used anything vSphere-related before.

I don't know if it can integrate with vRealize or vROps in order to already manage what has been done. Right now I'm very big into vROps to pull reports on all my VMs. I don't know if that capability is there already, but if I could integrate it more, if they went hand-in-hand, it would be easy. Not only could I deploy everything in one place, but I could go to another place just to pull my reports on what has been done.

I'm happy so far, I haven't had any stability issues.

I'm extremely happy with the scalability.

I have used technical support, but not for vRA. I used it to help with reverse-engineering my vSphere vCSA because it completely crashed and both sectors were corrupted and I needed to get it back. They were helpful.

We didn't have a solution that does exactly the same. For other systems, we use Chef, but I know that that is more for the application side of things. We haven't used anything like this.

What's important when looking for a vendor, for me, is that they take their time to actually see what we have and what we are trying to do, before pushing an agenda. If they could see what we have and create a design out of that, before suggesting anything else, that would make me want to work with that vendor more because then I would know that they are not pushing something, that they are giving me what is better for me.

Once I understood what it was trying to do, and what it was requesting of me, it was simple. But originally, it took me by surprise. I was not used to the setup yet. One of my main issues was having multiple SSL domains. It took me a while to see how those play a part.

Make sure that you know what your infrastructure looks like before you start.

I rate this solution at eight out of ten, with potential to grow. I still have to learn a lot more about it. Once I learn some of the additional features and add-ons that  I can implement, I think it will increase.