We were previously using Bash scripting. 

We did try BigFix for two years. However, because of costs, Ansible proved to be better cost-wise. The licensing fee was a big issue with using BigFix. Control from the BigFix perspective was a concern, because you were locked into the GUI. With Ansible, we were able to do everything from the command line and touch the entire environment from the command line. Once you use BigFix and an issue, you then have to log out or go into the box from one of the servers, but you were locked into the GUI in BigFix.

View full review »

We also use Chef.

View full review »

We previously used Puppet. 

View full review »

We used a Puppet configuration in the past. We staged with Puppet and then moved to Red Hat Ansible Automation Platform.

View full review »

I've used Puppet a little bit, but I quickly moved into Ansible as it became a standard over Puppet, Chef, and perhaps SaltStack. We moved quickly into Ansible. When Ansible was acquired by Red Hat, it quickly became a very interesting product. The first bullet point was the agentless infrastructure for Ansible.

Red Hat's open-source approach was also a factor for me, certainly. I'm an open-source enthusiast. It's a big plus that Ansible is an open-source project, and it's free. They gained popularity from that as well.

View full review »

We used multiple tools in the past three years, but we did not use any other similar product to Red Hat Ansible Automation Platform.

View full review »

I did not previously use another solution. 

View full review »

We also use BigFix. However, we need to have an agent on every server with BigFix, which is not the case with Ansible. 

Our manager had already implemented Ansible, and we were using it in the lab previously. In the lab, we saw it running very smoothly. Some of the production servers also use Ansible as well.

View full review »

We didn't use any other solution previously. There has been a scattering of other automation tools around, but nothing that had physically been a business directive. It was always bash scripts, secure CRT scripts, etc. They were just scattered everywhere. There was no semblance of order. If we had anything, it could be a guy that was working two days a week, but you never knew what day he was working or who was supporting it. We had nothing like that other than Puppet.

The main factor for going for Ansible was that within our environment, there were already a lot of people who had Ansible engine experience or had worked with Ansible Core. Ansible is an easy-to-use language. It is very easy to pick up, and you can start automating quite quickly with Ansible. It is not as complicated as Python or anything like that. There is ease of use. It is not like writing Python code where there is a lot out there, but there is no front-end GUI that we could bring users into quite quickly. It is not as scary because you can look at the GUI, and you can click around and run jobs within the GUI. You don't need to have any deep Python experience or complicated Ansible coding experience. Once you've got a playbook in your repository, you can just run it from the web front end, and we couldn't find anything else that had a web front end like that.

It has got a big community. There are always people out there writing new modules, and you've got Ansible Galaxy, and you've got Ansible Collections where one is vendor-provided and one is community-provided. It is just very progressive. 

View full review »

We have used Red Hat Satellite and Red Hat CloudFormation.

CloudFormation is like a showcase of our service catalogs. We provide that to our customers. It's tightly integrated with Ansible and frameworks. The customer can choose from the service catalog, and if it's automated, the customer can see how much it was from a cost point of view. CloudFormation reduces work activities on the ground.

View full review »

I just started using Puppet and Chef. The main thing where Ansible stands out is that you don't need to make any changes to the upcoming hosts. With Puppet and Chef, you have to install an agent program that will act as a layer for interacting with the host. You need to install an agent in between, which takes time as well.

View full review »

When I started in automation, Ansible was the first tool I used.

View full review »

Manual configuration and "Golden" templates for virtual machines were used.  The former is tricky to maintain consistency with. The latter seemed to require constant updating and it did not help maintain the configuration of already installed servers.

View full review »

We chose this solution simply because we use Red Hat. We trust Red Hat, and whatever Red Hat puts out, it is pretty solid.

View full review »

I had briefly toyed around with Chef and Puppet, but I didn't get anywhere with them. Then I found Ansible. It was at a previous job where I picked up on Ansible. At that job, they were against putting an agent on anything. So Ansible was it. That was the easy sell. Then I figured it out and rolled with it.

View full review »

We used Puppet and switched to Ansible because it's an agentless solution.

View full review »

We are also using Terraform.

View full review »

We previously were using custom-made Python scripts for automation. It can weirdly scale well when multi-threading is leveraged correctly. But, it definitely cannot replace an extensible framework like Ansible. 

The community behind Ansible and its important number of modules make it a lot more relevant.

We were also using Puppet at some point. But, it's a bit different than Ansible, it was not a competing usage for

View full review »

I used bash scripts before, but bash is not idempotent and you should write more code whereas Ansible already has them as a module. Ansible gives you an informative report after each task.

View full review »

We use all kinds of solutions like puppet, chef, .... Why do I like Ansible more? Ansible is easier, it makes use of yaml, and templating is done with jinja2. With other solutions there is a steeper learning process. Ansible is so easy that it takes you only a few minutes to get going. Where other solutions are more for programmers, Ansible is made for system engineers without any need to program or script in any language derivatives. Ansible puts all the intelligence in the modules. View full review »

Used S before.

Switched because of coworkers and even if I find SaltStack easier to learn, the documentation of Ansible made me choose it over Salt.

View full review »