VMware Aria Automation Reviews

As a software development company with a smaller staff, we've got a lot of technical people - the operations team and myself. Being able to give provisioning of environments over to our developers and the different teams has enabled them to put up environments faster and also freed up time for the IT team. This is really one of our bread and butter solutions for our developers.

As a development company, we have different versions that need to be provisioned constantly, and the build-up/tear-down of this, for the IT team, used to take forever. We have a lean staff. We haven't increased in people but we have increased our company size. To be able to do more with less, that's one big piece of it.

Also, having a fixed capacity plan, that's another piece, for budgeting. The organization it provides has been truer to the needs of spending.

We've just shifted to an Agile development as well, so there has absolutely been an improvement in speed to market. We now have consistent release plans because we have these environments as ready as they are.

The most valuable features for us are capacity planning as well as environment life management; putting in specific templates and workflows that we know are secure. That solidifies the environments that we're in or that are being provisioned. We also know that every environment being provisioned has a lifespan. It affects capacity, so it's great for budgeting, from my perspective, and good for my team.

In terms of it being user-friendly, we have a technical group, so understanding what they're provisioning, what subnet they're going to be using, the security profiles we have, with a straight developer that doesn't have all the bells and whistles, that's one part. If it needs to be on a certain VLAN, they can put it there if it's going to be used for a different purpose. It's that ability and flexibility to provide the different choices for our team in a straightforward format so they can do the services themselves.

Regarding that networking piece, more hands-on pieces, that come with that purchase to help you get to that good spot might be an area that would help.

It's very stable. The one little hiccup we had was with some of the networking but I think that was more our physical switch configurations, supports and protocols. When you try to lock things down you have to know it end-to-end. But once it's in place, it's rock solid. I think the stability on the network side is there. It was more on us, to be honest.

Right now, we're also installing a vRealize Automation in India and expanding. The fact that we're moving from the US to India just shows the power of being able to add capacity, CPU to it, as much as we need. If we need to grow that fixed capacity, we can.

It scales horizontally too with users, more systems, it's easy.

We have used technical support in the past. Not through me but through my team. We have a high expectation, we need that fast turnaround. We've had nothing more than a day or two, tops, in terms of turnaround time. They're very knowledgeable.

Before, it was piecemeal. We had templates. We had some VDI pools for some of these things. It was just a constant revision of that and it would sit idle for too long. So, for the whole pool, if one or two people were using it, great; but if 10 were using it, then it was not the most efficient way to operate.

When selecting a vendor the most important criterion is the relationship, to be honest. Pricing, you can beat people up and have negotiations on it. Pricing, obviously, at some point was an issue, that factors into it. And we need to make sure all the technology fits. But having a relationship with the vendor that can be with you through the good times but also the bad, that makes it worthwhile.

I was not involved, my team was. We did not bring in VMware to help. We have some knowledgeable folks. They knew it pretty well, so I think they liked the hands-on approach a little bit more. They got it up. It wasn't quite perfect but with some support, they were able to round it out and make it the great solution it is today.

We've got education credits through VMware, so we are training on this constantly. I think it's a matter of using the resources that are out there and focusing on this.

Rubrik is one we are looking at. And the whole AWS Hybrid Cloud is definitely on my roadmap.

For a specific business, you need to know what you're trying to do. For ours, it's a match that I wish we would have had immediately. It has paid dividends.

I give vRA a nine out of 10. Sure, there's room for improvement. I don't know all of those areas, I'd let my more technical people speak on that. For us, this has been one of those solutions where ownerships loves it, appreciates it, sees the difference.

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.

It's cut our server deployment times down from weeks to an hour.

Because we're running on the older version, we've actually had a lot of stability issues. We're currently evaluating either upgrading or integrating the new version, but we haven't made the decision yet.

Because we're on the older version, the scalability is a lot more complex than the newer version. We actually built bigger than we needed when we deployed it. I do know from testing it in our lab that the scalability in the newer version is pretty robust.

Excellent. They're knowledgeable and you're able to reach the right person.

No, we were just doing manual builds and manual deployments. Our management said that we needed to do something, so we invested in vRealize Automation.

I was involved in the initial setup of the older version. It was extremely complex and difficult to get right.

In evaluating the newer version, it's super simplistic, and they did a fantastic job of all the changes made to automate the automation pool.

The corporate government works a little differently. We had put out a set requirements and other vendors come and bid on it, then we pick the vendor who best met our requirements and has the lowest cost.

No, we were just doing manual builds and deployments. We did not consider any other vendors that I'm aware of.

Make sure you deploy the latest version.

• The automation, that is, being able to automate server deployment, including the option to do it manually if you want.
• Being able to collect logs and diagnostic information in one central location.

I can build machines quickly and deploy them from a central location to whichever worldwide datacenter we need. Also, we can collect system logs from all clusters and hosts, and then we're able to troubleshoot and view logs in one central location. This is a good thing because it saves time.

They just need to keep expanding it adding additional features.

I’ve been using for just a few months, including Log Insight.

So far so good, it's very stable, rarely any issues.

It’s definitely scalable, and does a lot that we’re not doing yet, but we’ll eventually be there. We’re capturing logs from all over world, and everything is in one location, so we can scale to meet that need.

VMware tech support is excellent. It’s one of the best vendor tech support I’ve found.

It's extremely easy, very straightforward, and has good documentation.

It simplifies daily chores, so go get it.

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.

DevOps is our primary use case. It's performing okay. We're getting ready to upgrade and move into an HA environment, so it will be much better.

The benefit to our organization is time to market. It has streamlined the process so that they can deploy systems, test the systems, and get the product to market faster. Speed of provision is much faster than what we used to manage, especially when we incorporate Day 2 Operations. We can get that into the automation and allow for that to take place, as opposed to the DevOps teams doing that all manually.

It has absolutely helped to increase infrastructure agility - not to its capacity by any stretch, but we're working towards that. It definitely has allowed us to be a little bit more agile.

The most valued feature is the streamlining of the DevOps process, automation and orchestration. It provides the ability for the entire Dev lifecycle to actually be incorporated into a single stream. That's our primary focus.

We still struggle a little bit with the configuration as far as making sure that we have all the endpoints where they need to be, because that's not as agile as we'd like in the back-end. We're working towards that with our DevOps teams to make sure that we're touching the right endpoints and getting the right data.

Also, what we would like to see is a lot more integration across platforms, multi-cloud. I think that's coming.

in general, it took us a long time to get it off the ground. We had a lot of issues upfront and we determined that we just needed to scrap it. I think we scrapped it two or three times before we actually got it built the way we wanted, and we're still not where we need to be. We have had downtime. There have been some issues, but we're also two iterations behind on version. We're getting ready to move to a new HA environment and go on to the newest product line.

Right now, it doesn't scale for us, but it will once we move into the new environment. It will probably scale five years out, especially with the way that we can integrate different endpoints.

Technical support has been phenomenal. Most of the time we get to the right person, but not always. We eventually do because we know who we need to talk to.

Previously, we used a product called LiveManager. It was not across the entire organization, it was just a subset, so there was nothing really prior to this.

When looking at a vendor, the most important criterion is how good a partner will they be? Will they be around? Is it somebody that we can trust and that has been utilized in the marketplace? In addition, is the solution scalable? And then we'll look at cost.

No way was the initial setup straightforward. We scrapped it multiple times. Going through some of the sessions today, here at VMworld 2018, we see that they're incorporating some of the certificate management and so forth. That's where our biggest challenge was.

Upgrading was pretty straightforward. In-place upgrades worked really well for what we've done. There wasn't a whole lot to that. It worked well.

Really, it's all about the initial setup and making sure that it is set up right.

We haven't calculated an ROI but we've realized ROI in manpower.

At the time, there wasn't really any competition when we decided to go this route. It was really only VMware.

In general, I'd recommend vRA but make sure that your framework is set, that you understand what your processes are so that you can fit into the framework.

It's not intuitive and user-friendly but we've made it that way. We've allowed the DevOps teams to incorporate some of their components inside of the catalogs themselves, so we give them a little bit more flexibility, rather than dictating what they need to do. That way, it really runs true to their process.

I rate vRA about an eight out of ten because of the inability to get this thing stood up, initially. We weren't the first to actually do it, and yet, it seemed like we were the first to do it. But because of its scalability, it's a product that we decided to go with.

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.

Our primary use case is to automate deployments of virtual machines and data actions. We have automated everything using vRA.

We have several customer teams that serve external customers. Previously, each team, when it received a change request to deploy a single virtual machine, had to create a ticket in our ticketing system. Then it had to go through a couple of departments. The time to get that all done was quite long, on the order of days. vRA has helped reduce the amount of time it takes to create a ticket in our ticketing system. We have been able to reduce the process to around 30 minutes. Obviously, it has reduced the cost and amount of work.

The automation part is valuable, especially where vRA integrates with vRO, because it reduces the amount of effort we have to make.

This solution is intuitive for the end user. For the guys who need to manage it, it is a bit more complex. It is quite hard to maintain, especially since a lot of work has to be custom-built, which takes a lot of effort.

Stability is not great, although, the latest release has been better.

Scalability is good.

I would rate their technical support as a six out of ten, but that's not completely their fault. A lot of our tickets have to be transferred to engineering. GSS has not been able to solve a lot of our issues.

We work a lot with VMware and were using vCloud Director previously. VMware architects came to our office and, after much discussion, vRA popped up as the best solution that fit our needs.

The setup, the installation, is straightforward, but only with the latest releases.

Upgrades are one of the points where incidents are happening. Every time we want to upgrade, a ticket needs to be created and moved to engineering because GSS is not able to help us. We are able to upgrade, but it takes quite a number of retries, which are very costly.

It's not a smooth upgrade process. For a DTA environment, which is very simple, it is a smooth process, but for our production environment, which is quite enhanced and has a lot of dependencies, it's not easy at all, and it results in a lot of errors.

We did it on our own.

We did not evaluate other vendors.

vRA 8, from what I have seen of it, in a session here at VMworld 2018 Europe, fulfills every need we have. The Service Broker is better. vRA simply speaks with all my other endpoints and I see a lot of benefits in that.

I would rate this solution as an eight because the way we set it up reduces the effort which would normally have been needed to deploy a virtual machine or perform data actions. I'm not giving it a higher score simply because of the difficulties we have run into in the past with it as well as the difficulties we continuously face during upgrades.

We are currently discussing if we should stay on vRA or move back to vCloud Director. For now, I would recommend vRA, having seen the roadmap of vRA 8, which, in my opinion, is really good.