VMware Aria Automation Reviews

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 this technology including VMware to support our customers' critical information systems.

The feature of automated balancing which implemented between two data centers solely for the purpose of a recovery plan is valuable.

I'm not wanting any particular feature; but there should be cost reductions. VMware comes at a high cost, and that's why we are in the process of transitioning to a more affordable alternative.

I have been using VMware Aria Automation for the last five years. 

I would rate the stability seven out of ten. Ensuring hardware compatibility is crucial in our platform. However, it posed challenges as some of our servers were not compatible, necessitating extensive adjustments to make them function correctly. Regrettably, this incurred a substantial overall cost, which was quite troublesome.

I would rate it nine out of ten. 

It's quite different. I had a rather negative encounter in the past. VMware provides local support, where you can request them to review and validate a global architecture design, which comes at a significant cost. On one occasion, despite having VMware validate the design, we encountered errors and events that had not been considered by VMware.

Neutral

We used to rely on VMware for assistance when setting up and deploying our infrastructure. The initial setup is complex. It is deployed on-premises for us by VMware teams. In the case of customers, it is dependent on the user's requirements. I would rate it four out of ten.

We encountered numerous challenging use cases that made it tough for us to deploy and handle. While the feature itself is intriguing, the administrative aspect has been quite burdensome for us. So, to sum it up, the feature rates a seven in terms of quality. However, when you dive into it and take responsibility for its ongoing maintenance, it turns into a nightmare. So, I would rate seven out of ten. 

We use SaltStack for configuration management, where we maintain configurations of 150 servers. It also helps with file integrity monitoring. 

We monitor the configurations against CIS standards. We run CIS benchmarks and maintain configurations with higher CIS values for each server. 

SaltStack's features are minimal. 

I have been using the solution for 14-15 years. 

We have had no issues with the tool's scalability. 

We don't have much interaction with the tech support team. 

I rate the tool's initial deployment a five out of ten. I rate adding a new server to an existing system a nine out of ten. It has pretty decent documentation for installation. 

SaltStack is an open-source product. 

I rate the product an eight out of ten. It is a strong and flexible solution. 

Our company uses the solution to have better insights for our on-premises infrastructure. We use some metrics to decide the placement of workloads based on available capacity. We integrate with automation and make dynamic decisions while working on workflows. 

We are moving a lot of our infrastructure to the cloud so are reducing use of the solution. Right now, we have twenty developers who perform automation tasks. 

The operations manager does a fantastic job on the front end because it includes on-premises and cloud use cases that pertain to any infrastructure. The solution has made great progress in integrating all these things together. 

The solution allow us to define our own super metrics. If we cannot an out-of-the-box metric, then we can write and start using our own super metric instead of waiting for the solution to develop something. 

The licensing models are a bit confusing so should be simplified. 

The solution could include more integrations and supportability around the container space. They have already started to do this, but could expand support for Kubernetes platforms and DevOps tools used for Kubernetes clusters or cloud-native development. 

I have been using the solution for seven years. 

The solution is stable so I rate stability a ten out of ten. 

The solution is absolutely scalable. 

We have contacted technical support several times. On average, they do a pretty good job but sometimes drop support requests. There is always some amount of work we do ourselves because we customize beyond the out-of-the-box options. 

Support is rated an eight out of ten. 

Positive

The initial setup is pretty easy and deployment takes about an hour. 

There are a lot of prerequisites to fill before attempting installation. If something is not right, the solution may not work the way it is expected. 

I rate setup an eight out of ten. 

We implemented the solution in-house. 

The solution is pretty expensive. If you can afford it, you should absolutely buy the solution because it provides good workload management. 

If you have oversized or undersized workloads, then the solution catches them and gives you auto-scaling suggestions that save you a ton of money. The solution will even automate some of the work to keep performance and resources at  optimal levels. It saves you from the cost of expanding your infrastructure. 

There are various licensing models that can be a bit confusing. 

The solution is the best fit if you have a VMware infrastructure because it understands the native components. 

We do not see a similar product in the VMware infrastructure that works as good as the solution. 

Often times, when I think of a missing feature I end up seeing that it is planned for an upcoming release. The solution keeps up with development so it is a great option.

I rate the solution a nine out of ten. 

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.

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.

We primarily use this solution to deploy servers. It is run on our own private cloud that we put into place because our legacy infrastructure did not allow self-service. It was operated by administrators and other people. We have a requirement that disallows us to be open to the outside, which means that we can't interconnect with clouds like Azure.

Whether for legacy purposes or our cloud system, we use it for automation. We automate each and every task, such as deploying servers, network configuration, operating system deployment, and others. Deploying a server has 13 tasks starting with creating the VM and allocating storage on the network, to saving a password in a secure location.

Using this solution has greatly reduced the time it takes to deploy a server. It used to take at least one month, whereas now, to deploy a server takes two hours.

Using this product has changed the processes that the developers follow. It changed things for them but I don't know what they were doing before that.

We have used VRA to improve our security posture, in part because we can avoid relying on administrators and other people. The solution has all of the privileges necessary to deploy what we have to deploy. This means that we have better control over our security and the fact that we have automated the process, we know if it's not working, and we know whether everything is done correctly. If you rely on people, there can be human errors, in particular with respect to the firewalling not being properly done. There are specifics such as whether we had more ports open than necessary, or perhaps not enough. By automating everything, our process, including the security, has really improved the way that we handle the communication between the new server and the rest of the infrastructure.

Implementing VRA has enabled us to leverage other VMware products to support IT ops. We already had VMware products in our organization and adding VRA to the environment has helped make better use of those components. This was not our primary driver but it was a good plus for us later.

VRA has allowed us to save application provisioning time, as well. I estimate that our time to provision has gone from one week to one hour.

The most valuable feature is being able to deploy a virtual machine from a low level. We can automate everything including network configuration, firewall configuration, storage, storage attachment, OS deployment, middleware, and so forth.

We use some of the DevOps features for infrastructure capabilities including VMware cloud templates, infrastructure pipeline for continuous delivery, and interactive development for GitOps use cases. I am not responsible for using these features but they have given us a lot more flexibility in our development. 

The DevOps capabilities have saved time for the developers, although I do not have the exact details. I can say that it is significant. 

Multitenancy management is a little bit difficult to do, so it is an area that can be improved.

We have been using VMware vRealize Automation for more than five years.

The stability of this product is good. We use it on a daily basis.

Scalability-wise, this is a good solution.

We have approximately 100 people using the cloud-based part of the solution, whereas about 10 of them use the legacy system.

We do not currently have plans to increase our usage.

We did not have another similar solution prior to this one. However, VMware did help us to drive value from the cloud quicker than the previous process. VRA gives us more reliability and more flexibility, allowing us to deploy faster through task automation. However, I can't explain specific ways that it may have helped our business.

The initial setup was complex, although I wouldn't necessarily say that it is because of the solution. Rather, there is complexity because of our environment. I was not part of the implementation team so I do not know all of the details.

It took approximately one month to deploy.

Our in-house team was responsible for deployment. We have some VMware experts in the organization. Approximately five people are required for deployment and maintenance. There is a support engineer, a solution architect, and we are responsible for the level-three support.

This is not the type of solution we deploy with the goal of seeing a return on investment. It is mainly used to speed up server deployment and infrastructure deployment. As we are in the banking industry, the fact that we are faster to deliver infrastructure or applications is not part of a return on investment. We deployed the solution in order to provide better quality to our internal clients.

When people out of IT were asking for infrastructure, it took a long time and they were upset. We have started to deploy some shadow IT and the driver behind deploying VRA was to show that we now have the tools to deploy things more quickly. 

This is an expensive product and the high price is starting to become an issue for us.

We are currently using version 7 of the solution but we are transitioning to version 8.

I would rate this solution a seven out of ten.

We use vRealize Automation not only to track the utilization of the environment but to deploy new VMs on a regular basis. When DevOps decide they need a whole bunch of VMs spun up for a new version of an application we are already running, we can duplicate everything we've already got, spin them all up, get them running. When they're done with whatever test case they have going on, we can either move them over to staging or we can completely wipe out the entire environment, and that's a lot easier to monitor and manage.

Simplification. It gives us one interface to control multiple environments. It's an easier way to look at how a large chunk of information or data or processors are being used, and what they're being used for.

I would like to see it expanding, growing in all of the cloud-based stuff that they are really pushing towards, and have it be more capable of what it is already doing. But in reality, that's probably our own fault because we're a little bit behind on the version of VMware that we're running. It's probably just that we need to get caught up on our version.

The stability is 95 percent. There are some situations where it gets a little bit clumsy. When it gets really big, when you're dealing with a very large deployment, it can be a little bit difficult, but it's better than nothing. It does a significant job, given what it's tasked to do.

Scalability is probably the best part about it. You can take things that you've already defined, that you've already built once, and build them again multiple times, without significant effort.

I haven't used technical support but my co-worker has, more than once, to deal with issues we were having while we were in the process of setting it up. I was off on other tasks so I never really had to deal with tech support. But, from what he said, it worked out well. They knew what they were talking about, they helped us get it sorted out.

There were other solutions that were used previously, but this one is the main one I have used, personally. Before coming to Bass Pro, where I am working now, it was a lot of VMware on bare metal and dealing with it directly. vRealize wasn't there.

We see our ROI is in terms of the reduced workload, because we can see a lot of things on one place and don't have to spend a lot of time going out looking for them, and in the simplification of deployment. Again, we can go to one place, do what we need to do, go off and work on other projects and come back and it's taken care of it itself.

I give the solution a nine out of ten. Again, that's probably our own being behind. It's entirely possible the newest version is a ten. It's the whole extension, further into more modern technology, but we're not on the newest version at the moment. So it's probably already there and we don't see it yet. We're trying to get everything pulled together between our company and several other companies, to be on the same version. We're in the process of upgrading to the 6.5 and then, hopefully, very soon to 6.7.