VMware Aria Automation Reviews

Multi-machine blueprints.

Prior to the deployment and utilization of vRealize environment infrastructure, deployments (VMs, IPs, DNS, firewall rules, load balancers) would take up to three months. After utilizing vRA we have reduced this to less than an hour for a complete, production-ready infrastructure deployment.

There are a lot of usability issues which I have. Overall, the product feels bloated and cumbersome. It feels like you are very locked in to what VMware has decided is the "way to do things" and you have to spend a lot of time developing custom code and logic to get around these artificial limitations.

Specifically, the blueprint design canvas has had a terrible memory leak error for several versions which makes designing blueprints difficult and time consuming.

One year.

Nothing specific to the product. Due to the complexity of the deployment, there can be issues with stability because you need to keep track of many moving parts.

No. The product is very scalable.

Due to the customizability of the product, support can often be very difficult. However, VMware support is often very helpful and capable.

No, we did not.

The initial setup is very complex. You will deploy at least three VMs, a Linux appliance, a Windows IIS server, and a Microsoft SQL server. If you want high availability, you will deploy two of the appliances and IIS servers. The deployment process requires specific versions of .NET and Java, as well as some specific config file edits. After the actual VMs are deployed and ready to go, you will then be required to set up tenants, and all the associated permissions and groups which are required for this. You will need to set up connections to your vCenter servers, and reservations based on these connections. Creating blueprints can be simple or very complex depending on your needs.

I don't know anything about this.

I was not part of the evaluation process.

vRA is very powerful, but you need to know what you're getting into. You really can do almost anything that you want using the product in conjunction with vRealize Orchestrator, but it requires a lot of knowledge and work.

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.

• Reactors, because of the automation help they provide (reacting to custom events).
• State dependency trees, because a state can be linked to the status of another state, allowing you to particularize the behaviour of the software in some cases. The result of the execution of a system_state can be linked to different other states. For example, you can say: IF Upgrade_Apache is OK then Restart_Apache else Rollback_Upgrade. In that manner, you can create a sort of dependency among multiple desired states.

For example, with automation, before SaltStack, user management to access servers by SSH was done "by hand". The risk was leaving life-long access for some users, who were no longer with the company.

Integration in BASH Scripts: Maybe I’m just lazy, but I've not been able to find a mapping between state execution success/failure and Salt command return codes.

I have used it for 1.5 years.

I have encountered stability issues; they are always resolved by new releases of the software.

I have not encountered any scalability issues.

Technical support is excellent, even by chat.

I did not previously use a different solution.

Initial setup was simple.

I use the community edition, so it is free.

Before choosing this product, I did not evaluate other options.

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.

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

Anything which operates "as a service". I have worked in the Cloud industry a long time, so I have a lot of experience with Cloud. I see that there is a lot of flexibility in anything that's a service. You can use it at any of the layers of Cloud, like infrastructure or software.

I have worked in client-facing roles and at enterprise level. We have used VMware vRA. The best has been, from the infrastructure side, having storage as a service for customers. On top of that we add functionality for monitoring and alerts.

There are a lot of improvements required with regards to vRealize Automation. There are a couple of areas I would like to pinpoint. There are a couple of workflows missing from the storage side, so we can't easily add to my current blueprint.

Almost eight years.

Yes, in older versions. For example, 5.1. There were a lot of stability issues. Now it seems pretty stable.

Scaling works quite well. I have vRealize Automation and on the Cloud I have IBM Blue Mix. So I have scaling of my environment and I can scale my storage.

There is very little documentation with regards to when your single sign-on password changes annually. Then there are a lot of issues with regards to setting up the database and syncing up the single sign-on passwords. At the end of the entire environment there is a network and rebuilding the entire environment is inevitable sometimes. So there needs to be documentation.

I had used OpenStack but I would not say it is great. There are a lot of pickups of bad information. I would say vRealize Automation is much better.

I would give the latest version of vRealize Automation a 10 out of 10 because it helped minimize the setup time.

It requires very limited time to set up an enterprise environment. There is a lot of inter-configuration required to ensure your environment is built properly.

• Extensibility and flexibility
• Open source
• Active community

Also, the text-based configuration is very important to discern differences in version control. It also means it is easily configured with templates, and easily edited.

Salt lets you run commands on hundreds of servers at once; and sync up software, tools, and scripts across your infrastructure.

The flexibility can hurt sometimes, as there are so many ways to accomplish the same task. I don’t want to give the wrong impression; the flexibility helps more often than it hurts. However, when there are multiple choices to a complex software problem, one can make mistakes, and with a configuration management system, a mistake can get pushed to an entire infrastructure automatically.

I have used it for one year.

Salt has been remarkably stable, and it is simple to send metrics to an external source like Elasticsearch.

I haven’t had any scaling issues.

I would rate technical support very high. Personally, I have posted issues to GitHub that have been responded to the same day or the next day, and closed within a week.

This was our first foray into the configuration management space. Previously, it was a bunch of PowerShell scripts.

Salt has a very straightforward installation.

Salt is free.

Before choosing this product, we were looking at PowerShell DSC, because we were all PowerShell anyway. It was too unpolished; did not seem to fit properly with what we had in mind.

Have a good plan about how you are going to target your infrastructure; a solid naming convention helps a lot.

We use it for automating the deployment of multiple virtual machines.

Our purchase unit had a lot fears in upgrading their environment into production, so we customized it for them. What we did was virtualized the production environment and set it up to the Lab Manager. Then, they could test on Lab Manager on the application, including upgrades, updates, etc.

The customer can set up multiple machine blueprints. Therefore, we are able to customize the template of three machines, then the customer can deploy without knowing anything about the IT business. 

It is not intuitive nor easy to use. Lab Manager was very intuitive, and it was built with VMware functions. However, VMware vRealize Automation bought it, and we have not been happy with it. We would like them to go back to the Lab Manager that we used to use.

The stability on the 6.2 version is very bad. It crashes. VMware tech support knows the IIS component is a bit buggy.

We have 30 virtual machines.

The technical support is okay.

The initial setup is very complex because we have a bunch of customization workflows. They were built-in features that we had to program as code with Orchestration. 

We haven't upgraded because we had to set up the entire environment with the vRealize Orchestration scripts. We have to do it again from the scratch.

We used a reseller for the deployment who was great.

I think we will be leaving the platform. 

For our business case, it was the wrong product, but there was nothing else on the market at the time. When we deployed our virtual machines, we had a very big template with 30 to 40 machines. It was difficult to configure all the virtual machines and blueprints. It was locked when it was deployed with vShield, and now, there is NSX and vShield is no longer supported.