Red Hat Ansible Automation Platform Reviews

We use it for everything. We use it for provisioning servers, configuring servers, auditing servers, and generating tickets to define a task for the things that we find.

The key to automation is standardization. You need to be able to make certain assumptions safely. As you automate more things, they say, "Well, why don't you do this?" You then say, "I cannot automate this because I cannot confidently predict this. There are too many variables." So, it makes people think that they have to do it this way or they have to be more consistent about how they do something. Consistency and standardization are something that has been lacking at least in my organization, whereas now, with the demand for automation, people are like, "You have to fix this if somebody else is going to help you with their automation." It is starting the dialogue. We are trying to figure out why people are doing things and we are coming across a lot of stories such as people are doing something for a reason that is no longer valid, but they just thought this is the way it always had to be done. They did that for a very specific reason. That reason is gone. They do not have to do it that way.

Ansible Automation Platform has a huge part in helping to reduce the number of steps involved in automating things. There are a lot of different groups within the organization that have achieved automation in their own way, and it worked for them. However, Ansible is a pretty consistent and easy way that everybody can use. It is much more approachable than some of the other methods that other teams have opted to use. At the end of the day, those teams may be using very advanced and pretty complex tooling. However, for the sake of making it continuous and for being able to integrate with teams that are using automation that is not as complex but still just as meaningful and necessary, they agree to do it this way. It is getting everybody in the same language and the same plane for us.

Ansible Automation Platform helps reduce the training required to learn how to automate things. I have seen places that have sent teams of people to get trained, but we have much more of each one, teach one approach. That worked for us.

We are getting to that point now where we will be able to reduce the time we spend on low-value or repetitive tasks. We often had very skilled people doing very mundane tasks, but we have gotten to a point where we have written automation, and we have written playbooks and given them to people who may be in a technical role but are not necessarily as technical as some of their other counterparts. A good way to put it would be that if you have two people who are assigned to clean a room, somebody got to vacuum and somebody got to dust. With Ansible, people who like to dust can dust. People who want to do the windows can do the windows. Previously, everybody had to do their own windows and their own dusting. It gives people the opportunity to specialize in what they are good at.

The ease of being able to use the modules and collections to define what our business processes are is valuable. We are able to give non-technical people the ability to look at a process and say, "We need a step here. Someone do something and put it right here." Previously, if we tried to tell a non-technical person to look at a bunch of code, they were not able to do that. It was meaningless to them, but now they have the ability to see. They may not understand everything, but you can describe what is happening. It makes it a little easier for them to understand the technical process from a business aspect.

There should be consistency. I know that it is always changing, but when we are trying to get some users to do something in basic Ansible that they are not really interested in doing but their job requires them to do it, they start finding inconsistencies. A good example of that is that we have people who are trying to automate things with Windows and Active Directory. There is a community version of the Windows collection that deals with Active Directory. You can use a lot of that code as it is described. It works with the certified Microsoft Active Directory collection if you take the same information because there are the same parameters and values, and the only thing that changes is the collection name. If you switch that out, it does not work, so having a new person run into a problem that even a seasoned person cannot understand does not work. It turns them off. You want them to have success early on. Sometimes in Ansible, you run into some inconsistencies that you do not understand and then you are concerned because it says, "We are going to deprecate this." You are like, "How long do I have to keep using this thing that is going to be deprecated before I have to move on to this other thing?" That just does not seem to work.

I have been using this solution for about four years.

It is stable.

It is scalable.

I was fortunate enough to bump into Sean Sullivan. He wrote the book Demystifying Ansible Automation Platform. If I have trouble with something, I find him and send him a message directly. He has got all the answers. Early on, I submitted some trouble tickets for things like the installation did not work, and they were able to eventually help me, but now, I don't even think to use them. I go directly to Sean.

Neutral

Prior to Ansible, I used Puppet for configuration management. Some people would say that Puppet is a competitor to Ansible, but I do not feel that it is. You can do a lot of things in Ansible that you can do in Puppet, but there are a lot of things in Ansible that you cannot do in Puppet. There are some things that, ecosystem-wise, Puppet does better, but at the end of the day, I can do everything that I need to do with Ansible. It may make our workflow a little more convoluted, but some of the things that I definitely needed to do with Ansible, I cannot do with Puppet alone.

For us, there were not any competitive platforms. The competitive platform for the Ansible Automation Platform would have been AWX, but that is not a solution that I would encourage anybody to go to and try to run production on. You can go for it, and I have seen people do it, but in our situation, it was not the best. Before we got to that point, we tried to replicate it by using Jenkins and a bunch of manual tasks, and it took a lot of MacGyvering to get that platform to work. Every so often, something would break. Instead of spending time on automation, I was spending more time trying to fix the tools. I want to work on automation. I want to drive the car. I do not want to work on the car. For us, there is no competition when it comes to ease of use, but there are some other teams that have the time and resources to have somebody driving while somebody else is working under the hood. For us, that does not work. On the flip side of that, I have to say that if you have something that is not breaking all the time, those people who used to spend their time fixing the breakdowns can help with automation. They do not have to worry about changing the tire. They can take a turn driving for a little bit.

We tried AWX which is the upstream project from the automation platform. We did try to use that. Going forward though, we may try to minimize our footprint on-prem, and we may start using the automation platform in Azure because we use Azure, not AWS. That is going to be my selfish attempt to get into the public cloud because I do not want to have to maintain the on-prem infrastructure for our automation anymore. 

We use other Red Hat products. Besides Red Hat Enterprise Linux and Red Hat Automation Ansible Automation Platform, we have Red Hat Satellite. Those are our three main products. I chose these products because I have been doing this for a long time. I have worked at a lot of places that like to just use free, open-source tools. I am all for open-source tools. I even like the free ones, but at some point, I started working at a lot of places where I did not have the time to troubleshoot and investigate some of the issues that come up when you are using a free and unsupported product. It helps me a lot to be able to say, "I want to stop working on this because I ran into an issue. I want to raise a ticket with Red Hat." I have a whole army of Red Hat specialists who can figure out and put me in the right direction instead of me losing so much time trying to figure out one thing, and often, not being able to figure it out on my own.

My utilization of Red Hat products has brought me in contact with a bunch of people who have been super helpful, and in turn, I have been able to figure out a lot of things and help others in return. There is the community aspect. There is also a certain level of confidence. You know you are working with things that the major companies are using. There are a lot of things you can do with other tools, but at the end of the day, you have to realize why you are doing a lot of extra work when you do not have to. Red Hat seems to be in the center of everything. A lot of the other products that other people opt to use in some way, shape, or form are byproducts of what Red Hat is doing. Why get a cheap knockoff?

We are considering using OpenShift, but it would involve replacing the product that a lot of our business processes heavily rely on, and OpenShift cannot necessarily replace those things. Those functions can be replaced, but it would not be in OpenShift alone. To get rid of one thing, we may have to replace it with two. We are just trying to evaluate the feasibility of it.

We do not use Red Hat solutions in the public cloud. Our business is not mature to a point where we can leverage a public cloud effectively or efficiently. A part of that comes from just vendor issues where the vendor is like, "This is how you do it. This is very monolithic." If we did that in the cloud, it would cost us a lot more money. It is not very efficient, so we do not use a lot of public cloud stuff, but we are trying to be more modern. We understand that there are some things we cannot put in the public cloud but there are things that we can. We are not able to do it right now, but we are trying to get those things in place, so education is a bit slow to follow everybody else.

We use on-prem traditional VMs. We do not use OpenShift. 

I did not like its initial deployment experience. I still do not like it. Once you do everything that needs to be done, it is straightforward, but there is a lot of tinkering around. Do not get me wrong. They tell you exactly what you need to do, but Ansible does not like some of the things you may have to set up when you are building systems that are CIS-compliant. For example, for things like file system mount properties, you have to have execution enabled. It is fine. I can change that, but you build a bunch of systems, and you do the installation, but it does not work. Why did it not work? The install instructions did not take into account that we may have these restrictions that are on a partition that they are using. It is not their fault and not our fault. We got to meet in the middle somewhere. I wish the deployment was a little easier. I wish there was a single license that they could give you for OpenShift or something like that so that you could spin up a small OpenShift cluster. Even if it is a one-machine type of thing that is not going to help you with your load balancing, high availability, or anything like that, just being able to spin up one instance, put the Ansible controller in there, and let it operate would have been great. That would have been ideal.

We deployed it on our own.

It is hard to quantify the cost savings because everyone was so secretive about what they did, and the time that it took them to get the work done was not really being counted for. People were doing things at night, and people were doing things on the weekends just to keep up, so it was never accounted for. It is hard to quantify what the cost savings are, but at the end of the day, we have not had people leaving because they are burned out and they are overworked. I feel that there are cost savings in some way, shape, or form. I could not put a dollar amount on it. There is something about working with the same set of people or seeing a bunch of people leave which just starts a trend of other people leaving.

My goal is to make it so that my job no longer exists. That is not a very smart goal, but I have to make sure that I have enough stuff in place where I am not needed. Somebody can walk in behind me and say, "I see what is happening here. I can continue this." I feel like I am getting there. In my heart of hearts and my dream of dreams, I would like to be Mary Poppins. I swoop in with my umbrella, do my Ansible stuff, get everybody to see how it could go, and get them doing it themselves, and then I will be off again down somewhere else. Ansible has allowed me to get other people to see how it can be done and be less reliant on anyone to do this.

We have to be mindful of how we use Ansible because of the licensing model. I am not saying that it is unfair or we do not find value in it. Because we are trying to automate so many different things, we have to be mindful of what we are doing and how we are doing it because we are trying to stay in compliance with it. I foresee that we are going to need more licenses, but management would like to see us use the same, if not less. I can hope and see how that goes. 

We used Puppet because that was the tool I was familiar with and was built into Red Hat Satellite, but once they said that they were switching everything to Ansible, that was a good reason to say that we are now going to use Ansible.

There are a lot of people, especially in the higher education space, who have been there for a very long time. The motivation and ability to draft in something as simple as Ansible is just not there for them. It is an opportunity for people who embrace automation, Ansible, and things like that to talk to the more senior people or the people who do not understand the Ansible aspect of it. They can start that dialogue and convert what is in their head and their older methods to getting things done into Ansible. Once we start doing that, we are able to daisy chain some of those different processes and tasks, and we can find different areas to improve and standardize. That has been a key to our organization. There are some people who we just would not be able to force to do automation, but it is easy for somebody who knows automation and Ansible to talk to them and say, "I do not know exactly what you are doing, but if you tell me, I can convert it into Ansible code for you?

In a perfect world, Ansible Automation Platform would help connect teams, such as developers, operations, or security, so that they can automate together, but we are not there yet.

I would rate Ansible Automation Platform a nine out of ten. The small areas of improvement that I would like to see probably are not there for technical reasons. There are a few things that I would like to see, but everything else is there.

We primarily use it for network automation and security or CVE resolution.

We save thousands of hours a year doing security updates and configuration updates. We save our administrator's time by pushing updates. It is a one-click solution, and all they have to do now is pull down whatever they need for their configs. It saves about 4,000 man hours a year.

If you imagine Tier 1, 2, and 3 administrators, I am sitting more at the Tier 3 level. We are able to push out more complicated configurations. We can do just an SSH push to thousands of devices. It saves the time of our administrators from having to go into the console of every device. They do not have to SSH into every device and manually type in those configs. We can resolve security issues within a matter of minutes rather than days.

You have the initial big push to get Ansible set up and running in the environment, but once it is there, any tweaks or changes involve just edits to the code base, and you are good to go. It is not at all intensive.

Red Hat Ansible Automation Platform has not reduced the training required to learn how to automate things. We are starting from scratch, so there is always going to be a learning curve associated with it. The more you peel that onion, the more involved it gets, and the more you have to learn about it.

Red Hat Ansible Automation Platform helps connect teams, such as developers, operations, or security so that they can automate together. It is hard to get anything done if all of those players are not talking. Knowledge bases are not siloed anymore. Previously, we did not have a cross-talk or sharing of information. Now that we have the platform, we have to share knowledge back and forth where we are pushing an update and they are telling us what is broken. There is constant feedback. There is a good feedback loop.

Red Hat Ansible Automation Platform has helped to reduce the time we spend on low-value or repetitive tasks. It is hard to quantify the time savings because of the mass scale at which we use it, but it would be within thousands of man hours a year.

My guess is that Red Hat Ansible Automation Platform has saved us costs, but I am not in a position to see those numbers.

When you have an enterprise-level number of network devices, the ability to quickly push out security updates to thousands of devices is the biggest thing.

At this time, I do not have anything to improve. What we struggle with is the knowledge base, but that is more about us having to go and find it and learn the platform on our own rather than an actual Ansible issue.

I have been using Red Hat Ansible Automation Platform for the last eight months. 

It is pretty good. Usually, if we have any issues, they are user-induced. When Ansible goes down or there is an issue like that, it is usually something we have done at the backend rather than Ansible itself.

It is very scalable. The way we use it is that we tie it in with another app to touch all of our devices and to deploy any configurations or whatever we need to push. Our code base sits on Git, and then we use another company for monitoring our devices. With one tower, or two for redundancy, we are able to push to more than 5,000 devices.

It has been good so far. There have been a few cases for which we reached out to them to get some help. I have not interacted with them personally, but I have heard good things. I would rate their support an eight out of ten.

Positive

I have not used any similar solution.

I was not there when we set it up. In terms of the deployment model, we still have one that is in the VM, and we are also using the containerized version. It is still Ansible Tower.

It has saved us thousands of man hours.

I was not there when we set it up. We have been using it for about four years. I am not sure about what happened before then.

I would rate Red Hat Ansible Automation Platform a nine out of ten.

We use the Red Hat Ansible Automation Platform to configure our infrastructure. It is mainly used to configure the whole activity.

Red Hat Ansible Automation Platform is a good choice when you have different distribution platforms. If you have an infrastructure with Ubuntu, VPN, and Red Hat distributions, Ansible can integrate these platforms through a small inventory file, such as a custom image or file.

The role-based access control (RBAC) feature is the most valuable, especially when used with Azure Galaxy Infinity.

Ansible is good at managing applications or devices on the existing infrastructure but cannot provision those devices.

The tool should allow us to create infrastructure. It has everything when it comes to management, but it lacks the provisioning aspect.

I have been using the Red Hat Ansible Automation Platform for three years. We're using the latest version of the solution

The solution’s stability is good. I rate it a ten out of ten.

I rate the solution’s scalability a ten out of ten.

The customer service and support are good. It is good if you know how to create and operate it, but it can be difficult for someone who does not have the knowledge of how to configure the YAML file. There is some technical difficulty here. 

Positive

The initial setup is straightforward.

We have seen an ROI as we are still using the Red Hat Ansible Automation Platform.

The pricing is okay.  

I would definitely recommend using the solution. Overall, I rate the solution a nine out of ten.

I use the solution for all kinds of automation, network automation, compliance security, software installation, and software configuration. I started using the solution as a configuration management tool, and now I also use it for automation. I also use Red Hat Ansible Automation Platform within the CMP platform Morpheus.

The most valuable features of the solution are its configuration management, drift management, workflow templates with the visual UI, and graphical workflow representation.

The solution should add a nice self-service portal.

The standard single-node installation is easy. When you have a protection grade installed, and the customer wants DR, it creates a problem. For example, if you have the database built in, but the customer wants to use RDS, you have to tweak it. Then, you have to use the governance policies and everything accompanying them. Some customization takes place, but overall, it's easy if vendors use a straightforward method.

I have been using Red Hat Ansible Automation Platform for many years.

Red Hat Ansible Automation Platform is a very stable solution. I rate Red Hat Ansible Automation Platform an eight out of ten for stability.

Around 10 users use the solution in our organization, a presales and sales company. Around 1,000 users used the solution in my previous organization.

I rate Red Hat Ansible Automation Platform a nine out of ten for scalability.

The solution's initial setup is not it's not hard. The steps to install the solution seem to be easy.

Users have to pay a per-node cost of around $ 100 per node. The solution's pricing depends upon the volume.

Users have to lay out how they want to build the solution. They should first build smaller job templates and then add them together to build workflow job templates.

Overall, I rate Red Hat Ansible Automation Platform a nine out of ten.

Our company use the solution to automate IT for many government use cases. 

The solution is capable of integrating with many applications and devices in comparison to BigFix. 

The infrastructure and user controls are much easier to use than BigFix. 

Community support is always available so it is easy to get direct information. There is a lot of basic, enterprise-level, and governance-level support. 

The governance features could be improved. 

I have been using the solution for four years. 

The stability is okay for our project. 

Large organizations like us have workloads for 55,000 people so need enterprise-level features. We are with the government so we have a lot of important data. 

The solution is scalable up to a point. There are some issues at the enterprise level. 

Technical and virtual support are top notch in any issue. There is a lot of community support available at all levels. 

The initial setup was a bit complex. Some of the web addresses were not working on the technical or management levels. Our team was very focused on policies and secure environments. Our team level is different from company management. 

We implemented the solution in-house. 

The solution is inexpensive compared to other products. 

The solution is not the best fit at the enterprise level because there are issues with reporting and websites when handling 24,000 servers. In this scenario, I rate the solution a six out of ten. 

The solution is a good fit for smaller or medium-sized businesses with up to 10,000 servers. In this scenario, I rate the solution a nine out of ten. 

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.

Our company uses the solution for automations, patching, scheduling, and installations. 

We have 500 users throughout the company and two or three people per team who handle ongoing maintenance. 

The solution has improved our productivity and functionality. The automations we have done for patching save a lot of time and effort for many users. 

We always have plans to increase usage because we have automations in the pipeline for installations and patching. 

The solution is very simple to use and we chose it for the simplicity. 

Being an Agent Plus makes our lives easier. 

There is always room for improvement in features or customer support. 

I have been using the solution for three years. 

The solution is stable with no issues. 

I am a user so am not familiar with scalability. Another team handles the platform and its scalability. 

Technical support is good and very helpful. 

I rate support an eight out of ten. 

Positive

We previously used Puppet. 

The setup is pretty straightforward. The government on our side makes things a bit tough but that has nothing to do with the solution. 

We implement the solution in-house. 

We also considered UDeploy but did not get to the point of comparing it to the solution.

The solution is a wonderful tool and is simple to learn and use. There is much flexibility in the open-source environment when using the solution. 

I rate the solution an eight out of ten. 

We can use it to configure or to change the configuration in a large number of servers. Also, if there are some issues in comprehension, for example, permission or ownership, we can fix that with the Ansible label. 

We can use other advanced features. Currently, for example, we are using BigFix for automation. We use Ansible since it doesn't need agents to install on every server. For BigFix, in contrast, you do need to have a BigFix agent for every server. Not having to do that with Ansible is a benefit for us.

The Ansible automation platform helps us achieve our goals. It is easier to handle and easier to understand. We can learn it easily, and we can share it with colleagues also very easily.

New colleagues and new people can understand the solution very well, making it quick for onboarding. 

It is easy to manage. If we make a playbook, we do need to have some skills in scripting or skills for the AML file. However, once we do, we can easily handle the issue.

We are just starting to use the solution. I can't speak to improvements, really. So far, I am more comfortable with this product than the previous one. Once we start using it heavily, maybe we will see issues.

I've been using the solution for one year.

The solution is stable. Some colleagues and other companies use it and comment that it is easy to use, easy to understand, and offers good features. They're very positive when discussing Ansible. 

The solution can scale. It can cover large amounts. Many other companies also use it successfully.

We have more than 600 Linux servers. We are using it on all the servers. 

We use Red Hat a lot. I open tickets for the Red Hat cases, however, with Ansible, I haven't opened any cases. My manager worked with them a bit.

If we have a problem with some file and we need to get Red Hat to analyze the issue and the file is 100GBs, we'll have an issue since we need to provide a log file for them to analyze. If it is around 12GB or 13GB, we can easily upload it to the Red Hat portal. With more than 100GBs, it will fail. I heard it should cover up to 250GB for an upload, however, I find it fails. Therefore, Red Hat needs to provide a way to handle this.

Positive

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.

I was involved in the initial setup. I use it in the lab server for now, and it is good. It is going to be in production soon. However, we already deployed it in lower environments, like the QA and development servers.

We might see an ROI soon. 

Previously, we had BigFix and considered other solutions. However, when Ansible came in, and we studied it a bit, we felt that it would be easy to understand and easy to implement. The learning curve was small. 

We are a contractor of the client. We support the client, so whatever the client needs, we use and provide. Our client owns Red Hat, and therefore we use it.

Our operating system is Red Hat. We chose it due to the fact that it is open source. In Red Hat, we can use VMware or physical servers or the cloud and find Red Hat to be easy to use, secure, and user-friendly. Also, if we use all RHEL products, they are all compatible with each other. If we use a third party, we might have issues. With RHEL products, it is already tested on the RHEL side, so we don't generally see issues. 

It's one of the best products to use. It is easy to understand and easy to manage. You can use it if you have a cloud, physical server, or VMware. It is very good and offers operational efficiency.

I would rate the solution nine out of ten. We like it, and we feel good about its capabilities.