VMware Aria Automation Reviews

The goal was to bring the automation process to our customers using virtual machines. We were looking to do the hybrid connection with AWS. 

It can run on Linux and several versions of Windows that we have.

It gives you the flexibility to analyze and consume resources.

vRA provides a multi-cloud, self-service, infrastructure-as-a-service cloud consumption and delivery layer. We have a connection and activation between AWS and Azure. 

There is the possibility to use the central policy, especially using Active Directory. You can put this process into the company so someone can follow it. I can put this control on-prem and outside of our on-prem, using our cloud solution.

You can consume resources into the data center and hybrid with AWS.

I can use the console with the dashboard. I also have access to the portal from Azure.

We use the cloud blueprints for Linux. I can use different templates on-premise and on the cloud via GCP. We can use traditional templates or develop new templates, using them to manage integration with the solution.

In the future, I hope to use a portal from GCP.

I have been using it for approximately five years. During that time, we have used versions 6, 7, and 8.

This solution is used by six sysadmins.

This was our first solution of this type.

The initial setup was complex from beginning to delivery. The current version is a bit more complex than version 7 to deploy.

Our deployment took two days.

Six people from our company were involved in setting up vRA.

vRA has enabled us to derive value from the cloud faster. It is five to six times faster than traditional solutions.

It is easy to deliver IT support when compared to a traditional solution. With vRA, I click it, open it, and then it is available in a few minutes. It saves time because a traditional solution might take two to three hours where vRA takes a few minutes. It's a big difference.

We analyzed the market. We also looked at OpenStack, which is similar in its functionality to vRA. We chose vRA because of its integrations. Integrations were more difficult with OpenStack.

I would recommend doing an integration with hybrid cloud. With vRA, this is excellent.

I would rate this solution as an eight (out of 10).

We are using SaltStack SecOps for a rather large fleet of VMs that include a mixture of both Linux and Windows, with many different OS versions for each. It is used to view the compliance of the systems within our infrastructure.

This product brings all of the rich data that it collects under once central view. It makes the remediation of compliance or security issues quick and easy to understand. Being able to see this data allows us to be agile and we are able to make changes on a massive scale, thus reducing the manpower needed to implement changes. 

SaltStack has given us the ability to deal with systems at scale and rectify issues at scale. This, along with the fact that SaltStack is a event engine, allows teams to be able to to creatively attack problems and view problems within our infrastructure.

The SecOps product allows us to see where there may be issues, what a current patch level may be at, and what the recommended patch is.

As far as compliance, SecOps is able to reduce the time it takes us to verify our systems are compliant with policy.

The most valuable feature is the ability to see both compliance and vulnerabilities in a dashboard view. Being able to see that data in one place is a real game-changer. This, along with the rich metadata from our systems allows us to be able to drill down to very specific facts about each and every system. With this level of insight, we are able to make changes both at scale as well as at an individual system or application level.

SaltStack SecOps has the ability to react to events and also allows us to start reacting automatically to issues that might be in that infrastructure.

SaltStack is still growing, and so there are still those growing pains.

Sometimes in order to get the functionality you want, you need to update to the latest and greatest of the software.  For companies that traditionally like to wait for bugs to be found, this can be a bit painful.   Most of the downsides are because the product is growing and is becoming more and more useful, so I can't complain too much about that.  It's evident that SaltStack is listening to it's customers and wants to create a fully functional piece of software.

We have been using SaltStack for three months.

This product seems to handle our scale issues so far.

From our experience, there are not very many issues that we've found with the product in of itself. I'm sure that as we need to scale out, there may be some help/guidance that we need to inquire of support/professional services, but I'm confident that those groups within SaltStack will be able to provide the guidance that is needed to be successful.

Prior to this, we used Puppet/SaltStack open-source. The Puppet solution had scale issues, and SaltStack Open Source didn't have the SecOps product

We did not evaluate other options before choosing this solution.

SaltStack, when viewed in the light that it is an event engine, is a very powerful tool.

Our primary use case for the product is self-service IT. VMware builds it as a portal for self-service and infrastructure as a service, which is what we are using it for, as we roll forward automating and orchestrating more tasks and being able to push things out of the hands of sys admins and into the hands of the users and app admins.

Digital transformation is more of a people problem than a technology problem in many cases. It is getting people used to the idea of self-service people and not having to go talk to the sys admin all the time, and empowering people to get things done. That's a real big thing. That's probably the biggest part of the change that this tool has on our organization: empowerment.

The solution has increased the infrastructure agility from people's perceptions of the infrastructure: Having an actual private cloud or something on-premise, which people can turn to a Window and provision things when they need it. The end result is it appears to be more agile, then the back-end is just the back end. 

• vRealize Automation has improved the speed of provisioning just by automating things, making people think about whether a human really needs to do something or can we make the machines do it for us. It is a lot faster to deploy things now.
• It has improved time to market. Just by improving them, making provisioning increases, time to provision, time to market is a definitely improved. 
• It makes a developer's life easier. They don't have to interact with their sys admins for everything anymore. It's an empowering thing.

We can automate a number of things which weren't automated before, then tie into things like VMware NSX and vRealize Operations Manager. We put things into their hands directly that were never there before, so not only do they feel empowered, but they can get their job done faster.

vRealize Automation on the back-end is still a little complicated. It has a lot of moving pieces, simplifying that from a pure infrastructure point of view would be a good thing. I would then like to have more out-of-the-box functionality and integrations with VMware components.

vRealize Automation stability is pretty good. They are always fixing bugs. The product team is doing a great job of addressing any issues that we might have.

In terms of scalability, vRA has connections to a lot of different systems. It's very flexible and an impressive product. It's almost scarily flexible.

We came to the conclusion that vRealize automation was right for us as part of an effort on our campus to consolidate IT from a real distributed model into a less distributed model, but still retain a lot of local control with departments.

A lot of higher education institutions have similar problems. People want to retain local control, but all the IT is spread out all over campus. This is a real problem. 

As we talked to people, a private cloud was the way we felt we needed to go: To be able to do self-provisioning and self-service for groups who really wanted it. We also wanted to be able to add additional advanced features, workflows, integration points, and approval processes, and vRealize Automation could do all of that. 

We were able to span from our simplest customer to our more complicated customer in the same product. This is why the product appealed to us.

I was involved in the initial setup of our environment.

The vRealize Automation team, when they released version 7 awhile ago, made immense improvements as far as being able to install and deploy the product, which has been super helpful. 

We track vRealize automation versions pretty closely. There are always new features which are of interest to us, bugs which have been fixed, and the upgrade process has been really smooth lately.

There is confusion between licensing levels. There are three different licensed versions of vRealize Automation, and there are different things which can happen in each of them. This is confusing.

vRealize automation really should be a front door to the whole VMware suite of products. The front door to a cloud: Just open it up, and let everyone do whatever they need.

We've been with vRealize Automation for a while now. 

OpenStack was pretty immature at the time that we were evaluating the solution. We also looked at Embotics and their stuff.

There are a lot of good options in this space. There is a lot of competition now. Do your due diligence around it. The VMware solutions stand on their own, but look around. Know what you are after: 

• Are you after infrastructure? 
• Are you after multi-cloud? 

Everything has a different focus.

The solution is getting better. VMware has been paying a lot of attention to it lately, and it's been inheriting a lot of their cloud efforts, user interface improvements, and getting more intuitive. It's a nice thing. To be able to build custom forms and do more things, which directly respond to our customer's needs.

If I had to rate the solution one to ten, I would give it a seven. There is room for improvement, but it looks like they are making those improvements and putting a lot of work into it.

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.

We use vRealize Automation for monitoring and for some administration tasks. Anytime we do upgrades or patching, we just read the reports and it makes our lives easier.

Earlier we used to spend a whole day to collect all the information regarding upgrades or patches. When we introduced vRealize, it reduced the time to between 30 minutes and one hour to finish the whole job.

It has also improved provisioning a lot. Today, if I want to provision one VM, it takes me five minutes. Earlier, it would take a minimum of 30 minutes to go and choose everything. Now, I can just click once and it can provision my whole VM. We also integrated with our Alexa, so even through voice functionality I can create a VM. One of the guys at VMware, along with our partner, deployed that in our environment. If I say, "Hey, Alexa, I need a VM with four gigs of RAM," it will go and start creating it.

In addition, it has reduced our CapEx and OpEx, especially the OpEx values. Initially, we had 25 people to manage it. After going with vRealize, 15 people can do all the jobs and they can concentrate on other improvements as well. It's good for our company.

The most valuable feature is that, instead of doing the VMotion manually, we have automated everything with a script, using vRealize. That means I don't need to think about things like compatibility. The system will do everything for me and just give me a report.

It's very user-friendly. It is not hard to go and find things. There is a one-click Help that you can use to find all the documentation you need to manage it.

From a stability perspective, VMware is number one compared to other products that are available in the market. We have never had any major downtime, after going to vSphere 6.5 and afterward. Earlier, yes, there were challenges, but nowadays it's very smooth and very straightforward.

VMware products are meant for scalability. For example, today my environment is 1500 VDS's. We acquired a company with 300 users. To merge them, I didn't need to worry about anything like hardware because it was already there. I was able to do it on the fly in one shot.

What we like about VMware, especially if I compare it with other vendors, is the support. When we call directly, the technical people jump in and start supporting us. Deploying the solution is, maybe. a three-month process. After that, managing it can be painful. So when a vendor is ready to offer that kind of support, a customer is ready to adopt their solutions. That's why we like VMware support.

We are a VMware shop. We also have Citrix and Microsoft hypervisors but, compared to both of them, VMware is the best for us, for our environment.

When selecting a vendor, price is not the only criterion. The product availability and how much better their support is, are also important.

In the initial setup, I took care of the hardware part, but the software layer and other things were taken care of by my engineers. It was straightforward.

Currently, we are upgrading the environment. Compared to the earlier versions, from my experience, the upgrade process is easier; for example, the compatibility checks. I also don't need to go and find out the resources that are required. It tells me in one report what the current environment is like and, if I want to go to the next level, what things I need to take care of. Based on that I can make things happen.

In a year, I used to spend, say, $10 per user. Now it's $5 per user. That is our approximate return on investment, 

Citrix was on our short list. But over the last ten years, we have been a big VMware shop. We wanted to continue with VMware because we are confident that VMware can address any kind of problem situation, any challenges. But with Citrix, we didn't find that kind of credibility when we did solution testing, a PoC.

I rate VMware a nine out of ten. To get to a ten there are a few areas they could improve, especially vSAN. Performance-wise, there are no challenges, but from a product perspective, it is not that flexible. What we have in vSphere today is very flexible, but vSAN is not.

It's our private cloud platform.

My engineers were able to pick it up quickly and we provisioned and created a private cloud in roughly three months.

Even with the virtualization, it would take us at least three or four days to create a VM. With vRA we have brought that down to seven minutes. The solution has helped increase infrastructure, agility, speed of provisioning, time to market, application agility. Everything got super fast.

It's also easier for IT to support developers. As soon as the developer wants a box, we can pretty much put it out there in a few minutes, instead of wading through a lot of manual paperwork and forms and email boxes and the like.

The solution is intuitive and user-friendly. It only took three months to start a private cloud. It was very good. Guys that didn't have a lot of knowledge in scripting picked up on it. Then I hired a VMware solutions architect and it just skyrocketed from there because he knew the ins and outs.

I can't say what new features I'd like right now because we're looking forward to the stuff that's in 7.5. I need some stick-time on 7.5 and then I can tell you what I want to see in 7.6 or 7.7.

It's very stable. We haven't had any issues and we've been using it for roughly two years. We're upgrading to the 7.5 now.

It scales fine. We've been scaling on storage but we actually have two divisions. We just deployed it to another division to help them out. The company I work for grows by acquisition so the new acquisitions are now getting this pointed to them so they can provision faster, with basically the same standards, instead of doing stuff manually.

Regarding technical support, because we have a solution architect on board, we have a lot of problems but his questions are not normal questions. His questions almost have to be escalated to a developer immediately. He doesn't ask anything simple or even just plain hard. His stuff is nearly impossible.

From that perspective, technical support has not done very well. But we have rockstars on the team and there's no way you're going to get great support because these guys are asking questions that even the rockstars of the VM world are scratching their heads about.

I brought VMware into the company in 2004. Before that it was manual, bare metal boxes.

I was involved in the initial setup but not as an engineer. Before I hired Alex, we had a guy put the stuff up. He did it in a couple of days. It was straightforward and it was functional, it worked really well. Then we got this new guy and he had so much insider knowledge. He worked out of Moscow. He was doing all the work for the all the other customers and we hired him in.

We're on 7.4, we're going to upgrade to 7.5 after Labor Day. Since we've gone live, we've done three upgrades and they've all been really good. No issues.

I can't provide numbers off the top of my head but going from three or four days to seven minutes to create a VM - and that seven minutes can go up to 50 servers wide - means it has worked beautifully.

We evaluated Hyper-V, that was a big failure. We looked at KBM, that was pretty good. We're using Acropolis Hypervisor right now. Everything is still primitive, but among the other ones, AHV from Nutanix seems to be the most stable functionally but it is still missing a whole lot of toolsets that you need. So we're not moving in that direction any time soon.

The other competitors are throwing everything at you for free but they don't have any management. You don't have the feature set that you have in vROps. vRA is much more sophisticated. You get what you pay for with VMware. You're getting all the feature set. Where everybody else is trying to give you stuff for free, they're harder to work with and then you spend more man-hours.

Start with VMware vRA. Other solutions haven't been in the game long enough. You're going to have a lot of custom-scripting that VMware already puts in there.

I rate it an eight out of 10 only because I wish we had a way to get through the technical support department faster. We've been with them long enough - and I've already talked to the sales guy about this - that they should almost have an "express lane." You lose two or three days going through the normal process. It goes to level-one and he bounces it to level-two, to level-three, when pretty much, because we've got this long history, they should know that when we call, it needs to be bounced all the way up to the top. That's just the reality.

VMware Aria Automation is used for automation.

The most valuable feature of VMware Aria Automation is the versatile automation and deployments.

VMware Aria Automation could improve reporting of the policies. They are difficult to customize. We have many policies but they are not able to be modified to what we want.

I have been using VMware Aria Automation for approximately three years.

The solution has been stable and smooth in operation.

We have one customer using the solution. The solution is best suited for enterprise companies.

The solution is scalable.

The support is good.

I rate the support from VMware Aria Automation a nine out of ten.

Positive

The initial setup of VMware Aria Automation was not difficult.

We did the deployment of the test environment.

I would recommend this solution to others.

I rate VMware Aria Automation an eight out of ten.

DevOps is our primary use case. It's performing okay. We're getting ready to upgrade and move into an HA environment, so it will be much better.

The benefit to our organization is time to market. It has streamlined the process so that they can deploy systems, test the systems, and get the product to market faster. Speed of provision is much faster than what we used to manage, especially when we incorporate Day 2 Operations. We can get that into the automation and allow for that to take place, as opposed to the DevOps teams doing that all manually.

It has absolutely helped to increase infrastructure agility - not to its capacity by any stretch, but we're working towards that. It definitely has allowed us to be a little bit more agile.

The most valued feature is the streamlining of the DevOps process, automation and orchestration. It provides the ability for the entire Dev lifecycle to actually be incorporated into a single stream. That's our primary focus.

We still struggle a little bit with the configuration as far as making sure that we have all the endpoints where they need to be, because that's not as agile as we'd like in the back-end. We're working towards that with our DevOps teams to make sure that we're touching the right endpoints and getting the right data.

Also, what we would like to see is a lot more integration across platforms, multi-cloud. I think that's coming.

in general, it took us a long time to get it off the ground. We had a lot of issues upfront and we determined that we just needed to scrap it. I think we scrapped it two or three times before we actually got it built the way we wanted, and we're still not where we need to be. We have had downtime. There have been some issues, but we're also two iterations behind on version. We're getting ready to move to a new HA environment and go on to the newest product line.

Right now, it doesn't scale for us, but it will once we move into the new environment. It will probably scale five years out, especially with the way that we can integrate different endpoints.

Technical support has been phenomenal. Most of the time we get to the right person, but not always. We eventually do because we know who we need to talk to.

Previously, we used a product called LiveManager. It was not across the entire organization, it was just a subset, so there was nothing really prior to this.

When looking at a vendor, the most important criterion is how good a partner will they be? Will they be around? Is it somebody that we can trust and that has been utilized in the marketplace? In addition, is the solution scalable? And then we'll look at cost.

No way was the initial setup straightforward. We scrapped it multiple times. Going through some of the sessions today, here at VMworld 2018, we see that they're incorporating some of the certificate management and so forth. That's where our biggest challenge was.

Upgrading was pretty straightforward. In-place upgrades worked really well for what we've done. There wasn't a whole lot to that. It worked well.

Really, it's all about the initial setup and making sure that it is set up right.

We haven't calculated an ROI but we've realized ROI in manpower.

At the time, there wasn't really any competition when we decided to go this route. It was really only VMware.

In general, I'd recommend vRA but make sure that your framework is set, that you understand what your processes are so that you can fit into the framework.

It's not intuitive and user-friendly but we've made it that way. We've allowed the DevOps teams to incorporate some of their components inside of the catalogs themselves, so we give them a little bit more flexibility, rather than dictating what they need to do. That way, it really runs true to their process.

I rate vRA about an eight out of ten because of the inability to get this thing stood up, initially. We weren't the first to actually do it, and yet, it seemed like we were the first to do it. But because of its scalability, it's a product that we decided to go with.