Red Hat Ansible Automation Platform Reviews

My main use case for Red Hat Ansible Automation Platform is managing servers through automated deployment, automated management, security patching, and everything in between.

For automating deployments or security patching with Red Hat Ansible Automation Platform, we use it for Docker Swarm clusters. We install Docker and automate Docker deployment inside the Docker Swarm, checking which are the master nodes and which are the server nodes and connecting them to each other. All of these things are maintained by Red Hat Ansible Automation Platform.

I have around 100-200 servers that we need to maintain through security patching. We need to perform sudo apt update or install packages inside them and maintain those servers. For that, we use Red Hat Ansible Automation Platform. We maintain an inventory file and execute everything from there.

The best features that Red Hat Ansible Automation Platform offers is that it does not require any additional resources inside the servers. Python is the only requirement, and since Python is already present inside the servers, we can run it from our location and it automatically deploys things and does the work for us.

The minimal requirements and easy deployment have definitely impacted my daily work and my team's efficiency. Red Hat Ansible Automation Platform is one of the best features that we depend on. We have evaluated other options, but Red Hat Ansible Automation Platform was the best choice because it has saved us a tremendous amount of time. We do not need to manually intervene in the servers or install third-party software to maintain these things.

It is very easy to write playbooks for Red Hat Ansible Automation Platform. Ansible Galaxy contains many playbooks that are readily available and ready to be used. It is highly configurable with Jinja templating, making it easy to maintain.

Red Hat Ansible Automation Platform has positively impacted my organization. Previously, we needed to go into the servers and maintain them manually, which used to take a lot of time. For 200 to 300 servers, the maintenance took about one to two months. New patches would arrive and we would have to repeat the process. Now, it is a one-night work or a 10 to 15 minutes task. We write a playbook, maintain an inventory, and roll out the updates and it starts working for us. Red Hat Ansible Automation Platform uses conditional clauses and has rollback options, functioning like a standard coding language that is simple to use.

There is definitely a reduction in errors with Red Hat Ansible Automation Platform because we have playbooks written with all the necessary clauses and rollback options. Manual work automatically creates more errors, whereas in automation, we have written sets that we do not forget every time we run it. We have protected written sets that we execute consistently.

Red Hat Ansible Automation Platform could benefit from improvements in certain areas. Red Hat Tower is available for enhanced functionality, though it operates on a paid model. I found that acceptable.

Otherwise, Red Hat Ansible Automation Platform is very easy to use with Jinja templating capabilities that make it really straightforward. I do not believe there is anything that could be improved with Red Hat Ansible Automation Platform that we have not already discussed.

I have been using Red Hat Ansible Automation Platform for the past eight years.

In my experience, Red Hat Ansible Automation Platform is very stable.

Red Hat Ansible Automation Platform is highly scalable. We are currently using 200 servers and we are adding more servers each day. Red Hat Ansible Automation Platform is easily maintainable and highly scalable.

We are not using Ansible Tower for customer support, so we do not receive official support. However, Red Hat Ansible Automation Platform has a large community with many written blogs and resources available, making it easy to maintain.

My experience with pricing, setup cost, and licensing for Red Hat Ansible Automation Platform was very simple. There is no pricing and no licensing required, as Red Hat Ansible Automation Platform is always free to use. If you do not use Ansible Tower, then it is definitely free and easy to maintain. Writing playbooks is just like writing a simple Bash script or writing code with clauses and everything.

I have seen a return on investment with Red Hat Ansible Automation Platform. We need fewer employees and have saved significant time. The work that previously took two months now takes 10 to 15 minutes. Red Hat Ansible Automation Platform is automated, so we do not need as many employees to perform manual work. We have fewer employees, which also results in cost savings.

My experience with pricing, setup cost, and licensing for Red Hat Ansible Automation Platform was very simple. There is no pricing and no licensing required, as Red Hat Ansible Automation Platform is always free to use. If you do not use Ansible Tower, then it is definitely free.

Before choosing Red Hat Ansible Automation Platform, I evaluated other options such as Chef and Puppet, but I did not use them.

The advice I would give to others looking into using Red Hat Ansible Automation Platform is that it is one of the best Ansible management tools available for servers. You should start using it. Red Hat Ansible Automation Platform offers Jinja templating where you can write your own templates and NGINX configurations. It is very simple to use and you do not need any extra server or additional infrastructure. I give this product a rating of 9 out of 10.

I have created resources for the monitoring tech stack with Red Hat Ansible Automation Platform, especially for setting up one master data center and another data center for different applications routed to the monitoring setup, where I have created Splunk servers and installed all Splunk agents and prerequisites with the help of Ansible, including an Ansible playbook.

I have used the agentless architecture in Red Hat Ansible Automation Platform, as SSH is agentless.

I use a centralized automation controller in Red Hat Ansible Automation Platform, called the master setup, where we execute our commands with installed prerequisites, inventory information, and the Ansible playbook, managing other node servers with a passwordless setup.

When creating any server with Red Hat Ansible Automation Platform, it is a significant advantage because if we set up a Splunk agent in one case, it is necessary for each server. By writing the playbook, the agent is installed immediately during server provisioning, providing us with an edge.

Red Hat Ansible Automation Platform is very helpful due to passwordless integration and the ability to interact with multiple servers at once, which is especially advantageous when dealing with thousands of servers.

The integration aspect of Red Hat Ansible Automation Platform has optimized my IT ecosystem significantly by consolidating multiple tools, such as a CI/CD pipeline with Jenkins, where we validate everything, including testing and SonarQube code quality.

The agentless architecture of Red Hat Ansible Automation Platform, using the SSH key, makes it passwordless and allows us to push configurations with one click, creating a major advantage.

Red Hat Ansible Automation Platform's main benefit is that it allows us to push configurations to multiple servers without manually visiting each one, maintaining efficiency.

I have observed that Red Hat Ansible Automation Platform could improve by creating modules for upcoming AI and ML tech stacks, as currently, specific modules for these are not available.

I have worked on Red Hat Ansible Automation Platform, especially Ansible Playbooks, for around three years.

I have not encountered any performance issues, crashes, downtimes, or limitations with Red Hat Ansible Automation Platform.

Ansible is a Red Hat product, so they provide all necessary support.

I have not escalated any questions to the Red Hat support team regarding Red Hat Ansible Automation Platform, as their modules are professional and complete.

Positive

Both Red Hat Ansible Automation Platform and Chef have similar capabilities but differ in architecture; one is agentless while the other is agent-full.

Setting up Red Hat Ansible Automation Platform on the AWS cloud is very straightforward; I take one server, install Ansible, set up the inventory, and use it.

By using the enterprise version of Red Hat Ansible Automation Platform, we receive support that aids in overcoming challenges, a measurable benefit in terms of ROI.

For enterprise users of Red Hat Ansible Automation Platform, there are fees, but it is free and open-source for testing or small labs.

I have worked with Chef as a configuration management tool for one project, and I have used Chef and Red Hat Ansible Automation Platform together in the same project.

I have worked on the AWS cloud with Red Hat Ansible Automation Platform.

Red Hat Ansible Automation Platform was hosted on AWS.

I prefer Red Hat Ansible Automation Platform because it is easy to implement, and the extensive supporting documentation is very helpful.

I suggest everyone consider Red Hat Ansible Automation Platform because it is agentless, easy to implement, and has sufficient supporting documentation available.

On a scale of one to ten, I rate Red Hat Ansible Automation Platform a ten out of ten.

They are using Red Hat Ansible Automation Platform for infrastructure automation and cloud automation. The platform is used for CI/CD automation, deployment, and automation. The main use is infrastructure automation.

Red Hat Ansible Automation Platform is easy to integrate. The platform is simple to use.

The dashboarding capabilities should be improved by bringing CMP (Cloud Management Platform) into Red Hat Ansible Automation Platform. Event-Driven Ansible is very important in the platform. Both Event-Driven Ansible and cloud management platform features are crucial improvements needed.

We have been using Red Hat Ansible Automation Platform since 2018, which is more than seven to eight years.

The stability of Red Hat Ansible Automation Platform is excellent, deserving a 10 out of 10 rating.

The technical support is not adequate. The Ansible sales and technical support services need significant improvement.

Red Hat Ansible Automation Platform comes with a high price point. Even though we use the platform, we need additional dashboarding tools because the complete infrastructure as code dashboard capability is missing.

Red Hat introduced a new product called Red Hat Developer Hub for platform engineering. While Red Hat Ansible Automation Platform is very good for automation, deserving an 8 out of 10 rating, the cost of combining Red Hat Developer Hub and Ansible is extremely high, which presents a significant challenge with the Red Hat product.

In AWS, customers are increasingly using Terraform rather than Red Hat Ansible Automation Platform. This is particularly true for cloud-based operations on AWS.

The choice between solutions depends on the situation. Developers tend to be more inclined towards Terraform, while infrastructure teams prefer Red Hat Ansible Automation Platform.

We are still actively working with Red Hat Ansible Automation Platform. Customers typically purchase directly from Red Hat for on-premise deployments, while those on public cloud buy from the marketplace.

We are recommending the solution to users as a Red Hat partner.

This review rates Red Hat Ansible Automation Platform a 10 out of 10.

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.

Positive

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.

I am the section manager for the open system section in a county. We provide support for Red Hat Enterprise Linux, the IBM AIX platform, and, of course, Ansible Tower.

Ansible Tower was brought in to automate a lot of endpoint security software. We have an entire process where we bring up virtual machines on the x86 environment. Every time we brought up a Linux or Windows virtual machine, all the endpoint software needed to be installed after the fact by the necessary groups. That was taking a long time. If we have ten machines pop up today, going to all ten machines and installing five different endpoint security tools takes a while. Ansible helped in adding Ansible playbooks into the workflow. Now, when someone clicks and says that I want a Linux machine and provides all the information, then in the end, it spins up the machine automatically and uses Ansible Playbooks to install all the necessary pieces of software. It then gives a login and the necessary passwords for the customer to log in and start working. We now know that every time we deploy, all our endpoint security products are installed and ready to go.

The benefit is in terms of time-saving. There is more time for our team to worry about and take care of other engineering work than worrying about installing endpoints. Also, our Oracle database team is working on Ansible Playbooks to automate patching, which takes a long time to plan and do, especially in the production workloads. We are working very closely with that group.

We also work with the backup group to see how we can automate the day-to-day mundane processes. All these aspects bring us a lot of value. We are saving time, and we can also restructure and understand our necessity to have extra people on the team. We can cut down costs on that. We can reorganize ourselves to focus on much better technology, such as AI and things like that, instead of wasting time doing manual processes.

It has helped us achieve our mission. It helps to reduce the workforce and manage the time of our existing workforce. They can be more involved in new technologies such as AI. Understanding them takes time. They save a lot of time with automation.

We use other Red Hat products. We use OpenShift. When containers started taking off, which was about six to seven years ago, the government sector did not want to go into the cloud and use AWS containers. However, in our county, the customers were demanding that. They were saying that their applications are modernizing and we need to provide them with a container environment. That is when we decided to go for it. Because we were already Red Hat customers and we have been running Red Hat Enterprise Linux since 4.x, we decided to go for OpenShift. It was the same platform, and they were offering manageable containers. That is how we brought in the container platform. It is rock-solid. We had it on-prem. We have moved it to AWS, and it is great. The new thing is OpenShift Container Platform Plus which comes with a slew of additional tools. These tools help us provide the necessary application infrastructure for containers for customers.

We have Red Hat Enterprise Linux and OCP running in AWS.

It takes away a lot of work. For example, if you have five security products to install, you install the first one, test it, and make sure it works. You then install the second one, the third one, and the fourth one, and then something happens. Something breaks. All that is taken away because we have foolproof systems built into our playbooks. There is also a continuous workflow from the start until the end.

With Ansible Tower, the automation methodology is simple. There is ease of learning. It definitely reduces the training required to learn how to automate things for technical folks. It is much easier than writing bash scripts. This reduced training affects our operations or business. For example, if security folks come and say that they need to write a bash script that will go into their workflow to install, uninstall, and upgrade agents, that is a lot easier to do with Ansible Playbooks.

It helps to bring teams together. Black lines between the operations, security, and other teams are going away. Those lines are becoming more gray and light gray. There are DevOps and SecOps, and even finance is becoming FinOps. It definitely helps teams come together, and then we try our best to guide the teams, whether it is the Oracle team or security team, so that eventually they will learn to do their own playbooks. We can always be the guardrails.

It increases productivity, saves time, and even saves the cost of people working after hours trying to get these things going. It is all in the workflow.

It has definitely helped to reduce the time we spend on low-value or repetitive tasks. There is a huge difference. About 20% of my staff's time is saved. They do not have to worry about things. Once you set it, you can forget it unless there is a change or there is something different. For example, the security group comes and says that they have stopped using the Cisco product. They are using some other vendor's endpoint security. In such a case, all we have to do is change those variables, and we are done. Previously, we had to go back, use the Windows uninstall program and reinstall. This is much easier.

The most valuable feature is that it is easy to build playbooks. The learning curve is not that steep. That is one thing. The other valuable feature is all the pieces of logs and things like that where you can go and find out if something went wrong. Those are the key features.

Also, we use the OpenShift Container Platform, so it blends in very well if you want to deploy containers or namespaces. Automatic DNS, creation of DNS, collation of namespaces, and other similar things can be automated with Ansible.

We are very satisfied with what we have. From a management point of view, whatever makes it easier for my team to help customers write their own playbooks would be something very beneficial. Everything is going as a service. Creating playbooks can become much more consumer-oriented so that customers do not need to contact us to write their own playbooks. It would be great to have something that can help us do that with a few clicks like all these new languages that are there today. We used to use a lot of bash scripts to do automation, but you need to be a Unix administrator for years to even figure that out. What Ansible is providing is somewhat user-friendly, but I would extend that to be even more user-friendly for customers so that they do not have to contact a technical team to write their playbooks.

We started using it about two years ago.

It is very stable. I have not had any issues since we brought it up. I have a non-production environment and a production environment. Non-production is just for our guys to play around with. It is not as big as the production environment.

Adding resources and satisfying customer demands is easy. We have no problems with scaling out.

Their support is fantastic. I would rate them a nine out of ten because the whole team was changed after IBM bought them. The new guys are getting used to it. Whenever I call them, they are very responsive. It was sad to see the team that we were used to for six or seven years being let go. I do not know why.

Positive

We did not use a similar solution previously. We used bash scripts.

The entire Ansible solution is on-prem. The team did not have any challenges deploying it. My team has been dabbling with Red Hat since Red Hat Enterprise Linux 4.x. It was just another Red Hat box for them. It was not a major issue for them to bring up the necessary infrastructure.

It was all done in-house.

In terms of the reduction in costs, we started using it only two years ago. I have to recoup my infrastructure cost for setting up Ansible Tower. We are charging our customers. Previously, we had bash scripts. There was not a cost, but now, I have to recoup the cost of Ansible Tower licensing. Its licensing is expensive. Currently, when it comes to a customer using Ansible Tower, there is a slight additional cost, but as more customers come to use my infrastructure for Ansible Tower for automation, it will become cheaper and cheaper.

Ansible Tower is pretty expensive.

We did not evaluate other products. This was the go-to product because we were already a Red Hat shop.

Overall, I would rate it a ten out of ten. There probably is not any other easier solution to automation right now, at least for my environment because we are a Red Hat shop.

Our use cases are related to system compliance, package management, system patching, and general infrastructure and security as a code.

We can easily remediate a lot of the routine tasks or even break-fix issues that keep coming up. It could be a simple break for which we do not have a root cause analysis for a proper solution, but it keeps coming up. We can easily remediate such issues and have those not impact workflows for our developers while we work on a full solution in the backend. It also helps with the general tasks of maintaining systems or correcting them when things get out of line. We are able to deploy things at scale versus having someone there. Their time is much more valuable. They do not have to spend five or ten minutes here or there throughout the day when they can be focused on a more dedicated effort elsewhere.

It helps us achieve our mission because we want to enable our researchers and developers to have an ecosystem that allows them to do what they need but in a secure environment. We want to protect system information, data, and IPs. We want to be able to do that at scale, quickly roll out changes, and maintain systems as needed for compliance. We want to allow all that holistically for our groups to manage. It has helped us with workflows to help expedite that process.

We also use other Red Hat products. We use Satellite and IDM, and we are moving towards AAP and EDA. We chose these products to help manage our infrastructure. Because we are managing Linux systems, we want everything to work and play with each other as well as they can. We are adopting the same ecosystem. Choosing Red Hat products allows us to do that with the most reliability, and we also get support from the experts who built the programs themselves. If anything were to go wrong, we have that backup of people who are dedicated to helping us find the solution for it. With multiple Red Hat products, we have interoperability. We are able to spread across different teams. If we standardize our process on the same products and the same technologies, it means we can train other departments and other groups to manage their own piece of the pie. If they have many different products, the only people who would know how to work with a product are the ones who are dedicated to working with that product, whereas if we standardize on the same kind of ecosystem, it is easier to cross-train on that.

It does a good job because the whole syntax is human-readable, and it is YAML. While it has its quirks, it is pretty straightforward. Generating playbooks, tasks, modules, and other things is pretty easy. Even the plugins are Python-based, so it is an easy language and it is near readable for Python, whereas, trying to make scripts for something or code in different languages is very tedious. You need people who are experts in making that deployable and handling any unexpected outcomes or different conditions that may cause issues, so having something that is easy and straightforward to learn and that handles all of the guesswork on the backend makes it much easier to develop automation.

It helps reduce the training required to learn how to automate things. It is a very easy language to learn, and it is not like learning an entire programming language.

It helps connect teams, such as developers, operations, or security so that they can automate together. Developers and operations definitely work hand in hand. Introducing infrastructure as a code or security as a code when they have not adopted that mindset can be difficult. They definitely agree with the concept but getting them to work and manage their own playbooks is a little bit more difficult because not everyone is intrinsically interested in coding even if it is a simple language. However, being able to have the partnership to say that we can help them out and they have a readable syntax is helpful. They can clearly see what is going on. It helps them a lot in understanding what is going on in the backend. We are becoming more and more productive as we get more products involved and more people on board with developing and adopting their own respective departments as code, such as infrastructure, security, IT, and anything else that we may have in the pipeline.

Its collection of certified content helps out a lot. We are able to pull certified content and then use it within whatever we are trying to deploy. Everything essentially works with whatever we are trying to deploy. If it does not work, we know that it is something on our end. It helps out with identifying known goods and then working from there.

It helps to reduce the time we spend on low-value or repetitive tasks. It has taken off about 45% of my workload from tedious tasks.

The easy-to-read syntax for YAML files and the interoperability between modules are valuable. There is also the ability to develop your own plug-ins and modules to be able to contribute. The scalability of Ansible across different environments is also valuable.

There are some integration issues with other technologies such as Satellite. It could be a Satellite issue and not an Ansible issue. There are bugs related to failed tasks not being failed and then reverting back to completed tasks. It might not be because of Ansible. It could be because of Satellite.

There have been some differences between the operating systems that we have noticed. It could be down to cryptographic policies, but we have noticed some speed issues. They should work on the speed of deployment on different operating systems.

They have already managed the other issue of introducing execution environments to make sure everything is the same with every system.

We have been using this solution for about two years.

It has been pretty reliable. The only issues that have come up are because of people asking it to do things that it is not built to do. All our issues tend to be someone on our end doing something that they probably should not be doing. If you are using it as it is intended, it is pretty reliable.

It is scalable. We have plans to increase its usage. We are planning to implement AAP, EDA, etc.

The support has been nice whenever we had to put in any Red Hat-related issues. They are fairly responsive.

If there are issues that exceed their knowledge base, they usually escalate it to someone else who can handle them. We usually get a working solution fairly quickly with an actual root cause diagnosis.

I would rate them a ten out of ten. They have always been pretty speedy and reliable.

Positive

We used to use Puppet. It is not the same. It is agent-based, and I am not a fan of it. Ansible is much more lightweight, robust, and flexible, so our other alternative used to be Puppet, but we are now onboard with Ansible.

In terms of ease of use, Ansible is a lot easier to read and develop with. Red Hat has certified content. They have their own supported modules, and the community also updates the modules that are community-maintained, whereas Puppet does not have the same kind of development. You are waiting for things to be updated from Puppet's end, which does not quite work with our use case. If there is a critical need for the update of a certain module to work with our environment, it does not really work because we need things to be updated semi-frequently or at least be maintained. Ansible helps take care of that. With Ansible, we can work with push or pull configurations depending on what we want to set up instead of having one configuration that Puppet works with, so it gives us flexibility.

Ansible is cheaper than Puppet, but we are scaling out and flushing out more infrastructure. So, because of how we use it, it does associate more costs. We use different kinds of licensing and products, but it is worth the costs and investments, whereas Puppet is its own ecosystem. It does its own thing, and that is it. It does not scale out to do the kind of things that we want to do.

We manage from a central location and push out to our remote sites. Everything is on-prem.

It was simple from the Ansible's end. The complicated thing was getting the other tools and architecture needed to push out to where we wanted and getting all that developed, but the initial push out with Ansible was pretty simple and straightforward.

Our deployment strategy was to get it running and push it out to showcase the proof of concept of how much time we spend doing this and how much time we can save now because it can handle that automatically. The game plan was not a true holistic view of what we could do moving forward because we could not do that until we got more buy-in from everyone else to show how this positively impacts the organization.

We did it on our own. We got the licensing and bought the tools. It was pretty much on us to figure it out.

The scalability of it is the biggest return on investment because it can scale to a small handful or thousands. It works for simple and complex scenarios. It can all be done without a lot of backend research. Obviously, with more complexity, you need people who know a bit more, but it is pretty easy to get up to speed. It is pretty flexible in terms of how it can scale to different environments.

Everything is generally fair. No one ever likes to pay a lot of money, but we are getting the value. We also get support with it. It has been fair and worthwhile.

We did not evaluate any other solution. It was pretty much trying to buy more into Puppet, but as we determined needs, we scaled it out to Ansible because we work in an environment with Red Hat. We also have other operational needs for which it works.

I would rate it a ten out of ten because I enjoy it a lot.

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.

Positive

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.

Positive

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.