VMware Aria Automation Reviews

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.

The primary use case is that it fronts VirtualCenter for our entire development environment. The current version performs well.

It provides us with rapid deployment and reclamation of servers. It has also increased the infrastructure agility, application agility, improved time to market, and made it easier for IT to support developers.

• Self-service for the servers
• Reclamation
• Self-service for all of our IT or development teams to expand and decrease their environments at will

Other than the features that are supposed to already be in place with the new version - meaning the tight integration with vROps, which they said was there but wasn't - the ability to migrate between clusters is a big deal right now. If you try to migrate a current client, create a research pool for a client, and they have multiple ESX clusters, you can't get it. It's so painful to do. The new version that we will be going to is supposed to do that automatically. And I will believe it until it doesn't work.

Its first iteration had some hiccups. It wasn't as streamlined. It crashed a lot more. This version has been way more solid.

Scalability has been excellent. It scales well horizontally. Vertically, you'd have to do a lot to make that happen. It will scale both ways. One way is easier. Horizontally is way easier to scale. It's just the nature of the way the product is built.

On the current version, support is much better. I have a TAM and I have mission-critical support, so I usually get to somebody.

We were previously using a product from CA that CA no longer supports. They got out of the business.

The initial setup was not straightforward. It was not simple, and we had a PoC. We had VMware help us deploy it, and it took them an exorbitant amount of time.

Upgrading hasn't been without its pain. We've had our issues, we've lost some data. There have been some hiccups along the way. We're confident that this next upgrade will be smoother, since it has been getting more stable over time.

The solution is intuitive to the end-user, absolutely. I've created a web portal, through vRA, in which users' specific requirements are built-in. Now, to develop that was not overly fun, but, overall, it is good.

I give it an eight out of ten because it has provided my development team a pure self-service portal. We deploy thousands of machines and reclaim. So, their time to business and their time to market has been improved exponentially.

Probably the extensibility as well as the out-of-the-box features it provides, which allow you to be very creative with things you can add on and customise. The extensibility is the most important part for me.

The extensibility allows you to take custom or proprietary requirements and make them happen. Where there's a lot of products, it will give you a set number of used cases, and if you have something that's outside of those, then it can be difficult to make that happen, but the vRealize Automation product allows you to just extend beyond what we'd initially expect them to be used for and make your own custom scripts that can be executed as well as the things that come out-of-the-box.

Yes, certainly. The ability to manage the product in code; so infrastructure is code. It certainly has improved in the last version, but it still isn't quite at the level that some of its competition is in. It's not infrastructure is called native, overlooks is getting closer to it, so that's probably the biggest single improvement to suggest.

About two years now.

Yeah, there are some issues with stability. I suppose with any product, when new versions come out sometimes there are bugs, and depending how wide-spread that is, it can take a varying length of time to clean a patch from a big crash or fault. I give it a seven out of 10 for stability. There are issues, but it's not dreadful. It is certainly better than it was in previous versions.

No, it's very scalable. It's fairly easy to add the numbers of servers to allow it to scale up. As I've said, we've seen it running hundreds of concurrent deployments with the right design and the right number of devices. Obviously, while supporting the platform, it's very scalable.

It's probably a difficult question to answer. Depending on the type of relationship you have with them, I've looked at a couple of places. One company had business critical support. They were very quite good at certifying specialists, they were almost always able to at least categorise a problem, if not fix it in the first sort of hour or two. If you don't have that level of support, you often go through a couple of levels of help desk first and that can be quite frustrating and quite difficult. So I think the level of support maybe averages out to a six out of 10, but it could be eight or nine if they got the right.

Previously, I worked in a team which tried a proprietary tool that did a very similar job, and the main reason for going a product like vRA, is that the development cost of it is handled by another company, so they'll maintain that, and we develop and maintain their own code base instead of paying for support from a larger organization. The idea is when you reach a certain scale, paying someone whose job it is or specialty it is to do this kind of work, they'll have a small team doing it, then having the rest of the people on that team might move on. I suppose to operate it into a prize scale was one of the main reasons for switching.

The installation has been greatly improved in the latest version. There's now a lesser based installation, which has made it many times easier. It is still something that requires a bit of knowledge and time (if you've never used the product before). It is probably going to take you a week or so to get familiar with the concept and try the installation maybe one or two times before it works for you. Once you've used it a few times, you can probably do an installation in a day or two. So maybe a seven out of 10, for ease of installation.

No, I've never been involved in the selection of this product, but I've actually joined teams that have already chosen to use it. I know some of the competition. Some of the other products have on from being the VMware vCloud Director. Some of the products are heard suggested via other places, like answerable and telethon.

Probably the decision to run a private cloud, such as VMware, versus running things in someplace like the public cloud and it being AWS. The main thing is about the scale, and getting sufficient scale, it can be cost effective to run your own private cloud. Best to find the right algorithms, if not setting up the hardware themselves; but you probably do need to reach that multi-million pound scale to make that the right decision. Smaller players are probably better off thinking about comparing costs without a cloud provider, and maybe a less niche product.

It's a good product. It's very extensible. It is fairly complex to set-up, and its fairly closely tied to VMware's infrastructure, so there's a lack of portability to public clouds and a lack of ability to manage infrastructure is code natively. Although it can be persuaded to do it, it's not always straightforward. Those are probably the biggest downfalls.

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.

Jinja/Python + wide range of embed functions for various platforms and purposes.

Jinja is based on Python, which is a fairly handy and comfortable programming language. They make it simple to create Python-based templates and, when necessary, create functions for actions that are not covered by the Jinja engine.

Centralized administration and orchestration of severs and services.

Support: It's not bad or poor, but there are some issues. On the one hand, it's about development and progress; on the other, there were some issues that took too long to get fixed by the SaltStack team and forced users to invent workarounds.

Documentation: I'd say it's a little bit complicated for beginners, some topics are not clear and so on. So, one will have to massively use search engines when it comes to complex setups and solutions.

I have used it for ~7 months.

I have encountered any stability issues.

I have not encountered any scalability issues.

Technical support is good (4 of 5).

I did not previously use a different solution.

The initial setup was neither straightforward nor complex; it required some effort.

It's OSS.

Before choosing this product, I evaluated Ansible and Puppet.

Be patient and you'll get a great solution.

We mainly use it for deploying SAP machines, SAP-type systems.

It allows some of the tenants to self-provision their machines, so they don't have to wait for us to create the machine for them. They can just do it themselves. It has helped improve our infrastructure agility.

All you do is just press a button, it cranks it out and everything is consistent, so that's one nice thing about it. The speed is also a valuable feature.

I don't find it to be user-friendly or intuitive because, in my case, when I have to deploy SAP systems, I need to jump between the vRA, the vRO, and the actual vCenter itself. I need to go back and forth to do different things. For example, with the vRA I'll deploy the base machine. With vRO, that's where I may have to get an IP address. If somebody's SAP machine has a secondary, virtual name, I need to get the next available IP address from vRO. And then, inside the vCenter, I need to do some firewall stuff, NXS. So it's not that user-friendly.

I wish they could make it just one application, just vRA, that does all that. There might be a way to do it but I haven't figured out how to do it yet.

Also, vCenter and vRA, I believe they share two different databases so sometimes you have to somehow sync them up. I wish there was only one database between the two or, somehow, one database would rule over the other one, so if you have both products, the vCenter might use the vRA database. Otherwise, when you do stuff in vCenter, you have to write a command on vRA to update the databases.

It's pretty stable. Once in a while we'll have a problem, but it will be something that's inside the vRA database that got corrupted somehow and they have to clear something out. For example, sometimes, when I deploy a machine, it'll be in the request queue and it'll stay there for a while. Then someone will have to go in there and do something to clear that queue.

It's scalable, in terms of adding Blueprints.

When looking for a vendor I look for a quick response to problems, and reliability. When there is a problem, VMware will help you chase it down. They'll follow up. I like their response times to our issues. They will also escalate.

My advice is: Get training.

I give vRA a seven out of ten, for now. In addition to the database issue I mentioned, it's not quite clear how to do certain things. I have not been given training on it. The learning curve is steep. For me, a lot of it is on-the-job training. There might be a better way to do things, a quicker way, but I don't know what it is right now. For now, I don't find it that intuitive to use.

vRA is a great tool. It gives a lot of flexibility. It gives the customer an experience to automate their processes, their provisioning process. So, we widely adopt that into our environment to automate a lot of provisioning processes to automate the VM provisioning. Thus, it's a great tool, which actually gives a lot of flexibility in terms of provisioning and orchestration.

I would say maybe a better interface. It looks very plain. So, a more user-friendly interface, so the vRealize Automation tool could be improved.

It is a very stable solution. It's a state-of-art kind of solution. It gives a lot of flexibility. It's customizable. You can tailor it according to how you want vRA to work for your organization. So it's a very stable tool. It's a very cool tool.

• It's scalable. You can scale it to whatever you want to do.
• It's customizable. You can tweak it to how you want to use the tool.

The tech support is pretty awesome. Whenever you have issues, you engage them. They are on top of the issues, and they get a resolution for you. It's a top-notch type of support from VM tech support whenever you face issues with vRA.

It is straightforward. It's not very complicated. Most of the tools that VMware develops are pretty straightforward. You just click off buttons. It's easily understandable, and it's easy to implement and use it.

It's one of the cool tools in the industry. Go get VMware.

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