Red Hat Ansible Automation Platform Reviews

Our use case is to stitch together all the units, all the teams writing roles and Playbooks, and provide a central point for execution, and a way of managing what is executing against the infrastructure.

I was the one who initially initiated Ansible Core and Tower within our department of the bank. I have actually been the Ansible evangelist, so I'm slowly migrating people from using batch scripts to using Ansible Playbooks. That has taken a little while but there has been an improvement in people using Ansible, and starting to automate things better, and people sharing code amongst the teams.

I prefer Ansible Core, but from an enterprise standpoint, an admin point of view, having the Dashboard and seeing how all the projects and all the jobs lay out is helpful.

What I would like to see is a refined Dashboard to see, when I log in: Here are all my jobs, here are how many times they've executed; some kind graphical stitching-together of the workflows and jobs, and how they're connected.

Also, those "failed hosts," what does that mean? We have a problem, a failed host can be anything. Is SSH the reason it failed? Is the job template why it failed? It doesn't really distinguish that.

The job workflow needs to be worked on. It's not really clear to how you actually link things together. What they probably could do is provide an example workflow on how to stitch things together. I think that would be very helpful.

One to three years.

After I built it, it was given to another department to manage. From what I'm seeing, it is reliable, since we've clustered it together. We have a cluster of Towers within each different environment, Dev, UAT, and Prod, and that controls which Playbook is executed in which environment. In regards to the clustering and it staying available, it's stable.

It scales well because of the clustering.

Sometimes it takes a couple of messages before they understand more difficult situations, but I would rate technical support at eight of ten.

At the time, the setup was pretty straightforward. I don't think there have been any changes in that regard.

I've used Salt and I've used Puppet. The reason I like Ansible is, first, the coding of it is very straightforward, it's very human-readable. I'm also on a contract, and I can clearly iterate and bring people up to speed very quickly on writing a Playbook, compared with writing up a Puppet manifest or a Salt script.

Everyone gets super excited about when we show them the automation part of Ansible: 

• How can you orchestrate things? 
• How do you operationalize it? 
• How do you take it to a group of people who don't have the experience writing playbooks themselves nor experience with command line? 

Tower allows control for more people to use it and have some safety nets behind it.

From speed to deployment, it is much quicker. It has an API in the back which allows for integrations. So, if you are building a pipeline with Jenkins or some orchestration tool, it's much easier to write the playbook and plug it in via Tower than try to link it yourself. Thus, it is quick to production.

If you look at network as a infrastructure, NetOps, and the continuous integration, we are certainly able to plug something (like Tower) into the pipeline, which is a big benefit and also a value add.

I haven't done a lot with the dashboards yet. One of the sort of difficulties on the network side is they just recently became first class citizens on the connection, so you have to do another step. However, I think now that is clearing up, and the dashboard will come into play more.

From a documentation standpoint, especially on the networking side of things, things are changing rapidly, most of time for the better. However, the communication on it is not probably where it could be. We could use some real life examples where we could point customers to them and say, "This is what you are trying to do. If you follow these steps, it would at least get you started a bit quicker."

One to three years.

I have had very few complaints from both my usage and when I've helped customers deploy it. From a stability standpoint, it seems to be pretty strong.

I haven't deployed it at a giant scale, but hundreds of nodes seems doable without too much trouble.

It's pretty straightforward. 

Sometimes from version to version, some discrepancies can make it a challenge to work through, but for the most part it's pretty straightforward. One of the reasons in the network industry that Ansible won out over some of the other automaton tools is the low barrier to entry. It's pretty simple to get started.

For deployment and maintenance, my team has two people work on it as their primary task.

We use the Red Hat Ansible Automation Platform for infrastructure provisioning as well as application deployment on Kubernetes and virtual machines.

We don't use Tower very often. We are currently primarily using the Ansible Playbook.

There are new modules available, which help to simplify the workflow. That is what we like about it.

When compared to Terraform, the execution speed of Ansible is very slow due to the way it executes things.

Improvements should be made in terms of execution speed, which is, I believe, the most lacking feature. Aside from that, re-triggering a failed task is another useful feature.

I have been working with the Red Hat Ansible Automation Platform for approximately one year.

I don't remember the exact version we're working with, but it's N-1.

Red Hat Ansible Automation Platform is a stable solution.

I've had no issues with the scalability of the Red Hat Ansible Automation Platform.

Our organization has four to five administrators who use this solution.

We have contacted technical support. I would rate them a four out of five.

Positive

We are also using Terraform.

The initial setup is quite straightforward.

This solution does not require specific maintenance.

The deployment was done in-house.

The cost is determined by the number of endpoints.

A license is required, if you are using Tower, we don't use it very often.

It is slower than other solutions.

Terraform is better for infrastructure provisioning. However, once the infrastructure is provisioned, we don't see any alternatives to Ansible.

I have a partnership with Red Hat.

It's clear and simple, and there's plenty of help available.

I would rate the Red Hat Ansible Automation Platform an eight out of ten.

On-premises

I like Ansible because it is:

• Easy to use.
• Easy to read.
• Easy to maintain.
• Easy to support.
• It works without an agent.

It has made software installation and updates much easier. Tasks including changing or checking configurations and files have been improved especially considering the big scope of servers.

It could work with a larger number of servers.

I've been working with Ansible since v0.7 and still use v2.2.

We only encountered issues with syntax, as sometimes it was changed and then one has to adapt.

There were a few scalability issues. I had no problems as long as the number of servers was less than 500. When the number of servers has exceeded 500, I encountered an increased number of failures when trying to provision all together. I tried to play with forks, timeouts, and other options, but as the number of servers grew, I got more failures, so I had to provision smaller groups.

I haven't yet used it.

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.

It was easy to install and easy to use.

I use the free version with Jenkins, it's enough for my needs.

We did not evaluate other options.

It should work easily.

We mostly use Ansible as a configuration management, application deployment, and VM provisioning tool.

I like that Red Hat Ansible Automation Platform is easy to use.

Red Hat Ansible Automation Platform is not the best at server provisioning. Terraform is better.

Complex data structures and control flow need improvement.

I've been using it for one year.

It is a stable solution.

It is scalable.

The initial setup is easy and takes a few hours to complete.

Red Hat Ansible Automation Platform is an affordable solution. Infrastructure maintenance of the Master server comes at a cost.

If you want to do server provisioning, don't go for Ansible. However, if you want to do server/network device configuration, application deployment, or configuration management, then Ansible is the best solution for you.

Overall, I would rate Red Hat Ansible Automation Platform at eight on a scale from one to ten.

Hybrid Cloud

We are still implementing it.

Ansible automation has benefited our organization.

I have found the automation to be the most valuable feature.

There needs to be improvement in the orchestration.

Still implementing.

The simplicity of the programs is the best part and the fact that there is no need to install clients on your hosts makes it unique compared to other orchestration tools.

We can now go to a customer and deploy all software in a few minutes instead of hours.

It's a young product so there is still room for improvement on the module side. There are about 150 modules at the moment but there are still many missing.

For a couple of months

Deployment is easy, it cannot be any easier.

The software is so small and well written that there are no stability issues. At the moment there is a new update every 2 months so if there is an issue with a bug it will be fixed in the next release.

It scales from a few up to 1000's of servers so does it scale - YES!

Customer Service: No idea. It's so simple and there is so much support on the internet that so far I have had no need to look for support.Technical Support: People at Ansible have been very nice to me so far even without a support contract. I get pointed to the help boards to get answers to my questions by their support staff.

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.

Setup is easy. Every distro has packages available and if you have a weird distro that hasn't one, you can install it easily with python pip or download it from github.

We installed it in-house. It is so simple for an IT person that with the online documentation that it should be easy to set you up in minutes.

The product is free, at least if you make use of the command line version. There is also a graphical version that has some extra features in reporting, etc. Here the price depends on the number of clients you want to manage. For us the cost was the time it took to learn the product which was only a day or two.

Puppet, Saltstack, Chef

If you are looking for something easy straight to the point for a non programmer this is what you need!!

We use it to deploy our infrastructure.

It has made our infrastructure more testable. We are able to build our infrastructure in CI, then are more confident in what we are deploying will work, not breaking everything.

It has been simple to get into, and we are able to get results out of it quickly. We automate across a bunch of different server and virtualization platforms and have been able to do that with Ansible across the board along with our networks.

For a couple of the API integrations, there has been a lack of documentation.

Three to five years.

Performance has been an issue on larger environments, but it has gotten a lot better over the past two years. So, we are seeing steady improvements there.

As long as there is a continued focus on improving performance and scalability, then it should meet our needs going forward.

We don't use Red Hat tech support. We support everything in-house.

We have written a lot of open source Ansible content. I work on the OpenStack Ansible project. So, we've done a lot of open source contribution and support all of our playbooks and roles in-house as well.

The initial setup is simple.

The documentations are great. Everything is pretty well-documented.