VMware Aria Automation Reviews

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.

What I like the most about vRA: Its seamless ability for users to be able to go pick a catalog item that we have created for them, while they are testing a new version of their code and say, "Okay, I want you to make my old version (based on these blueprints) run, please deploy me - my entire environment."

Whatever we do for the users, we use NSX integration for it, so they can have that encapsulated environment separate from their coworker trying to do the same code testing with the same IP address. Everything needs to be the exact same. That's what we love about it right now.

The biggest feature that we've seen so far is for them to lifecycle it out. A lot of times we have developers that build something, then they forget about it. Now, we lifecycle out after 30 days, so I don't have to waste those resources for a prolonged period of time.

It has made our developers be a bit more agile, instead of like old days, where it was, "Okay, we need a new environment, I've got to spin up the whole thing for them." Now, it's, "Hey, if you need a new environment, go to this URL, click these catalog items, whichever ones you might be working on."

The external Linux script is all automated for the developers. They just need to be able to say, "Hey, I need this new code pulled down," That's all. They don't even have to build their own workflows anymore. As for the VMware side, we can build the workflows for them, or work with somebody in the DevOps team to build workflows. So now all the developers have to do is click a couple of buttons, then they're working and they're on their way.

One of the things we saw in the initial phase was our integration with our development domains, where if we want to have more than one domain tied to it with users, we're seeing that as a struggle. However, VMware has said, some of these features have been worked out with IAM Appliances. So we are seeing a bit of improvement there, though we want to be able to see multiple domains that we can integrate into the same tenant space a little more seamlessly.

There are still some features that I would like to see changed. One pain point we have seen is users are able to set their lease expirations to zero, which means the lifecycle management gets disabled. So, it has some limitations there that we have seen. However, that's something VMware has gotten back to us and said should be fixed in future releases.

It's fairly stable.

There are some things that we would like to see. Maybe they already are in the current versions of 7. We're still running 6.2.5, but we would like to see a little bit more seamless integrations with some of our other products, like our DevOps tools. We use Vagrant or other things where the developer sometimes just wants to do their job through Vagrant CLI to communicate with vRealize Automation. However, we have seen that as a pain point so far.

We have tested a little on how to put in some operations metrics.

For example, if say, "This will run that script, deploy up some more virtual machines, and/or if this will automate that." We haven't had to expand on that yet. We're trying right now to use Automation Center more for development purposes only. We haven't utilized it in a production environment scenario yet.

We have. It was in the very beginning phases when we went to vRealize Automation. It was new for them, so it was a bit painful in the beginning, but lately it's been better.

They're snappy. They know their information.

VMware has really shaped up their support lately. Now, I can get to a intelligent conversation with somebody on their tech side, not repeat steps that I've already gone through. That's huge for us, and that was one thing which we had concerns about in the past with VMware. Those are some of the things we mentioned to them: "We need better supportability of your products." We have been seeing that a lot lately.

At a prior company that I came from, we used vCloud Director, and that was a product I loved.

It was something I could not obtain any more, because at the partner level you need VMware to still maintain the vCloud Director licensing. However, our company does have a giant vCloud Director pool now, the one that I work for, but the reason for vRealize Automation was, we can't get vCloud, which I needed a nice lifecycle control management, then we went with vRealize Automation, because it had the majority of the functions that you see in VCD but with just a little bit more added functions at that time. With the integration of NSX, that was something that was key for us. We really needed to be able to provision environments on the fly for them to have very like-for-like scenarios. However, when they're doing their QA testing or pre-stage testings, we needed the ability for encapsulation of those environments to be separate.

That's one reason we saw automation with integration with NSX and VSAN, it was a no-brainer for us.

I was involved in the initial setup.

The initial setup for the 6.2 environment was a little bit painful, because you have to have a separate the IAS server and different things, like a Windows server. Now, with the new 7, I know it's all appliance-based, which is beautiful.

It's easy to set up. I have a PoC environment right now we're toying with, and it's a lot more simplistic than the prior versions were. I'm more familiar with the old architecture of it, but I'm looking forward to really implementing the new architecture of vRealize Automation.

The vRealize Suite, it is a very expensive product. However, with all the things it did offer us, in the long run, it made sense for us, because we got to cut down a lot of our public cloud costs due to on-premise solutions.

We did utilize vCloud Air. It was one of the other tools that we did try out.

Now, I don't like to talk bad about VMware, but it was a disastrous product. It was vCloud Director, which I was familiar with, but the supportability was not there. There were some bugs whenever we were trying to do automation and workloads between our on-premise into the vCloud Air. That was the one thing we were trying to utilize, and it just didn't work well.

Then, the other automation solution we were using Chef and Puppet (and other things) for our DevOps tools, but we really wanted to shift more focus to the developers. They don't want to have to command-code out everything. Some of them want to just go, "Click, click, done."

When I went through the first demo of vRA, that's when I saw that this product would be a very beneficial product for our company.

Really pay attention to how you design your blueprints and your workflows, because a lot of developers do not want to do that. They do not want to design their own blueprints and workflow operations. They want it to already have been done for them. Make sure you have a strong relationship with your DevOps team so you can get the most out of this product. Because if you are trying to do it single-handedly as an Operations Center without the go-between, it'll be a struggle to get Development onboard with this type of product. But once they do get on board with the product, they won't want to look back.

Most important criteria when selecting a vendor: Supportability is huge, not to say everybody on our team should be experts in everything they do, but when you do need help, you want to make sure that you're working with top-tier support. I don't want to have to run through the wringer of, "Okay, I got to go through Tier-1, then Tier-2, then finally I can work with Tier-3 (somebody on my level of knowledge)."

vRA's Orchestrator allows you to connect to a huge ecosystem with a huge number of third-party systems to automate any and every IT process that you can think of. It makes it very flexible. Makes it really adaptable as opposed to some other systems.

It allows people to move into orchestration and automation, and most customers want to get into that but they don't really know how. vRO and vRA gives them a step through the door to allow them to start building upon. It gives you a framework, it gives you a baseline to let you build from there.

They are doing well as far as iterating quickly, iterating by often adding small things. I think there should be even more integrations with third-party systems. You have Infoblox and Puppet which great. Let's add Chef to the mix and just keep them coming.

So far so good.

Everything is much improved, especially with vRA's automation 7 and newer, as they move more things into virtual appliances and out of Windows. That's a win for everybody. It's a win for the customers. It's a win for us deploying it. It's a win for manageability, scalability, everything.

Tech support is usually great. As soon as you get a live person you're good. It just depends on the level of support that the customer is paying for. Sometimes that's nothing that we can control, it's just what they have.

It's much more straightforward now that it was in version 6.x., to the Nth degree. They have made it so that you can do either a proof of concept or fully distributed version of vRA with a wizard-driven GUI, which is amazing. Now, there are still some little quirks with that wizard, but it being there makes it much simpler than going it manually and installing each component and linking them all together after the fact.

For me, being a consultant, vendor selection isn't what matters. I want to use whatever is best for the customer. So whatever fits their business use case best is what I'm going to go with, what I'm going to recommend.

vRA does most things really well. There are still some issues such that, if you are going to go 100% cloud, if you don't want anything on-premise, there are some other solutions that might have a leg up.

Use vRA, but it's more about the process than it is about the product. You have to make sure that the users, who are going to be internal IT most of the time, that their expectations are set appropriately. Make sure that you have buy-in from the higher-ups as far as automating processes. You have to make sure you have by-in at all levels.