VMware Aria Automation Reviews

• The agility that it offers.
• The flexibility that it offers.
• The scalability that it offers for us to serve our end customers.

That's really helpful.

At this point in time, it's support for multiple platforms. It already supports certain platforms, so extending that to the multiple cloud platforms and services, that's where we are looking to go.

We have been using it for the last couple of years, and it has pretty much worked for us without any issues.

It is very scalable. We are currently using some 20,000 workloads across multiple customers.

VMware support has been very helpful throughout the journey of using all of the VMware products. I rate them five out of five.

The basic setup is pretty easy, but then into the next phases it all really depends on what services you want your end customers to subscribe to. Depending on that, the complexity will vary.

The most important criteria when selecting a vendor include:

• What is it really offering, for us as a customer, and for our end customers?
• How much flexible they have in understanding our needs and accommodating those needs.
• Support: How much support are they ready to offer, what are their capabilities in terms of getting us live, through the product lifecycle, and then helping us manage that product as we move along?

I think vRA stands at the top of the list of the products that we rate, because of the problems that it has helped us to solve, in terms of providing the services to our end customers. I think it has helped us a lot.

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.

Self-service and automation. They reduce the amount of time to build a virtual machine and reduce the operation costs.

The requesters create their own virtual machines now, instead of a series of tickets to get things built.

We're still running version 6. When we upgrade to version 7, a lot of our issues should be addressed already. Things like some of the flexibility, and some of the ease of automation.

It's very stable.

It's extremely scalable.

Since we moved to Business Critical Support, it's been very good. I always reach the right person.

We needed a self-provisioning front end. So, this was the best option.

Complex. We deployed the original version of vCAC and there wasn't a lot of documentation at the time. There are a lot of disparate parts that have to be deployed on multiple machines that involve a bunch of load bouncers. Issues like that.

We purchased PSO resources.

Licensing's expensive.

VM was the only one we really looked at.

The most important criteria when looking at various vendors are reliability, their position within the industry, and the ability to get references from existing customers.

Do a lot of planning upfront because some of the choices you make, when you initially deploy, you'll have to live with in the end. Sizing is the main one.

I would suggest hiring a PSO.

It is our service catalog for our hybrid cloud which is the most valuable feature.

It allows us to be more agile and provide services to our company more rapidly.

There is room for improvement for mostly stuff around containers and controlling containers.

This solution is very stable.

This solution is very scalable.

I have used technical support. They are excellent. We used their professional services to help us install it.

I just knew where the industry was going. I just knew that it has been moving for a long time in that direction and I was looking for something that we already owned. Also, the team was knowledgeable so that we could use them for orchestration.

The setup was complex. It's a lot of independent components that are put together that make up a software-defined data center. So, it's really complex. They sent an in-house team.

Support, cost, and functionality are the factors that we look for while selecting a vendor.

VMware was the only one that we actually looked at because the other option was OpenStack; we weren't going with OpenStack.

Do it and do it quickly.

It depends on what your app stack is and whether your cloud-native or not. However, if you have a monolithic stack like Oracle and the traditional data center apps, it's the way to go. But, if you are cloud centric and use a lot of web services, then it's probably not the right solution.

You should form a team, be committed to it and expect to put in a lot of work/effort/time into it.

• Automation
• The flexibility to actually build different components, in terms of virtual machines.

Our group, we do mostly the virtualization and a creation of systems. Therefore, it's not a cookie cutter build of a template, and that's it, it's more dynamic for our group.

It's increased the efficiency. There's less manual work through vRA. Now, Orchestrator is the one doing most of the work and making everything more automated.

I would like to see this additional features in the next release: The ability to have more dynamic forms. Some of the static forms that vRA provides in the XaaS form, they are good, but they could be a little more efficient. For instance, the calendar selections should have the ability to only go to a certain spot, as opposed to going out to something like 2040, for the requests.

Stability is really good. Once you got everything setup, even in its HA form, it's pretty stable.

Not as good, but there are some components in vRA that you can scale out a lot more quickly than other pieces.

In our group, more of the web solutions and the blog posts helped to grow our ability to use vRA.

They are always reachable by person and knowledgeable.

But because it's such a dynamic solution, at times VMware does have to go gather more resources in order to figure out the solution to things.

We had a previous VMware product called Lab Manager, then we had grown out of that box and decided to go with vRA.

I was involved in the setup. In the original version 5, it was very complex. Version 6 got a little better. Version 7 is much more improved.

In the first deployment, they sent an in-house team.

Microsoft.

Advice for looking at VM solutions:

Definitely research the product and see what's out there.

Look at blog posts of vRA. There's quite a few resources that you can search and find on the web which will basically get you on the ground running for deployment, even simply XaaS forms.

Most important criteria when selecting a vendor:

• Support
• The cost is always important.
• The ability of their features to match with ours.

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

For a few years, when we needed a server, it took us three months to deliver one. Now, we can bring one up in approximately 15 minutes.

Our delivery is now very fast.

It's very stable.

We're satisfied with the scalability of the solution.

They are very good. We have an account manager. We use the account manager, if necessary, and have with a relationship with them, so they can respond very quickly.

If you are looking to implement the product, do it together with VMware. It was a good experience for us.