VMware Aria Automation Reviews

It is primarily used for developers to spin up their own VMs and destroy them at will, afterwards my group spins it up in production machines. Probably, its most valuable feature is it takes time off of my schedule to quickly, securely, and conveniently deploy virtual machines, then I can work on other things.

The big benefit is it will spin up VMs quickly so it would take about 13 to 15 minutes to deploy a virtual machine. Whereas, if I were doing it based on an email from users who are requesting VMs, it might take time for me to hear back from them. This could be anywhere from an hour to a day. It's extremely convenient to be able to spin something up and be able to work on other things, because it's already done it, making my workload lighter.

Quantifying can be a little difficult because we recently rolled out. It is probably 90 percent quicker to get something out the door than it was before. For developers, depending on who is building VMs for them, sometimes they request anywhere from 20 to 100. Now, we can deploy them in a matter of an hour, where previously it might have taken me three days to deploy out 100 VMs.

It would be nice in the next release if they added in tool tips. Whether you're putting it together, adding a blueprint, or you're making a change in the system, highlighting or selecting something and having it tell you what it does or what it will do would be nice. Because it's such a complex system, it's hard to work with unless you've been using it for years to know what everything is doing.

So far, stability is great. We haven't had anything crash or be taken down by bugs that we've come across. 

We left room to be able to expand in the future. This was the job of our consulting company.

Previously, it was just me manually building VMs. 

When my workload started increasing and I started getting more tasks, my manager noticed that it took longer to deploy VMs. At which point, our senior admin knew about this product and suggested that we move forward with putting it into the new environment.

The setup process isn't intuitive and user-friendly, but once it's set up everything after that is easy. It can be as hard as you want it to be, or it could be as easy as you want it to be depending on how you're setting it up. 

It is completely upgraded to the newest right now. 

I spent about a month working on the set up. It was pretty complex. 

It takes a smart person well-versed in anything from JavaScript to building out blueprints to somebody who knows vCenter and vSphere. 

To deploy it, we brought in a consulting company because were strapped for user availability to set it up. Therefore, having a consulting company sped up the process of putting it together.

Since it's fairly new, we don't know the ROI yet. 

As far as value is concerned, it has been essential to our environment. We have been able to deploy VMs quickly and the developers have their own sandbox, so they can spin up and destroy VMs at their own will. 

It was always going to be VMware, because that's our primary virtual machine deployment. 

It is a solid 10. It's completely taken a lot of time off my plate so I can concentrate on other things, including learning the product as well as vRO, vRealize Orchestrator. 

If it's too complex for you, get a consulting company, because it makes the process a lot easier. I would definitely speak with other people who have implemented it in their environment. We've actually done that in the past for other products. It's nice to hear what other companies think about the product. It will help accelerate your decision.

Most important criteria when selecting a vendor: 

1. Ease-of-use.
2. Functionality to the point where it's not going to break, and there are no bugs in it. If the product has been long known to contain very harsh setup routines, it's going to take a long time for bugs get fixed, or there are multiple bugs which keep showing up in every version, this is something that I don't want to deal with.

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.

I am working on the architectural and design part of the product. We use it for capacity planning, reclamations of reports, infrastructure monitoring, alerts monitoring, and notifications.

There are many features in the solution. We can map all the service profiles. We can do the scripting in third-party applications. The solution provides multi-level approval features to download VMware workloads.

It also provides features like multi-tenancy. The tool seamlessly integrates with private and public clouds. There are a lot of good features in the solution. The product is very user-friendly.

The costing models in the previous version have been moved to vRO. The process is not simplified in vRO. I don't like this change in the new version.

Currently, I am using the latest version of the solution.

Once the product is customized and implemented, it is stable. We need a lot of effort during the initial stages.

It is a scalable tool. We can scale it horizontally and vertically. Our organization has plenty of users, including internal and external customers.

We use break/fix support. We don't get problems very often. Whenever there is an upgrade or customization, we use break/fix.

Setting up the primary components is easy, but sometimes scripting is complex. It is not a simple product. It is vast. Deployment, planning, mapping to the business requirement, and including the stakeholders take a lot of time. Modifying the product according to the business is challenging. Business is very dynamic, and we must tailor the features based on the business needs. We use a private cloud.

A lot of information gathering is required to deploy the product. We need to understand the business requirement, demonstrate various features, integrate many endpoints, customize the tool, integrate backup, and integrate scripting to auto-install various software. Deploying and configuring the solution takes a lot of time. It is a full-time job. It requires a dedicated team of people. There are a lot of components. It is challenging.

We need an experienced team to maintain the solution.

ROI is purely defined by how individuals define their goals to meet their business expectations. ROI can be easily achieved if we do proper planning. If we don't map the technology to the business, ROI cannot be achieved. That is the drawback. If you map the technology clearly to the business requirement, document the process, and approve the proof of concept with all the stakeholders, then deploying the solution makes sense. It would get better results in terms of ROI.

The tool is expensive since it is an enterprise product. The cost and the business requirement must be justified before deploying the solution in the cloud environment.

Before deploying the product, we must have a blueprint of how we want to use it. Then, we can plan it accordingly. We must plan the organizational needs before deployment. It will ensure minimum changes while deploying because it needs a lot of integration. A lot of third-party vendors will be involved during customization. However, having proper planning, knowledge, and technical abilities and integrating multi-skill vendors will make a perfect blend of technology for a better experience. Overall, I rate the product a seven out of ten.

Our primary use case of this solution is to provide our clients with a virtual private cloud. It has been performing very well. We've had some multi-tenancy issues but VMware has been very supportive. 

For repeated installations and the provisioning of VMs, we now have a clear definition of what has been installed, and we can monitor all that stuff. There are some functions for the ICDs, and we have continuous development and deployment.

It theoretically could help provision new clients faster if you adhere to the limits of the product then it makes provisioning the new client a lot faster. If you have customers like we have that are really demanding and want special solutions it will end up in huge customization.

We like the blueprint designer. We can create topologies with it. 

I have found it to be user-friendly because it's very UI centric. We have a problem that most of our developers would like to have it more on a flat file format. For our end user, it's just perfect.

I would like to see multi-tenancy in NSX and better functionality. 

We have found this solution to be stable as long as we don't test its limits. We have had huge installations where we had some problems with performance and stability. 

If you have a normal use case like a conventional enterprise and use it for yourself then you might never test its limits. In our case, our customers are creating a lot of business groups and this led to a lot of problems later on.

Their technical support is very good and swift. 

We switched because we don't want to focus on the cloud management platform. We want to have this resolved and supported by a vendor because we are system integrators and want to supply the services and the knowledge above that. 

The initial setup was complex because we have a high availability cluster. Especially when it comes to upgrades, we have a lot of downtimes and problems. The upgrade experience has been painful. 

The product as a whole was offered by Dell EMC but we used VMware as an integrator and for the setup. We still have some VMware specialists working within our team.

We have seen ROI. 

We built everything from scratch, it ended up being very costly. 

I would rate this solution a seven because it hasn't perfectly adapted to our use cases with multi-tenancy. 

If you're looking into this solution I would tell you that if you use this solution only within your own company, you'll be fine. If you have a business like ours, it can get complicated. 

It's a SunBox for the people developing apps for the healthcare company. They can submit the project chapter, implement what they want based on the template that we have in the vRealize Automation, check, compare, and then at the end, they can build a project charter with all the needed components.

In the past, we released several steps to implement an application in the company. The first step was the project charter. You explain what you want to do or how you want to do it and what the costs would be for this. This means that before having the project charter, you don't have any budget. The SunBox is free of charge: they think, they deploy, they test. If it's working, they do a project charter, if it's not working they go back and try other stuff.

It has helped with provisioning. I know several projects that were going faster with the up to date cloud. In the past, they would implement and if it wasn't the right step they would have to go back, discuss with us getting a new server with the right sizing, then they would implement, test and go back. With this, they implement, they test it, if it's not the right stuff, they just throw it out and implement the new stuff. It's direct. If they just increase the size then it's less work for everybody and everybody can achieve their work easily and quickly.

It's intuitive and user-friendly for the user, but not intuitive and user-friendly for the implementer because the templates are not easy to set up. For the end user, it's quite easy, but it's a fulltime job for the implementer and we don't have the time for it. This is why we used a service to implement instead of us. We don't have the time to focus on that. 

I would like to see more stability, something that is integrated and that checks that all of the servers are working well. Also, the ability to customize templates. 

I would like to see them implement vRealize into the cloud. It would be very smart for us to have vRealize in the cloud as a service that can be deployed internally. Then we don't have to implement anything anymore. We only need to take care of templates. 

The stability is why I rated it a seven and not higher. There were several cases where we had to restart some services because it wasn't working correctly anymore. People cannot extend their machine or replay their machine. There is no alert to say that there is a problem and that we should stop the service. The monitoring system is not very good.

Scalability is perfect. We haven't had any issues.

We have found their technical support to be good. 

It was a logical and smart decision for us to have this solution in place. It makes sense for my business. We used Orchestrate, the original version. It was the first automated system that could deploy complete solutions. We decided to go with this solution because it was evolving and I just followed the evolution. We switched to vRealize three years ago.

I wouldn't say the initial setup was straightforward but it wasn't complex.  

The upgrade experience went well. It's working well.

We used a service to implement. We did our research and now we have a good guy from VMware services. We plan to keep him. If we always have new people coming into deployment services it can take at least five days to teach them how the system works and to do all of the certifications needed. Our plan is to stick with this guy from VMware services. 

The ROI that we see is that people don't have to work too hard to have something done and therefore they have more time to market. They save time, which is money. We are an American company so if you save time, any implementation that we do is the implementation of a tool that can submit new work to FDA. One day is like one million.

I also have a lot fewer people asking me questions or for help. I don't need to be as involved in the discovery phase. People can now do their own job with something free and automated. They are happy.

We conducted studies on other options. We found other possibilities that were cheaper but so far this is what's working well for us and as of now we don't want to change. 

Our primary use case for the product is automating the basic rollout of a VM.

Our experience with it has been very good. It's one of those things where, if you don't have to think about a product, it just does its thing, it's in the background, you don't have to worry about it, that's always handy.

We're not too complex, we're not a dot-com, but it does help us with smoothing out the variability of things. It makes it so that we can deploy things very easily. We don't use a lot of the higher features it has, but the basic things we do, we can just knock them out on a daily basis. It's not a problem to use.

The flexibility it has given us in being able to deploy things very quickly and easily, taking it from having to build up an image, and deploy something manually, which would take several hours or a day, we can do in 20 minutes; just roll out a template very easily. If we want a half-dozen different systems, we don't have to manually build them. We just point a domain to each: bang, bang, bang, done.

The solution has helped us to increase infrastructure agility, mostly because, in addition to it being able to do its thing on its own, it has tie-ins to other parts of our CI/CD pipeline. We use Jenkins for our build process which, of course, vRA has plugins for, to be able to integrate with it. We use Chef and there is the Chef build as part of our image that we standardized to deploy, and that can tie in with our section of the pipeline that it does for applications.

It has made it easier for IT to support developers because we can stand up boxes a lot quicker. We can have a test environment, we can actually just clone off something and make it a lot quicker and easier for them to deploy; quicker deployment, quicker testing, quicker into production.

The most valuable feature is that it's able to deploy several different operating systems, it's able to deploy whatever we want. We can take a template, spin it up, revise it, save it back off, and be able to have that for other departments. We can have one for our Dev team and one for our Research team which has some specific requirements. We can keep track of them and deploy things automatically.

The tool is also usable for Windows and Linux and Mac. We have people who access the tool who have different requirements. For example, I'm in Windows, but we have a Linux group that also uses the tool, and some of the people in the networking department use Macs. So it's very usable across different functional groups.

We have also found it to be intuitive and user-friendly. It's something that, because it has the workflows that are very easily graphed out - you can follow what it's doing, it's very picturesque, you can see what it's doing easily - it's something that you can hand over to a user who is not familiar with it and they can wrap their brain around it pretty quickly. The networking group, which doesn't access the finer features of VMware a lot, we give it to them. When they want to deploy a tool, they can see what it's doing very quickly. It's not something that you have to understand a scripting language for to see what it's doing.

I honestly don't see much room for improvement, but how can I take a new employee and ramp him up so he can be productive quickly? How do we get the training materials standardized so we can get him up and running really quickly?

The stability is good. It's one of those things that we can just stand up and forget. We haven't really had any problems with it. It's just there, and we can rely on it.

Scalability is one of those things we haven't used or needed. But it's there when do. We have confidence that it will meet our needs when we need them.

We haven't had to use tech support for the product. Part of that is that I do my own support. During the initial deployment, I had a few questions. We already had a VMware representative up there. So I asked him my questions. The support was good.

We have gone all the way from version 5.5 to version 8. VMware provided us the steps that we needed to do to go from this version to this version to this version, the progression we needed. From there, it was very straightforward.

I would easily give vRA a nine out of ten. It has done everything that we need. We're not the most complex use case, but it's done everything we need, we can just forget about it in the background.

It's a nine and not a ten because of the training stuff. It would be helpful to have a nice flow of training for a new employee. I'm the "old guy" of the shop and we're bringing on new people or new use cases. For example, the user-services department needs to start using it. How do we bring in new people to use its fleshed-out features, in addition to just our using it, where other departments are using it? How do we bring those people in? That's the only thing we really need.

Primary use case for us is how do we consolidate, how do we provision machines as fast as possible, provision databases? Also, how do we go from on-prem to cloud?

We like vRA because it helps make systems available on time for our customers, on demand. Previously, if a customer requested machines or servers it would take three or four days to deliver. But now we can give them specific tools, or a portal, where they can shop and select which server they want. We provision servers faster. For example, to get a database machine provisioned it would take a week. Now it's a matter of 30 minutes.

Also, we now have control over the network, the server team, the storage. We only need a single team, customers are only talking to one team.

I don't think it's intuitive or user-friendly. I think it's a good tool. Any automation tool, these days, the learning curve is kind of high. You're teaching sysadmins who never developed stuff. Maybe they modified a little bit of code and now you tell them, "Hey, here's the tool, use it." But you have to know a little bit of DevOps. So you have to train them how to do the scripting.

They could also improve a lot on the interface itself.

We have not had any outages or crashes so far.

Scalability is very agile. You can scale it however you want.

If you have the Premium Support you might get somebody. Other than that...

I was responsible for the upgrade. It was very complex. One the reasons was that we were going version to version. We learned that some of the objects that were supported in previous versions were duplicated across the board. So we had to clean a lot of the databases to get the new versions.

We are still at an early stage so our assessment is probably going to be at the end of the next quarter.

My advice would be to hire Professional Services. Don't do it yourself.

When looking to work with a vendor, the most important factor is skills. They need to have the right skills, especially when you don't have time, your project timeline is very short. Skills are the key: someone who knows the product, who has lot of experience, and who has done it before.

We are using it to offer self-service capabilities to our customers, a self-service portal.

One of the huge benefits, of course, is that it gives direct control to the customer. They have a direct knowledge of what they're using. They know the resources that they're taking advantage of and how much it's actually costing them to take stuff. 

It's helping our operations actually get closer to our applications team because they're now starting to build automation around the information they get from the operations teams; when they build blueprints, for instance. So they're able to build these bigger application stacks and there's a better understanding, from both sides, of what's required.

I would like to see easier custom components for it - that would be the best way I could word it. It's more like custom items for it.

Also, the authentication piece could always use some work. They should make it a little bit more dynamic, a little bit easier to deal with large-scale AD deployments. They need to make it a little more enterprise-ready. That is the one thing that kills us. I hate harping on the authentication issue, but it is huge.

We have run into some issues with stability. Primarily, some of the components seem to go out of whack with each other sometimes but, for the most part, it's been stable. It's just that when it fails, to be honest, it seems to fail spectacularly. It has to do heavily with the authentication portion of it. That is one of our biggest issues with it.

Beyond that, vRO can get out of sync with vRA. We've run into that every once in a while. But it's very rare, compared to the authentication problem.

It seems to scale well. We haven't really had too many problems. There have been a couple of issues, but they have mainly been with our external systems, not the solution itself. It has been able to handle the churn workload.

Technical support has been really good. There have been a couple of issues, but they've been fixed, mostly in an update or a hotfix. And they've been willing to jump on calls almost immediately with us.

The solution we were using, technically, was ServiceNow but it wasn't as good for our environment. It was very good at creating small cookie-cutter, but not for large-scale.

When looking for a vendor the most important thing is support. Absolutely. If I don't understand the product, I need to make sure I can get an answer as quickly as possible.

The initial setup was pretty straightforward. Everything was connected. There were little "gotchas" here and there, but either they were easy to resolve with tech support or the documentation usually had some comments about them.

We have already seen the return on it. We've been able to cut down the cost, the time dealing with the back and forth between customers. We can say, “I've got your server, now you can do this,” or, “Here's your server, it's already been provisioned and ready to go for your app."

Make sure you think out the entirety of your deployment because it's hard to change components after the fact. Make sure that the initial deployment is good. We got that from VMware. They were very good at understanding the size of the environment and they tried to scale it for that environment.

I would rate this solution at about eight out of 10. It has been good but, as I said, there are some faults. Overall, it has performed phenomenally and the support behind it has made it absolutely useful.