At my previous firm, I worked with vCloud Automation Center (vCAC). vCAC only evolved into the vRA later on. While primitive, it was stable and good to use, though not very customizable.

vRA was the first solution of this type for my current organization.

We had an open-source Automation on the POC basis. It was in the development phase. We didn't deploy due to the security features.

We have used Dell IDPA before. We switched to VMware Aria Automation for more flexibility. It integrates with many VMware products, including Nutanix and ESXI data centers and hypervisor.

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.

I have used Red Hat before, and VMware Aria Automation is better. It is considered better due to its extensive experience in the field. The tool has acquired an existing product in the domain for several years.

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.

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.

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.

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 had a home-grown solution before, but we changed to vRA because of it's simplicity and compatibility with all the tools we use.

For the virtualization part, we have previously used Veeam.

We licensed VMware a long time ago. Now, we are moving from our legacy infrastructure to have a proper, private cloud environment.

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 brought VMware into the company in 2004. Before that it was manual, bare metal boxes.

We switched because we don't want to focus on the cloud management platform. We want to have this resolved and supported by a vendor because we are system integrators and want to supply the services and the knowledge above that. 

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.

From the usability point of view, if you have experience working on other platforms, then you will feel familiar working with VMware Aria Automation, and it would mostly be the same experience. Only VMware Aria Automation's interface would feel different compared to the interfaces of the Other products one may have experienced with in the past. Most of the features are the same in VMware Aria Automation and in the other products that are similar to it.

In my company, we work with other tools, but there are dedicated teams who are assigned specifically to use each product.

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. 

It was a logical and smart decision for us to have this solution in place. It makes sense for my business. We used Orchestrate, the original version. It was the first automated system that could deploy complete solutions. We decided to go with this solution because it was evolving and I just followed the evolution. We switched to vRealize three years ago.

We didn't have a previous solution. Regarding this solution, I don't think the cost was a major factor in its selection, based on what it offers. It was more of, "Can it meet our growing needs, as well as what is the experience that is out there?" Based on those issues, I am sure that is why it was selected.

This was our first solution of this type.

The solution we were using, technically, was ServiceNow but it wasn't as good for our environment. It was very good at creating small cookie-cutter, but not for large-scale.

When looking for a vendor the most important thing is support. Absolutely. If I don't understand the product, I need to make sure I can get an answer as quickly as possible.

We wanted to scale, and these days, everything is being automated. Therefore, we needed a solution that did not require us to reinvent the wheel or create new automation scripts here and there, but used something already built into the system, which we could use to automate our web flows.

There is a war on wasted initiative and on waste of time, more than a concern about environmental resources, unfortunately. The war has been identified on multiple levels, especially deploying in our realm.

When looking to work with a vendor, the important criteria we look for are

• professionalism
• the value of the product for the return on investment
• personally, I look at energy costs and savings as well.
  

We had no automation engine before we started vRA a couple of years ago. It was something that our directors and our management really wanted to get into our environment so we could automate some of these processes that are very redundant.

When selecting a vendor, interoperability - whether it can operate with the other solutions that we've already implemented - is important. Also, how much the vendor is willing to help and work with us to make their solution viable is another factor.

We've been with VMware for such a long time, in excess of a decade, and because of that, I wasn't working here when they had an earlier solution.

Before, it was piecemeal. We had templates. We had some VDI pools for some of these things. It was just a constant revision of that and it would sit idle for too long. So, for the whole pool, if one or two people were using it, great; but if 10 were using it, then it was not the most efficient way to operate.

When selecting a vendor the most important criterion is the relationship, to be honest. Pricing, you can beat people up and have negotiations on it. Pricing, obviously, at some point was an issue, that factors into it. And we need to make sure all the technology fits. But having a relationship with the vendor that can be with you through the good times but also the bad, that makes it worthwhile.

We brought in vRA as part of a new product offering for our customers. It's what we have used from the ground up to provision virtual machines.

We were using vCenter Orchestrator just by itself but it was only used by our internal teams to build for other users. vRA has enabled us to give self-service to all the end users.

In terms of switching, honestly, a VMware sales team came by. We were getting complaints from a lot of our end users on provisioning time, and we would generally get people that were requesting more than they needed because of the time constraints. So we wanted to simplify the process and make it a self-service portal and that was the reason to switch.

It was the best solution at the time we started the project, which was about two and a half years ago. It may not now, be but we are pretty heavily invested in the stack so we don't want to throw all that money away and kind of switch platforms and start from scratch again.

The most important criteria when picking a vendor is their ability to solve a problem that we have; and then second would be cost.

No, we were just doing manual builds and manual deployments. Our management said that we needed to do something, so we invested in vRealize Automation.

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.

We did not use another product previously.

We had to invest in a new solution because we had to react faster to customer demands. Previously, it took a long time from requesting a new virtual machine to provisioning it. Now, it is much quicker for the customer. 

We work a lot with VMware and were using vCloud Director previously. VMware architects came to our office and, after much discussion, vRA popped up as the best solution that fit our needs.

We were not using anything previously. We have been using VMware for quite some time.

We used the Orchestrator that was free, but started to build some automation on top of it, then we needed to evaluate different tools in the market.

Previously, it was just me manually building VMs. 

When my workload started increasing and I started getting more tasks, my manager noticed that it took longer to deploy VMs. At which point, our senior admin knew about this product and suggested that we move forward with putting it into the new environment.

We had a little homegrown thing but that doesn't really count.

When selecting a vendor, if we already have an established relationship with the vendor, it's easier than going to a new vendor and establishing a new relationship.

We weren't using much. This was right at the beginning of when we were starting to automate things. We saw the VMware automation and decided that, since we had VMware, it would be the logical choice. And then we started with Jenkins for a lot of our other operating system features. Jenkins, of course, has plugins that talk to VMware natively, so it was a natural fit.

When selecting a vendor, the biggest thing for us is multi-operating system support. There is the classic divide. I'm on the Windows side. We have a Linux department also. When looking at different tools, something might be better for Linux but we have to have something that will work for both of us. We don't want to have two different tools for two operating systems. Whereas the Linux team wanted to use Puppet instead of Chef, Chef supports Windows and Linux both, better. The nice thing about VMware, aside from it being a lot more OS-agnostic, is that both teams can use the product. One product for both operating systems. That was one of the primary things. We could have a tool that runs great, but it might be a situation where, "Oh yeah, your Windows support is lame." That's the big thing for us, the interoperability between operating systems.

I was doing it by hand.

We did not have an existing automation product.

We already owned vRealize Automation as part of our suite licensing. We did evaluate the Cisco UCS Director product for one month and found it too complex to setup.

We did have a previous solution but I am not able to disclose its name. vRA is an end-to-end solution with all the capabilities.

We knew we needed a new solution when we were falling behind and could not deploy what the business units needed.

Because the way technology was going, such a physical footprint, people are now going virtual. When we realized that, we started getting a lot more virtual questions as opposed to physical, which is a good thing. We realized we needed to start pumping out these VMs at a much faster rate to meet with our demands. That's what steered us toward this product.

We're pretty heavily invested in VMware, so there was no competition.

We built an SDDC environment and we needed a way for customers to consume services out of it.

We switched because VMware canceled the Lab Manager products. So, we were looking for something, then we started with vCloud, but VMware canceled vCloud too. Thus, it has been a very rocky road. My one message to VMware, "Stick with one direction and stop cancelling products all the time."

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

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

We did use a previous product, but integrating it with VMware was very custom.

I just knew where the industry was going. I just knew that it has been moving for a long time in that direction and I was looking for something that we already owned. Also, the team was knowledgeable so that we could use them for orchestration.

We also looked at Cisco. 

The CIO asked us to set up self-service for visiting. We looked at a couple other things. We actually bought a different product first and it did not work at all. It was a Abatix. We did that for about a year and a half, but it just didn't work like it was supposed to.

Then, we came up with a requirements document for what we're actually trying to achieve for that project. Afterwards, we start evaluating the various metrics.

We have tried Cisco UCS Director, which is an equivalent product and we had a hard time. They haven't matured at all. They have so many issues: bugs. We do a lot of deployment as VMware partners so we have done some deployments where the customer initially thought of going with UCS Director, then they changed their mind because of ongoing issues. Then, they finally went ahead with vRA.

To my knowledge, I don't think there was a previous solution.

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

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

We needed a self-provisioning front end. So, this was the best option.

We were not using something else, but internally we were overscaling a lot of different solutions and we were getting criticism from upper-level management.

Previously, I worked in a team which tried a proprietary tool that did a very similar job, and the main reason for going a product like vRA, is that the development cost of it is handled by another company, so they'll maintain that, and we develop and maintain their own code base instead of paying for support from a larger organization. The idea is when you reach a certain scale, paying someone whose job it is or specialty it is to do this kind of work, they'll have a small team doing it, then having the rest of the people on that team might move on. I suppose to operate it into a prize scale was one of the main reasons for switching.

I did not previously use a different solution. This is the first automation tool that I have used.

We knew that we needed to switch to this solution because our customers asked for it. 

We didn't have a previous solution. We were doing manual. We still are, but we're within 15 to 20 days of deploying it. We went with this solution because of the partnership with VMware. We have vCenter, we have a bunch of their products, so it just made sense to try to go with a simple approach.

The most important criteria when looking to work with a vendor are the ability to adapt to us and our needs, and that the vendor be quick on responses.

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

No, we did not.

I was a VMware consultant for years and I saw successes with it in other people's environments.

At a prior company that I came from, we used vCloud Director, and that was a product I loved.

It was something I could not obtain any more, because at the partner level you need VMware to still maintain the vCloud Director licensing. However, our company does have a giant vCloud Director pool now, the one that I work for, but the reason for vRealize Automation was, we can't get vCloud, which I needed a nice lifecycle control management, then we went with vRealize Automation, because it had the majority of the functions that you see in VCD but with just a little bit more added functions at that time. With the integration of NSX, that was something that was key for us. We really needed to be able to provision environments on the fly for them to have very like-for-like scenarios. However, when they're doing their QA testing or pre-stage testings, we needed the ability for encapsulation of those environments to be separate.

That's one reason we saw automation with integration with NSX and VSAN, it was a no-brainer for us.

I had used OpenStack but I would not say it is great. There are a lot of pickups of bad information. I would say vRealize Automation is much better.

We did have a previous solution 15 years ago, but we switched due to scalability.

We were using Lab Manager before but that was decommissioned so this was the next solution. We chose it because it did everything we needed it to do, it was the logical step from Lab Manager.

The criteria for the selection process included that we needed to have a self-service environment for our developers, that Customer Care be able to deploy machines, destroy machines, complete the entire VM lifecycle - and this does it.

We had a previous VMware product called Lab Manager, then we had grown out of that box and decided to go with vRA.

We have been using the older version (VMware vRealize Automation Center).

Yes. Poor vendor support and less stability.

No.

I am not aware of a previous solution. We moved to vRA because the business wanted quick, repetitive deployments.

We used a little bit of everything.

No, we have been using vRA for three years.

This is the first product we used.

We had another product before this, but we moved away from it to use vRealize Automation. The UI, administration possibilities, and the integration of the overall system were better than the former system, which was not up-to-date.

We are highly virtualized, so we like anything related to VMware because we need the visability their products provide. We need to know what is going on, so we can supervise our operations.