VMware Aria Automation Reviews

We use it for monitoring.

The benefits include a smoother migration to cloud services and access to new features, but overall, it doesn’t seem to have a significant impact.

I like its capacity, the self-service portal, and operational automation. The most beneficial feature is that it saves time when creating new virtual machines, deploying security measures, and writing infrastructure code, making things easier and faster. We have a standard we follow, reducing the time spent repeatedly rewriting everything.

The integration is a bit tight. I need the right package to use it properly. The new automation processes for VMware are messy, and support could be better.

We’ve been using VMware Aria Automation for six months.

Overall, it’s stable.

I don’t have complaints about its scalability; it seems fine.

When we call support, responses take a long time, and urgent issues can’t wait days for a reply.This leads to operational troubles.

Negative

We evaluated four different options, including Nutanix for virtualization and Ansible for automation.

The experience was not straightforward; we used the Gradios version before, so it wasn’t a new experience, but it was typical.At first, we received direction from VMware technicians, but after the first month, we had to handle everything ourselves. It took longer than expected because of hardware issues and is not fully complete yet.

I would rate it high because, compared to other solutions, VMware’s pricing is quite expensive. VMware products have become significantly more costly in recent years, leading to higher costs.

If you can afford it, I would recommend it. Its integration with virtualization and high availability features make it valuable. I don’t see a direct integration of AI; it seems more about resource management and efficiency than advanced AI features.

Overall, I would rate the solution an eight out of ten.

We use SaltStack to configure virtual machines, ESXi hosts, or any Windows product.

The product’s most valuable feature is its ability to provide environmental security.

There could be better initial documentation for the product.

We have been using SaltStack for six months now.

It is a stable product. I rate its stability an eight out of ten.

The platform scales well. We can configure multiple systems. I rate its scalability a ten out of ten.

We can contact VMware support. But we find out the solutions ourselves. Although, its online documentation needs a lot of improvement.

Negative

We have deployed SaltStack on a hybrid cloud. It is difficult to set up and requires one executive to operate the deployment. I rate the process a six out of ten.

It is an open-source product.

The product works great for changing configurations. I recommend it for the DevSecOps environment. I rate it a seven out of ten as it is not user-friendly.

VMware Automation allows you to deploy your blueprint on-prem or on a public cloud, so you have a consistent, unified service catalog.  Users can request revisions to our infrastructure, applications, and resources from one portal on the private or public cloud. We only have one or two people with the knowledge and experience to use vRA and the vRA Orchestrator.

Aria Automation gives you the flexibility to deploy tenants with customized blueprints for permissions and policies. Version 7.8 consisted of multiple products, so you had to deploy a lot of virtual machines on one of the servers.  Starting from 8.6, VMware consolidated all the components into one Linux appliance. This allows the option to use vRA or DevOps capabilities.

They could extend the ability to use vRealize Orchestrator Automation for organizations with multiple tenants. It should be easier to operate and extend different capabilities from vRealize Orchestrator. Currently, it's difficult to build advanced services in Aria Automation because you need to use the vRealize Orchestrator. 

I have been using Aria Automation for about three or four years

Aria Automation is stable.

You can deploy a single node or an enterprise cluster consisting of three nodes. 

I rate VMware support six out of 10. 

Setting up Aria Automation is difficult. The complexity varies depending on the environment size and infrastructure. It has a lot of prerequisites. For example, it has to have a firewall prepared before installation. Aria Automation is deployed through an installer called vRealize that integrates VMware identity manager, Aria Automation, and the vRealize Lifecycle Manager. The deployment takes about three days.

I rate VMware Aria Automation seven out of 10. Aria Automation needs products like vRealize Orchestrator to extend its capabilities and accessibility. If you are using Aria Automation by itself, you won't get the features you want, and the license cost is high. It needs to be cheaper, easier to use, and have more native capabilities. 

Before deploying Aria Automation, you need to know the prerequisites for the nodes. Each appliance consists of multiple components, and each has its own log. You need to understand your use case and what you want to use so you can customize the services you need to provide. For simple services, you can use only Aria Automation. If you need to customize advanced services, you will have to purchase vRealize Orchestrator and also CI/CD DevOps tools.

We use vRealize Automation for all of our court locations and the customers are able to, on any day of the week, 24/7, provision VMs at will and maintain them.

As opposed to the old days where customers put in a ticket and they waited three or four days to get a server provisioned for them, today they can get servers provisioned in five minutes. So, the time to market for our customers is much better, much improved. It's multi-tenanted, meaning one court customer doesn't see the other court customer. They're very happy about that.

For time to market, it's absolutely incredible that a court customer can come in and, within a few days, have the service provided to them. They can then spin up one or 100 servers. Before, it would take them six months to a year to get there. So, for time to market, there are incredible savings. And there are cost savings from their perspective as well. They don't have to manage HVAC and space and cooling and all of those things that they used to have to do. Today, all they have to do is provision a server and manage their users, which is what they should be focused on.

We don't know what they run, we don't manage them. We just provide the infrastructure and they are saved from having to purchase infrastructure, having to purchase licensing, and having to maintain servers internally. So it's a win-win for the courts and for us. We love the product.

The most valuable features are that it's multi-tenant and the ability for scale.

From a customer perspective, they log in and they have Catalog: what services are available to them. They simply click on that and then there's an option: I can have a Linux server, I can have a Windows server. They select it, configure it, how many CPUs, how much memory, how much storage, and hit the button, submit. It's that easy.

I would like to see more integration to do things like DR, from a court perspective. Today, for us, SRM doesn't scale because each of our customers has a local vCenter environment as well as the vCenter in our environment. So we can't get SRM to scale to the point to which we need. From an integration perspective, DR inside of that would be good.

Also virtual desktops. I know you can spin up virtual desktops in vRA, but they're not thin-provisioned. I don't know if that's because the other product, Horizon View, is there, but it would be nice to see more integration. I know NSX is getting more and more integrated. We talked a little about vROps. I see that integration coming in.

But for vRA, DR would be a service we'd like to be able to offer to the customers, and it should be integrated, in my opinion, in vRA.

We scale, we have 180 plus customers in the environment and we have courts with as few as maybe four servers and as many as 80. So it's a very diverse range of systems and they absolutely love it. It scales great.

vRA is pretty reliable. We use technical support more for upgrades.

In the event that we've had issues, cluster-wise perhaps, within VRA, we've had to use technical support, but very seldom. I can't point to an outage related to vRA. The outage is probably something else related to either NSX or vCenter itself, perhaps the PostgreSQL Database is filling up. But vRA itself has scaled incredibly well for us.

When we've needed it, the support itself is good, very good.

You have architectural design questions that you have to address. We have multiple sites, multiple data centers. One of the fundamental questions is, how do you get HA in vRA? Do you have active-active, active-standby? Today, for vRA, we deploy it out of one site and we use remote execution managers at the other site. We're kind of in an active-standby mode, if you will. We're semi single-point-of-failure, in that respect. We probably should move to get an active-active scenario, but we're not there today.

But the setup was not too bad. It's nothing like a vROps, for example.

vRA is great. If you're looking for a multi-tenanted solution that is very easy, from a customer perspective, to use, and make it seamless for the customer to actually get what they're looking for, i.e. a server, developers love this. For the customer, from the time to market and ease of use perspectives, you can't go wrong with vRA. It's that good.

I would rate it at about nine out of 10. If they would integrate DR, that would bring it to a 10.

We are mainly using it for automation. Our main use case is providing in-house kind of cloud capabilities to the enterprises so they can utilize automated provisioning, backups, etc.

Different customers have different versions. We are probably using versions 6 and 7.

One of our main customers is a big tech company. We have created automated labs for their products. They have these events in which they wanted to do training on the event site, and they wanted to have on-the-go labs. We utilized vRA to do that. Another customer for whom we are using VMware vSphere and vRA is a government entity. They have other customers or end-users that are different departments of the government. They have provided them cookie-cutter and templates to provision the VMs and do the backups. So, they are using vRA along with vSphere and the stack to provide a kind of government cloud.

We use the following DevOps for Infrastructure capabilities: the cloud templating standard for VMware Cloud infrastructure and infrastructure pipelining for continuous delivery. Through these capabilities, we have achieved more control, more monitoring capabilities, and more efficiency in terms of delivering solutions with much more confidence and less number of failures. There is also less strain on our human resources, so everything becomes more easily manageable. These features have saved time for our developers. They have saved 30% to 40% of the time. Using DevOps infrastructure has definitely improved reliability.

vRA has helped to automate deployment for our developers. These automatic deployments have saved time. It has improved the self-service kind of deployments for the development teams. We have our own internal data centers, and we are also doing a lot of customer deployments. In both cases, it has reduced the time that they have to spend communicating internally with other people. They have these cookie-cutter operations that they can utilize. They can provision their own stuff or deploy their infrastructure pretty quickly. So, the dependencies are reduced, and the developers can focus more on their own part rather than calling the infrastructure team to provision or automate something.

We have been using VMware within our organization and for our customers, and vRA has enabled us to leverage existing VMware processes, systems, and training in our organization to support IT Ops.

vRA's automated processes have reduced infrastructure provisioning time. There is about a 60% reduction of time in infrastructure provisioning. 

Our application provisioning time is also reduced by using vRA automated processes. We have Ansible and other stuff with vRA. There is a 60% to 80% reduction in time for application configuration. It has also reduced the time to market for our apps by at least 40%.

The automation part is most valuable. Because it is a VMware product, the automation capabilities that come with vRA are pretty extensive. We can integrate and build a lot of features on top of it, which makes it extremely useful for us.

We have been using it in our own data centers and for our customers for almost five years.

It is pretty stable. This is based on what I have heard or seen for different projects.

I would think that it is scalable. Our clients are usually looking for somebody who can deploy and configure their environments or provide some kind of managed services support. Around 10% to 15% of our customers are on VMware vSphere automation and vRA automation. Internally, there is a 25% utilization. We are planning to expand its usage this year, and we will see how multi-cloud automation can be utilized. We will try to implement things or use cases in a virtual environment, and then we can resell those use cases, provide support for those use cases, or give training to the customers. 

I have not worked with them myself, but our customers have VMware support, and we use their TAC accounts to raise an issue and get support.

Previously, we were mostly using manual processes. The reasons for implementing vRA were more control, visibility, and flexibility. We wanted to move away from manual, human intervention-based processes to automated processes, which would also provide more stability.

Its initial setup is of medium complexity. It is not too straightforward, and it is not extremely complex. It can improve. There are technicalities that are involved.

We have done some deployments that have taken us less than a week. We have also done deployments that have taken us months. On average, it takes three to ten days.

The deployment strategy depends on the requirements. We like to have a repeatable model, but most of the time, customers have different needs. Wherever possible, we utilize a repeatable model. 

In our organization, we have five people who are dealing with VMware infrastructure. Our senior solutions architect has different kinds of certification in VMware solutions. There are two senior engineers and two junior engineers reporting to him. So, we have a team of five people for our internal management and external deployments.

We have received a return on investment. We are a lean team, and we are able to deliver more. We are able to manage more than what we could manage previously, and we don't have to have lots of people. We are also saving a lot of time, and it is also providing us more visibility.

I don't think we evaluated other solutions.

While implementing a solution like vRA, the most important thing is to understand why you're using it for a use case. If you want to implement a solution to do automation, I would suggest seeing what kind of integrations it provides with different endpoints and plan around it. vRA provides pretty extensive integrations. My advice would be to first just understand why you want to use vRA and then have a strategic roadmap implemented. You should start with a basic implementation and then go on top of it.

vRA has enabled us to derive value from the cloud more rapidly, but we have not yet fully realized that value. We are planning to use the multi-cloud features more as we go along. It is in the roadmap that we have for this year. Similarly, vRA has enabled us to manage the cloud easily through its entire life cycle, but we have not exploited it fully. We have not utilized it for multi-cloud environments. We have mostly focused on the on-prem environments and on Azure and AWS to a certain extent. We are working on utilizing vRA along with other automations from our tech cloud. There is an internal roadmap that we have for this year in which we want to monitor multiple multi-cloud environments, not only for our own staff but also for our customers.

We have not used VMware Cloud Templates and iterative development for GitOps much. We have not used the multi-cloud Infrastructure as Code yet. We are planning to use it.

We have also not used vRA much to extend our security footprint into the cloud. We have done it here and there but not fully and not to the extent that I am happy about.

I would rate vRA an eight out of 10.

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. 

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.