VMware Aria Automation Reviews

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

We use it for server deployments, typically. It's mostly for managing our own private cloud, for infrastructure-as-a-service deployments. It has performed well. We just recently went through an upgrade that had some hiccups to it, but it's been performing well for us.

It allows us to deploy servers on a much faster basis. Instead of deploying a VM from a template and going through the process of configuring that VM, with vRA we're able to click once and it does everything: grabs an IP, joins it to the domain, loads whatever configuration agents are needed. It does all of that without manual intervention.

It has definitely improved the speed of provisioning over the old-school way of deploying a VM from a template.

Ease of use, the GUI, is probably the best feature, so that really anybody can use it. You don't have to be technical to be able to deploy a VM.

I find it to be intuitive and user-friendly. Regarding some of the files that you feed it, you don't have to do a ton of development. You can feed it pretty standard configuration files. You don't have to be a developer, you don't have to know C# or Java or the like to get it going.

An improvement - and maybe this is already a feature that I don't know about - would be to be able to deploy to public cloud. Deployments to the public cloud would probably be a good feature if it's not already there, to be able to deploy to AWS or Azure, etc.

My impression of its stability is "middle of the road." We've had some issues where it seems to be a little bit sensitive, where deployments fail and we don't really know a specific reason why. We'll dig through logs and try to figure out what's going on, but it's not always apparent why it failed. And you can kick it off again and it'll succeed. So stability could be better.

The scalability is okay. You can't, to my knowledge - and I could be wrong - tell it to deploy like this: "I want 20 VMs all configured this way," and have it go ahead and spin them off. You have to do them one at a time. So, from a scalability standpoint that's not great, but it could also be that we're just not using it correctly. We don't actually have the need to do that very often, but from time to time we'll get a request such as, "We need five SQL Server VMs." It would be nice to be able to do it once and be done with it, rather than repeat that process five times.

To my knowledge, I don't think there was a previous solution.

I wasn't involved in the initial setup but we just went through an upgrade. It was not without its challenges. Some of the challenges were probably on our side, being able to support the newer infrastructure. But I seem to recall there being some issues importing some of the old settings and from vRA 6 into vRA 7 so that you could destroy VMs that were built in 6 from within the 7 UI. There were some challenges in getting that done. It's done, but I believe that there were some speed bumps to that.

I rate vRA at seven out of ten. There's some room for improvement, but it's better than the old way that we used to do things. It's a good product, it could just use some ironing out.

The most important criterion when selecting a vendor, to my mind, is support: a support network, whether it be knowledgebase articles online, forums online, or calling into actual, paid support.

• Bulk/Remote execution
• Event/Reactor system
• Configuration Management

These features serve as the most critical pieces for automating anything, not just state, but also execution and remediation.

I don’t want to build automation that just does a thing or two. I want to build automation that is intelligent, part of the fabric of our environment, and is somewhat self-sustaining. I think SaltStack can help me do this.

SaltStack provides the capability necessary to truly streamline our SDLC and environment management. From a high level, it allows coders to code, testers to test (automated testing too), and admins to admin in the most inter-connected and effective way possible.

• Web UI
• Maintenance of their code

We have been using this for three years.

There are some issues here and there, such as nuances with Windows and minions ‘falling asleep’, but its manageable.

I did not encounter any issues with scalability.

I would give technical support a rating of 8/10.

I was using more of a Frankenstein automation solution previously, and the reason for switching was the capability of SaltStack, performance, and ramp up time (ease of use).

The setup was pretty straightforward. It took some time getting familiar with all the configuration options and playing around with pillars and grains. On the whole, it was relatively easy to get going.

I think they are going to have a tough time with the Enterprise licensing. So much can be done with the Open Source side, and especially for smaller shops. I personally think the pricing for Enterprise is hard to justify.

We looked at Chef, Ansible, and Puppet.

Do it and take full advantage of its capability. Be creative and automate everything you can with it.

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.