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.

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 everything. We use it for provisioning servers, configuring servers, auditing servers, and generating tickets to define a task for the things that we find.

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

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

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

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

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

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

I have been using this solution for about four years.

It is stable.

It is scalable.

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

Neutral

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

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

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

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

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

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

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

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

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

We deployed it on our own.

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Positive

I have not used any similar solution.

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

It has saved us thousands of man hours.

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

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

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.