VMware Aria Automation Reviews

Our primary use case for this solution is for making a cloud through ICDC. We have to integrate them into many VM masses with vRA.

Before it would take months to deploy a VM, now, with this solution, we can deploy many VMs in one hour. We can do a stack of them with Mediaware.

This solution has definitely helped increase the speed of provisioning. We can now deploy many VMs in one hour. We also don't need to call in as many teams to deploy them. Now it's just one team and they can deploy the machines way faster. It's very good.

We like that it gives the user the possibility to deploy on their own, we have found that to be a very valuable feature.

We have and we haven't found this solution to be user-friendly. In this case, we have another portal in the front because we have some use cases we can add to the products so we use another portal for that to reply to all of the requirements.

This version has all of the features we want. 

Stability is good. It helps us provide more services and give more capacities. It improved our infrastructure and gives us more possibilities to provide our users. It's a very good product.

Scalability is good. We also use other solutions and we are still beginners with these products. We still have to set the time to configure it so that we can maximize its benefits.

We had to use their technical support only once. We didn't have any issues with them, they were great.

The setup was complex in many ways. The first reason is that we have many teams who work on it so it gets complicated gathering all of the people needed. The second reason is that it can be complicated to install it quickly, and within a reasonable amount of time.  

We have a VMware PSO at work who is very good. He was experienced and had good knowledge so we were very happy. We are very enthusiastic to continue with VMware in the future.

I would rate this solution a nine because we've had a good experience with their consultants. Also, because the product is evolving. 

I would advise someone looking into this or a similar solution, to test the solution beforehand and to be in contact with VMware for advice and help with configuration. You'll realize this solution isn't so complicated.

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.

We use it for deploying, data recovery, and DR.

In terms of recovery, it takes only a tenth of the time that's required compared to a human element. It gives us time savings, which equals cost savings, which equals personnel savings.

Having the visibility of the infrastructure at that level helps greatly with infrastructure agility, application agility, and speed of provisioning.

The most valuable features are the metrics and reporting aspects. The historical data and extraction enable us to tell where the trends are and where contentions may exist in the future.

I also like that it reduces the human interaction and requirement.

It would be nice if, at the director level, the manager level, there was a pretty graphic. They don't like to see numbers and line items, they want to see graphs and scales and real-world pictures. That would support better reporting.

Thankfully, where we're at, we don't have the need for the criticality, we don't need a quick reaction to stability issues. But having the right resources available will help the stability.

We have scaled up. For me and my team, it's very easy.

On a scale of one to five, I would rate technical support a four. It's not always associated with the correct team on the first go-round, but eventually, we get the right people to get the right solution taken care of.

There is a war on wasted initiative and on waste of time, more than a concern about environmental resources, unfortunately. The war has been identified on multiple levels, especially deploying in our realm.

When looking to work with a vendor, the important criteria we look for are

• professionalism
• the value of the product for the return on investment
• personally, I look at energy costs and savings as well.
  

Without the right technical expertise, the initial setup can be a little more cumbersome, but with the knowledge and the backing of the infrastructure and the engineering, it's fairly simple.

We have upgraded many times. We know how to do it. It's fairly simple for us. We don't get the admins involved. The engineers take care of it all.

As far as ROI goes, we see it in the human time element in deploying, that's been a really big improvement. Cost savings go with that inherently.

We looked at a couple of other vendors but we went with VMware because VMware is standard. Why not go with the best?

Give it time to save you time.

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

Mostly, vRA is for automating deployment. We use it with templates to deploy and maintain compliance based on the certifications we have. It's a way to maintain consistency across cloud and data center environments. 

We have about 30 to 40 engineers. They are primarily support engineers what we call platform hybrid teams. They create templates and help customers deploy VMs.

The main benefit of vRA is a faster deployment for our customers. Before implementing vRA, we were building VMs from scratch, but vRA allows us to create images, so we can deploy a VM in just a few minutes.

Obviously, it depends on the hardware installed and everything, but the time has been significantly reduced. Time is money. We want to provide as much flexibility in the private cloud and bring our customers as close to the private cloud as possible.

The preset policies and templates are useful. I would say that vRA is one of the best solutions we have. The CI/CD features also look helpful even though we aren't using them at the moment. We plan to get more involved and train our customers as much as possible.

The solution could be lighter. As an administrator, I would like to simplify the number of services I need to deploy. They took a significant step in that direction by removing all the Windows dependencies that we had in the past, but there are still a lot of services consuming resources. 

I would also like to see a richer API. This is true of all VMware solutions because the REST API is not the best.

I have been using vRA for the last three years. We've gone through different versions of the solution.

We haven't had major issues with vRA so far. Generally speaking, all the VMware infrastructure does work. I wouldn't say it's rock-solid, but we haven't experienced significant stability problems on the platform.

Our most significant deployment is two clusters working with a single instance, and it's running perfectly fine. It comprises two clusters of 15 ESXI servers each, so it's a massive deployment.

We do plan to increase usage and deploy vRA for other customers, but we currently have a small number of customers actively using it. Then we have our internal segment of vRA that we connect to a few small customers. But the idea is to expand it and add as many customers as possible.

I rate VMware support eight out of 10. We have a VMware service agreement, and we've used support a few times. It was helpful, but they needed to research some of our questions because our implementations tend to be a bit complex. That's why I don't give it a perfect 10.  

Positive

We had a home-grown solution before, but we changed to vRA because of it's simplicity and compatibility with all the tools we use.

I rate vRA eight out of 10 for ease of setup. The previous version of vRA was harder to deploy, but they have simplified it considerably. 

After the deployment, daily maintenance doesn't take more than one day a month. There is nothing much to be done once it's set up. The upgrading is sometimes a headache, and it takes longer. For deployment and maintenance, we need at least one network engineer, one platform engineer, and three storage people. That's because our team is split into three different tiers.

I would rate vRA six out of 10 for ROI. It's in the middle. We haven't quite broken it even yet, but we are close.

We pay a license based on volume. I rate VMware vRealize Automation four out of 10. The license is quite expensive. 

The engineering team evaluated a few solutions, but we went with vRA because it is the fastest and easiest.

I rate VMware vRealize Automation seven out of 10. I recommend it for any company that constantly deploys VMs. This tool will help you a lot. 

Without it in our data center, we would have to have a different solution. It's what we thought was the best architecture for our company.

What I like about the software are the performance and the optimization, based on the unit pricing.

It's very stable. And due to the software contracts - we have a subscription membership - we get the newer versions. It's going be around and, from what I heard at one of the sessions today at VMworld 2018, it's going to be around for a while.

It's scalable. We're such a large company, we would never even consider using it if we didn't think it had a lot of room to grow, for the capacity that we utilize.

Technical support is okay, VMware is fine. I work with both Dell EMC and VMware and, of the two, VMware has more of a commitment to us and makes sure that the products are working in the way that they intended and sold to us.

In addition to production-level support, we buy mission-critical support. Mission-critical support makes sure that we get responses quickly. They actually know who we are when we call.

I rely on the Technical Account Manager from VMware to give us the solution for our network or data center. I'm not an SE, so we also rely on our internal SEs to provide us the right version and capabilities. It's customized for us.

We've been with VMware for such a long time, in excess of a decade, and because of that, I wasn't working here when they had an earlier solution.

We upgrade it anytime we do a technical refresh. It's just like anything else. We're in a complex environment, so to upgrade it, it's almost like you have to migrate the data that is utilized underneath. It's not simple, but it is done periodically.

You should look at the complexity and size of your environment, and when utilizing that background for your requirements, I personally would recommend VMware. You should look at what your deliverables are in this solution. If you do that, you have something you can measure it by, to determine if it's a good fit for you. But I do suggest that you look at VMware as a potential vendor.

I rate the solution at seven out of ten because I don't believe it's a perfect solution. It fits in our data center and it works for our organization, so it's a good solution for us. Yet, at the same time, technology changes so quickly today that a solution you bought three years ago, even if it's upgraded, isn't the solution that's going to fit. For example, we're all going to the cloud or on-prem/off-prem, and because of that, that solution may be in the cloud tomorrow, so I won't be buying it anymore, I'll be buying the cloud version of it because it's utilized through a different service provider.

My most important criteria when working with a vendor are really easy. I evaluate the vendor based on these things: 

• What is their reliability? 
• What is their pricing model?
• Is it a partnership versus our just being a customer that they want to make large margins from?

Primary use case is for automatic deployment of VMware guests.

It's performing as we want. We're not really asking anything too complex of it, but it does what we ask of it.

Our organization started to move a lot more towards automating all the things that we can. We're catching up to that, but we're definitely heading in that direction. It's one of those things that enables us to tie in with our other pieces, with automating the operating system, etc. VMware is then able to automate the build of our virtual machines.

In terms of infrastructure agility, we're still getting our feet under us in some areas, but it's definitely playing it's part and doing what it does well.

Our speed of provisioning has also improved. We used to build systems manually, which would take four hours or a day. Nowadays we're able to spin something up off a template that we update every so often and it takes about 20 minutes. We can take an existing template, build it back up, add some configuration for it, specific applications, turning things into what the developers need, and then we can have them deploy it off that. It makes it so that we can have customization within a framework.

The most valuable feature is the integration with some of our other automation platforms. We're starting into Jenkins, and it has a plug-in for other automation of operating systems and things. So it works together with our infrastructure. We don't have a very complex environment, we don't have NSX yet or anything really crazy, but all the things we do have, it has been able to interoperate with them.

It is intuitive and user-friendly. It took some growing. We had to figure it out in the beginning, but that was a couple versions ago. We like the improvements that have been made over time, so it's definitely been able to progress with the environment.

We don't have too complex of an environment, we're not doing machine-learning or any of the advanced features all that much. We're a pretty straightforward IT shop. We just provide servers, and then, from there, it's what the customer wants. The next step we would probably like to see is to have a customer portal, so instead of our having to punch the button, the customer could. But I believe that VMware offers enough that setting that up is more on us, rather than waiting for them offer it.

We needto learn more, advance our usage of the product. We're doing what we can with what we have, but we have to learn a bit more. Better training, or training modules, wouldn't hurt. I haven't personally looked through what the portal has, but more training is always good, so we could take a new employee and point him to the training and get him up to speed quickly. I have had 10 years or so experience with VMware, but I'm the old the guy in the department. Everybody else is newer than me on this and not everyone has my experience. So the training would be nice.

I've been impressed with the stability so far. It does what we ask it to. That's always nice. You don't have to think about it. We haven't had any downtime.

We can scale it up or down. We haven't needed to yet, but we can.

We haven't had to use technical support. I do a lot of blog reading, so I look up my answers on my own. But tech support, on other issues, has been where we need it to be.

We weren't using much. This was right at the beginning of when we were starting to automate things. We saw the VMware automation and decided that, since we had VMware, it would be the logical choice. And then we started with Jenkins for a lot of our other operating system features. Jenkins, of course, has plugins that talk to VMware natively, so it was a natural fit.

When selecting a vendor, the biggest thing for us is multi-operating system support. There is the classic divide. I'm on the Windows side. We have a Linux department also. When looking at different tools, something might be better for Linux but we have to have something that will work for both of us. We don't want to have two different tools for two operating systems. Whereas the Linux team wanted to use Puppet instead of Chef, Chef supports Windows and Linux both, better. The nice thing about VMware, aside from it being a lot more OS-agnostic, is that both teams can use the product. One product for both operating systems. That was one of the primary things. We could have a tool that runs great, but it might be a situation where, "Oh yeah, your Windows support is lame." That's the big thing for us, the interoperability between operating systems.

I thought the initial setup was straightforward. The biggest thing, once we had it set up, was to integrate it with the vCenter, but that was pretty straightforward. That was part of the workflow. It is automated within the product as part of the initial deployment, which is really handy.

The upgrade experience was also quite easy.

Better pricing is always handy, but I feel it's at the right price point.

There were not too many on our list. VMware was the natural fit. We saw the automation. We liked it. Chef, technically, will do automation. It has connections into VMware. We preferred having the VMware automation handle it. Chef will do it, but it doesn't have as many things. We would have had to write a lot more tools for it. It's one of those things where, instead of Chef's being the one tool to rule them all, where we do that for everything, we branched out to VMware automation to handle its subset.

Jenkins is a Swiss Army knife. It will do literally everything. The problem is that you have to tell it to do everything. You have to build all of the features into it that you want. There's a language to do it, but it just says, "here's the entire toolbox, do whatever you want." It doesn't have as many pre-packaged things. VMware has the ability to build things, but it has a lot of things preconceived, which is very handy. If I just need the basics, I need to stand up some VMs, it already has those workflows built in. Jenkins doesn't have nearly as many things built in. They can both expand to what we need, but VMware had some pre-provided things that were very handy to get off the ground quickly.

vRA has a very nice toolset for being able to integrate with VMware. It is great for being able to automate things within the VMware environment. We probably need to learn more about it, so we can fully realize its use, what the plugins for other things are. But it's doing everything that we need for now. We've seen that it has room to grow with us.