VMware Aria Automation Reviews

The primary use case is to automate systems, and at a faster pace, so we can give them to our end-users faster.

It has cut down the time for building out a machine. A process that used to take three hours is down to 20 to 30 minutes. If the users need a machine fast, we can get it presented to them quicker. So it has absolutely helped with the speed of provisioning.

The most valuable feature is the way that it plugs into our monitoring systems, and Infoblox and Puppet.

I don't find the solution to be intuitive and user- friendly. The GUI is really complicated. Tracking down logs and errors is very hard. Then, it takes a specialized JavaScript person to build.

Also, I'm not sure how the upgrades are going now, but they definitely need to evolve the upgrade process. 

Finally, the logs are very generalized. Giving more of an indicator of what's actually going wrong, rather than just a generic error code, would help.

We had a lot of issues at first. Especially with doing any kind of upgrades, it was a complete tear-down and a complete rebuild of all the Blueprints. The upgrade process was not easy or intuitive at all. But it seems to be getting better.

It's easy to be scalable on it. You're as scalable as the infrastructure you have behind it.

I have used technical support, but more on the infrastructure side, not on the system side. My experience with them has been good. They get back to us quickly. We're a TAM customer, so we get quite a bit resolved pretty quickly.

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

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

I came in about halfway through the initial setup. It was very complex. We had VMware projects going on, so we had a couple of consultants giving us full-time personnel to help us through it. We had VMware there, and AdvizeX was another one. Then we had the specialty people from VMware that they deployed out to our place.

We still haven't gotten it into production yet. But once we do, our value is going to be the ability to turn around virtual machines a lot faster.

Read as much as possible and then take it slowly and don't try to jump in full force. Make sure you have a good plan going into it. That was one of our mistakes. We were expecting, "Oh, this will be pretty easy," but once we got into it, was a little more complex than we were thinking.

I give the solution about a seven out of 10, given the process we've gone through with it. We've had it now for three years, but we haven't been able to really deploy it in production. I don't know if it's because of the documentation or just the ability to be able to use it and make it functional.

Automation and operations.

So far we haven't really implemented it on our own organization as far as using it with IT in the workplace internally. But vRA has helped us bring in a lot of customers because they use things like Chef and Puppet, and this works in that same kind of realm. So it has drawn those customers to us. We are, as part of our VMware venture, working on our expertise in that realm.

Where it is implemented, in the little bits that we've labbed it out, internally, it has, obviously, increased our infrastructure agility. Otherwise, we wouldn't be continuing to implement it. Once you get all the pieces together, it improves delivery times for internal labs for our internal teams.

We like the seamless, non-vendor-specific application that we can provide with it. We're a service provider, so we have all kinds of different clients and they have different applications. Automation works with all of them, pretty much across the industries. The ability for it to be compatible across many different products is really what's important to me because that's what's selling: being able to go cross-platform and be hybrid. That's the most important feature.

After that, ease of use would be up there too. We also like the GUI display which ties in the non-devs with the devs and helps them work together.

They can improve on the dashboard representations and the options for non-technical people. I would like to see the ability to customize that and maybe provide them with helpful guides to what subscriptions they have. Sometimes, I find that I have to do more explanation to people who do approvals. I would really like to customize the display to the terms they use in their particular business unit. So a little bit more of a nod to the customization of the UI for non-technical users would be helpful.

Also, I expect it's going to come with time, but there is not too much documentation out there because it's fairly new, and not very many people use the little niche product. So more documentation.

So far, VRA seems stable to me. I don't have any complaints.

We haven't had any scalability issues yet, but we are approaching that potential, whenever we get larger customers. The customers that we do have on, if they do use it, they're just testing the waters with it.

They're very helpful. We have Premier Support with them, so we're always working with them. Our TAM is always on top of things. It's good.

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

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

The setup is straightforward. There are plenty of hands-on labs and guides. It's more the, "What can I do with this?" As a project engineer, I try to translate from the vendor to the customer, according to whatever they're doing at their end.

We haven't really had any bumps in the road deploying it.

My advice would be to go to hands-on labs to see if it's exactly what you're looking for because, as far as the reality versus the expectation goes, it might be a little bit of a shock, especially for the non-technical person. If they're going to say you, "It's going to be great. You're going to know everything," there are some things you might have to take into consideration. They might have to do a little tutorial for you. I would just try to set your expectations.

I rate it at eight out of ten. I believe it's intuitive and user-friendly. Could it improve? Yes. Could it be worse? It could've been a lot worse. So it's okay.

The extra two points are because one of the first issues, on one of the first versions that I took training on, was around the idea that, yes, here's your dashboard so people can deploy resources without having to know too much, but it seemed kind of bare as far as presenting it to those people. That's the only gap that I see and it's just going to be filled in with user experience and people like me saying, "I'd like a little bubble to pop up," or something to hover with information when someone has to give approval. I'd like for them to be able to see why they are approving this, without having to go dig into why we set up that limit. 

It would be nice to have a tooltip that says, "This was agreed upon..." or whatever comment I want to display. For example, if I want to reference a ticket number internally: "Approved, XYZ," or "Related to mass ticket maintenance ABC," so they can say, "Yes, that's right, this is the DFW migration," or the like. They're non-technical and those are the kind of terms they use. I find the UI is missing that part. I have to explain it to them. And then, of course, they're going to forget, or they're going to get a new guy in, and he's going to say, "Why do I keep having to approve these things?" It would be really nice if it just told him right there. This is why you're approving it because of mandate such-and-such, or memo number 123.

From other products that we work with - I came from the troubleshooting operation side of the house before I started working in Product, so I worked with VMware on ESXi and vSAN - they have always been good at taking our opinions. For vRA, I'm starting that process with them, so I'm not expecting them to have a turnaround yet, but I'm expecting them to take our feedback, for sure.

• 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.

• The automation, that is, being able to automate server deployment, including the option to do it manually if you want.
• Being able to collect logs and diagnostic information in one central location.

I can build machines quickly and deploy them from a central location to whichever worldwide datacenter we need. Also, we can collect system logs from all clusters and hosts, and then we're able to troubleshoot and view logs in one central location. This is a good thing because it saves time.

They just need to keep expanding it adding additional features.

I’ve been using for just a few months, including Log Insight.

So far so good, it's very stable, rarely any issues.

It’s definitely scalable, and does a lot that we’re not doing yet, but we’ll eventually be there. We’re capturing logs from all over world, and everything is in one location, so we can scale to meet that need.

VMware tech support is excellent. It’s one of the best vendor tech support I’ve found.

It's extremely easy, very straightforward, and has good documentation.

It simplifies daily chores, so go get it.

The Salt Formulas are very, very helpful, as they help to get the configuration needed to install any new package and configuring the same; very, very simple and easy.

We have scaled from two servers to about 140 servers in a very short period of time. This would have been a nightmare had it not been for the SaltStack configurations.

I think debugging can be improved. In case of errors, the devOps team finds it difficult to read the Python stack traces at times.

Although the Salt Formulas have matured recently, they still have some glitches. They are open-source contributions. Every Salt Formula has two parts: 1) pillar data and 2) Salt configuration. Both have to go hand in hand.

Sometimes the Salt configuration was found to have a few bugs that do not align with the pillar data. The stack traces thrown do not help much and require a bit of experience to deal with those situations. We end up correcting either the pillar data or the Salt configuration.

This is by no means an issue with the SaltStack software. Since it’s written in Python, the stack trace thrown for any error needs some level of expertise to deal with.

One example we found was that one of the Salt Formulas was using a Salt module in a particular version. Upon upgrade, the Salt module was no longer part of the default package. It took my team some time to realize what had happened, because the Python stack trace was not pointing to the exact problem in hand but would point to a random Salt configuration location.

I have been using this solution for more than two years now.

I have not encountered any stability issues.

I have not encountered any scalability issues.

We did not use technical support. As it was open sourced, we developed the required technical support in-house.

We were not using any other solution for our configuration management.

The initial ramp-up period to understand the concepts took time. Post that, it’s a very easy-to-use solution, especially after the Salt Formulas have matured.

Its open-sourced, so we do not use licencing, and its free to use.

We evaluated Puppet and Chef before deciding on SaltStack.

Ansible and SaltStack are very good solutions. I prefer SaltStack as its been developed from the ground up and is a lot better than Puppet and Chef.

The initial learning curve is low. I had a working configuration building fairly complex proprietary Internet servers within a couple of months, well before the rest of our server team was ready for production builds.

The developers are very quick to respond to reported issues and offer advice to deal with them (or correct something you are not using well). The couple of times I had to deal with them were actually very pleasant.

The relationship between the state files and the actual filesystem being served by the master is as simple and elegant as the way *NIXes treat everything as a file.

The execution capability both in a shell on the Salt master and using cmd.script within state files allows even a novice to make things happen the way they want until they learn to use all of the available modules the right way. This, for me, was part of getting up and running fast. This reduced the learning curve for me tremendously, as I got my initial server build framework running. I have been able to continue refining the system in stages since then and it is easy because of the relationship between the state files and the files they serve.

We have developed a complete, multi-tiered, stable build system for our Internet servers with SaltStackas the base of the build system. It is stable and easy to modify as we grow and change our needs.

We currently use the Salt Cloud module for integration with Amazon Web Services, but I would like to see more integration with AWS, specifically an ability to stably control an ever-expanding and contracting cloud of EC2 instances in a sane fashion.

SaltStack has many community-maintained modules available. One of the modules is called EC2 Autoscale Reactor and it's function (alongside the Salt Cloud module) is to control an autoscaling group's instances as they are added and removed. I found this module difficult to configure and unreliable, as far as getting and maintaining control of new instances as they were created by the autoscaling group. In fact, the developers even labeled it "experimental." I would like to be able to reliably control all instances in an expanding and contracting autoscaling group without manual intervention.

For the record, our cloud has moved away from needing this as a requirement. We use SaltStack and Salt Cloud strictly as a build management system and have moved towards our Internet servers being strictly "hands-off," except for developer instances. I want this feature as an improvement because the ability to manage a dynamic cloud of Internet servers adds a lot of power to SaltStack and to me.

I have been using it for 1.5 - 2 years.

I mentioned the initial learning curve elsewhere in this review. Of course I encountered issues with deployment of SaltStack. I had never used an infrastructure management system prior to this, so the concepts were a bit foreign. I put in a ticket or two as I initially learned to get the system running. I found that across Linux systems, there were sometimes version differences in the repositories and began building a specific Git revision of SaltStack on all systems as a result.

The only stability issue I encountered in almost two years of use had to do with a different version of SaltStack being served on the repositories for an Ubuntu Salt Master and Amazon Linux minions. I have since migrated to using all Amazon Linux instances for everything and always building the same Git revision on all instances and have never had a bit of instability in the SaltStack system since then.

I have encountered no scalability issues with SaltStack. In fact, I haven't stretched the system very far, but because it supports multiple masters, Syndic, and minions as "runners", the scalability and high availability looks to be amazing.

A+ for the little time I have spent dealing with support. They were quick to respond and the technical expertise was fantastic.

A+ because the developers are directly involved in the support.

SaltStack was my first choice because it is open source and was reviewed extensively as a good choice because of the low learning curve.

The hardest parts of initial setup for me were learning some of the intricacies of YAML and Jinja, and figuring out the moving parts on the master so I could get the system to reliably create the minions I wanted. Later, learning to configure Salt-cloud was a bit tough because of the configuration files required to work with resources on Amazon Web Services. None of these issues were "showstoppers", though, as the amount of online documentation and configuration examples for other users is excellent.

An in-house team implemented it.

The only calculation I can make on ROI is the countless hours I have NOT spent configuring and deploying servers. I now issue a few commands on the Salt Master as my build server, and the servers are built, Amazon Machine Images are created, and they are blue-green deployed. All I have to do is check the various stages for completion and occasionally check build logs for errors and make corrections. I have a lot more time to focus on the rest of DevOps.

As a small start-up, we have not gone to a licensed model yet.

The only evaluation I did was to spend lots of time reading reviews and asking questions of people I know who are already using configuration management and execution tools. SaltStack was my first choice.

I spent my time learning Saltstack through trial and error, researching the online document system as needed. If you decide to use SaltStack, buy the O'Reilly book called Salt Essentials first. It is not very big, but it explains the concepts required to get a working system very well. I think if I had gotten the book first, I would have cut my initial time spent learning in half.

VMware Aria Automation is used for automation.

The most valuable feature of VMware Aria Automation is the versatile automation and deployments.

VMware Aria Automation could improve reporting of the policies. They are difficult to customize. We have many policies but they are not able to be modified to what we want.

I have been using VMware Aria Automation for approximately three years.

The solution has been stable and smooth in operation.

We have one customer using the solution. The solution is best suited for enterprise companies.

The solution is scalable.

The support is good.

I rate the support from VMware Aria Automation a nine out of ten.

Positive

The initial setup of VMware Aria Automation was not difficult.

We did the deployment of the test environment.

I would recommend this solution to others.

I rate VMware Aria Automation an eight out of ten.

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.