VMware Aria Automation Reviews

Everything that takes away from my having to do my own tasks is a very big plus. With Automation and a lot of the components we are looking at right now, I will be able to template everything out and streamline the process, which is going to save me a lot of time. My main focus is COOP sites and disaster recovery, so automating those makes my job easy.

It decreases a lot of manual labor involved in the initial deployment of systems. Instead of my having to go deploy a template and join it to the domain and add software to it, all that is pre-staged once and never done again.

It has also increased the infrastructure agility a lot. A perfect example is that I use Veeam Backup, so I deploy additional proxies whenever our network changes. I don't have to go out and sign in to the vSphere host because I have a different location. I can add additional resources from one location to my disaster recovery management console.

I find the system to be intuitive and user-friendly. In general, I'm quite happy with the entire setup. Once you configure the system, navigating the portal is pretty simple. They use a lot of the vSphere UI interface structure so it's intuitive, especially if you have used anything vSphere-related before.

I don't know if it can integrate with vRealize or vROps in order to already manage what has been done. Right now I'm very big into vROps to pull reports on all my VMs. I don't know if that capability is there already, but if I could integrate it more, if they went hand-in-hand, it would be easy. Not only could I deploy everything in one place, but I could go to another place just to pull my reports on what has been done.

I'm happy so far, I haven't had any stability issues.

I'm extremely happy with the scalability.

I have used technical support, but not for vRA. I used it to help with reverse-engineering my vSphere vCSA because it completely crashed and both sectors were corrupted and I needed to get it back. They were helpful.

We didn't have a solution that does exactly the same. For other systems, we use Chef, but I know that that is more for the application side of things. We haven't used anything like this.

What's important when looking for a vendor, for me, is that they take their time to actually see what we have and what we are trying to do, before pushing an agenda. If they could see what we have and create a design out of that, before suggesting anything else, that would make me want to work with that vendor more because then I would know that they are not pushing something, that they are giving me what is better for me.

Once I understood what it was trying to do, and what it was requesting of me, it was simple. But originally, it took me by surprise. I was not used to the setup yet. One of my main issues was having multiple SSL domains. It took me a while to see how those play a part.

Make sure that you know what your infrastructure looks like before you start.

I rate this solution at eight out of ten, with potential to grow. I still have to learn a lot more about it. Once I learn some of the additional features and add-ons that  I can implement, I think it will increase.

Automation and operations.

So far we haven't really implemented it on our own organization as far as using it with IT in the workplace internally. But vRA has helped us bring in a lot of customers because they use things like Chef and Puppet, and this works in that same kind of realm. So it has drawn those customers to us. We are, as part of our VMware venture, working on our expertise in that realm.

Where it is implemented, in the little bits that we've labbed it out, internally, it has, obviously, increased our infrastructure agility. Otherwise, we wouldn't be continuing to implement it. Once you get all the pieces together, it improves delivery times for internal labs for our internal teams.

We like the seamless, non-vendor-specific application that we can provide with it. We're a service provider, so we have all kinds of different clients and they have different applications. Automation works with all of them, pretty much across the industries. The ability for it to be compatible across many different products is really what's important to me because that's what's selling: being able to go cross-platform and be hybrid. That's the most important feature.

After that, ease of use would be up there too. We also like the GUI display which ties in the non-devs with the devs and helps them work together.

They can improve on the dashboard representations and the options for non-technical people. I would like to see the ability to customize that and maybe provide them with helpful guides to what subscriptions they have. Sometimes, I find that I have to do more explanation to people who do approvals. I would really like to customize the display to the terms they use in their particular business unit. So a little bit more of a nod to the customization of the UI for non-technical users would be helpful.

Also, I expect it's going to come with time, but there is not too much documentation out there because it's fairly new, and not very many people use the little niche product. So more documentation.

So far, VRA seems stable to me. I don't have any complaints.

We haven't had any scalability issues yet, but we are approaching that potential, whenever we get larger customers. The customers that we do have on, if they do use it, they're just testing the waters with it.

They're very helpful. We have Premier Support with them, so we're always working with them. Our TAM is always on top of things. It's good.

Before vRA, we were using a combination of Chef and Ansible. We moved to vRA because I'm on the VMware side of the house, so naturally, that was part of it. Also, we switched because we foresaw the need for hybrid cloud and wanted to be relatable to VMware, so we could have an answer to compete with business units. We wanted to say, "We have vendor-supported vRA that does the same as your third-party or your open-source." We wanted that name brand with it because that's the department I'm in.

Compared to the previous solutions, while I don't have too much experience with them, from what I understand, from what I have heard from the people I work with that helped me on that side, it is a lot quicker. In the small test bed that we have, it is performing better as far as being able to deliver, and being consistent in its delivery.

The setup is straightforward. There are plenty of hands-on labs and guides. It's more the, "What can I do with this?" As a project engineer, I try to translate from the vendor to the customer, according to whatever they're doing at their end.

We haven't really had any bumps in the road deploying it.

My advice would be to go to hands-on labs to see if it's exactly what you're looking for because, as far as the reality versus the expectation goes, it might be a little bit of a shock, especially for the non-technical person. If they're going to say you, "It's going to be great. You're going to know everything," there are some things you might have to take into consideration. They might have to do a little tutorial for you. I would just try to set your expectations.

I rate it at eight out of ten. I believe it's intuitive and user-friendly. Could it improve? Yes. Could it be worse? It could've been a lot worse. So it's okay.

The extra two points are because one of the first issues, on one of the first versions that I took training on, was around the idea that, yes, here's your dashboard so people can deploy resources without having to know too much, but it seemed kind of bare as far as presenting it to those people. That's the only gap that I see and it's just going to be filled in with user experience and people like me saying, "I'd like a little bubble to pop up," or something to hover with information when someone has to give approval. I'd like for them to be able to see why they are approving this, without having to go dig into why we set up that limit. 

It would be nice to have a tooltip that says, "This was agreed upon..." or whatever comment I want to display. For example, if I want to reference a ticket number internally: "Approved, XYZ," or "Related to mass ticket maintenance ABC," so they can say, "Yes, that's right, this is the DFW migration," or the like. They're non-technical and those are the kind of terms they use. I find the UI is missing that part. I have to explain it to them. And then, of course, they're going to forget, or they're going to get a new guy in, and he's going to say, "Why do I keep having to approve these things?" It would be really nice if it just told him right there. This is why you're approving it because of mandate such-and-such, or memo number 123.

From other products that we work with - I came from the troubleshooting operation side of the house before I started working in Product, so I worked with VMware on ESXi and vSAN - they have always been good at taking our opinions. For vRA, I'm starting that process with them, so I'm not expecting them to have a turnaround yet, but I'm expecting them to take our feedback, for sure.

As a VMware partner, we use it to help us automate the deployment of VMs.

It has helped IT to support development. For example, one of our customers has a development team and, before this solution, it would take ten days to develop and test their solution. Now, it is down to one day.

The user interface is not that intuitive. If it is for technical people like me, it is intuitive, but not for the common man. It's intuitive for me because I know what the technology is behind it. For me, because I use it repeatedly, the same type of use case, it's okay, but for our customers, it would be very difficult.

I would also like to see a test environment, testing before implementing, to see how it will relate to existing things. That would make it feature-rich.

If you don't make any technical changes, it works. You need a test scenario before implementing changes.

It's scalable. It's very good in scaling.

Technical support is good.

The implementation for vRealize is straightforward. The upgrade experience is pretty good, satisfactory.

I would say our clients see an ROI of 30 percent.

I recommend this solution, though it is not that great. It is okay for what it is for. When it works it's great. For me, personally, I don't want a call from a customer that it failed. Most of the time it works. If it doesn't, then we do troubleshooting.

I rate it a seven out of ten because it needs improvement in stability, performance, and quality.

We use it to automate redundant tasks. We're limited to two guys, so automation is beneficial and we'll probably implement it with ServiceNow, down the road.

In terms of benefits, we haven't gotten there yet, but increasing our infrastructure agility, speed of provisioning, time to market, application agility, and making it easier for IT to support developers, are all reasons we have it and are looking to get it working. We have had it set up for six months or so.

The automation of the redundant tasks and the implementation of ServiceNow are huge for us, as we are a cloud provider to the campus. It will allow us to automate a lot of tasks that constituents need done, which is very important to us.

In terms of it being user-friendly and intuitive, from what I've used, the little bit I've done in hands-on labs, it's been pretty easy.

That ServiceNow implementation is a little rough, but those guys in Ohio are doing a great job on it. Seeing things like that, things that integrate would be great. Anything that has REST APIs should have a plugin, that's really what makes it powerful.

So far, so good, in terms of the stability.

The scalability is very good. That's one of the reasons we like it. Is scales great.

Understand your business processes before working with it. That's what we're doing right now: getting a better grasp of our business processes and how the lifecycle of these VMs work, so we can better utilize vRealize Automation.

I rate it at eight out of ten because of its intuitiveness, its ease of use, and the features that it will bring to us - a two-man team - will be like having a couple of extra guys on hand. And that's really great. I know PowerCLI is there and we can always script it out. But automation is really a powerful tool that we're looking forward to using, that will make it a lot easier. It covers a lot more. So we're happy about that.

We are looking at doing automation at the enterprise-class level.

The product is really excellent. VMWare provides a complete ecosystem. And it covers multi-cloud, which is where the market is going. We are able to cover compute, network, storage, etc. We have been able to take it to the next level where VMWare is providing the validated designs, VVD. 

Let's take compute, for example. At compute we have seen, in a session here at VMworld 2018, with AWS or Azure or GCP, you are able to create an abstract layer on top of it and manage it. That's what automation at the cloud level is.

Similarly, when we are talking about hypervisors, whether it is Linux or Windows, we have been able to create hypervisors and to deploy the solutions on the same server. That's the kind of automation which we are bringing in. It's a complete solution.

Looking at the desktop level, desktop virtualization, VDI-related solutions are there.

A lot of automation issues are coming up in the market. Customers are looking at containers, among the new technologies which are coming up. How we can integrate with the multi-cloud? I can see, in the sessions happening here at VMworld 2018, that all these things are getting addressed, but the container-related solutions are something I am looking forward to.

We are thinking about containers. PKS is one of the issues. We would like to do a container service. In addition, the VMware Kubernetes Engine is something which we are focusing on.

From the storage perspective, we will bring in vSAN; NSX-T from the networking perspective. But what is the is the overall solution? How would this compare with what the Cloud Native Computing Foundation is providing? That is something which we have to look at it. 

VMware has something called VVD, VMWare validated design. How far the container solutions are going to be a part of that is also something which we'll be looking at.

It is absolutely stable, at this stage. We are able to meet our customers' expectations. VMware is a company which has already grown up. That's the reason we're opting for these new technologies, even though it's taking some time. Even if it is going to be a little bit slower, it's going to be stable. We trust VMware.

I have not used technical support but I have heard it is good. My engineers say that it's good.

Our customers feel it's very costly. But when VMware is providing so many things, the cost is on par with what they're offering.

It's really about whether you want to buy the full solution today and utilize it, or if you want to bring in a lot of people, integrate, and spend on that. Overall, if you look at five to ten years of time, either you buy the full solution or you will bring in the people and try save some costs, but it is going to be almost the same.

If your requirements are on par with what VMware is providing, we would recommend it.

I would rate VMware solutions, overall, at eight out of ten. Whenever we talk about VMWare, people only think about the hypervisors, virtualization. But it's not only about the virtualization at the compute level, it's also at the storage level, at the network level, at all levels. It's about a complete solution. It creates an abstract layer on top of all these things.

We use it for server virtualization.

It's scalable. As the needs of the university grow, it's growing with us.

There is room for improvement but, hopefully, everything is being been addressed already. For example, integrations. VMware is going crazy with M&A and integrations take time, so I can't complain.

It's a stable product.

I'm very happy to see the partnership with AWS.

Technical support is fantastic. They're responsive with tickets.

We used a little bit of everything.

The initial setup was complex. It's improving now.

I'm happy with the product. I would absolutely recommend it to a colleague.

When you compare it to other products in the market, it depends on what you're trying to do.

Our primary use cases are around deployments supporting DevOps, around service provisioning of IP addresses, DNS; self-service entitlement or enablement. And then, driving some workflow processes from our service marketplace, through automation, to actually have them execute within the infrastructure.

It's performing pretty well.

Speed to market. It helps us to improve the rate at which we deploy and the consistency in which we deploy. It has allowed us to scale up and scale down very quickly.

As we meet our open enrollment periods and then we come off of those enrollment periods and go into a normal operational state, we now have that ability to flex down that environment or flex up the environment quickly.

Another side of the coin is the supporting of DevOps. Now, with the advent of the automation, we've been able to give DevOps the ability to spin up environments, give them lease times, and then have it automatically reclaim the environment. So we can build workflows around DevOps processes that are more consistent. Our past configuration was that they would spin up whole DevOps environments of full, physical machines and they would run indefinitely. That was "Bob's" Dev environment and then "Joe" would come and say, "I want one." And then we'd have all these environments. Now, I can give him his environment for 48 hours and I can take it away and he can spin up another one. Or I can archive it. It allows us to be a little bit more agile.

The most valuable feature is the consistency it delivers, at the end of the day. We know that we have consistent images based off consistent Blueprints, check-pointed or QA'ed in a consistent manner.

It is not super-intuitive. It does require some skills to understand how to use it. I had no problem, but I had spent a lot of time already learning this product ahead of moving it to an operational status. But as we did so, we had a hard time bringing some people from other groups into the fold, to script and work against this environment. So, the ability to build workflows within that automation needs to be streamlined.

In terms of additional features, I would like it to be able to poll my vCenter infrastructure more rapidly and adapt to changes quickly. It should alert me and let me know when there are broken components, as a result of underlying infrastructure changes. It needs to be more stringent.

It is very stable. I've had no downtime from the vRealize Automation appliances or components. I think the biggest challenge is being communicative in the infrastructure as you change the infrastructure underneath the automation. This goes back to the naming conventions and the consistency, but you need to be cognizant, as you change your underlying infrastructure - whether that is new storage arrays you're adding, new DV switches you're creating, or new hosts that you're taking out or putting in - you have to be cognizant of your automation.

It would be nice if this product was a little bit more intuitive regarding what's connected to it.

We could scale horizontally with Automation but we're looking more at containers to scale some of our apps more horizontally. But yes, it does integrate very well with other vSphere products that allow us to scale horizontally as well.

The technical support is very good. I've actually been able to turn over my operations to use technical support. They can actually walk me through the problems within the product. That has been great because I tend to focus more on infrastructure or the underlying components, so for the code components, the support is great.

We were manually spinning up clone templates and building them.

We recently took over and built our IT after 50 years of being under HPE. About five years ago we decided to internalize our IT and take everything back. We built a new IT organization literally, out of this solution; it is one of the tools that made us successful. Once we virtualized our infrastructure, automation is what made us be able to work with it.

Our important criteria when looking at any vendor are support and communication.

I was involved in the initial setup and the PoC. It was very complex on the initial setup because we started with the 6.x version and eventually migrated to 7. The way it was architected, with the Orchestrator being outside of the vRA appliance, was difficult to set up and configure. The next versions made it a much more straightforward configuration.

We did not do an upgrade. We did a parallel build. Several upgrades actually blew up and failed and destroyed the environments, so we gave up attempting to upgrade a 6.x environment and built a brand new 7.x. At the time, we did not have Code Stream so we could not laterally migrate. An important component of this is Code Stream. For the ability to scale and have multiple automation instances, Code Stream is essential to be able to move that back and forth. If you already have an existing automation environment, you should look at Code Stream very heavily, rather than redevelop.

We have seen quite a bit of return on our investment. We've actually been able to really change the way that we're doing build and deployments of virtual machines. We've reorganized around that capability. At one time we had a dedicated build team, separate from Windows and LS teams. Now, we've integrated them together because those teams are actually spinning up and building their own VMs right out of Automation.

We did look at some automation around the Red Hat stack itself. Our environment tends to be larger on the Linux side than it is on the Windows side, the Microsoft side. So we did give some consideration to maybe automating through Ansible and some other processes. But because of the simplicity of development, relative to the other options, we chose vRA. We also chose it because of the integration with our vCenter. We wanted to be under vRealize. We wanted to be one consistent stack, whether it's monitoring, spinning up, security, or containers. We want to try to keep everything under one platform.

I would definitely recommend vRealize Automation.

One thing that we've had to realize about this product is, it's dependent on some back-work that you do inside your vSphere environment to prepare for it: things like tags, things like folders, things like naming conventions. We've discovered that these are very important when you're attempting to roll out this product because you already have an established vCenter environment. For instance, in our case, where we had multiple data centers, we may have had different implementation times and perhaps may not have had the same standards around things like naming conventions, DV switches, or storage. Because they map, you have to very cognizant of that.

That's been an issue, not only on the Automation side but across the whole vRealize Suite. I also manage all of the vROps, the analytics, and the integration between the analytics, the vCenter, and the Automation.

It can be tricky. You need to be detail-oriented on how you configure and set up your vCenter so that you're consistent in all implementations. If you have a multi-vCenter environment, you want to make sure you use the same naming conventions across them.

We already had established standards, but as new people came on board, they may have varied something thinking, "Oh, I can just shorten this," or "I'll hyphenate this VLAN_, no, actually I'll do a VLAN-". When you go to map that, to automate that, and you go to read your available VLANs, suddenly it doesn't recognize them because you're not consistent in your conventions. That's one thing we really discovered in automation.

The second was using naming conventions that are consistent and searchable so that you can understand different applications and environments. That's going to be very important when you're actually building automation and workflows.

It's something that the customer needs to be cognizant of and vigilant about as they move towards automation. Automation is taking the existing infrastructure and attempting to automate it and use it and leverage it in a way that's dependable and consistent. I think that's the greatest thing we get out of Automation. It isn't speed, it's consistency; consistency in deployment, consistency in execution.

I give the solution a nine out of 10, based on my satisfaction with the product. My experience with its growth over time - the last few versions I've looked at, 7.3 to 7.4 - is that it is going to give us some capabilities in integration that we didn't have before.

The primary use case is that it fronts VirtualCenter for our entire development environment. The current version performs well.

It provides us with rapid deployment and reclamation of servers. It has also increased the infrastructure agility, application agility, improved time to market, and made it easier for IT to support developers.

• Self-service for the servers
• Reclamation
• Self-service for all of our IT or development teams to expand and decrease their environments at will

Other than the features that are supposed to already be in place with the new version - meaning the tight integration with vROps, which they said was there but wasn't - the ability to migrate between clusters is a big deal right now. If you try to migrate a current client, create a research pool for a client, and they have multiple ESX clusters, you can't get it. It's so painful to do. The new version that we will be going to is supposed to do that automatically. And I will believe it until it doesn't work.

Its first iteration had some hiccups. It wasn't as streamlined. It crashed a lot more. This version has been way more solid.

Scalability has been excellent. It scales well horizontally. Vertically, you'd have to do a lot to make that happen. It will scale both ways. One way is easier. Horizontally is way easier to scale. It's just the nature of the way the product is built.

On the current version, support is much better. I have a TAM and I have mission-critical support, so I usually get to somebody.

We were previously using a product from CA that CA no longer supports. They got out of the business.

The initial setup was not straightforward. It was not simple, and we had a PoC. We had VMware help us deploy it, and it took them an exorbitant amount of time.

Upgrading hasn't been without its pain. We've had our issues, we've lost some data. There have been some hiccups along the way. We're confident that this next upgrade will be smoother, since it has been getting more stable over time.

The solution is intuitive to the end-user, absolutely. I've created a web portal, through vRA, in which users' specific requirements are built-in. Now, to develop that was not overly fun, but, overall, it is good.

I give it an eight out of ten because it has provided my development team a pure self-service portal. We deploy thousands of machines and reclaim. So, their time to business and their time to market has been improved exponentially.