VMware Aria Automation Reviews

• We use it for our own private hosting. 
• We do services for departments within the State of California. 
• We have a large agency where we design and deploy an automation solution around vRealize Automation.

It's done most of what we needed for our customers. However, custom integration had to be done with certain things which are not exotic.

I would like to see more out-of-the-box blueprints and workflows for the rest of VMware's products and its portfolio.

We would like them to continuously improve the product with upgrades, as they have been.

The product is stable. When we used it early on, the changes were so rapid that we had to be careful with versioning. We probably still have to be pretty careful between versioning. The environment includes NSX, as well as vRA. Therefore, we have to pay attention to making sure everything is compatible.

Scalability hasn't been a problem. For the agency where we have it deployed, there are 4500 to 5000 VMs.

The first version that we deployed was not long after VMware had acquired the product. This was with version 6 or 6.2 for a production deployment. There was a lot of work to do with certificates, etc. However, the setup is getting better with each version. 

If you do a deployment for a proof of concept, it is simple. When you start to do a deployment where you need higher availability and more resiliency, then the complexity goes up drastically.

From the customer perspective, the value was worth it.

Be particular about requirements and what your goals are with the customer. There is a lot more to this product than doing a deployment, so make sure you understand the use cases.

What I like the most about vRA: Its seamless ability for users to be able to go pick a catalog item that we have created for them, while they are testing a new version of their code and say, "Okay, I want you to make my old version (based on these blueprints) run, please deploy me - my entire environment."

Whatever we do for the users, we use NSX integration for it, so they can have that encapsulated environment separate from their coworker trying to do the same code testing with the same IP address. Everything needs to be the exact same. That's what we love about it right now.

The biggest feature that we've seen so far is for them to lifecycle it out. A lot of times we have developers that build something, then they forget about it. Now, we lifecycle out after 30 days, so I don't have to waste those resources for a prolonged period of time.

It has made our developers be a bit more agile, instead of like old days, where it was, "Okay, we need a new environment, I've got to spin up the whole thing for them." Now, it's, "Hey, if you need a new environment, go to this URL, click these catalog items, whichever ones you might be working on."

The external Linux script is all automated for the developers. They just need to be able to say, "Hey, I need this new code pulled down," That's all. They don't even have to build their own workflows anymore. As for the VMware side, we can build the workflows for them, or work with somebody in the DevOps team to build workflows. So now all the developers have to do is click a couple of buttons, then they're working and they're on their way.

One of the things we saw in the initial phase was our integration with our development domains, where if we want to have more than one domain tied to it with users, we're seeing that as a struggle. However, VMware has said, some of these features have been worked out with IAM Appliances. So we are seeing a bit of improvement there, though we want to be able to see multiple domains that we can integrate into the same tenant space a little more seamlessly.

There are still some features that I would like to see changed. One pain point we have seen is users are able to set their lease expirations to zero, which means the lifecycle management gets disabled. So, it has some limitations there that we have seen. However, that's something VMware has gotten back to us and said should be fixed in future releases.

It's fairly stable.

There are some things that we would like to see. Maybe they already are in the current versions of 7. We're still running 6.2.5, but we would like to see a little bit more seamless integrations with some of our other products, like our DevOps tools. We use Vagrant or other things where the developer sometimes just wants to do their job through Vagrant CLI to communicate with vRealize Automation. However, we have seen that as a pain point so far.

We have tested a little on how to put in some operations metrics.

For example, if say, "This will run that script, deploy up some more virtual machines, and/or if this will automate that." We haven't had to expand on that yet. We're trying right now to use Automation Center more for development purposes only. We haven't utilized it in a production environment scenario yet.

We have. It was in the very beginning phases when we went to vRealize Automation. It was new for them, so it was a bit painful in the beginning, but lately it's been better.

They're snappy. They know their information.

VMware has really shaped up their support lately. Now, I can get to a intelligent conversation with somebody on their tech side, not repeat steps that I've already gone through. That's huge for us, and that was one thing which we had concerns about in the past with VMware. Those are some of the things we mentioned to them: "We need better supportability of your products." We have been seeing that a lot lately.

At a prior company that I came from, we used vCloud Director, and that was a product I loved.

It was something I could not obtain any more, because at the partner level you need VMware to still maintain the vCloud Director licensing. However, our company does have a giant vCloud Director pool now, the one that I work for, but the reason for vRealize Automation was, we can't get vCloud, which I needed a nice lifecycle control management, then we went with vRealize Automation, because it had the majority of the functions that you see in VCD but with just a little bit more added functions at that time. With the integration of NSX, that was something that was key for us. We really needed to be able to provision environments on the fly for them to have very like-for-like scenarios. However, when they're doing their QA testing or pre-stage testings, we needed the ability for encapsulation of those environments to be separate.

That's one reason we saw automation with integration with NSX and VSAN, it was a no-brainer for us.

I was involved in the initial setup.

The initial setup for the 6.2 environment was a little bit painful, because you have to have a separate the IAS server and different things, like a Windows server. Now, with the new 7, I know it's all appliance-based, which is beautiful.

It's easy to set up. I have a PoC environment right now we're toying with, and it's a lot more simplistic than the prior versions were. I'm more familiar with the old architecture of it, but I'm looking forward to really implementing the new architecture of vRealize Automation.

The vRealize Suite, it is a very expensive product. However, with all the things it did offer us, in the long run, it made sense for us, because we got to cut down a lot of our public cloud costs due to on-premise solutions.

We did utilize vCloud Air. It was one of the other tools that we did try out.

Now, I don't like to talk bad about VMware, but it was a disastrous product. It was vCloud Director, which I was familiar with, but the supportability was not there. There were some bugs whenever we were trying to do automation and workloads between our on-premise into the vCloud Air. That was the one thing we were trying to utilize, and it just didn't work well.

Then, the other automation solution we were using Chef and Puppet (and other things) for our DevOps tools, but we really wanted to shift more focus to the developers. They don't want to have to command-code out everything. Some of them want to just go, "Click, click, done."

When I went through the first demo of vRA, that's when I saw that this product would be a very beneficial product for our company.

Really pay attention to how you design your blueprints and your workflows, because a lot of developers do not want to do that. They do not want to design their own blueprints and workflow operations. They want it to already have been done for them. Make sure you have a strong relationship with your DevOps team so you can get the most out of this product. Because if you are trying to do it single-handedly as an Operations Center without the go-between, it'll be a struggle to get Development onboard with this type of product. But once they do get on board with the product, they won't want to look back.

Most important criteria when selecting a vendor: Supportability is huge, not to say everybody on our team should be experts in everything they do, but when you do need help, you want to make sure that you're working with top-tier support. I don't want to have to run through the wringer of, "Okay, I got to go through Tier-1, then Tier-2, then finally I can work with Tier-3 (somebody on my level of knowledge)."

When I started working with VMware Aria Automation, I used it mostly to automate the server build process. We completely automated the entire VM-build and post-build processes. I then used the tool at another organization in relation to CICD pipelines.

We now see more hybrid cloud scenarios and enrollment of network automation as well.

VMware Aria Automation reduces the time to market when it comes to deploying new solutions. Usually, it takes three to six weeks to deploy a new solution. Now, with VMware Aria Automation and the automated blueprint, the overall time to market is an hour, depending on approval.

The solutions can be deployed across any cloud, which is a huge advantage when a customer requires machines to be deployed rapidly.

The extensibility of the solution when it comes to writing your own ABX actions is a valuable feature. You can write it in PowerShell, JavaScript, or Python, which is great.

I also like the fact that you can pause a build process, do other tasks, come back to it, and continue with the build process.

The ability to customize the entire user frontend experience with the design canvas is great as well.

When it comes to the orchestration workflow, you're on your own. The documentation and resources are very limited, and you have to learn everything on your own.

Though the product is very powerful by itself, many who work with it struggle to get up to speed. As a result, they view VMware Aria Automation as the icing on the cake and hold on to their PowerShell scripts on the backend.

I would also like to see more integration with third-party solutions. The documentation regarding integration with third-party tools such as ServiceNow needs to be improved.

I've been working with this solution for 10 years. My first deployment was back when it was called vCloud Automation Center or vCAC.

The stability of the vRA platform itself is very good, but because of Workspace ONE, I would rate the overall stability at seven out of ten.

In terms of scalability, I would rate this solution at eight out of ten.

The technical support team in Ireland is excellent, and they resolve issues on the same day. However, if your ticket ends up at another location, it may take a few days to receive a resolution. Overall, I would rate technical support at eight out of ten.

Positive

An experienced person will find the on-premises deployment easy to do. I would rate the initial deployment at nine out of ten for an experienced person. For one who is new to the solution, I would rate it at seven out of ten.

The initial setup may take anywhere between 40 minutes to one hour.

As is the case with any other automation product, VMware Aria Automation also requires a journey. You will need to start slow, build the platform, and make sure you have good out-of-the-gate use cases. You can start with automating basic server requests. If you already have CICD tools in your environment, then you can integrate them and try a few playbooks.

You will definitely need to train your staff so that they can keep moving forward with the tool. It is a complex product, and you will need at least one full-time employee who has experience with scripting and an interest in automation who can be dedicated to this solution.

Overall, VMware Aria Automation is flexible, reliable, and scalable. With VMware Aria Automation as a cloud service, it is even easier to deploy and manage. Therefore, I would give this solution an overall rating of eight out of ten.

We are using it for developers to test code. Our Customer Care uses it to troubleshoot customer issues. We also have a training business unit and they deploy classes for customer training.

We've been using it for four years now. It performs well. It does the functions we need. We do have some issues from time to time. I wish there was a little bit of more maturity out of the product, but it is getting better with every release.

It has definitely increased speed of VM deployment. When a normal server-request would come in, it might take anywhere from three to four days to deploy. Now, within 15 minutes, they can click and have something up and running.

The IT support for developers is nice as well because they are able to manage the environment themselves.

Self-service: Letting the end-users deploy their own machines so the administrators are hands-off at that point.

The user-friendliness is seen in the minimal training that is required to get them up and running, to start deploying machines and accessing.

Something as simple as formatting the catalog in a different way would be helpful because there is no option for doing so. A lot of the contents for the virtual machine, blueprints that you can request, are hidden from view and there's no way to change the view.

It does go down from time to time. We have some issues with the appliances sometimes and we have to do reboots in the middle of the day. That affects the ability for them to deploy. Existing stuff that is already deployed, there's no downtime for that, but it does keep them from deploying at that time.

We have it deployed in a highly-available environment and scalability is nice because we just add another ESX host and then we are able to increase the capacity.

Technical support is helpful. Sometimes they can take a little while to get back to us, but for the most part, we end up finding a solution to cases.

We were using Lab Manager before but that was decommissioned so this was the next solution. We chose it because it did everything we needed it to do, it was the logical step from Lab Manager.

The criteria for the selection process included that we needed to have a self-service environment for our developers, that Customer Care be able to deploy machines, destroy machines, complete the entire VM lifecycle - and this does it.

The setup is fairly complex, but we've been using it for a while so I'm pretty knowledgeable about it now. Upgrades are pretty straightforward. We had a lot of problems originally deploying it, with some certificate issues. We had an engagement with VMware so they were able to help us get a proof of concept environment set up as well. So that was helpful.

It's a good solution. The deployment can be complex so I would recommend engaging professional services for setting up a proof of content environment to evaluate it.

I rate vRA at eight out of 10 because of issues with the stability of the appliances. But other than that, it's a pretty solid product. It does exactly what we need it to do and we are happy with it.

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.

The primary use case is to automate systems, and at a faster pace, so we can give them to our end-users faster.

It has cut down the time for building out a machine. A process that used to take three hours is down to 20 to 30 minutes. If the users need a machine fast, we can get it presented to them quicker. So it has absolutely helped with the speed of provisioning.

The most valuable feature is the way that it plugs into our monitoring systems, and Infoblox and Puppet.

I don't find the solution to be intuitive and user- friendly. The GUI is really complicated. Tracking down logs and errors is very hard. Then, it takes a specialized JavaScript person to build.

Also, I'm not sure how the upgrades are going now, but they definitely need to evolve the upgrade process. 

Finally, the logs are very generalized. Giving more of an indicator of what's actually going wrong, rather than just a generic error code, would help.

We had a lot of issues at first. Especially with doing any kind of upgrades, it was a complete tear-down and a complete rebuild of all the Blueprints. The upgrade process was not easy or intuitive at all. But it seems to be getting better.

It's easy to be scalable on it. You're as scalable as the infrastructure you have behind it.

I have used technical support, but more on the infrastructure side, not on the system side. My experience with them has been good. They get back to us quickly. We're a TAM customer, so we get quite a bit resolved pretty quickly.

We didn't have a previous solution. We were doing manual. We still are, but we're within 15 to 20 days of deploying it. We went with this solution because of the partnership with VMware. We have vCenter, we have a bunch of their products, so it just made sense to try to go with a simple approach.

The most important criteria when looking to work with a vendor are the ability to adapt to us and our needs, and that the vendor be quick on responses.

I came in about halfway through the initial setup. It was very complex. We had VMware projects going on, so we had a couple of consultants giving us full-time personnel to help us through it. We had VMware there, and AdvizeX was another one. Then we had the specialty people from VMware that they deployed out to our place.

We still haven't gotten it into production yet. But once we do, our value is going to be the ability to turn around virtual machines a lot faster.

Read as much as possible and then take it slowly and don't try to jump in full force. Make sure you have a good plan going into it. That was one of our mistakes. We were expecting, "Oh, this will be pretty easy," but once we got into it, was a little more complex than we were thinking.

I give the solution about a seven out of 10, given the process we've gone through with it. We've had it now for three years, but we haven't been able to really deploy it in production. I don't know if it's because of the documentation or just the ability to be able to use it and make it functional.

Automation and operations.

So far we haven't really implemented it on our own organization as far as using it with IT in the workplace internally. But vRA has helped us bring in a lot of customers because they use things like Chef and Puppet, and this works in that same kind of realm. So it has drawn those customers to us. We are, as part of our VMware venture, working on our expertise in that realm.

Where it is implemented, in the little bits that we've labbed it out, internally, it has, obviously, increased our infrastructure agility. Otherwise, we wouldn't be continuing to implement it. Once you get all the pieces together, it improves delivery times for internal labs for our internal teams.

We like the seamless, non-vendor-specific application that we can provide with it. We're a service provider, so we have all kinds of different clients and they have different applications. Automation works with all of them, pretty much across the industries. The ability for it to be compatible across many different products is really what's important to me because that's what's selling: being able to go cross-platform and be hybrid. That's the most important feature.

After that, ease of use would be up there too. We also like the GUI display which ties in the non-devs with the devs and helps them work together.

They can improve on the dashboard representations and the options for non-technical people. I would like to see the ability to customize that and maybe provide them with helpful guides to what subscriptions they have. Sometimes, I find that I have to do more explanation to people who do approvals. I would really like to customize the display to the terms they use in their particular business unit. So a little bit more of a nod to the customization of the UI for non-technical users would be helpful.

Also, I expect it's going to come with time, but there is not too much documentation out there because it's fairly new, and not very many people use the little niche product. So more documentation.

So far, VRA seems stable to me. I don't have any complaints.

We haven't had any scalability issues yet, but we are approaching that potential, whenever we get larger customers. The customers that we do have on, if they do use it, they're just testing the waters with it.

They're very helpful. We have Premier Support with them, so we're always working with them. Our TAM is always on top of things. It's good.

Before vRA, we were using a combination of Chef and Ansible. We moved to vRA because I'm on the VMware side of the house, so naturally, that was part of it. Also, we switched because we foresaw the need for hybrid cloud and wanted to be relatable to VMware, so we could have an answer to compete with business units. We wanted to say, "We have vendor-supported vRA that does the same as your third-party or your open-source." We wanted that name brand with it because that's the department I'm in.

Compared to the previous solutions, while I don't have too much experience with them, from what I understand, from what I have heard from the people I work with that helped me on that side, it is a lot quicker. In the small test bed that we have, it is performing better as far as being able to deliver, and being consistent in its delivery.

The setup is straightforward. There are plenty of hands-on labs and guides. It's more the, "What can I do with this?" As a project engineer, I try to translate from the vendor to the customer, according to whatever they're doing at their end.

We haven't really had any bumps in the road deploying it.

My advice would be to go to hands-on labs to see if it's exactly what you're looking for because, as far as the reality versus the expectation goes, it might be a little bit of a shock, especially for the non-technical person. If they're going to say you, "It's going to be great. You're going to know everything," there are some things you might have to take into consideration. They might have to do a little tutorial for you. I would just try to set your expectations.

I rate it at eight out of ten. I believe it's intuitive and user-friendly. Could it improve? Yes. Could it be worse? It could've been a lot worse. So it's okay.

The extra two points are because one of the first issues, on one of the first versions that I took training on, was around the idea that, yes, here's your dashboard so people can deploy resources without having to know too much, but it seemed kind of bare as far as presenting it to those people. That's the only gap that I see and it's just going to be filled in with user experience and people like me saying, "I'd like a little bubble to pop up," or something to hover with information when someone has to give approval. I'd like for them to be able to see why they are approving this, without having to go dig into why we set up that limit. 

It would be nice to have a tooltip that says, "This was agreed upon..." or whatever comment I want to display. For example, if I want to reference a ticket number internally: "Approved, XYZ," or "Related to mass ticket maintenance ABC," so they can say, "Yes, that's right, this is the DFW migration," or the like. They're non-technical and those are the kind of terms they use. I find the UI is missing that part. I have to explain it to them. And then, of course, they're going to forget, or they're going to get a new guy in, and he's going to say, "Why do I keep having to approve these things?" It would be really nice if it just told him right there. This is why you're approving it because of mandate such-and-such, or memo number 123.

From other products that we work with - I came from the troubleshooting operation side of the house before I started working in Product, so I worked with VMware on ESXi and vSAN - they have always been good at taking our opinions. For vRA, I'm starting that process with them, so I'm not expecting them to have a turnaround yet, but I'm expecting them to take our feedback, for sure.

The primary use case is going to be managed services. We're a hosting provider and we're looking to provide provisionable resources across multiple cloud platforms and to be able to support Day 2 Operations. We're trying to fully manage the lifecycle process as well as fully integrate with all of our management end-points, whether it would be inventory, ITSM, or backups, etc.

Eliminating the need for our engineers to do any of this manually, and being able to focus their efforts on the deeper level customizations at the OS level - like installing applications and leveraging things that we would not necessarily want to offer in an automated sense just because of the diversification of the implementation - that has been of value to us.

I personally spend a lot of time in vRealize Orchestrator, so being able to directly tie into the back end on the APIs, I find that to be what really is the most advantageous thing for me.

The solution is intuitive, but not necessarily user-friendly. In particular, it's the documentation. It's a lot of going-through-the-weeds types of scenarios. There is just an abundance of information, so it's a matter of understanding how the objects or the relationships exist, and then, obviously, being able to access that information and knowing how to make use of it.

If there were a tighter integration with either AWS or Azure - being able to have a little bit more out-of-the-box, flexibility-wise, and the ability to realize that - it would help. You're getting out-of-the-box workflows that will literally allow you to provision, but there's a large development gap to cover the use cases that we're trying to provide or support.

The stability of the product has been good. However, I feel like the upgrade, doing more of the infrastructure administration, has been more problematic for my organization. But otherwise, it's been a good product.

Scalability is good. We haven't had any real concerns over that because we have a data center footprint. We haven't had any real limitations on acquisitioning new hardware so, at the rate at which we're growing, we're making the right projections and we haven't really exceeded our availability.

VMware tech support is not terrible. At times I feel like it's hard to get to the proper person to speak with, because I deal with vRealize Automation. It's a matter of trying to get straight to the second tier.

We just had vCenter. Ultimately, we were looking to take that to the next level. We wanted to allow our customers to be able to potentially consume the catalog items and to better leverage things, and to give more transparency to what we can provide. At the same time, we wanted them to not have to go through all of the ticket-raising process. We wanted to be able to allow them to get right to it.

The initial setup is pretty straightforward. I've done it many times though, so at this point I can almost do it without documentation.

Compared to alternative solutions in this space, the feature set of this solution is unrivaled. I can't really think of anything else that has a better management platform, that would be as mature as this software.

Do your research beforehand, because the architecture itself can get you tripped up if you don't properly align your certificates. You definitely have to have an idea of where you want to end up.

There is certainly room for improvement with some of the little things I was talking about, like either better managing of the upgrade process, or just making the infrastructure deployment a little bit easier. It feels like all of the pieces have been automated on one level or another, like with the PowerShell scripts, doing all the IS, Windows boxes preparation. They just need to get it to be more end-to-end.