VMware Aria Automation Reviews

• Bulk/Remote execution
• Event/Reactor system
• Configuration Management

These features serve as the most critical pieces for automating anything, not just state, but also execution and remediation.

I don’t want to build automation that just does a thing or two. I want to build automation that is intelligent, part of the fabric of our environment, and is somewhat self-sustaining. I think SaltStack can help me do this.

SaltStack provides the capability necessary to truly streamline our SDLC and environment management. From a high level, it allows coders to code, testers to test (automated testing too), and admins to admin in the most inter-connected and effective way possible.

• Web UI
• Maintenance of their code

We have been using this for three years.

There are some issues here and there, such as nuances with Windows and minions ‘falling asleep’, but its manageable.

I did not encounter any issues with scalability.

I would give technical support a rating of 8/10.

I was using more of a Frankenstein automation solution previously, and the reason for switching was the capability of SaltStack, performance, and ramp up time (ease of use).

The setup was pretty straightforward. It took some time getting familiar with all the configuration options and playing around with pillars and grains. On the whole, it was relatively easy to get going.

I think they are going to have a tough time with the Enterprise licensing. So much can be done with the Open Source side, and especially for smaller shops. I personally think the pricing for Enterprise is hard to justify.

We looked at Chef, Ansible, and Puppet.

Do it and take full advantage of its capability. Be creative and automate everything you can with it.

Configuration management: We were using SaltStack for orchestration in liaison with OpenStack. It was good for Linux machines, but the Windows experience was fragile.

They put in a few patches for Windows machine orchestration, but the experience was still painful.

Hands down, the main thing for improvement is Windows orchestration. Repo is very limited and multiple issues occur when installing vendor products.

Other areas would be to build test cases, with ease, for states. I haven’t found one. SaltStack had a focus only on Linux from the very beginning. Windows has always been a sore point. The repo for Windows was very inadequate and if I am right, I heard a SaltStack guy himself say that he is not very fond of Windows orchestration.

Another area of improvement is stability. Vendor products that required multiple customization had many handicaps, such as lack of LDAP or Active Directory support and, biggest of all, inadequate repo for Windows states.

We have used this solution for almost two years.

There were lots of stability issues, and we did hire a consultant from SaltStack.

We did have to upgrade the infra running salt-master quite frequently.

The setup was complex. The salt-master topography was master-minion, but then expanded to syndic, then back to master-minion. We did have to juggle, but that may be the shifting overall cloud architecture. It looked more like a chicken-egg problem, but we did have to revise the Salt architecture frequently.

I was not in the decision-making process, but I was told they evaluated Ansible. I am not sure the degree of depth in which it was evaluated.

Stay away from Windows orchestration. Have an alternative for orchestrating Windows machines. Think about how to prepare test cases when things change. The breaks spread like wildfire.

• Configuration management
• Remote execution
• Grain & mine

I like knowing what state my machines are in, and I like being able to change their state all at once.

Some of what we do, we could not do without SaltStack.

Sometimes it feels like there are more moving parts than is necessary, and maybe something simpler would do.

I have used it for two years.

As long as the versions matched, we have not encountered any horrible stability issues so far. :)

The opposite: It does better with more nodes than it does with fewer, in my opinion.

The docs, though sometimes cryptic, are excellent and thorough. I haven't personally used their technical support services.

I previously used Puppet. I switched because our shop here likes using Python solutions over Ruby ones.

Initial setup was more complicated than Puppet, but the solution was also more comprehensive. Setup was worth the trouble.

SaltStack is completely open source, though you might consider SaltStack Enterprise as a way to get up and running more quickly.

Before choosing this product, Ansible and Puppet were brought up. Ansible seemed too small of a tool for what we needed and Puppet was written in Ruby, so they were discounted.

Thoroughly research how SaltStack works; that knowledge has helped me a lot.
SaltStack is a one-stop-shop for your datacenter's management, monitoring and state control needs. Using it that way allows you to get the most out of the tool. It is configuration management, but also orchestration, monitoring, and has reactive capabilities.

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.

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.

We are using it for infrastructure service, automating things in Active Directory, and deploying Microsoft SQL and Oracle databases. We are also using it to automate some scenarios within our infrastructure.

Having a one-stop-shop for our IT services is one of our goals. Exporting and democratizing the tools helps our end users to do their work efficiently and to be more agile. It helps to minimize the time to market for our product.

Using the solution we are able to automate database refreshment. This process used to consume a number of working days. With vRA fully automating this process, it is now down to five or 10 minutes. As a result, we're able to refresh our testing and development environments frequently. When we go with a new deployment in production, the deployment is based on a fresh copy of production. We're able to have multiple environments so that we can test more product concurrently.

We use VMware Cloud Templates and having a standard template to be deployed gives us a standard across our environment and minimizes the time it takes to provide services. Despite having 20 machines, we just do the configuration once and then we can deploy it across the whole infrastructure for all environments: production, testing, and development. And this reduces the time to market for our services. They improve reliability. They give us consistency. Having things assembled and having everything in one image helps us provide reliable services. And they have saved time for our developers.

Having an enterprise service catalog and being able to automate various parts of our infrastructure are among the most important components.

It needs to be more dynamic with variable customization to make new workloads more reliable. It also needs to be faster. We are exploring vRA version 8 right now and maybe what I'm requesting is available in the new version, but we haven't explored it fully yet.

We have been using VMware vRealize Automation for seven or eight years.

VMware's customer support for vRealize Automation is good. They are knowledgeable about the product and have improved their response time. The support is fine.

We did have a previous solution but I am not able to disclose its name. vRA is an end-to-end solution with all the capabilities.

The pricing is very high.

The primary use case for deployment of vRealize Automation was to facilitate a service provider web portal front-end to our Hosted Private Cloud and Business Continuity solution. This is a fully automated virtualized SDDC, using VMware as the base hypervisor. We also incorporate NSX for network automation, vCenter Orchestrator for workflow execution, and additional software packages to support the service as a whole (vROps, Log Insight, Network Insight, NSX Manager, etc.).

Our core networking is made up of a spine/leaf architecture using Cisco ACI/APIC and our storage is virtualized behind a Hitachi (HDS). We use SnapMirror and NetBackup as our DR tools.

We needed vRA to easily integrate with our hypervisor, orchestration, security (tenant segmentation, PCI), workflows, custom code, and internal monitoring/management tools. Since we didn’t have time to develop our own web front-end during the development sprints, vRA saved considerable time and resource cycles. Its ability to easily integrate with all of the VMware cloud products as well as public cloud providers, like AWS and Azure, out-of-the-box, makes it an even more powerful tool.

vRealize Automation is improving the way we host and serve up our fully hosted private cloud solutions as a cloud service provider. It has created efficiencies in how we deploy, manage, monitor, and develop within the service. It provides velocity both from management and customer perspectives, from ingesting new catalog items, developing new workflows for additional features, and/or allowing customer access to multiple guest OS instances at scale in a shorter time frame.

From a service provider perspective, its ability to integrate with vRealize Operations and vRealize business management suites provides a window for being able to execute predictive and reactive analysis that you can use to automate your cloud solution from a resource, management, and/or customer perspective.

vRA provides that single pane of glass for our cloud tenants to deploy, monitor, access, and manage their VMs/guest operating systems. vRA allows a cloud service provider to quickly build out a web portal front-end interface that easily integrates with all of the VMware vRealize products, providing an all-encompassing cloud solution.

Additional features also allowed us, as the service provider, to configure branding options for the site itself, as well as full integration into the orchestration layer, including workflows, security control, reporting, billing for our cloud admins, tenant admins, and end-user (customer).

The most valuable feature is vRA’s ability to integrate whether with additional VMware vRealize suites or other vendors' cloud products.

Also, vRA in combination with vCenter Orchestrator makes it very easy to design, import, and deliver quality workflows and blueprints. These can be used for various functions within the cloud portal, from both a production as well as a business-continuity perspective. Examples include automated failover activities in combination with SRM and SRA Replication, VM deployments based on a catalog, being able to roll out an entire LAMP stack dev environment with the click of a button, or ingest and inject data into back-end CMBDs, etc.

Its fully integrates with network and storage virtualization via NSX and workflow development, and secure APIs are available to customize automation using other vendor tools such as Puppet, Chef and/or PowerShell.

There are many features that I find extremely valuable but vRA’s ability to be a central hub for all of the parts that make up a hosted private or multi-tenant cloud solution is extremely valuable. Ultimately, the outcome of this design is a highly available and agile solution with a wide array of integration that enables you to provide a fully automated, scalable private cloud solution that can meet the market and customer demands now and in the future.

I have listed some additional features below for general reference:

• Easy integration into other VMware-based vRealize cloud products via SSO
• Single pane of glass interface
• Parameterized blueprints to enhance reusability and reduce sprawl
• Policy-based optimization of virtual machine placement
• NSX integration enhancements
• Enhanced control of NSX-provisioned load balancers
• Enhanced NAT port forwarding rules
• NSX security group and tag management
• Automated high-availability for NSX Edge Services
• NSX Edge size selection
• Enhanced vRealize Business for Cloud integration – cloud nanagement platform
• Improvements to high-availability
• Health Service
• Configuration Automation Framework – Puppet Integration
• REST API

Most of the areas for which there was room for improvement are being covered in the latest 7.4 release which will include all new workflows for additional management of a customer’s cloud and infrastructure, directly from the Web portal itself. Some of these features today require the ability to build out your own workflows, which can become complicated if you don’t have the knowledge base.

VMware is aware of this and is making the next version of vRA and vCenter Orchestrator with this in mind. They are going to include additional granular-level controls from within the self-service portal itself. This will allow us, the service provider, to pass these additional features on to our customer base giving them greater control and management of their dedicated cloud.

Some of the new vRA 7.4 release features include:

• New and enhanced curated blueprints and OVF files
• New custom form designer
• Enhanced multi-tenancy capabilities
• vRealize Suite Lifecycle Manager now extends to IT content management 
• New IT content lifecycle management

No issues with Stability now working on testing out the new version on NSXt via blueprints which will provide a whole new level of control and management for our SDDC virtualized networking stack.

No issues currently with scalability of the product or its uses cases it was implemented for.

One of the best support and architecture teams we have ever worked with from a vendor perspective. Very knowledgeable and on the cutting edge of virtualization.

The software setup is fairly easy but does require knowledge of the VMware product suite. The complexity comes in whether this a service or a dedicated infrastructure. Normally in service oriented infrastructures which are purpose built for multi-tenancy where you have multiple customers hosting multiple sub-tenant customers which require many layers of micro-segmentation and security to be built in. In a dedicated infrastructure you are building for one business or a single customer even though they have segmented sub-tenants such as account, IT, Operations etc it is all internal to that business. The level of micro-segmentation and security is much less in complexity to provide a final solution.

We implemented a majority of the service internally and only reach out to the vendors developers prior to making changes in the design that could impact rework to correct bottle knocks and development dead ends. 

From experience working with other service provider cloud products, VMware vRealize Automation Center is the best out-of-the-box solution to quickly build out your cloud portal and fully integrate it into your orchestration layers, as well as your compute and storage infrastructures. It can support multiple public clouds as well as hypervisors, providing that single pane of glass for management, operations, and reporting. I would give it a nine out of 10 as there is always room for improvement, since cloud is always evolving.