VMware Aria Automation Reviews

States, pillars, and custom modules have all taken us a long way in achieving our goals. There is great depth to it and we're looking forward to exploring all of its features.

We are moving from managing a handful of individual servers to being able to manage large scale collections. If we need to fit a particular use case, SaltStack makes it very easy to provision a new cloud instance quickly and almost effortlessly.

There are a number of bugs and regression errors that can make it frustrating at times, but given the flexibility so far I have found adequate workarounds.

The GITFS is flawed and requires a lot more work. We were able to construct our own workaround with local clones of all git repositories that are refreshed whenever a new commit or merge is made. GITFS is a feature in SaltStack which allows the salt-master to directly interact with git repositories. In theory, this is an incredibly efficient and useful capability. However, when implemented, we found server processes and load would escalate out of control whenever anyone made a git commit to the GITFS repositories. We were using v2015.8.5 at the time.

After researching the problem with the SaltStack community, we learned that there were multiple problems in the implementation of GITFS and what we witnessed was experienced by other users. Several SaltStack users recommended not using GITFS. As a workaround, I set up our salt-master with its own local copy of all of our git repositories and made use of the salt event reactor feature. When a git commit is made on our git server, a git hook triggers a salt event. Salt-master reacts to the salt event by performing a pull on its local repository copy. Its not as slick as the intended design of GITFS, but it works very well and has proven quite stable, completely eliminating the problems we experienced with GITFS.

At some point in the future we will revisit the GITFS feature, but for now we are satisfied with the current solution.

I have been using the solution for six months.

We have encountered quite a few stability issues with the GITFS option, but its been quite stable since we switched to our workaround solution.

We have not yet encountered any scalability issues.

This is an open source tool so we find out about fixes, patches, and other solutions through the online community and other online resources, such as Stack Overflow.

We did not have a previous solution as we are new to using DevOps management tools, but we researched others before we decided on SaltStack as our tool of choice.

Initial setup seemed so easy, but there is an art to designing pillars, writing state files, and other customizable structures.

This is an open source solution, but there is a paid enterprise option. If you plan to pursue the enterprise solution route, contact SaltStack for details. The open source option is very approachable.

We evaluated Puppet, Chef, and Ansible.

If you are planning to use the open source version, plan to allocate more project time than you think you need. However, once it's in place it will save you a great deal of effort.

Mostly, vRA is for automating deployment. We use it with templates to deploy and maintain compliance based on the certifications we have. It's a way to maintain consistency across cloud and data center environments. 

We have about 30 to 40 engineers. They are primarily support engineers what we call platform hybrid teams. They create templates and help customers deploy VMs.

The main benefit of vRA is a faster deployment for our customers. Before implementing vRA, we were building VMs from scratch, but vRA allows us to create images, so we can deploy a VM in just a few minutes.

Obviously, it depends on the hardware installed and everything, but the time has been significantly reduced. Time is money. We want to provide as much flexibility in the private cloud and bring our customers as close to the private cloud as possible.

The preset policies and templates are useful. I would say that vRA is one of the best solutions we have. The CI/CD features also look helpful even though we aren't using them at the moment. We plan to get more involved and train our customers as much as possible.

The solution could be lighter. As an administrator, I would like to simplify the number of services I need to deploy. They took a significant step in that direction by removing all the Windows dependencies that we had in the past, but there are still a lot of services consuming resources. 

I would also like to see a richer API. This is true of all VMware solutions because the REST API is not the best.

I have been using vRA for the last three years. We've gone through different versions of the solution.

We haven't had major issues with vRA so far. Generally speaking, all the VMware infrastructure does work. I wouldn't say it's rock-solid, but we haven't experienced significant stability problems on the platform.

Our most significant deployment is two clusters working with a single instance, and it's running perfectly fine. It comprises two clusters of 15 ESXI servers each, so it's a massive deployment.

We do plan to increase usage and deploy vRA for other customers, but we currently have a small number of customers actively using it. Then we have our internal segment of vRA that we connect to a few small customers. But the idea is to expand it and add as many customers as possible.

I rate VMware support eight out of 10. We have a VMware service agreement, and we've used support a few times. It was helpful, but they needed to research some of our questions because our implementations tend to be a bit complex. That's why I don't give it a perfect 10.  

Positive

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.

I rate vRA eight out of 10 for ease of setup. The previous version of vRA was harder to deploy, but they have simplified it considerably. 

After the deployment, daily maintenance doesn't take more than one day a month. There is nothing much to be done once it's set up. The upgrading is sometimes a headache, and it takes longer. For deployment and maintenance, we need at least one network engineer, one platform engineer, and three storage people. That's because our team is split into three different tiers.

I would rate vRA six out of 10 for ROI. It's in the middle. We haven't quite broken it even yet, but we are close.

We pay a license based on volume. I rate VMware vRealize Automation four out of 10. The license is quite expensive. 

The engineering team evaluated a few solutions, but we went with vRA because it is the fastest and easiest.

I rate VMware vRealize Automation seven out of 10. I recommend it for any company that constantly deploys VMs. This tool will help you a lot. 

Without it in our data center, we would have to have a different solution. It's what we thought was the best architecture for our company.

What I like about the software are the performance and the optimization, based on the unit pricing.

It's very stable. And due to the software contracts - we have a subscription membership - we get the newer versions. It's going be around and, from what I heard at one of the sessions today at VMworld 2018, it's going to be around for a while.

It's scalable. We're such a large company, we would never even consider using it if we didn't think it had a lot of room to grow, for the capacity that we utilize.

Technical support is okay, VMware is fine. I work with both Dell EMC and VMware and, of the two, VMware has more of a commitment to us and makes sure that the products are working in the way that they intended and sold to us.

In addition to production-level support, we buy mission-critical support. Mission-critical support makes sure that we get responses quickly. They actually know who we are when we call.

I rely on the Technical Account Manager from VMware to give us the solution for our network or data center. I'm not an SE, so we also rely on our internal SEs to provide us the right version and capabilities. It's customized for us.

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.

We upgrade it anytime we do a technical refresh. It's just like anything else. We're in a complex environment, so to upgrade it, it's almost like you have to migrate the data that is utilized underneath. It's not simple, but it is done periodically.

You should look at the complexity and size of your environment, and when utilizing that background for your requirements, I personally would recommend VMware. You should look at what your deliverables are in this solution. If you do that, you have something you can measure it by, to determine if it's a good fit for you. But I do suggest that you look at VMware as a potential vendor.

I rate the solution at seven out of ten because I don't believe it's a perfect solution. It fits in our data center and it works for our organization, so it's a good solution for us. Yet, at the same time, technology changes so quickly today that a solution you bought three years ago, even if it's upgraded, isn't the solution that's going to fit. For example, we're all going to the cloud or on-prem/off-prem, and because of that, that solution may be in the cloud tomorrow, so I won't be buying it anymore, I'll be buying the cloud version of it because it's utilized through a different service provider.

My most important criteria when working with a vendor are really easy. I evaluate the vendor based on these things: 

• What is their reliability? 
• What is their pricing model?
• Is it a partnership versus our just being a customer that they want to make large margins from?

We use it to automate workloads and it works well. The performance is as advertised.

It automates the creation of new VMs for us, so there is less human error, less work. It has simplified provisioning for us.

It integrates with our backup solution.

It is not intuitive or user-friendly. It's complicated as heck. We actually hired VMware Professional Services to come in. I understand the newer version, which we're not quite on yet, is easier and that the interface is better. But the product is really a profession unto itself. The user interface could be improved.

It's stable. Doesn't die.

We have not yet had to scale it but I understand that the product does scale.

I've used VMware tech support frequently. It's good, always good. They deliver. It's easy to get the person I need.

We did hire VMware to come in and do it, of course. I was not there, in this role, at the time. They came and it works.

We haven't gone through an upgrade process yet. That's on the roadmap. We'll do that before the end of the year but we also have to do vSphere and the rest of VMware stuff.

I don't think there was an ROI attached to the project. We just needed to automate some of these provisioning processes.

I would recommend vRealize Automation. 

If you don't already have experience in it, you're probably going to hire a partner to help deploy it and make it tie into your environment. Make sure the third-party stuff works with it, make sure the APIs are open. We use it to automate. During the provisioning process, we use it to talk to the Infoblox with the DNS stuff and the IP provisioning, and to talk to our Veeam too. Just make sure that the rest of your stuff is going to work with it.

I rate it a nine out of ten. To get it to a ten they should make it easier to use and to understand what it's doing.

We are using it for developers to test code. Our Customer Care uses it to troubleshoot customer issues. We also have a training business unit and they deploy classes for customer training.

We've been using it for four years now. It performs well. It does the functions we need. We do have some issues from time to time. I wish there was a little bit of more maturity out of the product, but it is getting better with every release.

It has definitely increased speed of VM deployment. When a normal server-request would come in, it might take anywhere from three to four days to deploy. Now, within 15 minutes, they can click and have something up and running.

The IT support for developers is nice as well because they are able to manage the environment themselves.

Self-service: Letting the end-users deploy their own machines so the administrators are hands-off at that point.

The user-friendliness is seen in the minimal training that is required to get them up and running, to start deploying machines and accessing.

Something as simple as formatting the catalog in a different way would be helpful because there is no option for doing so. A lot of the contents for the virtual machine, blueprints that you can request, are hidden from view and there's no way to change the view.

It does go down from time to time. We have some issues with the appliances sometimes and we have to do reboots in the middle of the day. That affects the ability for them to deploy. Existing stuff that is already deployed, there's no downtime for that, but it does keep them from deploying at that time.

We have it deployed in a highly-available environment and scalability is nice because we just add another ESX host and then we are able to increase the capacity.

Technical support is helpful. Sometimes they can take a little while to get back to us, but for the most part, we end up finding a solution to cases.

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.

The setup is fairly complex, but we've been using it for a while so I'm pretty knowledgeable about it now. Upgrades are pretty straightforward. We had a lot of problems originally deploying it, with some certificate issues. We had an engagement with VMware so they were able to help us get a proof of concept environment set up as well. So that was helpful.

It's a good solution. The deployment can be complex so I would recommend engaging professional services for setting up a proof of content environment to evaluate it.

I rate vRA at eight out of 10 because of issues with the stability of the appliances. But other than that, it's a pretty solid product. It does exactly what we need it to do and we are happy with it.

• We use it for our own private hosting. 
• We do services for departments within the State of California. 
• We have a large agency where we design and deploy an automation solution around vRealize Automation.

It's done most of what we needed for our customers. However, custom integration had to be done with certain things which are not exotic.

I would like to see more out-of-the-box blueprints and workflows for the rest of VMware's products and its portfolio.

We would like them to continuously improve the product with upgrades, as they have been.

The product is stable. When we used it early on, the changes were so rapid that we had to be careful with versioning. We probably still have to be pretty careful between versioning. The environment includes NSX, as well as vRA. Therefore, we have to pay attention to making sure everything is compatible.

Scalability hasn't been a problem. For the agency where we have it deployed, there are 4500 to 5000 VMs.

The first version that we deployed was not long after VMware had acquired the product. This was with version 6 or 6.2 for a production deployment. There was a lot of work to do with certificates, etc. However, the setup is getting better with each version. 

If you do a deployment for a proof of concept, it is simple. When you start to do a deployment where you need higher availability and more resiliency, then the complexity goes up drastically.

From the customer perspective, the value was worth it.

Be particular about requirements and what your goals are with the customer. There is a lot more to this product than doing a deployment, so make sure you understand the use cases.

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

The self-service portal, as well as the Orchestrator. They are important, because now, especially, I'm getting a lot of public cloud deployment. So the orchestration piece is really handy for day-to-day operations. I'm doing different item consultation management, as well as directly deployed in the public cloud. So those are the two most important features, they are very helpful.

Added features have improved it a lot recently in version 7.03, so you can deploy Azure VMs directly and you can do config management, or you can run scripts. It's really better than it used to be.

Starting from vRA 7, deployment, such as an upgrade. It's so simple, so easy, so interactive. In the past, we had to go through a bunch of operations, but now it's just one click and it can update the vRA client at the back end.

One thing I have seen, although it might just be my personal experience, it's the High Availability. I get a lot of requests and in two different models, the simple model and distributed. With distributed, installation is a pain. I have always gotten into errors when employing a distributed environment, which provides High Availability. So on that, improvements can be made so the process can go more smoothly.

Another thing that's not the best, during deployment, is if we have to integrate managing physical servers. Right now, it's limited to a mature VM environment only. Physical would be helpful.

Four to five years.

No, it is definitely stable.

It is scalable, I haven't see any problem. I haven't done much, but I know that the distributed model is highly scalable and I have deployed that. In the simple model, something like 10,000 operations simultaneously, which is more than enough for most people.

I have called multiple times. I have been using this product for a while, in terms of deployment. I have managed some improvements as well. We are a big VMware partner shop, so we have provided feedback in a lot of processes.

I would rate them as nine out of 10. I don't want to give a 10 because nothing is perfect, but my experience has been really wonderful where the issues have been raised and have been addressed. I have gotten really good technical staff most of the time.

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.

vRA setup now is pretty straightforward in a simple deployment. I do most of the functionality, then you just do service mainly. There was one time where I was working and I had to rip out the whole deployment, but I was able to rebuild the whole deployment within a day. That's pretty awesome.

It's very simple, in a very time efficient manner. It deploys the whole environment infrastructure.

UCS Director is the other main product I have used, but it's always vRA that I go to.

From my experience, people think of a High Available, then they plan to deploy a distributed environment, but I don't see much value. Because if they've got a distributed environment, it gets complex and there are more issues and sometimes people run out of patience. So I advise: Go for a simple environment that does 99% of the workload, then, if needed, you can scale it.