VMware Aria Automation Reviews

We primarily use it to automate workloads.

The most valuable features are the multimachine blueprint and advanced designer configuration.

Automation or scripting should be simplified so that administrators who are not experts can have a better grasp of automation.

My organization has been working with this solution for about six years.

We have had no issues with stability.

VMware Aria Automation is a very scalable solution because it integrates well with a couple of leading products in the industry. For products that are not already integrated, there are plugins or adapters that can be used with customization. 

Because we are a large organization, we probably have more than 30 people who use the solution.

The basic installation is quite easy. If you have all of the prerequisites ready, then within two to three working days the basic foundation can be created.

Two people could probably deploy and maintain one foundation of the solution.

We deployed the solution ourselves.

We have definitely seen an ROI because automation is directly related to productivity.

Try to use the maximum level of automation possible within VMware Aria Automation. It will help you to achieve the maximum results. This solution has a lot of other features other than provisioning, like tighter integration with third-party products, ISVs, backup software, and open APIs. To fully utilize the product, you would need to get into these areas along with normal provisioning.

On a scale from one to ten, I would rate VMware Aria Automation at nine.

We have used it for infrastructure management between our hybrid cloud, provisioning and patching, using automation.

The automation functionality has been most valuable. With a click of a button, we are able to automate provisioning, the build of new hardware and apply patches. These are all extremely important and differentiated tasks that can be automated in SaltStack. 

The solution is very easy to code and to set up. It works on a YAML language which is very simple and does not require someone with programming experience to start using it. 

This solution could be integrated with more hardware for an improved offering. 

We have used this solution for five years. 

This is a stable solution. 

This solution is easy to scale.

The support from the customer service team is good. 

The pricing for this solution is roughly 20% lower than the competitive products in the market.

I would advise those considering this solution to ensure they have the necessary in-house talent or access to an external vendor who knows this solution well. It is not a widely used technology so it is important to ensure you can support it. 

I would rate this solution an eight out of ten. 

Primary use case is building a self-service portal for students at our university. It has performed quite well up until now.

We are able to provision VMs much faster than before. Therefore, students can click VMs, submit their form, and VMs will be provisioned automatically.

It's quite user friendly. Everyone can use it, even non-technical people. This is good, since we use it to build a self-service portal which even users with not a lot of technical background can use.

We upgraded twice. The last upgrade was a bit problematic. 

Up until now, it has been quite stable. However, we have not pushed it to its boundaries.

Its scalability looks good, but we have not experienced it yet. 

So far, technical support has been quite good. I have reached quite competent employees of VMware who have helped me a lot.

We did not use another product previously.

We had to invest in a new solution because we had to react faster to customer demands. Previously, it took a long time from requesting a new virtual machine to provisioning it. Now, it is much quicker for the customer. 

The initial setup was straightforward.

We deployed it ourselves.

It made the provisioning of the virtual machines easier and faster. We can react more quickly to customers' demands.

We did not evaluate anything else. We have so many VMware products that it was a logical conclusion for us to chose this one.

We are overall satisfied with the product.

Give it a try. Try it out in the labs from VMware. Evaluate it quite deeply, and see if it fits for your purpose or company.

We use it for the deployment of new environments and multiple stacks, as well as deployment inside of NSX. It is also used for easy application deployment and container management.

We can do scripting and do customization after deployment. With vRA, we can integrate everything with a single-click. Then, there is also track management and change management control.

The repetitive tasks which took provisioning storage, network, and compute two to three weeks, now take five minutes.

I like the automation that it provides to deploy VMs and multiple apps. The integration with NSX and AWS for endpoints, which allows us to manage workloads, such as the comparison that it does between different VMs. It can do this in AWS or Azure.

Any new VM admin simplifies deployment. Instead of only deploying templates, we can deploy blueprints which are easier on day-to-day operations for an organization.

VMware should go the way of vROps, with everything in one machine, the ability to scale out, and a more distributed environment instead of having the usual centralized SQL database. 

Three-tier environments are not scalable.

They need to get away from Windows.

It depends, because you are still dependent on the Windows machine that does all the requests and pulls from other agents. It can scale out if you size it right the first time.

We used technical support with previous versions.

We knew we needed a new solution when we were falling behind and could not deploy what the business units needed.

The product has come a long way. Now, it is more streamlined and GUI-based. 

I have done parallel upgrades, then used my grade settings for it.

We also evaluated CA.

We chose VMware because we are a VM shop and the product allows multiple endpoints. We could also have endpoints for AWS.

While it's user-friendly use, you need to know what you are doing with it.

Get your requirements beforehand. Make sure of the services that you want to provide and have them nailed out. If you are just writing VMs, then you don't need vRA. If you are providing services, you're going to become a broker of services to people, so you have to plan ahead. Also plan the workloads that you're going to be providing because they will consume a lot.

The ability to provision to on-prem and public cloud using a standardized set of blueprints.

It has reduced provisioning time from roughly three to six weeks to about an hour on a private cloud, and about 25 minutes on public cloud.

The ability to provision native cloud services as well as the ability to provision Azure VMs in the same way we provision AWS VMs. Right now, it's a broken process. Azure is kind of a work around. It would be good to have native address support and paths servicing offerings from Azure and AWS offered natively through VRA.

On a scale of one to 10 stability is a seven.

There are a lot of moving parts and we often have difficulty with like an individual service on one of the components failing and bringing down the entire stack, and that's pretty regular. We've been using it since version 6 and that's been pretty consistent. As the components have been compressed, it's gotten better, but for each of the Windows servers and components that we have, there are regular service failures.

Scalability is excellent.

We use BCS and that makes a difference. Typically, it depends on what time of day we're calling and what region we're in. Usually out of Cork, Ireland it's pretty good and out of the U.S. it's good. But when it gets sent overseas we do have some issues.

Other than that, support also has a problem with complexity. For a vanilla build of vRealize Automation, they generally know how to support it very well, but because we have a lot of customizations - we have a lot of custom software components and integrations - by the time we're able to get the support call up to speed on what's going on, we've generally figured it out on our own. That's not to say it's anyone's fault, it's just that we have a lot of customizations in there.

When we call we don't always get the same person. Sometimes it requires an escalation and we eventually find someone whose good. But it's something like every third time that we get someone who is good from the beginning. Other than that, two out of three we'd have to work through an escalation process.

We were using vCenter Orchestrator just by itself but it was only used by our internal teams to build for other users. vRA has enabled us to give self-service to all the end users.

In terms of switching, honestly, a VMware sales team came by. We were getting complaints from a lot of our end users on provisioning time, and we would generally get people that were requesting more than they needed because of the time constraints. So we wanted to simplify the process and make it a self-service portal and that was the reason to switch.

It was the best solution at the time we started the project, which was about two and a half years ago. It may not now, be but we are pretty heavily invested in the stack so we don't want to throw all that money away and kind of switch platforms and start from scratch again.

The most important criteria when picking a vendor is their ability to solve a problem that we have; and then second would be cost.

DynTek. We used Presidio as well as ServiceNow.

Really look at the competition that's come a long way. Cisco's product, ServiceNow's product, Red Hat even has a product that is competing and, depending on their workload type and their end point type, there are potentially better solutions. But if you are a fully integrated VMware environment, this is still the best option.

Regarding implementation, you should have a very well documented process for your current provisioning. You should have documented all the types of workloads and blueprints you would potentially need based on user demand, not based on what the admins think. We made that mistake. We offered what we thought the user would want and most of the blueprints we created went unused. But then when we went the opposite way in the newer release. We basically poled our entire community and they gave very specific responses. So, focus on what the users tell you they want otherwise they're not going to use the product.

• Hybrid/multi-cloud infrastructure automation capability
• Configuration management
• Complex orchestrations
• Imperative programming style
• Declarative “states” DSL
• Simple YAML syntax
• Vitality of open source community involvement
• Infrastructure remote control: This fans out from a single command to many (from a handful to potentially thousands of) target machines or VMs. The fine-grained targeting features make it easy to do just what you want on just the infrastructure you want affected, with mechanical consistency. The complex orchestration capabilities allow smart conditional remote control operations on different targeted infrastructure, driven by either, or both, automatic reaction to events, or manual triggers or commands. These are the critical features needed to implement continuous delivery of anything anywhere.

Preparation of Hybris Commerce HY300 training laboratory environments and Hybris Expert Services demo infrastructure went from days of effort down to hours. Reliability and consistency is no longer a concern.

Code maturity is reaching a point where refactoring some internals will be important to maintain the rate of improvement. The software has evolved at a breakneck pace, and there is a lot of legacy code which needs refactoring and cleanup.

This doesn’t affect the operation of the software as much as it affects the learning curve for the open source community. If the code gets messier and messier, then community involvement will taper off.

Major architectural features, like the transport system for example, have been subsequently refactored. When I wrote the review, SaltStack had decided to replace ZeroMQ for extremely large scale operations, and embarked on a novel approach RAET. This appeared by early estimation over engineered and under tested, and lost momentum. Without missing a beat, SaltStack rolled out an asynchronous TCP transport option that was both simpler and more scalable. This was received well by large operations depending on SaltStack. This is a major refactoring win, and a testament to the maturation of the software.

Contributing to SaltStack could be difficult as their internal development processes matured. One symptom observable from community contributor not long before I wrote my original review, was git history rewriting. I’m not going to go down the rabbit hole about why this is bad, but I will say that this hasn’t to my knowledge happened since. I once worried this difficulty would be a barrier to progress at SaltStack, but I am no longer worried.

In particular, I was working with salt-cloud when I authored that review. Since then I have seen considerable attention paid to refactoring code I thought was problematic. They have a mature API deprecation process, which is not 100% executed (things get deprecation warnings, but the deprecated code can remain longer than declared). Even that has been improved, and in the mean time a lot of new functionality has appeared without affecting the quality of existing code.

Conventions around using salt, like formulas, testing methodology, and new functionality like the Salt Package Manager have added to the maturity of SaltStack. These conventions enable commercial and open source contributions to the SaltStack DevOps ecosystem, increasing the rate that SaltStack accretes capabilities without adding stresses to the core development at SaltStack.

We have used this solution for a year.

I did not encounter any issues with stability.

I did not encounter any issues with scalability.

Technical support is excellent.

I have used Chef. Chef is harder to teach, so it is more difficult to build an internal community around the toolset.

There are multiple ways to do the initial setup. The documentation is clear, but could be better organized.

It’s free until you need support. It will deliver a lot of value prior to production exposure, but you should plan to get an enterprise SaltStack license by the time your DevOps iterations can deliver reliably to QA.

We evaluated Chef, Puppet, and Ansible.

Make sure you have cross-functional collaboration between your development teams and operations teams.

Develop configuration as code in parallel with code development.

Use SaltStack to deploy and control both development sandbox environments and also full scale test and production environments.

Cross-platform Windows and Linux support: We run a Windows infrastructure within AWS with several key services deployed on Linux instances.

We have been able to integrate with AWS to deploy continuous delivery services with an extremely quick turnaround time. Salt lets us manage those instances, and control the deployment seamlessly.

Windows support and support in general: Getting responses to problems can take weeks or months in my experience. Windows support is advertised as a first-rate supported platform; however, it is ripe with issues that have added countless hours to our roadmap. Documentation is also severely lacking for much of the Windows platform support, and in many cases I have had to resort to third-party blogs and tutorials for resolving problems.

I have used it for nine months.

I have encountered stability issues with Windows support in AWS/EC2.

I have not encountered any scalability issues so far.

I rate technical support as 3/10. The only support we get is through the mailing list or through GitHub. They have offered a higher level of support for $20k, but we haven’t seen anything to indicate the value in doing that when the platform as a whole has issues that should have been tested before being deployed.

This organization I work for used Altiris before, but we switched to Salt to scale into AWS.

Initial setup should have been straightforward; however, documentation issues and bugs in general caused this to take a very long time.

The software is open source and free; however, things that should be tested for stability (like Windows support) are not fully vetted, and it’s unclear if a paid support offering would actually resolve those problems.

Before choosing this product, I evaluated Chef, Ansible, etc.

Don’t rely on the SaltStack documentation alone; use Google and other resources to find help, if you are not going for paid support. Windows support is lacking but you can overcome the issues with a bit of ingenuity.

Our use case is infrastructure automation, like self-service.

We utilize all the blades that we had available in the computes, mostly going into VMware vCenter.

When I have been using it, it has been mostly for private compute.

We provided the ability to request virtual machines to our end users. Before, this was a very manual process, which took engineers to do. Now, it's an automated process.

vRA has enabled us to leverage existing VMware processes, systems, and training in our organization to support IT ops. 

Most valuable thing is that it's flexible. You can do anything with coding.

VMware needs to make it to where it is not as custom. Right now, you spend a lot of time making the services work. In order to get it up and running initially, that takes time. I would like it if they didn't require custom code and we could get it running out-of-the-box.

I have been using vRA for about five years.

Stability is pretty important. For example, if the platform goes down and people can't provision anymore, people are relying on the automation versus old manual processes.

Our developers and IT consumers use it as well as other infrastructure teams.

vRA is the means for 90 percent of our infrastructure requests. There are use cases where things, like big data or bare-metal, don't necessarily provision this type of stuff.

The service of VMware during our deployment was average; I wouldn't say VMware support is exceptional.

Post-deployment, it takes time to get to the right people in order to get proper support.

We did use a previous product, but integrating it with VMware was very custom.

There is complexity to the setup. You have to custom write code for any integrations. It took six months to make it end user ready.

There were about 10 of us involved in the setup. We have just a cloud team.

We have seen ROI from replacing manual processes with automation.

vRA has helped to automate deployment for developers. The solution increases developers’ responsibilities and productivity because now they can provision their own VMs and focus on the code.

The solution’s automated processes have reduced infrastructure provisioning time. Automation takes the time down to about an hour. Whereas, it could take days if it was done manually. This time reduction also applies to vRA's automated processes, which have reduced application provisioning time.

The solution has reduced time to market for our apps. It takes the burden off of our internal processes, which can now provision VMs in an automatic fashion.

It is pricey for what you get. Nutanix is cheaper.

We did not evaluate other options.

Make sure you give yourself enough time to implement or replace all your use cases as a business.

The solution requires specific expertise with it to be able to use it effectively.

I would rate this product as a seven (out of 10).