VMware Aria Automation Reviews

The primary use case is going to be managed services. We're a hosting provider and we're looking to provide provisionable resources across multiple cloud platforms and to be able to support Day 2 Operations. We're trying to fully manage the lifecycle process as well as fully integrate with all of our management end-points, whether it would be inventory, ITSM, or backups, etc.

Eliminating the need for our engineers to do any of this manually, and being able to focus their efforts on the deeper level customizations at the OS level - like installing applications and leveraging things that we would not necessarily want to offer in an automated sense just because of the diversification of the implementation - that has been of value to us.

I personally spend a lot of time in vRealize Orchestrator, so being able to directly tie into the back end on the APIs, I find that to be what really is the most advantageous thing for me.

The solution is intuitive, but not necessarily user-friendly. In particular, it's the documentation. It's a lot of going-through-the-weeds types of scenarios. There is just an abundance of information, so it's a matter of understanding how the objects or the relationships exist, and then, obviously, being able to access that information and knowing how to make use of it.

If there were a tighter integration with either AWS or Azure - being able to have a little bit more out-of-the-box, flexibility-wise, and the ability to realize that - it would help. You're getting out-of-the-box workflows that will literally allow you to provision, but there's a large development gap to cover the use cases that we're trying to provide or support.

The stability of the product has been good. However, I feel like the upgrade, doing more of the infrastructure administration, has been more problematic for my organization. But otherwise, it's been a good product.

Scalability is good. We haven't had any real concerns over that because we have a data center footprint. We haven't had any real limitations on acquisitioning new hardware so, at the rate at which we're growing, we're making the right projections and we haven't really exceeded our availability.

VMware tech support is not terrible. At times I feel like it's hard to get to the proper person to speak with, because I deal with vRealize Automation. It's a matter of trying to get straight to the second tier.

We just had vCenter. Ultimately, we were looking to take that to the next level. We wanted to allow our customers to be able to potentially consume the catalog items and to better leverage things, and to give more transparency to what we can provide. At the same time, we wanted them to not have to go through all of the ticket-raising process. We wanted to be able to allow them to get right to it.

The initial setup is pretty straightforward. I've done it many times though, so at this point I can almost do it without documentation.

Compared to alternative solutions in this space, the feature set of this solution is unrivaled. I can't really think of anything else that has a better management platform, that would be as mature as this software.

Do your research beforehand, because the architecture itself can get you tripped up if you don't properly align your certificates. You definitely have to have an idea of where you want to end up.

There is certainly room for improvement with some of the little things I was talking about, like either better managing of the upgrade process, or just making the infrastructure deployment a little bit easier. It feels like all of the pieces have been automated on one level or another, like with the PowerShell scripts, doing all the IS, Windows boxes preparation. They just need to get it to be more end-to-end.

We were looking to have a single pane of glass (one console) to manage our complete infrastructure. It has helped us integrate having one user interface to manage our infrastructure and application templates.

vRA's multi-cloud strategy is very important to us as a cloud service provider.

The hardware that we use is Dell EMC.

The manual efforts of creating a VM for an individual customer has now been eliminated, e.g., creating a template or blueprint. With Orchestrator, we will take that blueprint and build a form for the customer. All this used to be done manually by an administrator, from a network, storage, and compute point of view. The admin's job is simple now versus the way we were doing it before.

It provides a single pane of glass for management. These types of platforms help us to have a holistic view.

The solution has helped us to automate deployment for developers. Before developers have to build another virtual machine, they can run code with VMware Code Stream integration. They can verify and download code, which really helps our developers be faster.

vRA has enabled us to derive value from the cloud more rapidly. We have seen increased services along with more integrations and catalogs. Now, we can create and update policies faster. 

The solution has freed up our time to concentrate on other things.

• vRealize Orchestrator
• Catalog Service

The policy control is excellent. There are multiple security controls that we can achieve by using this tool. When we were siloed, the policy implementation and control were difficult.

We use the solution’s following DevOps for infrastructure capabilities:

• The cloud templating standard for VMware Cloud infrastructure
• VMware Cloud Templates
• Infrastructure pipelining for continuous delivery
• We partially use iterative development for GitOps use cases, as it is not very good.

These capabilities boosts our administration and management from a technical point of view and help our team maintain the solution. Reliability improved because now the CI/CD and DevOps are integrated and managed under the same team using the same software.

They should concentrate on navigation and service improvements.

We have been using it for more than two years.

From the inception and kick-off meeting, VMware has been very professional from a project management standpoint. They know what their goal is and have all the ground work done. They have a dedicated Project Manager. They know what kind of resources that they need, so it happens in a very timely manner. We don't have any complaints from a VMware product management standpoint, because they are all professionals. 

I would rate the technical support post-deployment as a 10 out of 10.

Prior to using any VMware products, we had Cisco UCS Director. 

Prior to vRealize Automation, we had VMware vCloud Automation Center, or vCAC. It was not a mature product. At that point in time, everything was working in silos and the integration was difficult because the APIs were not mature. After we did the automation upgrade, this embedded everything, so it now has one single URL for accessing all applications. 

The initial setup was straightforward. From a product point of view, it is seamless. The code runs. The software is built into all the appliances, then everything is deployed automatically and integrated with the scripts.

There are commercial implications to start up vRA if a company has no hardware nor knowledge of the product.

Our deployment was one month. Integration and completion of the migration took another two months. Put together, it took us a total of 90 days to implement and start using it. 

For the initial setup, there were four people from my organization involved:

• One SME from compute and storage
• One SME from network
• One SME from application
  
• One technical project manager.

We have seen ROI. The more VMs that we create, the more services that we are creating for our customers. Our delivery times are reduced, so we have more productivity.

The DevOps for infrastructure capabilities has saved time for our developers by automating processes and reducing provisioning time. Task time has been reduced by 40 percent. 

When it comes to IT operations, 40 percent of our time has been reduced because of Code Stream.

From a budget point of view, the pricing is a bit on the higher side.

We did need to purchase some new hardware for the cloud because we wanted to upgrade it.

While we evaluated other options, vRA made it easy and quick for us to go with this solution as an existing VMware customer. With new products, there are training implications. Also, VMware is one of the market leaders.

If you are already a VMware, definitely consider the cost implications of going with vRA versus a competitor.

VMware Cloud Foundation (VCF) is 100 percent mature on the private cloud. We don't have any issues working on it.

We are using other solutions from VMware to extend our network security.

Training is a continuous process. 

I would rate this product a nine out of 10.

Primary use case is, generally, a DevOps lab-type environment that we have, spread across multiple locations throughout the United States. It's meant for a DevOps shop, for our developers to spin up, spin down VMs or applications, and do their testing.

Big-time cost savings on administrative overhead without having to constantly manage virtual machines, spin them up, spin them down, manually. We can automate all of that now and most developers will be able to access a page, landing zone, and do that all themselves, rather than having an admin or someone on the team have to do it for them.

As far as increasing the infrastructure agility, that goes back to the cost savings. Being able to tear down entire development enclaves, essentially by pushing a button or invoking a command line, and spin them all back up, is immensely valuable for an Agile development shop.

It does help, to an extent, with speed of provisioning. But to me, I'm also thinking on the back end, the technical end, depending on which environment I'm on, it might have flash or, in some areas, it might have old spinning disk. So the speed is going to be limited to that as well. But as far as the software itself and using the API calls, it's definitely speedy.

It has definitely made it easier for IT to support developers. That is one of the main aspects of the product line. It's for having that in place, to not have to call up Joe Shmo Admin to say, "Hey, can you go manage this for me, spin this up for me?" You can have a portal for a developer, another user login, spin up the resources, shut them down if they need to, request apps, and all without having to bother your admin next door. 

Valuable features include the extensibility of it and the customization of a lot of the Blueprints, that you can customize, and the community as a whole. There's a ton of community-generated Blueprints that might be (helpful) to set up a design for your automation needs, that you can use as a base and go on from there and make changes to it. That would probably be the biggest thing.

Once it's deployed, managing it is pretty intuitive.

The deployment mechanisms for the initial deployment of the product line lack the appropriate documentation to give someone who's never used it before... Obviously, you want people who are knowledgeable in the product line before they deploy it, but there might be cases where someone wants to go to the website, go to the doc section, and do a step-by-step on how to deploy it. That's really not as brushed-up as other documents I've seen that they have. That would definitely be an improvement on their end.

I haven't had any stability issues with it.

Scalability, I have no issues with that as well. As long as I have the compute, storage, and network bandwidth to support it, the underlying infrastructure is there. It's pretty expandable.

Technical support has been fine, adequate. I have not really had any need for it, per se. It's more so self-taught and people going to training and learning how to use it. If we have an issue, it's generally really rare that we'd have to reach out and talk to tech support. So I don't have a lot of experience having to deal with them on it.

The deployment of it is not overly intuitive. It does require some knowledge about putting it out there and deploying it.

I have had the opportunity to upgrade it and that is definitely not the easiest of things to do, generally. As long as you follow the checklist, and which product line you're updating in the specific order, you won't break your system. But if you don't follow the sheet or "the law," you will definitely mess yourself up big-time.

Make sure that you know what you're getting into, first off, what it's for and what you might need it for because I might recommend maybe a less robust product line for your needs as opposed to something that's more of like a higher infrastructure, corporation-level product line, like vRealize.

Every version, they've updated the UI, scalability, added new products to be able to work with different cloud vendors. Overall, that part of it's fine, there have been improvements from version to version.

As far as automation techniques, like Chef or Puppet or Ansible, it's the age-old thing: Mac, Windows, Linux, whatever works for what I need, I'll use. I don't really have a preference, as long as it works for what I need.

It has saved us a lot of time and work. It helped us to reorganize some of our service lines, so we could be more efficient. For example, on our open system server team, we had 15 people building servers, now we have two.

Once you've learned the product, it is very easy to use.

The entire automation orchestration of it. It integrates into all of the other products that we have, e.g., ServiceNow. 

We have a self-service portal, and it does that very well.

It has a learning curve.

We have no issues whatsoever with it. It's very stable.

We have no issues whatsoever with it. It's very scalable.

We have a technical account manager, but we also rely heavily on VMware's support team, who is excellent to work with.

Upgrades have been extremely simple with their Lifecycle Manager product.

We actually used a lot of VMware services because we didn't want it sitting in the box too long. We had them come in, then they had it up and running in two days. There was a lot of tweaking to do, but it was up and running in two days.

We have seen significant ROI. We used to have physical servers, it took 90 days to get a server, order it, buy it, and get it in. We have it down to 10 minutes, building a server with virtualization, and now that's too slow. So, we let the customer do it at their speed. Therefore, it is pretty much up in a couple of minutes and they have a server.

We usually look at least three other vendors minimum. 

We chose VMware years ago. We have also had Hyper-V and KVM. So, we've had different products from different vendors. However, now, we are down to just VMware, because it's very stable and reliable.

Talk to a lot of different companies and people that have done it. Find out what not to do and what to do. It will make your journey easier.

We are working on a lot of the digital transformation right now. We are working more on the Pivotal Container Service (PKS) product, and a lot of integrations that they're doing with the performance monitoring, the metrics, and KPIs. This is very important to us.

Most important criteria when selecting a vendor:

• Transparency: Be very open with us. 
• Be very knowledgeable about their products, so that we don't have to go through three or four different people to get one answer.

The ability to customize your own portal. We've gotten to the point now where we've used it to create this whole environment for users to be able to self-provision their own machines and get them into networks. We have a very large number of different networks, which means that many options of where they can put those VMs; their own environment.

We used to do everything manually. Up until just a few months ago, we used to have little reviews where, if they wanted a VM, they would come to us, tell us what they wanted, then someone on the team would actually submit the vRA form in an older version of vRA.

Now, the end user can go in and request what they want and do all that themselves, as long as they know enough about their application to get what they need. So, if you're just trying to add a couple of VMs or projects, where you know pretty well what you want, you don't have to spend days getting in line to talk about it, or worse, like back in the old days where you had to spend weeks waiting for someone to get it done.

Since I haven't been able to get as far into version 7, I haven't actually gotten into the guts of it, I don't know if this taking place already. But perhaps more blueprints of common tasks that are already there, so you have more of a place to start from. They may be there in 7, I haven't gotten a chance to look. It would need to have a base of, "Oh, I want to connect and build a VM and have these things," something to start from. Especially for people who don't have the teams that we've had working on it, they could get going quicker.

In the later versions, 6 and 7, it seems very stable. Really, it's nothing within the program itself that ever seems to cause the failures. It's some other component it's reaching out to which tends to have a problem, and that's not vRA at all. It's very good about telling you what's dead. It's usually more that the other application is having a fault and vRA tries to utilize it and gets an error back from the application, which then gets back to vRA.

It's not an even an integration problem. It's the application that it's going out to is not working properly. Then, it lets us know that it's not able to, for instance, connect to a Linux VM to the management product and register it. If it gets a failure there, it tells the folks who are managing the vRA. They tell us, and we go in. We check the management server. "Oh, it's not working. Well, let's go ahead and we need to restart it."

It's the same story on the other side with it connecting to AD. If for whatever reason, there's a problem with it connecting to AD, they'll go look at it. "Oh, this is the main controller having a problem."

It seems to scale up pretty well. If you're talking about how many classes it manages, the older version, the 6.0 series, we actually have it managing all of our clusters across both of our major datacenters; we're talking about being able to build in to dozens of different clusters. So, it's scaled very well.

You can do quite a few at once. Usually, it's more the order of what it's getting back from an independent service. Sometimes, they can step on each other if you put too many off at once, but that has to do with the fact it's trying to request a sequence number; you're trying to get two sequences at once. But that's not really as problem with vRA. It's the way that it was setup to retrieve stuff from these other third parties.

I haven't been the one that's had to call.

Complex. Part of the reason it's complex is that it's like a blank slate. You have to go out there and make your own environments. It doesn't really do anything for you, so if you've got an idea of what you want to do, you have a path forward. But if you don't, if you're just sitting there looking at the blank screen, it could be daunting for some people.

We kind of knew what we wanted and it just took a while to get all those things setup. You have so many different components. Nothing within in our environment was simple, so every management product that we use was probably different than what anyone else would use. So getting all that to work, finding an interface that worked well, that was really why it became complex. It was the complexity of our environment behind it.

So it's not necessarily vRA, it's just that if you don't already have something that's out-of-the-box which says, "Oh, we do all these things..." (I'm harkening back to vCloud Director, because vCloud Director was an all-in-one that did everything).

I think documentation and support are probably the most important things. If you don't care about documentation and support, you can grab a free one and try and build it. If you want someone who is going to be able to answer your questions, someone who's got the documentation already, so when you have a given error, they have it right on their webpage: "This is what this error means. Go do this." VMware's very good about that.

Overall, VMware is very good. It's very stable, very extensible, but it does have a relatively high learning curve. So folks that don't have the resources to dedicate to it may not be able to get very far. I do think it's a very good product, but it's very much a build-your-own product. That's good in other ways.

I would suggest people think about: "How much of this do you want to figure out yourself?" Because even within that process of building your own, you still have that layer of support. If you're looking at which one to pick, pick the one that's going to be able to provide you with advice. We've had professional services working with us on a lot of it at different points in getting it up and running. That's been a very nice driving force towards getting it to completion.

Integrating this tool with other technologies/third-party tools, that are not part of the VMware family, is the most valuable feature of this solution.

If we have a product that allows us to communicate with different products that are not part of its family and make things happen in their application, it is a wonderful thing.

It resembles the benefits of cloud computing and is achieving more things by using only one product.

We can automate the infrastructure services, which in turn reduces manual work, saves time, and eventually leads to more productivity.

It can be used effectively for IaaS and PaaS. Thus, there is only one type of software to be managed by various departments/teams in the organization.

vRA is a very good product, that supports different vendors connecting to it. Currently, it feels like a complete product and I don’t have any areas that need to be improved.

It automatically becomes large, when we need to connect different vendors to it.

It can be made larger, so that the organizations can also use it for physical infrastructure.

I have used this solution for a year.

We did encounter some stability issues. I found the GUI that we use in vRA to be unstable sometimes. For example, there was no proper update of the tasks that were provided. Sometimes it took a little longer to provide new updates.

I have not approached technical support yet.

It was easy to set up this product.

As soon as I started using this tool, I started seeing results immediately. This product is flexible and easy to implement. Its multi-tenancy support makes it more effective for use with different customers.

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 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.