VMware Aria Automation Reviews

We are using it to offer self-service capabilities to our customers, a self-service portal.

One of the huge benefits, of course, is that it gives direct control to the customer. They have a direct knowledge of what they're using. They know the resources that they're taking advantage of and how much it's actually costing them to take stuff. 

It's helping our operations actually get closer to our applications team because they're now starting to build automation around the information they get from the operations teams; when they build blueprints, for instance. So they're able to build these bigger application stacks and there's a better understanding, from both sides, of what's required.

I would like to see easier custom components for it - that would be the best way I could word it. It's more like custom items for it.

Also, the authentication piece could always use some work. They should make it a little bit more dynamic, a little bit easier to deal with large-scale AD deployments. They need to make it a little more enterprise-ready. That is the one thing that kills us. I hate harping on the authentication issue, but it is huge.

We have run into some issues with stability. Primarily, some of the components seem to go out of whack with each other sometimes but, for the most part, it's been stable. It's just that when it fails, to be honest, it seems to fail spectacularly. It has to do heavily with the authentication portion of it. That is one of our biggest issues with it.

Beyond that, vRO can get out of sync with vRA. We've run into that every once in a while. But it's very rare, compared to the authentication problem.

It seems to scale well. We haven't really had too many problems. There have been a couple of issues, but they have mainly been with our external systems, not the solution itself. It has been able to handle the churn workload.

Technical support has been really good. There have been a couple of issues, but they've been fixed, mostly in an update or a hotfix. And they've been willing to jump on calls almost immediately with us.

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.

The initial setup was pretty straightforward. Everything was connected. There were little "gotchas" here and there, but either they were easy to resolve with tech support or the documentation usually had some comments about them.

We have already seen the return on it. We've been able to cut down the cost, the time dealing with the back and forth between customers. We can say, “I've got your server, now you can do this,” or, “Here's your server, it's already been provisioned and ready to go for your app."

Make sure you think out the entirety of your deployment because it's hard to change components after the fact. Make sure that the initial deployment is good. We got that from VMware. They were very good at understanding the size of the environment and they tried to scale it for that environment.

I would rate this solution at about eight out of 10. It has been good but, as I said, there are some faults. Overall, it has performed phenomenally and the support behind it has made it absolutely useful.

The primary use case is to deploy an automated self-service portal for virtual machines for testers and developers to use. It is performing well.

It benefits the speed of our development, and the speed of anything we test and send through to production. It helps us get things to market faster. We're able to get the application out and be more agile with it.

It also raises the caveat for people who like VM sprawl. We have people who don't clean up after themselves.

The self service portal: People don't have to come to us to request something. They can just go fill out a form. Within 30 minutes, they have what they requested.

Once you get in there and start to understand the product, it is more intuitive. However, for somebody coming in from the outside, it takes a while to understand it. There is a lot of terminology. I am the primary admin on it, but I have some guys who tend to support me when I'm gone, and they try to find stuff on it. They don't know the best place to look because some of the terms don't make a lot of sense to them. This is more of a training issue than just getting better familiar with the product. I would like them to improve the product training.

We had a stability issue just this morning. This past weekend was patch day, so it was Monday and patches were done Saturday. The form didn't display properly, so I had to reboot the vRA. Due to the HA, we had to reboot the vRA appliances to get it working again. This might be because the database were ripped out from underneath of it and never reconnected. However, this is not a common occurrence.

Version 7.3 seems to be more scalable than previous versions.

I have talked to some folks out of Denver who do a lot of the vRA support. We also use a partner out in the UK who helps to support us. Both are responsive.

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.

I worked with the UK partner to set up the 7.3 version. The upgrade process 6.x to 7.3 was a significant effort. I'm hoping that 7.3 to the next version is much smoother.

I'm very interested in the integration with Puppet. However, my organization doesn't have the funding for something like Puppet right now. If VMware would integrate that feature set (Puppet) into vRA. That would be very awesome.

Find out what the requirements are and what do you want do with it, then see if it fits. If you're looking to deploy virtual machines through a self-service portal, this product works well.

Most important criteria when selecting a vendor: It meets our requirements.

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.

We use it for deploying, data recovery, and DR.

In terms of recovery, it takes only a tenth of the time that's required compared to a human element. It gives us time savings, which equals cost savings, which equals personnel savings.

Having the visibility of the infrastructure at that level helps greatly with infrastructure agility, application agility, and speed of provisioning.

The most valuable features are the metrics and reporting aspects. The historical data and extraction enable us to tell where the trends are and where contentions may exist in the future.

I also like that it reduces the human interaction and requirement.

It would be nice if, at the director level, the manager level, there was a pretty graphic. They don't like to see numbers and line items, they want to see graphs and scales and real-world pictures. That would support better reporting.

Thankfully, where we're at, we don't have the need for the criticality, we don't need a quick reaction to stability issues. But having the right resources available will help the stability.

We have scaled up. For me and my team, it's very easy.

On a scale of one to five, I would rate technical support a four. It's not always associated with the correct team on the first go-round, but eventually, we get the right people to get the right solution taken care of.

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.
  

Without the right technical expertise, the initial setup can be a little more cumbersome, but with the knowledge and the backing of the infrastructure and the engineering, it's fairly simple.

We have upgraded many times. We know how to do it. It's fairly simple for us. We don't get the admins involved. The engineers take care of it all.

As far as ROI goes, we see it in the human time element in deploying, that's been a really big improvement. Cost savings go with that inherently.

We looked at a couple of other vendors but we went with VMware because VMware is standard. Why not go with the best?

Give it time to save you time.

Our primary use case is to automate the end-user request for either a VDI or a server virtual machine.

It has taken some time to implement vRA. Over the different versions, we had a lot of problems doing some upgrades, but as of right now, it's working really well.

The benefits are that it reduces the administrators' having to manually make all these VDIs and deploy servers. It's really an optimization tool for administration. It helps by reducing the amount of time that administrators and engineers have to spend to provision and manage specific VDIs and servers. It puts that work on the end-user, and then the automation engine does it.

We have integrated our CICD pipeline into an automatic catalog request through some API calls. It can request and provision new virtual machines behind the NSX load balancer straight out of the CIDC pipeline, add those nodes to the load balancer, request SSL certs, and do SSL termination at the load balancer so that it's not encrypted behind the scenes - all of which has really been helpful. So it has helped to increase infrastructure agility, speed of provisioning, time to market, application agility, and made it easier for IT to support developers.

The most valuable feature is the portal where you can assign permissions to specific people to request specific items in the catalog and allow them to provision things for themselves. Or it enables them to request different services that you can create through vRO and vRA.

We do partner with VMware on their beta testing, so we have already communicated some of the features we'd like to see back to VMware. I don't know that I'm allowed to speak about it because it's on an NDA.

Stability has gotten a lot better. However, the vRO aspect, when you have a multi-vRA head, is a little bit finicky still. vRO still needs to stay on one appliance and be one application, because, when you have two, you can't see runs on the other one that are happening when you're not logged into that one.

Scalability is good. We have extended its reach out into our DR site and out into the hybrid cloud. The extendability is really much better than it was in the early days of vRA.

I haven't personally used tech support. I know that we have used VMware's preventative tickets when we're getting ready to do upgrades so that we have support on-call when something goes wrong, because something usually goes wrong.

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 have had the opportunity to upgrade the solution multiple times. The upgrade to vRA 7.3 was painful. The most recent upgrade we did to 7.4 was very sleek, it was smooth, it went really well.

We have seen value from it. We've seen that typically, the people who are provisioning VDIs and server VMs can now utilize most of their time towards other projects and moving the environment forward, instead of just hammering out virtual machines all day.

We haven't really looked at a lot of competitors. We do use SCCM, which isn't really a competitor, but it's a different type of management. It seems that vRA works a little bit better in the vSphere environment because it can connect to all the other VMware products really easily.

Use it, but be ready to invest a lot of time, man-hours, into building it out in the way that you want to use it. It can do a lot of things, and that's one of the problems - that it can do a lot of things. So you have to know what you want it to do before it'll do what you want it to.

In terms of it being intuitive and user-friendly, from an end-user perspective, I believe it is. From the administration and development side, it's a little bit complex. It takes a little bit of time to understand how everything works behind the scenes of vRA and vRO, but once you start learning it, it's kind of intuitive, once you get your feet wet with it.

I rate vRA about a nine out of 10, because of some of the "gotchas" that aren't really well documented. But it is very valuable for us in how we've implemented it and how we're utilizing it.

• Hybrid/multi-cloud infrastructure automation capability
• Configuration management
• Complex orchestrations
• Imperative programming style
• Declarative “states” DSL
• Simple YAML syntax
• Vitality of open source community involvement
• Infrastructure remote control: This fans out from a single command to many (from a handful to potentially thousands of) target machines or VMs. The fine-grained targeting features make it easy to do just what you want on just the infrastructure you want affected, with mechanical consistency. The complex orchestration capabilities allow smart conditional remote control operations on different targeted infrastructure, driven by either, or both, automatic reaction to events, or manual triggers or commands. These are the critical features needed to implement continuous delivery of anything anywhere.

Preparation of Hybris Commerce HY300 training laboratory environments and Hybris Expert Services demo infrastructure went from days of effort down to hours. Reliability and consistency is no longer a concern.

Code maturity is reaching a point where refactoring some internals will be important to maintain the rate of improvement. The software has evolved at a breakneck pace, and there is a lot of legacy code which needs refactoring and cleanup.

This doesn’t affect the operation of the software as much as it affects the learning curve for the open source community. If the code gets messier and messier, then community involvement will taper off.

Major architectural features, like the transport system for example, have been subsequently refactored. When I wrote the review, SaltStack had decided to replace ZeroMQ for extremely large scale operations, and embarked on a novel approach RAET. This appeared by early estimation over engineered and under tested, and lost momentum. Without missing a beat, SaltStack rolled out an asynchronous TCP transport option that was both simpler and more scalable. This was received well by large operations depending on SaltStack. This is a major refactoring win, and a testament to the maturation of the software.

Contributing to SaltStack could be difficult as their internal development processes matured. One symptom observable from community contributor not long before I wrote my original review, was git history rewriting. I’m not going to go down the rabbit hole about why this is bad, but I will say that this hasn’t to my knowledge happened since. I once worried this difficulty would be a barrier to progress at SaltStack, but I am no longer worried.

In particular, I was working with salt-cloud when I authored that review. Since then I have seen considerable attention paid to refactoring code I thought was problematic. They have a mature API deprecation process, which is not 100% executed (things get deprecation warnings, but the deprecated code can remain longer than declared). Even that has been improved, and in the mean time a lot of new functionality has appeared without affecting the quality of existing code.

Conventions around using salt, like formulas, testing methodology, and new functionality like the Salt Package Manager have added to the maturity of SaltStack. These conventions enable commercial and open source contributions to the SaltStack DevOps ecosystem, increasing the rate that SaltStack accretes capabilities without adding stresses to the core development at SaltStack.

We have used this solution for a year.

I did not encounter any issues with stability.

I did not encounter any issues with scalability.

Technical support is excellent.

I have used Chef. Chef is harder to teach, so it is more difficult to build an internal community around the toolset.

There are multiple ways to do the initial setup. The documentation is clear, but could be better organized.

It’s free until you need support. It will deliver a lot of value prior to production exposure, but you should plan to get an enterprise SaltStack license by the time your DevOps iterations can deliver reliably to QA.

We evaluated Chef, Puppet, and Ansible.

Make sure you have cross-functional collaboration between your development teams and operations teams.

Develop configuration as code in parallel with code development.

Use SaltStack to deploy and control both development sandbox environments and also full scale test and production environments.

We use it for about 1,000 clients at Santander Bank in Brazil and, nowadays, we have about 22,000 machines. It's performing very well.

Before, it took us two days to provision new machines, and today the whole process is done in about two hours. Previously, there were a lot of complaints about how long it took to create a new machine. The process was manual. We had to create the machines and put the data on the CMDB but, nowadays, it's super-fast, magical, too easy. About two years ago, the process was based on 15 people. Nowadays, we use three people to manage things.

The most valuable feature is the process it provides us and the time it takes us to deliver to our clients.

I also find it to be intuitive and user-friendly.

They need to help in managing the change of corporate culture involved in establishing the solution.

It is a stable product.

It scales.

Tech support is very good, responsive. They provide us with support in Portuguese in Brazil.

I was not involved in the initial setup but I have been involved in the upgrade process. It was very easy. The whole process was too easy.

I rate it nine out of ten because of the simplicity of the solution. It's so easy to manage

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?