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.
External reviews
365 reviews
from
and
External reviews are not included in the AWS star rating for the product.
Automation on steriods
What do you like best about the product?
its capabilities on event-driven. integration with indsutry standard tech stack for example serviceNow
What do you dislike about the product?
I personally found it a little hard to navigate through the dashboard
What problems is the product solving and how is that benefiting you?
Infrastructure Automation.
- Mark review as helpful
I Like AAP
What do you like best about the product?
it can do automation virtually anything under the sun.
What do you dislike about the product?
can't think of any. Well, there is one. I think EDA controller is not that enterprise ready yet.
What problems is the product solving and how is that benefiting you?
automation, workflows, config mgmt
Enables us to build new servers and updating software on servers in a very consistent way
What is our primary use case?
How has it helped my organization?
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.
What is most valuable?
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.
What needs improvement?
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.
For how long have I used the solution?
We have been using this solution for about three years.
What do I think about the stability of the solution?
It is stable.
What do I think about the scalability of the solution?
It is scalable. Especially on OpenShift, you can scale it out pretty easily.
How are customer service and support?
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.
How would you rate customer service and support?
Positive
Which solution did I use previously and why did I switch?
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.
How was the initial setup?
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.
What about the implementation team?
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.
What was our ROI?
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.
What's my experience with pricing, setup cost, and licensing?
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.
Which other solutions did I evaluate?
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.
What other advice do I have?
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.
AAP @ summit 2024
What do you like best about the product?
Helps us with pipelines CI/CD and automation,
What do you dislike about the product?
Upgrade/update process is tedious with lot of pitfalls.
What problems is the product solving and how is that benefiting you?
Automating our servers deployment, patching. Release Management
Ansible-Rev
What do you like best about the product?
Ansible reduces time to manage and deploy platforms and infrastructure. The knowledge is accumulitive as is the playbooks. The eco system builds on itself.
What do you dislike about the product?
Ansible documentation and repositories are difficult to differintiate between subscription and veted content and community. There is alot of overlap.
What problems is the product solving and how is that benefiting you?
Bringing idempotency to the forefront and bringing the identical and or standardized set up on all hostses/targets in the inventory.
AAP has been key in optimizing our pipelines for server provisioning to both on-prem, aws, and azure
What do you like best about the product?
Easy to use interface and observalibilty of events in the system
What do you dislike about the product?
It was a little difficult for me to get up to speed but I believe Lightspeed and WatsonX would have been a great value-add for me if it was avaliable at the time.
What problems is the product solving and how is that benefiting you?
I can't thinl of any specific problems that I have encountered.
AAP
What do you like best about the product?
AAP helps me get stuff pushed out to production
What do you dislike about the product?
some times i have trouble getting a machine configured initially
What problems is the product solving and how is that benefiting you?
getting machines in a consistant state
We love Ansible
What do you like best about the product?
it allows us quick configuration and deployment at scale
What do you dislike about the product?
Sometimes I hate the indenting of the yaml files.
What problems is the product solving and how is that benefiting you?
With the growing number of servers we support it allows us to roll out and config in a faster turnaround time
AAP - when you need non-tech employees to execute complex tasks
What do you like best about the product?
The best is the ability to grant non-technical or tech users that do not need access to perform functions, the ability to do this without needing complex interactions, such as gaining access to secrets, not needing to know how to write code, etc.
What do you dislike about the product?
The cost, and the learning curve needed to master it.
What problems is the product solving and how is that benefiting you?
It has allowed me to give non-RHEL admins the ability to perform config management without needing to know how to write playbooks, and not knowing what collections are needed.
Automates Everything under the sun! Need I say more?
What do you like best about the product?
Ansible is:
Python abstracted
Easy to create automate tasks
Simple to find modules to automate everything under the sun
Easy to use your Python skills to make modules for your automation niche needs
Awesome for cross platform support
Playbook development is the same and forces you to use GIT :)
Python abstracted
Easy to create automate tasks
Simple to find modules to automate everything under the sun
Easy to use your Python skills to make modules for your automation niche needs
Awesome for cross platform support
Playbook development is the same and forces you to use GIT :)
What do you dislike about the product?
The AAP module implementation requires containers and although well documented it is not apparent.
What problems is the product solving and how is that benefiting you?
Windows has SCCM / Intune, Linux has Ansible for the task automation. Currently using Ansible to automate standard operational and LCM tasks
showing 141 - 150