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 use it for firewall upgrades and backups. That is pretty much it for now because it has been only a year.

Ansible Automation Platform has saved a lot of time, man-hours, and money. Specifically for the upgrades, there have been a lot of time savings.

It keeps us in compliance. It helps with compliance drifting and keeping us up to date with code.

It helps to reduce the number of steps involved in automating things. Everything is performed consistently every time. There are no missed steps. If you do it manually, you might miss a step. With Red Hat Ansible Automation Platform, it is just the same every time, which is good.

Ansible Automation Platform does not reduce the training required to learn how to automate things. There is a lot more overhead and a lot more training to teach how to use Ansible.

Ansible Automation Platform helps connect teams, such as developers, operations, or security so that they can automate together. Our engineering team can now collaborate or work with our operations team. We build the Ansible solution, and they run the solution. There is more teamwork.

We use the collection of certified content. It is 80% there for helping to quickly add automation to our systems. It is decent.

Ansible Automation Platform has helped to reduce the time we spend on low-value or repetitive tasks by 80%.

Automation is valuable. It saves us time in performing tedious tasks or repetitive tasks.

The web GUI can be a little bit better. There should be a couple of more features.

I have been using this solution for about a year.

It is stable.

It is very scalable. We are planning to increase its usage.

Their support is decent. They are responsive. I would rate them a nine out of ten.

Positive

We have not used any other similar solution.

We do use other Red Hat products. We use Red Hat Enterprise Linux because that is the enterprise standard that we have across the company. That is the one they use across the board. The support is the main reason for choosing Red Hat Enterprise Linux.

We do not use any Red Hat solutions in the public cloud.

It is on-prem. Its deployment was a little difficult the first time, but after that, it got progressively simpler.

We deployed it ourselves.

We are able to automate complex tasks and make them more streamlined with just one button.

It is a little pricey but it is affordable. It is not that bad.

We did not evaluate any other solution.

I would rate Ansible Automation Platform a ten out of ten. It has helped us go from manual to automation. We are still far away, but it is getting us on the right path. It is getting us there. It is great.

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.

We use the solution for Linux patching automation. Currently, we are using the solution for patching normal configuration-related work. However, we also plan to use it for the provisioning of the servers.

The most valuable features of the solution are automation and patching.

The solution is slightly expensive, and its pricing could be improved.

I rate the solution ten out of ten for stability.

Red Hat Ansible Automation Platform is a scalable solution. Around 300 to 400 users are using the solution in our organization.

The solution’s technical support is very good.

The solution’s initial setup is very easy.

The solution can be deployed within a day if you have all the resources. To deploy the solution, you need to check if you have a proper infrastructure and everything in place.

Users with the right environment, like Linux, should go for Red Hat Ansible Automation Platform. With the Red Hat Ansible Automation Platform, we don't have to do manual things, increasing our efficiency. The solution helps us complete our complex work very easily, increasing efficiency.

Overall, I rate Red Hat Ansible Automation Platform ten 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.