VMware Aria Automation Reviews

What I like the most about vRA: Its seamless ability for users to be able to go pick a catalog item that we have created for them, while they are testing a new version of their code and say, "Okay, I want you to make my old version (based on these blueprints) run, please deploy me - my entire environment."

Whatever we do for the users, we use NSX integration for it, so they can have that encapsulated environment separate from their coworker trying to do the same code testing with the same IP address. Everything needs to be the exact same. That's what we love about it right now.

The biggest feature that we've seen so far is for them to lifecycle it out. A lot of times we have developers that build something, then they forget about it. Now, we lifecycle out after 30 days, so I don't have to waste those resources for a prolonged period of time.

It has made our developers be a bit more agile, instead of like old days, where it was, "Okay, we need a new environment, I've got to spin up the whole thing for them." Now, it's, "Hey, if you need a new environment, go to this URL, click these catalog items, whichever ones you might be working on."

The external Linux script is all automated for the developers. They just need to be able to say, "Hey, I need this new code pulled down," That's all. They don't even have to build their own workflows anymore. As for the VMware side, we can build the workflows for them, or work with somebody in the DevOps team to build workflows. So now all the developers have to do is click a couple of buttons, then they're working and they're on their way.

One of the things we saw in the initial phase was our integration with our development domains, where if we want to have more than one domain tied to it with users, we're seeing that as a struggle. However, VMware has said, some of these features have been worked out with IAM Appliances. So we are seeing a bit of improvement there, though we want to be able to see multiple domains that we can integrate into the same tenant space a little more seamlessly.

There are still some features that I would like to see changed. One pain point we have seen is users are able to set their lease expirations to zero, which means the lifecycle management gets disabled. So, it has some limitations there that we have seen. However, that's something VMware has gotten back to us and said should be fixed in future releases.

It's fairly stable.

There are some things that we would like to see. Maybe they already are in the current versions of 7. We're still running 6.2.5, but we would like to see a little bit more seamless integrations with some of our other products, like our DevOps tools. We use Vagrant or other things where the developer sometimes just wants to do their job through Vagrant CLI to communicate with vRealize Automation. However, we have seen that as a pain point so far.

We have tested a little on how to put in some operations metrics.

For example, if say, "This will run that script, deploy up some more virtual machines, and/or if this will automate that." We haven't had to expand on that yet. We're trying right now to use Automation Center more for development purposes only. We haven't utilized it in a production environment scenario yet.

We have. It was in the very beginning phases when we went to vRealize Automation. It was new for them, so it was a bit painful in the beginning, but lately it's been better.

They're snappy. They know their information.

VMware has really shaped up their support lately. Now, I can get to a intelligent conversation with somebody on their tech side, not repeat steps that I've already gone through. That's huge for us, and that was one thing which we had concerns about in the past with VMware. Those are some of the things we mentioned to them: "We need better supportability of your products." We have been seeing that a lot lately.

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 was involved in the initial setup.

The initial setup for the 6.2 environment was a little bit painful, because you have to have a separate the IAS server and different things, like a Windows server. Now, with the new 7, I know it's all appliance-based, which is beautiful.

It's easy to set up. I have a PoC environment right now we're toying with, and it's a lot more simplistic than the prior versions were. I'm more familiar with the old architecture of it, but I'm looking forward to really implementing the new architecture of vRealize Automation.

The vRealize Suite, it is a very expensive product. However, with all the things it did offer us, in the long run, it made sense for us, because we got to cut down a lot of our public cloud costs due to on-premise solutions.

We did utilize vCloud Air. It was one of the other tools that we did try out.

Now, I don't like to talk bad about VMware, but it was a disastrous product. It was vCloud Director, which I was familiar with, but the supportability was not there. There were some bugs whenever we were trying to do automation and workloads between our on-premise into the vCloud Air. That was the one thing we were trying to utilize, and it just didn't work well.

Then, the other automation solution we were using Chef and Puppet (and other things) for our DevOps tools, but we really wanted to shift more focus to the developers. They don't want to have to command-code out everything. Some of them want to just go, "Click, click, done."

When I went through the first demo of vRA, that's when I saw that this product would be a very beneficial product for our company.

Really pay attention to how you design your blueprints and your workflows, because a lot of developers do not want to do that. They do not want to design their own blueprints and workflow operations. They want it to already have been done for them. Make sure you have a strong relationship with your DevOps team so you can get the most out of this product. Because if you are trying to do it single-handedly as an Operations Center without the go-between, it'll be a struggle to get Development onboard with this type of product. But once they do get on board with the product, they won't want to look back.

Most important criteria when selecting a vendor: Supportability is huge, not to say everybody on our team should be experts in everything they do, but when you do need help, you want to make sure that you're working with top-tier support. I don't want to have to run through the wringer of, "Okay, I got to go through Tier-1, then Tier-2, then finally I can work with Tier-3 (somebody on my level of knowledge)."

vRA's Orchestrator allows you to connect to a huge ecosystem with a huge number of third-party systems to automate any and every IT process that you can think of. It makes it very flexible. Makes it really adaptable as opposed to some other systems.

It allows people to move into orchestration and automation, and most customers want to get into that but they don't really know how. vRO and vRA gives them a step through the door to allow them to start building upon. It gives you a framework, it gives you a baseline to let you build from there.

They are doing well as far as iterating quickly, iterating by often adding small things. I think there should be even more integrations with third-party systems. You have Infoblox and Puppet which great. Let's add Chef to the mix and just keep them coming.

So far so good.

Everything is much improved, especially with vRA's automation 7 and newer, as they move more things into virtual appliances and out of Windows. That's a win for everybody. It's a win for the customers. It's a win for us deploying it. It's a win for manageability, scalability, everything.

Tech support is usually great. As soon as you get a live person you're good. It just depends on the level of support that the customer is paying for. Sometimes that's nothing that we can control, it's just what they have.

It's much more straightforward now that it was in version 6.x., to the Nth degree. They have made it so that you can do either a proof of concept or fully distributed version of vRA with a wizard-driven GUI, which is amazing. Now, there are still some little quirks with that wizard, but it being there makes it much simpler than going it manually and installing each component and linking them all together after the fact.

For me, being a consultant, vendor selection isn't what matters. I want to use whatever is best for the customer. So whatever fits their business use case best is what I'm going to go with, what I'm going to recommend.

vRA does most things really well. There are still some issues such that, if you are going to go 100% cloud, if you don't want anything on-premise, there are some other solutions that might have a leg up.

Use vRA, but it's more about the process than it is about the product. You have to make sure that the users, who are going to be internal IT most of the time, that their expectations are set appropriately. Make sure that you have buy-in from the higher-ups as far as automating processes. You have to make sure you have by-in at all levels.

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.

The most valuable feature is the governance system around deployment of solutions.

It cuts out a lot of waste, unutilized hardware, and improves performance.

Automation: We want to be able to have a lot more preconfigured solutions. Where a user can go into the marketplace, pick out the preconfigured solution, and deploy that straight out without having a highly-skilled employee specifically for this role.

It is fairly stable. We've so far not had any major outages with it. If we have any misconfiguration issues, it's pretty quick to use the automated system to find the problem, diagnose it, and fix it, then you back it up.

It is very scalable, at least for our environment. We have thousands of ESXi infrastructure, and for that, it works well.

Have not really used it.

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.

It was straightforward, but it needed technical expertise in this particular area. For those competent in the field that could help us, we utilized them to set it up.

An in-house team.

We looked at VMware. We looked at AWS automation capabilities, but at the end of the day we decided to go with VMware, because VMware was an all-in-one platform that we could use.

Go for the product, but make sure you have experienced folks on the platform that can help your admins to ramp up and go to market quickly.

When selecting a vendor, make sure:

• They have continuous support.
• The performance of their platform will scale, even if you load up the system to a point.
• The system actually will be able to dynamically detect flaws and prompt the admin to go fix the flaw.

The most valuable features are:

• How it takes what we used to do in the same process as manual steps, and automates them, such as creating servers.
• It's self-service for creating your own virtual machine.

It's shortened down our SLA's for VMs. When vendors request an application for various VM's, we used to take a two week process (approximately) from building a VM, QAing, and building it. Now, it can be done in a matter of two days, at max, thus, shortening the process.

Implementation directly with our SRM product, because we know what the other products are out there that VM is offering, such as Site Recovery Manager (SRM). There are ties which you can customize to put them into that, but it would be nice if it came as an out-of-the-box feature.

It's very stable. Just like any other project, it does have its quirks and kinks, but like anything else you work through it. You have to customize it to get it used to your environment. There are growing pains.

We recently went through two or three upgrades, and now we're doing an upgrade for the most recent version. In that regard, it's pretty scalable. The way we can actually manage our virtual machines directly through the interface is somewhat of a gain as well.

They are very knowledgeable of their product. This all goes back to customizing our kind of needs, because everybody's needs are not a one size fits all. You kind of have to customize it to fit to your environment. They have been helpful with this. Also, when we run into any issues, which have not been many, they've been very helpful with resolving them.

We actually have an onsite resident, which helps as well.

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.

It was a pretty straightforward implementation, but it was just mostly customizing it. We house somewhere around 3000+ virtual machines in our environment. It's hard to customize for that large of a footprint. We have a team who handles the automation piece, since we have such a large virtual footprint.

Most important criteria when selecting a vendor:

• Look at the support they provide, the backing of their product, and so on.
• Have a big company name, like VM, where they have stability.
• Fitting the your needs - nobody wants a product that they are never gonna use.

If you get a lot of virtual machine requests, this is the product to get.

The most valuable features are:

• Seeing how the actual servers are responding
• CPU times
• Memory times.

This allows us more scalability in terms of different applications in using specific servers.

Resource management. That's the biggest thing. We're not scaling solutions too much larger than what they actually should be. We can actually take back a lot of the memory with some of the solutions that we're not necessarily using overall. This kind of management is probably the most beneficial.

There is some performance lag, but that could be on our end.

Great. I haven't noticed anything.

I would say great. For different solutions, it allows us to scale.

I haven't. My company has though. I haven't heard anything negative with it. It's all been positive.

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.

I was not involved.

Look into it heavily when researching similar products, especially if you're looking in terms of budgetary issues with different servers or how you're gonna scale something. It allows you to have pretty concrete data to show to your management.

I wasn't a part of the decision-making process. I know VMware was one of the top choices.

Make sure, and this solution does this, it touches on everything you want to see in a solution in terms of CPU memory. This is such an all-encompassing solution.

Someone that's willing to be a good partner with us. Someone who's responsive, and who when they set us up, or when we enter a partnership, they don't just disappear afterward.

• Web front-ends
• Orchestrator scripting engine

We're automating a lot of OS builds. The front-end gives us a way for users to go and request those services and the orchestrator pirate lets us automate a lot of the functions involved in them.

It's like a streamline deposit made more available.

I want to see them get rid of the IS component and make it a VMware appliance. There are a lot of requirements for Windows servers, which is not good for our environment. This makes configuration and installation tough.

It's cumbersome to set up. It requires a lot of Window servers, which we don't like and the external load balancer configurations, which we also don't like. But overall it does have an HA solution, so that's better than no HA solution.

We got VMware resources to guide us and help us with the deployment.

It has an HA configuration, which is pretty good. It could be better.

You can scale out deployment so that's good as well. You can just tack on more Windows servers. That's good for scale out.

I'd give them a seven out of 10.

We get a lot of run around in terms of technical support. Usually, first tech we get can't help us. We end up going down the pipeline to get someone that can.

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.

I was involved in the initial setup. It was a complex product.

vRA requires a lot of development work. It's not something you just set up, then it works. You have to tailor it to your environment and develop stuff to do with it. There is a lot of development effort with the product.

If you are looking at implementing the product, hire a Dev team.

No, we're using vRA and other VMware products.

They're the pioneers of virtualization.

The vSphere stack and all their other products are integrated with our core stack, which is vSphere. That's really the big reason why we like all their other products.

It's cut our server deployment times down from weeks to an hour.

Because we're running on the older version, we've actually had a lot of stability issues. We're currently evaluating either upgrading or integrating the new version, but we haven't made the decision yet.

Because we're on the older version, the scalability is a lot more complex than the newer version. We actually built bigger than we needed when we deployed it. I do know from testing it in our lab that the scalability in the newer version is pretty robust.

Excellent. They're knowledgeable and you're able to reach the right person.

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.

I was involved in the initial setup of the older version. It was extremely complex and difficult to get right.

In evaluating the newer version, it's super simplistic, and they did a fantastic job of all the changes made to automate the automation pool.

The corporate government works a little differently. We had put out a set requirements and other vendors come and bid on it, then we pick the vendor who best met our requirements and has the lowest cost.

No, we were just doing manual builds and deployments. We did not consider any other vendors that I'm aware of.

Make sure you deploy the latest version.