Red Hat Ansible Automation Platform Reviews

I am using Red Hat Ansible Automation Platform as a part of the scale-up of the nodes in OpenShift.

Mostly, we use the solution for upgrading-related stuff.

The most valuable feature is that Ansible is agentless.

For my day-to-day operations, the one module that I am using is very good, and it is giving the intended results. Ansible has a lot of modules to perform your day-to-day activities. I don't think there will be room for improvement based on the current instances or use cases.

The scalability of the solution has some shortcomings. Thus, the solution's scalability has some room for improvement.

Though not much, I have experience with Red Hat Ansible Automation Platform for two years. I am a customer of the solution.

Stability-wise, I rate the solution a ten out of ten.

Scalability-wise, I rate the solution a nine out of ten.

The initial setup for Ansible is very easy.

I'm not using the solution in this containerization. In the present environment, we are not using something like Red Hat Ansible Tower. We are using just an Ansible node which is something we use as a server for accessing all of our nodes and managing all of the nodes. Also, building an Ansible node as a bastion or jump host is a pretty easy task.

Actually, when you are building Ansible Tower, I think you need to go for the pricing. For other things, you don't need to do that, I guess. So it's a pretty good tool to automate your day-to-day or daily tasks or activities that can be done with Ansible. It has a lot of features, helping materials, and modules, which will be helpful in automating one's day-to-day jobs. It's pretty easy for us to upgrade and work with the nodes on Red Hat Ansible Automation Platform.

If you go with any other tools, like Chef or Puppet, they are very hard to configure. Red Hat Ansible Automation Platform is agentless and pretty straightforward. It will reduce a lot of our headaches in general.

I rate the overall solution a ten out of ten.

We had a lot of manual labor. We had patching that was a manual process, and we had configuration drift. There were a lot of touch points. There were parts of the business where we knew that there could be a faster deployment and much quicker development and production. Ansible has increased our speed of deployment. We have a source of truth now. It has sped everything up, and it has saved a lot of people's time.

We've got on-prem and cloud deployment. We've got it in AWS, and we've got a proof of concept in Azure. We are looking at Azure SaaS, but at the moment, we don't know which way that would go.

We're realizing its benefits on a daily basis now. The biggest issue that we've had has been changing the way people work. We have a lot of people doing the work, and they all had a certain way of working. There were a certain set of tools that they used. We had to gradually migrate all of the tools that they were using to be more automated. There was a lot of code and a lot of tools on people's individual machines or shared drives. For example, User 1 had all of his applications and tools on his machine, and he might also have had some small scripts that he wrote personally on his machine. When User 2 came along, he didn't get to see what User 1 had because all of the scripts were on his machine. By automating more, we've put all of our code into a central repository so that everybody who is a member of that repository can see everyone's code. Nobody is siloed anymore. We have a lot more collaboration. There is a lot more progressive thinking in the way people are working. It is not where a bit of code is written for one specific purpose. It is always adaptable by just changing variables, etc.

It has effectively sped up everything from our sandpit environment to our full CI/CD process and our end deployment. Previously, we had to build everything manually in the sandpit. We had to build everything manually in the test environment, and we had to build everything manually in the production environment. Because we have environments that are matched all the way through, now, after we've built something in the sandpit, we can just promote that code. So, the copying of that code through various platforms has been eliminated with the use of Ansible and our repository system.

It has an easy-to-use interface. It is REST API driven, and it integrates with Active Directory. It provides the ability to grant permissions to other users who would not necessarily have those permissions via the GUI so that they could run other people's jobs. For example, you could have the Oracle team grant permissions to the Linux team so that they can use each of those playbooks or each other's code. It is called shift-left.

Ansible has just been upgraded, and the only issue that we are seeing at the moment is that the user interface can be slow. We're currently investigating the refresh period with Red Hat when you click a job and run a job. It seems that the buffer no longer runs in real-time. We haven't discovered whether that's partially an issue with our environment, but Red Hat has come back and said that they're working on a couple of bugs in the background. We've upgraded to that version in the last six months, and that's the only issue that we've seen.

There should be a more adaptive search feature. For example, if you had the name Mr. Smith, and you type in Smith, sometimes, it doesn't find Smith. You've to type Mr. first and then Smith. The search feature has certainly taken a little bit of a step backward from what we were used to in Ansible Tower.

I feel if we took this to the customer now and asked the customer to start using the product as it is, we'd be getting a lot of pushback because as an automation platform, it feels as if it is very early in its life cycle and development. I know that within Red Hat, a lot of the tests that they perform are automated tests. Somebody doesn't necessarily sit at the GUI. When you speak to Red Hat, they always say that a lot of the customers don't use the GUI. They might have got a front end or some sort of ServiceNow provider that runs all these jobs, but the search and job updates are the main challenges at this time.

It has been five years with Ansible Core and three years with the Red Hat Ansible Tower offering.

Its stability has been good. There are odd glitches within Ansible AAP, but within Core, there are no problems.

It is scalable. We just add more nodes if we need them.

It is used at multiple locations and in multiple departments, and our end users have multiple operating systems. There are probably over a hundred thousand users. We're going to put some more nodes in at some point in the future.

Their technical support has been good. Because we're a big organization, we have our own allocated SME within Red Hat, and we normally liaise with him. The Ansible support itself has been okay if we need to raise a ticket, but we're usually raising tickets just to get something on their system. We normally speak with the SME allocated to us, and he has been excellent. Our SME is called Pat, and I would rate him a ten out of ten. 

I would rate the support team within Red Hat an eight out of ten. The trouble is that if you raise a support case with Red Hat, they don't appreciate how much experience a specific customer has got or how much troubleshooting they've already done. So, the first thing they do is they'll ask for a basic set of files, which is understandable, but when we've already passed that point where we've already done all the checks, instead of going in at the first line, we need to go in at the third line to get something resolved. That's where Pat picks it up.

Positive

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. 

It was straightforward. The deployment took about a week.

We liaised with Red Hat. For Tower, we followed the deployment guide, and for the automation platform, we followed the upgrade process. We fed back any issues we had to Red Hat, and they were quick to resolve them.

There are ten people on our team, but not all of them were involved in deployment. It is a two or three-man job. We're all engineers.

In terms of maintenance, we have regular maintenance windows. Whenever there is a new version of AAP, we update it. We obviously run all our Linux patches on a regular basis, and we always sit and wait till we've done some testing on Ansible before we update the Ansible version on that box. There are ten people on our team, and we normally just pick slots between us so that the same person is not doing the same maintenance window all the time. The majority of it is automated, and it is just a case of somebody sitting in and checking that the job has run, and there haven't been any issues.

At the moment, it is just time saved.

I don't see the pricing or licensing features, but from what I understand, it is fairly reasonable.

Don't be narrow-minded. Don't be put off by adopting something that you've never worked with before. There is plenty of documentation out there to help you. It has a thriving community, and there is plenty of information online. Red Hat's documentation is also very good. You can get yourself up and running across a variety of platforms quite quickly by just looking at the Ansible site.

I would rate it a nine out of ten because there are a few quirks with the GUI at the moment. I would've rated Ansible Tower a ten out of ten. 

We just started using Community with Ansible. We are trying to install agents to either a cloud or a local virtual machine. We are still in the starting phase as it has only been implemented for two months.

My team thinks it is easy to work with, especially when working with the nodes. When the nodes increase, from say five to 15, I don't have to do anything extra.

1. There are so many models that I don't have to create one. I don't have to worry about anything. In these two months, everything was easily available.
2. Since it is in YAML, if I have to explain it to somebody else, they can easily understand it. 

One problem that I'm facing right now is the mismatch between the new version of Python and Ansible. Sometimes it's Python 2, and sometimes it's Python 3. When things get a bit dicey, I wish that Ansible would solve this issue by itself. I don't want to have to specify if it is Python 3 or version 2.

I haven't had any issues, but I have only been working with it for two months.

It is scalable enough for our needs. We are not working with hundreds of nodes, just ten to 15.

The community is enough for me.

The initial setup is pretty straightforward.

I researched with other tools, but I still chose Ansible. One reason, it was agentless. With other tools, I had to install agents. Ansible has a big plus factor being agentless.

We primarily use the solution for automation purposes. We also use it for CI/CD plus DevOps. So these are the three main uses. We can use it for operational automation plus DevOps. We handle applications, pipelines, deployments, et cetera.

With this solution, we're able to cover our client's needs. 

The automation is very good. The operational automation and DevOps are the most valuable features for us. 

It's easy to set up.

The solution can scale.

It's very stable. 

Now, there is a GitHub solution that came on the market. GitHub's integration with Ansible is adding value for the customer as GitHub has the capability to push/pull architecture plus it can bring in collaboration and versioning. As long as they continue to develop this integration, it will continue to be useful. What is next is to look into the infrastructure.

The improvement is already there in GitHub's capability. GitHub is already there, however, they can bring something like that into the solution as well too. They can bring AOPs capability. They should think of this product as an end-to-end solution and begin to develop it that way. 

The solution costs a lot. It's not cheap.

I've been using the solution for the last four years. 

The solution is extremely stable. that's why so many organizations end up using it. There are no bugs or glitches. It doesn't crash or freeze. It's reliable. 

The solution can scale well. It works for small or large enterprises. There is no limitation. 

Technical support has been good. We are very satisfied with the level of service we get. They are continuously improving their services as well. As long as they continue to improve we will remain happy.

Positive

The solution is very straightforward. It's easy to set up. It's not difficult at all. 

How many engineers you need to handle the implementation depends on the project and use case. It depends, for example, on how many automations will be created, et cetera. The time it takes to deploy also varies. Different use cases have different deployment times. 

Our company provides the implementation for our clients. We are able to handle the setup ourselves. 

We've seen an ROI. It is reducing the resources needed by the customers.

It's an expensive product. It's costly. 

We're charged between $8 to $13 a month per license. There are some limitations as well, however, specifically in AOPs.

We're partners. 

Which version we use depends on the customer If they have a license the latest is fine. We can also work with an older version. Whatever's possible we can do. We have the list of the scripts available, which can help us do the automation for the customer.

It's on the cloud we utilize Azure and AWS. It can also be used on-premises.

It's an effective tool. We weren't sure about it at first, however, it helps reduce resources and has been helpful to customers. 

I'd rate it an eight out of ten. 

Our use case for it is as an automation tool. For the Linux side, we have very few automation tools. We do have Puppet Enterprise as a matter of fact, and we're looking at tools for automating our day-to-day operations, server builds, configuration management, etc.

We've got a demo version of Tower. We've been playing with it, using it for patching. One of our first goals is to automate patching.

The improvement is going to come in that we are going to be able to maintain configuration management, through the use of both Puppet and Ansible. Currently, in a manual process, hands-on - that is what kills us. When we have a system administrator trying to do his job, that kills us every time. We have 2,500 servers and if a project comes to him, we have 15-minute time-outs. I don't like that. He'll go in there and he'll change it. And we can't control that and we don't know when it gets changed.

The hope is that we automate and then it's there, we know it's there. And then we'll use Puppet to come in at the back, and just maintain it. That is our plan.

If somebody tries to change something through Puppet, we're going to get reports. Ansible is going to be used on the front end, and if somebody comes up and says, "We need this patch pushed out. It's an urgent patch. It's high criticality. We need to do it now," we'll do it through Ansible. We'll write a Playbook or a module and just, boom, get it done.

The most valuable feature is the Playbooks and pushing them out.

We'll probably use it in conjunction with Puppet, because Puppet is more a solution where every 30 minutes it's going to check, whereas as Ansible doesn't do that. You have to push, from my understanding. That's what I thought. I could be wrong.

It has been stable so far.

It's scalable. We're looking at an enterprise configuration, when we get it done. It's a matter of getting it licensed.

So far, in our interactions with technical support, they've been knowledgeable. We're very happy.

The setup looks pretty straightforward. From what I've seen, although it was done by another person, it seemed to be pretty simple. I think it was an RPM.

We can use the solution for a group deployment if we have an infrastructure where we need to deploy software onto multiple machines at the same time. The tool should be on an Ansible server, and the server should be able to do SSH to the multiple hosts on which it wants to act.

We can automate a few host configurations using the product.

The solution must be made easier to configure.

I have been using the solution for almost five months. I am using the latest version of the solution.

The product is very stable.

The product is scalable. We can use it on multiple cluster levels.

The documentation is quite good. We don’t need to call anyone.

The initial setup is quite easy. The deployment took 15 to 30 minutes. The tool was deployed on a Linux machine. People deploying the solution must have some hands-on experience in Linux.

It’s an open-source tool.

I recommend the solution to others. Overall, I rate the solution a nine out of ten.

We use it for the bot. It helps to keep tracking all the automation processes that are ongoing in your ecosystem

It helps with patching and keeping everything compliant.

Automation tracking is the most valuable feature. 

The SSM connection access needs improvement because right now, they do everything through SSH.

I have been Red Hat Ansible Automation Platform for a few years. 

The solution is very stable. 

If there's some cloud add ons, we would increase the usage. Only admins use the solution. 

We just create a server, and then we use that server to on-premesis.

Ansible has good performance. Overall, I rate the solution an eight out of ten. 

We primarily use this solution for network configuration pushes. We use scripts from Ansible to push configurations to specific devices such as routers.

The best features are the orchestration and flexibility of the solution.

It would be helpful to have templates for common configurations. It would make it much easier and faster rather than creating a whole script. The templates would decrease the learning curve as well.

I've been working with Red Hat Ansible Automation Platform for a year.

Red Hat Ansible Automation Platform is quite stable. If you set it up correctly with the right configurations and there are no hiccups during installation and deployment, it will be stable.

I'd give stability a rating of eight out of ten.

It's a scalable solution. The capacity of the single instance is quite enough to hold up an enterprise. From a resilience perspective, you have to have a cluster that actually holds the whole thing.

On a scale from one to ten, I'd rate scalability at seven.

I would rate technical support at nine out of ten.

Positive

Once all of the components are in place, there are no issues with the initial setup. I would rate the initial deployment process at seven out of ten.

The deployment can take two days to a week depending on the requirements and resources available.

Red Hat Ansible Automation Platform is an expensive solution. There may be additional fees to use advanced features.

I would highly recommend Red Hat Ansible Automation Platform, especially to organizations that are moving toward a cloud or hybrid cloud infrastructure.

Overall, I would rate this solution at seven on a scale from one to ten.