We mostly utilize Ansible for deployment automation and CI/CD pipelines.

I have used some of the Ansible libraries for some of the deployments. The way conditions are handled in Ansible, such as skip conditions or failure conditions, can be complex with multiple conditions, but there is support for using them.

Additionally, the automation capabilities streamline deployment processes, providing reliability and reducing manual intervention and errors.

More library support for microservices architecture and Kubernetes would be helpful. There is also a need to improve the handling of conditions, which can be tricky and require the use of flags.

I have been working with Ansible for about six to seven years.

Ansible is quite stable. There are infrastructure-wise reliability and fewer issues, although network issues might cause some failures.

Ansible can face scalability issues, such as limitations when trying to scale up infrastructure. It might struggle with connection dropping or spawning additional VMs under certain conditions.

I have used both Ansible and Terraform. Ansible can lag when compared to Terraform for certain microservice deployments.

The initial setup can be challenging and is not very intuitive. A person needs to be knowledgeable in Ansible, and it should be well documented.

The benefits include the maintainability of the existing environment, especially a hybrid infrastructure. Ansible makes scripting and learning processes better and easier.

There is a pricing associated with Ansible, however, I find it reasonable.

I would recommend Ansible. That said, it depends on the infrastructure and whether an off-premises or on-premises cloud is used.

I would rate Ansible between eight and nine.

We use Red Hat Ansible Automation Platform for the automation of our servers and applications. We also use both Terraform and Ansible to automate our infrastructure.

Red Hat Ansible Automation Platform has saved our time and reduced errors in our processes. It used to take us two months to provide a server in our organization, and now it only takes a few minutes to have the same server. Automation has ensured that tasks are done in the same way every time, reducing the likelihood of errors.

The capacity to install products on the operating system is very valuable. Ansible is better at handling the final configuration of servers. We prefer Terraform for creating multiple resources in a project, but Ansible is better for final configurations.

Ansible's centric idea of servers needs to be changed. In modern infrastructure, there are more than just servers. The initial server-centric approach in Ansible is a bit strange. It should improve its functionality with cloud resources like Azure, AWS, or Google Cloud.

Ansible could also improve its capabilities in managing several resources at the same time, similar to Terraform. Moreover, more integration with other tools would be beneficial.

I have been using Red Hat Ansible Automation Platform for about three to four years.

The stability of Ansible is rated high, around eight to nine on a scale of ten.

We haven't experienced any problems with Ansible's scalability. We use it at the project level and create around ten to 20 resources. We haven't tested it with thousands of servers, so it's difficult to say how it would perform in such scenarios.

We are using the free version of Ansible, and so far, the support has been very high, considering that it is a free version. We are in discussions with Red Hat and IBM about possibly purchasing the commercial version when we start using Ansible for patching servers.

Before Ansible, we used BladeLogic from BMC. We switched to Ansible as it was easier to use, had more functionality, and there were more people in the market who knew Ansible compared to BladeLogic. Overall, Ansible is a much better product.

The setup of Ansible is easy. It's faster to start working with Terraform. However. Ansible's setup is also straightforward. The basic installation process is quick and effortless.

I recommend using both Ansible and Terraform for automation, especially now that both are under IBM.

I'd rate the solution eight out of ten.

We are primarily using Ansible for automation purposes as it is a configuration management tool. It is utilized for various activities such as DNS activity, changes to web servers, virtual host settings, and other day-to-day tasks, all of which are templated in Ansible.

Ansible allows us to manage a multitude of servers efficiently. We can deploy configurations and changes effectively and gather detailed reports. This means we have substantial control and flexibility in managing our servers.

I can do anything with Ansible. It allows control over thousands of servers, whether virtual or physical. The flexibility to manage deployments, configuration changes, and reporting is highly valuable. Ansible is containerized, making it easy to pull updated containers for automation.

There are challenges in using the graphical interface, particularly in open-source versions. The Subscription model presents some limitations, and there is room for improvement in making the Ansible navigator more flexible for open-source use. Installation can also be challenging, especially for graphical components.

I have been working with Ansible since 2012.

Ansible is very stable. There are no issues concerning the system's stability when managed with Ansible.

Ansible provides fantastic scalability. This tool allows us to manage a significant number of clients without limitations, making it suitable for large-scale operations.

I rate Red Hat's customer support for Ansible at nine points out of ten. Customer support for Ansible is excellent, and any issues we have encountered have been resolved promptly.

Setting up Ansible is relatively straightforward. Installing the core product takes about thirty minutes to an hour. However, fully setting up Ansible with additional servers might take around two to three hours.

The implementation is handled by myself and one other colleague.

There is a need for more flexibility in the subscription model, but I do not have detailed insights into the pricing and licensing setup.

I'd rate the solution nine out of ten.

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.

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 are primarily using it to update OpenShift as well as managing more than 800 Windows servers and about 50 Linux or Red Hat Enterprise Linux servers.

The main benefits are reducing server configuration drift and building new servers or updating software on servers in a very consistent way.

My team manages all of the server platforms. We are the middleware team. We support EAP, OpenShift, and the whole gambit. Being able to consistently configure those machines and the software on those machines so that the applications run in a consistent way, good or bad, is key. Even if it is bad, at least it is done consistently. We can pinpoint the problem, make changes from the playbook, and reapply it. We can get it corrected in a very consistent manner, and we do not actively skip a host. If somebody is manually making changes, we know where that goes.

I would rate Ansible Automation Platform very highly for helping to reduce the number of steps involved in automating things. After you develop your playbook, that playbook consistently runs, and the playbooks are not difficult at all. Once you understand how Ansible works, it is straightforward. Even on a Windows platform, it is not difficult at all. However, writing new roles is a different story. I have written a couple of those. I have about a dozen or so custom roles written in PowerShell to run on Windows. Even for that, the documentation was not bad.

Ansible Automation Platform can help reduce the training required to learn how to automate things. I can give somebody a playbook, and if the author of that playbook follows our standards of documentation, it eases that quite a bit. However, we have some playbooks that are pretty complicated. In those cases, they have to understand what it is doing under the covers. Onboarding to Ansible is pretty straightforward once you get the handle on what tasks are there and what to do in the pretask and the roles. Once you grasp that concept, especially the concept that every task and every playbook will run concurrently on every host which is a hard one for people to grasp, it makes a lot of sense. This reduced training has affected our operations or business.

We use the platform's collection of certified content. It is very good. We can find things easily for Red Hat Enterprise Linux. If we find something for Red Hat Enterprise Linux but cannot find it for Windows, we will model the Red Hat Enterprise Linux version to create one for Windows.

Ansible Automation Platform has helped to reduce the time we spend on low-value or repetitive tasks. I can give a good example of that. We are also a Dynatrace shop, so we have set up monitors for our certificates on our servers. Dynatrace is alerting us when certificates are 30 days out. We have not yet hooked it up to the automation platform, but the next step is to do that. It is going to run the playbooks that are already there to renew those certificates. After that, we are going to integrate it with ServiceNow to open a ticket when it does that and close the ticket once it succeeds. We are moving down that path, but we are not quite there yet. As an example, we have to renew every single certificate in about three months. I have one playbook that we can run across all of our servers. Regardless of the type of application that is on that server, that playbook will renew the certificate from our certificate server. We will download the certificate to the machine, implement it in Windows, export it from Windows, convert it to the format that the application needs, be it a key store or a PIM file, load it into the application store, and then restart the process of that target application. If you try to do that by hand, you can just forget it.

The development tools are decent and being able to consistently manage those servers is really the key, which is why we went with Ansible in the first place.

There should be better Windows support. We have had to develop a lot of our own roles because of the Windows platform. The Red Hat Enterprise Linux ones existed but not the Windows versions, so I have had to develop a bunch of Windows ones.

We have been using this solution for about three years.

It is stable.

It is scalable. Especially on OpenShift, you can scale it out pretty easily.

Their customer service is good. Their technical support experience varies. If you open your ticket with the correct information, and you can direct it to the right person, you get excellent technical support. If you do not know how to open your ticket, you might end up in a different group or with a different person who does not really know, and then you have to bounce around a little bit. You have to be very careful how you open your ticket.

I would rate their support about a nine out of ten. We run JBoss queues, and we run it on Windows. If we have a problem, we get people who do not know anything about Windows. They often give us solutions for Red Hat Enterprise Linux, but we know that it is not going to work, so there is a little bit of that. I cannot blame the support person for that. I just have to ask him to give me somebody who knows Windows.

We started out with Chef and threw it away.

In terms of a competitive platform, I was forced to use SAS. I hate it. My team only uses Ansible. We do not need to use SAS anymore. There is no comparison between the two. Ansible is so much easier to use, especially once you get the grasp. At first, you are going to say, "This does not really make sense." After you have written your first playbook and you can see those benefits, it makes a big difference.

Ansible Automation Platform has reduced our costs by more than the competitive platform. It allows my team to focus on more important things than day-to-day routine. Ansible takes care of that in the playbooks. We can focus on new enhancements, new features, and new products. It frees up our time. There is a good 30% to 40% time saving because we were doing a lot of things by hand. We now do not need to do that.

We use other Red Hat products. We use Red Hat JBoss EAP, SSO, and Fuse. We still have Fuse in production. We have not migrated from it yet. We are using Red Hat AMQ as well.

We chose these Red Hat products because even though our platform is Windows, we are a Java shop. Almost all of our custom apps are written in Java. When we were looking at the platform to run those applications, EAP was really beneficial cost-wise. Especially because I came from a WebSphere background, migrating over to EAP was cost-saving. The applications required very little rework the way we architected it. We did not use WebSphere-specific classes. We tried to stay Java agnostic, so it was really a cost-saving for EAP, and then with the support we got from Red Hat, EAP was the front runner. Fuse came into play when we needed a service bus, and then from there, we got SSO. We needed to connect our applications to Okta, so SSL came into play for that, and then from there, OpenShift came into play. One thing led to another.

We switched to OpenShift because we were a big Fuse user. With the Fuse going end of life, we decided on our natural path. We had a bunch of our routes and other things written in Camel. Our natural path was to migrate to Camel in spring and run it in OpenShift. That is what brought OpenShift into play. I wanted to bring it in for a long time, but that gave me a good bargaining chip to get it in-house.

The benefit that we have seen from using these Red Hat products is that we have had very little downtime that was not scheduled. We have availability, uptime, and support. Once they are set up and configured using Ansible, they just run. We rarely had a problem where we had to open a support ticket. Every once in a while something quirky goes on but not that often.

We are deploying to OpenShift. It is on-prem OpenShift.

The barebone deployment was pretty simple. We started to configure it to talk with our Active Directory server and then our certificate server. We use Thycotic secret servers for our secret store. We had to integrate with the Thycotic secret server, but once we figured all that out, it was straightforward. It took us a couple of months to get there. We had to export our host inventory. We use SolarWinds to manage the host inventory. We wrote a script that exported that host inventory from SolarWinds and created the Ansible inventory from it. We are still using that. We run that every hour or so. It runs automatically and updates the inventory. Overall, the deployment was simple. The configuration was a little more difficult because of our environment.

We create all of our Ansible configurations as code, and we apply it all through GitHub. We do not configure Ansible manually.

We initially used an integrator when we were implementing Ansible Tower. They were pretty decent. They leaned more toward Chef than Ansible, but we overrode them.

The ROI is in resource hours and allowing those people to do other things. It reduces the time to debug problems because you know things are going to be done in a certain way on the playbook. We have made it a strict policy that people do not make manual changes. If you have to make a change, you are going to go back to the playbook and make that change.

Ansible is a lot more competitive than any of the others. Its setup was also straightforward. In fact, we just implemented Ansible on OpenShift, so that is how we are running the Ansible Automation Platform now.

We started going down the Chef path, and it was harder to use and harder to understand than Ansible. We started with Chef and then we thought of giving Ansible a try, so we started in parallel, and then we threw Chef away in about two months. I said, "I want this set of tasks done on this server. Do it in Chef and do it in Ansible."

We did not evaluate anything else. The other choice we were given was Microsoft Windows's version and I did not want to go there because I have machines other than Windows. I do not have a lot, but I do have machines other than Windows.

Ansible Automation Platform has not helped us connect teams, such as developers, operations, or security so that they can automate together. In our organization, getting security involved is like pulling teeth. They say, "You got to meet these standards. Go figure it out." They set the standards, and we have to implement them. I cannot get them involved in anything other than them telling us what we have to implement.

There are not a lot of Windows users like us. We have made it work very well. We had to do extra to get there, but it was not that much.

I would rate Ansible Automation Platform a nine out of ten. I do not give tens. If we push one button and it is set up and works with everything, I would give it a ten, so that is never going to happen.

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.

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 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 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 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.

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.