VMware Aria Automation Reviews

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

States, pillars, and custom modules have all taken us a long way in achieving our goals. There is great depth to it and we're looking forward to exploring all of its features.

We are moving from managing a handful of individual servers to being able to manage large scale collections. If we need to fit a particular use case, SaltStack makes it very easy to provision a new cloud instance quickly and almost effortlessly.

There are a number of bugs and regression errors that can make it frustrating at times, but given the flexibility so far I have found adequate workarounds.

The GITFS is flawed and requires a lot more work. We were able to construct our own workaround with local clones of all git repositories that are refreshed whenever a new commit or merge is made. GITFS is a feature in SaltStack which allows the salt-master to directly interact with git repositories. In theory, this is an incredibly efficient and useful capability. However, when implemented, we found server processes and load would escalate out of control whenever anyone made a git commit to the GITFS repositories. We were using v2015.8.5 at the time.

After researching the problem with the SaltStack community, we learned that there were multiple problems in the implementation of GITFS and what we witnessed was experienced by other users. Several SaltStack users recommended not using GITFS. As a workaround, I set up our salt-master with its own local copy of all of our git repositories and made use of the salt event reactor feature. When a git commit is made on our git server, a git hook triggers a salt event. Salt-master reacts to the salt event by performing a pull on its local repository copy. Its not as slick as the intended design of GITFS, but it works very well and has proven quite stable, completely eliminating the problems we experienced with GITFS.

At some point in the future we will revisit the GITFS feature, but for now we are satisfied with the current solution.

I have been using the solution for six months.

We have encountered quite a few stability issues with the GITFS option, but its been quite stable since we switched to our workaround solution.

We have not yet encountered any scalability issues.

This is an open source tool so we find out about fixes, patches, and other solutions through the online community and other online resources, such as Stack Overflow.

We did not have a previous solution as we are new to using DevOps management tools, but we researched others before we decided on SaltStack as our tool of choice.

Initial setup seemed so easy, but there is an art to designing pillars, writing state files, and other customizable structures.

This is an open source solution, but there is a paid enterprise option. If you plan to pursue the enterprise solution route, contact SaltStack for details. The open source option is very approachable.

We evaluated Puppet, Chef, and Ansible.

If you are planning to use the open source version, plan to allocate more project time than you think you need. However, once it's in place it will save you a great deal of effort.

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.

We use it to push out automation for all of our servers, not only to developers who are requesting what we call "cattle" - they want hundreds of servers to be able to test - but also to start getting away from the "onesie, twosie" builds, to save us more time on deploying so we can work on other projects.

Time savings. It takes about an hour less for me to deploy a VM using automation then it would if I had to do it manually.

It does a lot of things automatically that would take our group, when we're already strapped for time, a lot of time to go through and clean stuff out of databases and the like.

Overall, it has helped to reduce the time it takes to troubleshoot issues and improved the quality of service to users.

To manage when VMs aren't being used, we have it set up so that it will auto-destroy them after a certain amount of time, obviously with permission from the user who owns it. 

I want to see HTML 5. I want to get rid of JavaScript. First off, I know nothing about JavaScript. That doesn't mean I'm going to know anything better about HTML 5, but I do know that we have a lot of issues with Java crashing when we're using vCenter. I obviously don't want that to happen with the vRealize Automation and Orchestrator side.

So far it's very stable. We haven't had any crashes, any issues with it. The problems that we have had have been in configuring things because we're already in the last stage where we're accepting the consultant's work. So we're finding little things here and there.

But otherwise, generally, the system has been up. We haven't had any downtime with it, other than the stuff that needs to be configured a little better.

It should be scalable. We have left room for it to be scalable. But right now we have a target area that we have it set at, and it's perfectly set that way.

I was doing it by hand.

The end-user portion is user-friendly. When you're actually building it, it's a little complicated in setting it up.

For example, in vRealize Automation, there are a lot of different areas where you have to go in and set up key components that have to link to other areas. We had a consultant come in and build our system. If I had to do it on my own, I'd have been spending a couple of hours trying to figure it out. And whether it would work or not, obviously I'd be testing it. But once I actually get to know the product it would be a lot quicker.

I've seen ROI on my end because I've been able to deploy some VMs quicker which has left time for me to go into vRA and configure it a little better. We have not pushed it out to our developers yet, but that's coming soon.

Absolutely go for it. I believe in it. I've seen and I've heard companies talk about how valuable it is. My only suggestion is, if you're strapped for time, get a consultant or some third-party or VMware Support to help you with the deployment. There are a lot of "gotchas" in there that we didn't know about and I'm glad we did go with a consulting company.

I give it a nine out of ten. I never really like giving something 100 percent because there's always room for improvement. I feel that it's a very solid system but there are little tweaks in there that could be done better.

For example, HTML 5, which I hear is coming. But also, to me, they should make it easier to figure stuff out. It's a little hard when you're trying to branch out and do it on your own. If the consultant goes away for a day and you're trying to figure things out, tooltips or some sort of help or some sort of highlighting of things that would give little tidbits indicating you need to link this to this over in this direction, etc; that would help out new people.

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.

What we do with it is we've taken a very lengthy deployment process and we have shrunk it from what was a months-long process down to a matter of hours.

We've also had benefits with configuration consistency because the machine is doing it for us. We aren't manually typing in, editing config files, and all that.

Security, it's helped us integrate other products like VMware's NSX product, so we have the east-west traffic security rather than just north-south. The cost savings that we have with the man hours that used to be sunk into actually deploying these VMs is a huge savings for us.

I spend a lot of time talking with some of the product's team members making requests. Machine prefix, which is what they call their naming scheme, I wish that it was more flexible. Right now, you're relying on creating your own system and leveraging vRealize Orchestrator to handle it if you have something more complex than their basic needs, which is just the name and then the number at the end.

Version control for blueprints: As it stands, you can make any changes you want. There's no record of it. Everything else is pretty much how I want it.

I will say the VRA has its problems. We have had issues with stability. We initially deployed on Version 7.1, and there are issues with the high availability feature that it had. It forced you to manually failover the database, and so it wasn't an actually automated HA feature. That has been solved in 7.3. I haven't seen any issues with it, yet.

I haven't had it deployed for very long, but just like small things like selecting stuff, the blueprint design campus, I've noticed, has a really bad memory leak, so it can be hard to edit blueprints. Overall, as long as you know how to administer the IaaS boxes, you should be good to go.

It gets a rap for being an incredibly complex product to deploy, specifically because it's a highly scalable solution. You have to know how to set up all these different pieces, deploy Windows boxes, set up IaaS, configure your load balancers, whether that's in NSX or, say, an F5, which is what we use, or whatever else you're going to use.

Technical support is usually pretty good. I've gotten hot fixes turned around in two or three days. Sometimes, it's very tough because of how complex a product is, to know where exactly the problem lies, so it's nice to have VMware support to lean back on whenever that's the case.

It's very not straightforward. Perspective: I just deployed the newest version 7.3. It took me about a week total, just a solid 40 hours of work, to get it deployed fully. There are issues with some of the documentation. Mostly, it was fine, but there's a bug with the installation wizard that I spent a long time trying to sludge through by myself, but after opening a support case, they were able to get it taken care of really quickly.

It has a long way to go still but, for what it does, it does well and it helps enable you. Even if there are a lot of problems with the product itself that still need to be fixed, I don't think that they outweigh the actual business value that you'll get by having the product if you do a lot of deployments or if you need to provide access to developers. There's a whole myriad of cases that you could be using it for. If it falls within one of those cases, it can be extremely helpful.

Being able to provide automation for my customers, essentially having guard rails on what they can deploy and how much it is they're deploying in my environment.

We're still rolling it out. It's starting to help a little bit and people are starting to be able to see the power of it. I expect it will help, but we're still early in the journey.

Improvements in the API. Make it easier because that's where we tend to struggle when we were working with other groups. We spend time trying to digest the API to figure out how to actually consume it.

The UI could stand a lot of improvement as well. It doesn't look like a modern UI, so it needs some work.

I've been using it for four or five years.

But in my current employer, I've only been there for about eight months. They had it, but nobody was actually pushing the solution.

I haven't really had any issues with stability over the last four or five years that I've been using it.

We tend to do smaller deployments than huge deployments of it because we're usually targeting multiple groups.

I haven't contact technical support yet, but I do have a contact with VMware that I feel is knowledgeable.

I didn't set up this environment, but I have done the setup previously.

The process has gotten better. It's still a bit of complex. Once it's setup, you shouldn't have to touch it much.

Upgrades have gotten easier as the solution has progressed. It used to be much more difficult. Now, the process is a lot more streamlined.

Not applicable. The company already had the product when they brought me onboard.

Most important criteria when selecting a vendor:

• Features
• Stability
• A community who know the product and can share information about it.

The ability to quickly setup the self-provisioning of vSphere VMs was one of the primary drivers for us to use this product over others. Additionally, the product has several plugins and an almost limitless potentional for further automation using vRealize Orchestrator. Lastly, its integration with NSX is superb and very much a critical part of our VM provisioning.

We are using the following vRealize suite products: Log Insight, Operations, Orchestrator, Business for Cloud, and Automation.

We have given internal IT developers the ability to self-provision VMs for development and testing. This has been a hit with our staff. I have talked to several of them involved in the POC and it has drastically increased their efficiency since they do not need to wait on IT Ops. Additionally, the publishing of templates, firewall rules, and software installs in the system has increased the communication and transparency between IT development and IT operations.

As with all recent VMware products, more focus needs to be done on QA. I encountered far too many bugs for an enterprise product. Additionally, more native vRA integration for various parts of the VM lifecycle will take some of the onus off the engineer to learn so much about Orchestrator.

I used version 6.2.0 for five months and version 7.0.1 for 11 months.

We did have stability problems. I encountered several issues with the product after the upgrade from 6.2.0 to 7.0.1. I would highly recommend that anyone looking to move to 7.x from 6.x should do a migration rather than an upgrade. VMware did not do enough QA on the product in order to handle in-place upgrades.

We did not encounter scaling issues because we had a limited release of the product since it was a POC.

Technical support from the frontline technicians is very good, but if your problem has to be routed to “engineering” then be prepared to wait for days (sometimes weeks) for resolution.

We did not have an existing automation product.

We already owned vRealize Automation as part of our suite licensing. We did evaluate the Cisco UCS Director product for one month and found it too complex to setup.

The initial deployment of vRealize Automation was not complex, but it was tedious and error prone. This was the 6.2.0 version and these issues have been fixed in the 7.x versions.

I would advise heavy VMware shops to look into getting suite licensing and leverage the VMware ELA framework if possible. Additionally, I would highly recommend that NSX is purchased in conjunction with vRealize Automation in order to get the most out of the product.

We evaluated Cisco UCS Director.

Do your research ahead of time and try to find others in your area who have already deployed the product. Your VMware rep can usually provide contacts that may be able to provide advice. Additionally, start talking to internal developers at your company and see what pain points they have and how automation can help. This communication will also help when you start publishing catalog items in automation, because a lot of more advanced workflows will require knowledge of Javascript and PowerShell. Lastly, start working with Orchestrator now. It has the steepest learning curve, but it is critical to understand how it works for advanced workflows. Orchestrator is already included with your vCenter licensing.