VMware Aria Automation Reviews

The ability to customize your own portal. We've gotten to the point now where we've used it to create this whole environment for users to be able to self-provision their own machines and get them into networks. We have a very large number of different networks, which means that many options of where they can put those VMs; their own environment.

We used to do everything manually. Up until just a few months ago, we used to have little reviews where, if they wanted a VM, they would come to us, tell us what they wanted, then someone on the team would actually submit the vRA form in an older version of vRA.

Now, the end user can go in and request what they want and do all that themselves, as long as they know enough about their application to get what they need. So, if you're just trying to add a couple of VMs or projects, where you know pretty well what you want, you don't have to spend days getting in line to talk about it, or worse, like back in the old days where you had to spend weeks waiting for someone to get it done.

Since I haven't been able to get as far into version 7, I haven't actually gotten into the guts of it, I don't know if this taking place already. But perhaps more blueprints of common tasks that are already there, so you have more of a place to start from. They may be there in 7, I haven't gotten a chance to look. It would need to have a base of, "Oh, I want to connect and build a VM and have these things," something to start from. Especially for people who don't have the teams that we've had working on it, they could get going quicker.

In the later versions, 6 and 7, it seems very stable. Really, it's nothing within the program itself that ever seems to cause the failures. It's some other component it's reaching out to which tends to have a problem, and that's not vRA at all. It's very good about telling you what's dead. It's usually more that the other application is having a fault and vRA tries to utilize it and gets an error back from the application, which then gets back to vRA.

It's not an even an integration problem. It's the application that it's going out to is not working properly. Then, it lets us know that it's not able to, for instance, connect to a Linux VM to the management product and register it. If it gets a failure there, it tells the folks who are managing the vRA. They tell us, and we go in. We check the management server. "Oh, it's not working. Well, let's go ahead and we need to restart it."

It's the same story on the other side with it connecting to AD. If for whatever reason, there's a problem with it connecting to AD, they'll go look at it. "Oh, this is the main controller having a problem."

It seems to scale up pretty well. If you're talking about how many classes it manages, the older version, the 6.0 series, we actually have it managing all of our clusters across both of our major datacenters; we're talking about being able to build in to dozens of different clusters. So, it's scaled very well.

You can do quite a few at once. Usually, it's more the order of what it's getting back from an independent service. Sometimes, they can step on each other if you put too many off at once, but that has to do with the fact it's trying to request a sequence number; you're trying to get two sequences at once. But that's not really as problem with vRA. It's the way that it was setup to retrieve stuff from these other third parties.

I haven't been the one that's had to call.

Complex. Part of the reason it's complex is that it's like a blank slate. You have to go out there and make your own environments. It doesn't really do anything for you, so if you've got an idea of what you want to do, you have a path forward. But if you don't, if you're just sitting there looking at the blank screen, it could be daunting for some people.

We kind of knew what we wanted and it just took a while to get all those things setup. You have so many different components. Nothing within in our environment was simple, so every management product that we use was probably different than what anyone else would use. So getting all that to work, finding an interface that worked well, that was really why it became complex. It was the complexity of our environment behind it.

So it's not necessarily vRA, it's just that if you don't already have something that's out-of-the-box which says, "Oh, we do all these things..." (I'm harkening back to vCloud Director, because vCloud Director was an all-in-one that did everything).

I think documentation and support are probably the most important things. If you don't care about documentation and support, you can grab a free one and try and build it. If you want someone who is going to be able to answer your questions, someone who's got the documentation already, so when you have a given error, they have it right on their webpage: "This is what this error means. Go do this." VMware's very good about that.

Overall, VMware is very good. It's very stable, very extensible, but it does have a relatively high learning curve. So folks that don't have the resources to dedicate to it may not be able to get very far. I do think it's a very good product, but it's very much a build-your-own product. That's good in other ways.

I would suggest people think about: "How much of this do you want to figure out yourself?" Because even within that process of building your own, you still have that layer of support. If you're looking at which one to pick, pick the one that's going to be able to provide you with advice. We've had professional services working with us on a lot of it at different points in getting it up and running. That's been a very nice driving force towards getting it to completion.

The most valuable feature is the governance system around deployment of solutions.

It cuts out a lot of waste, unutilized hardware, and improves performance.

Automation: We want to be able to have a lot more preconfigured solutions. Where a user can go into the marketplace, pick out the preconfigured solution, and deploy that straight out without having a highly-skilled employee specifically for this role.

It is fairly stable. We've so far not had any major outages with it. If we have any misconfiguration issues, it's pretty quick to use the automated system to find the problem, diagnose it, and fix it, then you back it up.

It is very scalable, at least for our environment. We have thousands of ESXi infrastructure, and for that, it works well.

Have not really used it.

We wanted to scale, and these days, everything is being automated. Therefore, we needed a solution that did not require us to reinvent the wheel or create new automation scripts here and there, but used something already built into the system, which we could use to automate our web flows.

It was straightforward, but it needed technical expertise in this particular area. For those competent in the field that could help us, we utilized them to set it up.

An in-house team.

We looked at VMware. We looked at AWS automation capabilities, but at the end of the day we decided to go with VMware, because VMware was an all-in-one platform that we could use.

Go for the product, but make sure you have experienced folks on the platform that can help your admins to ramp up and go to market quickly.

When selecting a vendor, make sure:

• They have continuous support.
• The performance of their platform will scale, even if you load up the system to a point.
• The system actually will be able to dynamically detect flaws and prompt the admin to go fix the flaw.

The most valuable features are:

• How it takes what we used to do in the same process as manual steps, and automates them, such as creating servers.
• It's self-service for creating your own virtual machine.

It's shortened down our SLA's for VMs. When vendors request an application for various VM's, we used to take a two week process (approximately) from building a VM, QAing, and building it. Now, it can be done in a matter of two days, at max, thus, shortening the process.

Implementation directly with our SRM product, because we know what the other products are out there that VM is offering, such as Site Recovery Manager (SRM). There are ties which you can customize to put them into that, but it would be nice if it came as an out-of-the-box feature.

It's very stable. Just like any other project, it does have its quirks and kinks, but like anything else you work through it. You have to customize it to get it used to your environment. There are growing pains.

We recently went through two or three upgrades, and now we're doing an upgrade for the most recent version. In that regard, it's pretty scalable. The way we can actually manage our virtual machines directly through the interface is somewhat of a gain as well.

They are very knowledgeable of their product. This all goes back to customizing our kind of needs, because everybody's needs are not a one size fits all. You kind of have to customize it to fit to your environment. They have been helpful with this. Also, when we run into any issues, which have not been many, they've been very helpful with resolving them.

We actually have an onsite resident, which helps as well.

Because the way technology was going, such a physical footprint, people are now going virtual. When we realized that, we started getting a lot more virtual questions as opposed to physical, which is a good thing. We realized we needed to start pumping out these VMs at a much faster rate to meet with our demands. That's what steered us toward this product.

It was a pretty straightforward implementation, but it was just mostly customizing it. We house somewhere around 3000+ virtual machines in our environment. It's hard to customize for that large of a footprint. We have a team who handles the automation piece, since we have such a large virtual footprint.

Most important criteria when selecting a vendor:

• Look at the support they provide, the backing of their product, and so on.
• Have a big company name, like VM, where they have stability.
• Fitting the your needs - nobody wants a product that they are never gonna use.

If you get a lot of virtual machine requests, this is the product to get.

The most valuable features are:

• Seeing how the actual servers are responding
• CPU times
• Memory times.

This allows us more scalability in terms of different applications in using specific servers.

Resource management. That's the biggest thing. We're not scaling solutions too much larger than what they actually should be. We can actually take back a lot of the memory with some of the solutions that we're not necessarily using overall. This kind of management is probably the most beneficial.

There is some performance lag, but that could be on our end.

Great. I haven't noticed anything.

I would say great. For different solutions, it allows us to scale.

I haven't. My company has though. I haven't heard anything negative with it. It's all been positive.

We were not using something else, but internally we were overscaling a lot of different solutions and we were getting criticism from upper-level management.

I was not involved.

Look into it heavily when researching similar products, especially if you're looking in terms of budgetary issues with different servers or how you're gonna scale something. It allows you to have pretty concrete data to show to your management.

I wasn't a part of the decision-making process. I know VMware was one of the top choices.

Make sure, and this solution does this, it touches on everything you want to see in a solution in terms of CPU memory. This is such an all-encompassing solution.

Someone that's willing to be a good partner with us. Someone who's responsive, and who when they set us up, or when we enter a partnership, they don't just disappear afterward.

• Web front-ends
• Orchestrator scripting engine

We're automating a lot of OS builds. The front-end gives us a way for users to go and request those services and the orchestrator pirate lets us automate a lot of the functions involved in them.

It's like a streamline deposit made more available.

I want to see them get rid of the IS component and make it a VMware appliance. There are a lot of requirements for Windows servers, which is not good for our environment. This makes configuration and installation tough.

It's cumbersome to set up. It requires a lot of Window servers, which we don't like and the external load balancer configurations, which we also don't like. But overall it does have an HA solution, so that's better than no HA solution.

We got VMware resources to guide us and help us with the deployment.

It has an HA configuration, which is pretty good. It could be better.

You can scale out deployment so that's good as well. You can just tack on more Windows servers. That's good for scale out.

I'd give them a seven out of 10.

We get a lot of run around in terms of technical support. Usually, first tech we get can't help us. We end up going down the pipeline to get someone that can.

We're pretty heavily invested in VMware, so there was no competition.

We built an SDDC environment and we needed a way for customers to consume services out of it.

I was involved in the initial setup. It was a complex product.

vRA requires a lot of development work. It's not something you just set up, then it works. You have to tailor it to your environment and develop stuff to do with it. There is a lot of development effort with the product.

If you are looking at implementing the product, hire a Dev team.

No, we're using vRA and other VMware products.

They're the pioneers of virtualization.

The vSphere stack and all their other products are integrated with our core stack, which is vSphere. That's really the big reason why we like all their other products.

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.

We use it as a self-service customer portal, for all of our present customers. So far, it's going pretty well.

There are a lot less tickets, and we get more people onboard much faster.

Between I think 7.0 and 7.1, when we first had it, the IDM Appliance had a lot of issues with SSL. Upgrade has been a issue, we always have to call in and open up the ticket for assistance. It's just not been that good. I think 7.2 to 7.3, which one of our engineers just did, was actually the only time we've actually been able to do an upgrade well.

Also, there's a couple of UI things that we'd like to see improved, but we'll put in future requests for those.

It's been better, but it did not start off so well. We've been using it since 6.0, and 6.0 had a lot of issues. Early 7.x versions had a lot of issues as well.

We're actually not that big, so we do a simple deployment.

We use them for all our issues, though it took awhile. It seems like we're getting the right people now.

The CIO asked us to set up self-service for visiting. We looked at a couple other things. We actually bought a different product first and it did not work at all. It was a Abatix. We did that for about a year and a half, but it just didn't work like it was supposed to.

Then, we came up with a requirements document for what we're actually trying to achieve for that project. Afterwards, we start evaluating the various metrics.

It was complicated. 7.0 was a lot easier.

We're doing cross-training now, so the guy that actually took over for 7 is cross-training the rest of us, and it's been a lot easier for us.

With 6.0, it's just less Windows machines.

It's a product worth looking at.

The self-service portal, as well as the Orchestrator. They are important, because now, especially, I'm getting a lot of public cloud deployment. So the orchestration piece is really handy for day-to-day operations. I'm doing different item consultation management, as well as directly deployed in the public cloud. So those are the two most important features, they are very helpful.

Added features have improved it a lot recently in version 7.03, so you can deploy Azure VMs directly and you can do config management, or you can run scripts. It's really better than it used to be.

Starting from vRA 7, deployment, such as an upgrade. It's so simple, so easy, so interactive. In the past, we had to go through a bunch of operations, but now it's just one click and it can update the vRA client at the back end.

One thing I have seen, although it might just be my personal experience, it's the High Availability. I get a lot of requests and in two different models, the simple model and distributed. With distributed, installation is a pain. I have always gotten into errors when employing a distributed environment, which provides High Availability. So on that, improvements can be made so the process can go more smoothly.

Another thing that's not the best, during deployment, is if we have to integrate managing physical servers. Right now, it's limited to a mature VM environment only. Physical would be helpful.

Four to five years.

No, it is definitely stable.

It is scalable, I haven't see any problem. I haven't done much, but I know that the distributed model is highly scalable and I have deployed that. In the simple model, something like 10,000 operations simultaneously, which is more than enough for most people.

I have called multiple times. I have been using this product for a while, in terms of deployment. I have managed some improvements as well. We are a big VMware partner shop, so we have provided feedback in a lot of processes.

I would rate them as nine out of 10. I don't want to give a 10 because nothing is perfect, but my experience has been really wonderful where the issues have been raised and have been addressed. I have gotten really good technical staff most of the time.

We have tried Cisco UCS Director, which is an equivalent product and we had a hard time. They haven't matured at all. They have so many issues: bugs. We do a lot of deployment as VMware partners so we have done some deployments where the customer initially thought of going with UCS Director, then they changed their mind because of ongoing issues. Then, they finally went ahead with vRA.

vRA setup now is pretty straightforward in a simple deployment. I do most of the functionality, then you just do service mainly. There was one time where I was working and I had to rip out the whole deployment, but I was able to rebuild the whole deployment within a day. That's pretty awesome.

It's very simple, in a very time efficient manner. It deploys the whole environment infrastructure.

UCS Director is the other main product I have used, but it's always vRA that I go to.

From my experience, people think of a High Available, then they plan to deploy a distributed environment, but I don't see much value. Because if they've got a distributed environment, it gets complex and there are more issues and sometimes people run out of patience. So I advise: Go for a simple environment that does 99% of the workload, then, if needed, you can scale it.