VMware Aria Automation Reviews

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.

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.

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.

We are looking at doing automation at the enterprise-class level.

The product is really excellent. VMWare provides a complete ecosystem. And it covers multi-cloud, which is where the market is going. We are able to cover compute, network, storage, etc. We have been able to take it to the next level where VMWare is providing the validated designs, VVD. 

Let's take compute, for example. At compute we have seen, in a session here at VMworld 2018, with AWS or Azure or GCP, you are able to create an abstract layer on top of it and manage it. That's what automation at the cloud level is.

Similarly, when we are talking about hypervisors, whether it is Linux or Windows, we have been able to create hypervisors and to deploy the solutions on the same server. That's the kind of automation which we are bringing in. It's a complete solution.

Looking at the desktop level, desktop virtualization, VDI-related solutions are there.

A lot of automation issues are coming up in the market. Customers are looking at containers, among the new technologies which are coming up. How we can integrate with the multi-cloud? I can see, in the sessions happening here at VMworld 2018, that all these things are getting addressed, but the container-related solutions are something I am looking forward to.

We are thinking about containers. PKS is one of the issues. We would like to do a container service. In addition, the VMware Kubernetes Engine is something which we are focusing on.

From the storage perspective, we will bring in vSAN; NSX-T from the networking perspective. But what is the is the overall solution? How would this compare with what the Cloud Native Computing Foundation is providing? That is something which we have to look at it. 

VMware has something called VVD, VMWare validated design. How far the container solutions are going to be a part of that is also something which we'll be looking at.

It is absolutely stable, at this stage. We are able to meet our customers' expectations. VMware is a company which has already grown up. That's the reason we're opting for these new technologies, even though it's taking some time. Even if it is going to be a little bit slower, it's going to be stable. We trust VMware.

I have not used technical support but I have heard it is good. My engineers say that it's good.

Our customers feel it's very costly. But when VMware is providing so many things, the cost is on par with what they're offering.

It's really about whether you want to buy the full solution today and utilize it, or if you want to bring in a lot of people, integrate, and spend on that. Overall, if you look at five to ten years of time, either you buy the full solution or you will bring in the people and try save some costs, but it is going to be almost the same.

If your requirements are on par with what VMware is providing, we would recommend it.

I would rate VMware solutions, overall, at eight out of ten. Whenever we talk about VMWare, people only think about the hypervisors, virtualization. But it's not only about the virtualization at the compute level, it's also at the storage level, at the network level, at all levels. It's about a complete solution. It creates an abstract layer on top of all these things.

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.

I think the ability to create blueprints and define our lab environments and vRAs. It's really easy for anyone to use it. Just drag and drop VMs and all these other components into the Blueprint Composer.

I think having the ability to create different tenants, having a catalog items, and having a different user base go in there and having them pick from the specific items that they want; have them be more living in control.

The additional features I would like to see are better integration with Horizon, or actually integration with Horizon since it doesn't seem to be existent, more integration with NSX, and also better integration with Code Stream.

So far, it's been stable. Although, we have a few issues with it. Mostly, the issues that we encounter have been integrations with Horizon, integration with NSX, and a little bit the integration with Code Stream as well.

Scalability is great. They allow you to deploy in different situations and scale up. If you want a bigger vRealize Automation installation, you just spin up more of these appliances.

They are very responsive, but I for one of the issues that I had, they were not able to answer my question. I had to get into more of the low level of the application and try to figure out a solution for it.

It was somewhat complex. The documentation is very long, and I was able to install it based on a blog that I found online. Someone had already previously installed it. They went step-by-step. I thought that was more useful than the documentation.

No, we were happy with what they demoed, and what they showed us.

I think the support and the feedback that we got from the salesperson, the response time that we got, we were really happy with it.

I give it a six out of 10 because we still haven't met what we intended it for.

It works very well just spinning up VMs, creating blueprints, for doing some of the basic stuff. But doing some of the more advanced stuff, it still needs a little bit more work.

• The agility that it offers.
• The flexibility that it offers.
• The scalability that it offers for us to serve our end customers.

That's really helpful.

At this point in time, it's support for multiple platforms. It already supports certain platforms, so extending that to the multiple cloud platforms and services, that's where we are looking to go.

We have been using it for the last couple of years, and it has pretty much worked for us without any issues.

It is very scalable. We are currently using some 20,000 workloads across multiple customers.

VMware support has been very helpful throughout the journey of using all of the VMware products. I rate them five out of five.

The basic setup is pretty easy, but then into the next phases it all really depends on what services you want your end customers to subscribe to. Depending on that, the complexity will vary.

The most important criteria when selecting a vendor include:

• What is it really offering, for us as a customer, and for our end customers?
• How much flexible they have in understanding our needs and accommodating those needs.
• Support: How much support are they ready to offer, what are their capabilities in terms of getting us live, through the product lifecycle, and then helping us manage that product as we move along?

I think vRA stands at the top of the list of the products that we rate, because of the problems that it has helped us to solve, in terms of providing the services to our end customers. I think it has helped us a lot.

Remote execution in itself is a big time saver at any scale.

For example, a particular incident happened at one of my previous organizations. We had to do a PoC on a lot of servers, where traffic was to be generated from a few hundred machines (something like 'bees with machine guns') and would allow us to benchmark one of internal components.

So, before we began working on it, I suggest the use of SaltStack because of its remote execution. They could easily start generating traffic from a few or all these servers and then get a good feel of a Flash Sale in Ecommerce.

Eventually, one of my colleagues was assigned this task and he used SaltStack. He liked the way SaltStack (on the entire cluster) was up and running in a few minutes, and also gave him flexibility to generate traffic, make config changes, etc. on the fly.

Currently, most of our configuration is in SaltStack, so scaling up when necessary with or without Salt Cloud would be real easy.

Traditionally, the team here expects the use of Golden AMIs for scaling up the infra, which, though useful, has its limitations:

• Security updates to the OS are the biggest concern.
• Non-standard configuration on one server would also cause some serious issues if its AMI is used by mistake in scaling up.

If, instead, we push configuration to new servers during scaling up, then we fix those issues.

And, I was also considering the fact SaltStack gives near flat-line performance (for both remote execution and pushing changes through states), whether the infra size is 10 servers or if it has grown beyond a few hundred. So, that is at least one area that we need not be worried about.

The configuration management is at least one aspect that would take care of itself (not considering redundancies, reporting, etc. required for SaltStack here at the moment).

Personally, I feel that SaltStack has many renderers, but the documentation was a bit lacking (in particular, for Py it was close to nothing) when I was studying it up a few months back.

Salt supports multiple renderers Py, PyObjects, etc. (https://docs.saltstack.com/en/latest/ref/renderers/index.html#multiple-renderers). These allow users to write states in JSON, Mako, MsgPack, etc. Py renderer allows us to write states in Pure Python.

I had many scenarios where SaltStack didn't have enough functionality at the time (it has been added in recent releases). For instance, I was trying to add an instance into ELB as the last step of orchestration. But, Salt didn't have anything to support it. So, instead I went ahead and wrote a small state in Py renderer.

There are also cases where Jinja + YML is not enough and to DRY up the states, one has to use either the Py or PyObjects renderer. I prefer Python, as you then don't have to look up the syntax of a particular renderer and a simple Python script would suffice. The catch here is that Salt expects output in a particular format and initializes its internal variables in a specific format, too.

I spent most of my time figuring out how to make this Python script work with SaltStack. Any such functionality that’s missing from SaltStack can be easily implemented using the Python (Py) renderer. So, if the documentation around renderers is improved, it will help anyone with a very specific use case.

I have used it continuously for the last year, and sporadically for the last three years.

Sometimes, salt-minions do start consuming very high memory, but I've generally seen this to last just a few moments or at most a minute. On a production system, this might cause an impact on serious loads.

Additionally, if many of the servers in infra are down, and you bring all of them up simultaneously, it used to bring down salt-master. This happened until last year, when I was working at scale. Since then, I have switched from that job; it’s difficult to test this pain point now.

I haven't tried technical support.

I did not previously use a different solution.

Learning SaltStack did seem a bit daunting at the moment I was learning it. The concept of creating a top.sls with references to various states and their targets, then creating corresponding files in YML, took a day or two; beyond that, it was real easy.

If someone is using it for an infra consisting of a 1000 servers or more, then support would be real useful. Others can go through the documentation and learn from forums or SO posts.

I tested Puppet and Chef, but could never get around to using them in production or at work.

Salt was more of a Swiss Army knife. And our work at the time was more focused on rapid manual changes.

Create valid states for all environments and keep the difference between these environments minimal. Use test cases as much as possible.