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.

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

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.

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

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.