Sign in
Categories
Your Saved List Become a Channel Partner Sell in AWS Marketplace Amazon Web Services Home Help

Reviews from AWS customer

1 AWS reviews
  • 1
  • 4 star
    0
  • 3 star
    0
  • 2 star
    0
  • 1 star
    0

External reviews

365 reviews
from and

External reviews are not included in the AWS star rating for the product.


    reviewer2399208

Easy-to-read YAML syntax, good interoperability, and high scalability

  • May 08, 2024
  • Review provided by PeerSpot

What is our primary use case?

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

How has it helped my organization?

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.

What is most valuable?

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.

What needs improvement?

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.

For how long have I used the solution?

We have been using this solution for about two years.

What do I think about the stability of the solution?

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.

What do I think about the scalability of the solution?

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

How are customer service and support?

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.

How would you rate customer service and support?

Positive

Which solution did I use previously and why did I switch?

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.

How was the initial setup?

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.

What about the implementation team?

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

What was our ROI?

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.

What's my experience with pricing, setup cost, and licensing?

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.

Which other solutions did I evaluate?

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.

What other advice do I have?

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

Which deployment model are you using for this solution?

On-premises


    Eric B.

Great Automation Product and Platform

  • May 08, 2024
  • Review provided by G2

What do you like best about the product?
Being able to automate all of the tedious and recurring tasks that have been a pain to run either on a daily, weekly or montly basis.
What do you dislike about the product?
The lack of folder or template management. We currently have 50 templates and to sort through them is a pain when all encompassed in 1 window.
What problems is the product solving and how is that benefiting you?
Having continuous and identical tasks being run the same each and everytime and takign that output to then further inform our users of the process.


    Defense & Space

Good product, but limited use case for our enviroment

  • May 08, 2024
  • Review provided by G2

What do you like best about the product?
Flexibility, ease of administration, and future feature ads
What do you dislike about the product?
Steep learning curve, ux is not intuitive
What problems is the product solving and how is that benefiting you?
Having a front end for ansible, making it easier for people to use that are unfamiliar with CLI interfaces.


    Consulting

Best Ui for Ansilbe with a lot of governance features

  • May 08, 2024
  • Review provided by G2

What do you like best about the product?
Control Groups and audit logs are one of the features i use in mz day to daz business
What do you dislike about the product?
Database migrations could be a pain, GitOps isn't good integrated
What problems is the product solving and how is that benefiting you?
The certified collections for SAP are really helpful to quickly setup a SAP sytem for testing purposes


    Banking

Ansible is not only a great product but has helped to change the culture at our org

  • May 08, 2024
  • Review provided by G2

What do you like best about the product?
I like the fact that ansible uses Yaml which is plain test language, it makes it easier to teach new people joining our team, i also like that it is vendor agnostic so we only need one automation platform for our entire fleet
What do you dislike about the product?
I think the only thing i dont like about AAP is that there is no select all and disable or enable servers in an inventory. This means that i have to manually disable or enable each server
What problems is the product solving and how is that benefiting you?
Consistancy: Because of ansible our network functions are now very consistant which avoids outages.


    Consulting

AAP is a game changer

  • May 08, 2024
  • Review provided by G2

What do you like best about the product?
AAP is packed with amazing features. Being able to intelligently automate workloads at scale has tremendously impacted our efficiency. New advances with Event Driven Ansible are super exciting going forward
What do you dislike about the product?
It would be nice to have one unified interface for the controller and hub, but that's a minor gripe
What problems is the product solving and how is that benefiting you?
User provisioning, server and application automation, and potentially OCP integration


    sri t.

Simplicity and robust

  • May 08, 2024
  • Review provided by G2

What do you like best about the product?
Storing the passwords securely that meets standards in Financial sector.
What do you dislike about the product?
The upgrade process is not that smooth currently.
What problems is the product solving and how is that benefiting you?
We were able to integrate with Service-now, Network devices and Microsoft teams which to solve the our Remediation porocess.


    Andres G.

An excellent front end for Ansible empowerment

  • May 08, 2024
  • Review provided by G2

What do you like best about the product?
I think the best aspects of AAP are the ability to provide our teams with a nice, clean front end. Surveys are a very attractive feature to empower even non-technical users to leverage automation.
What do you dislike about the product?
I haven't found anything specific that I to identify as a drawback.
What problems is the product solving and how is that benefiting you?
AAP has given us a central interface with RBACs allowing us implement automation more broadly and lower the barrier to entry for our non-systems folks. It has made it easier for our network teams to get comfortable in the ansible space and reduced the number of ansible silos running in isolated environments.


    reviewer2399166

Makes automation easy and helps with standardization

  • May 08, 2024
  • Review provided by PeerSpot

What is our primary use case?

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.

How has it helped my organization?

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.

What is most valuable?

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.

What needs improvement?

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.

For how long have I used the solution?

I have been using this solution for about four 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.

How are customer service and support?

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.

How would you rate customer service and support?

Neutral

Which solution did I use previously and why did I switch?

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.

How was the initial setup?

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.

What about the implementation team?

We deployed it on our own.

What was our ROI?

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.

What's my experience with pricing, setup cost, and licensing?

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. 

Which other solutions did I evaluate?

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.

What other advice do I have?

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.


    Sujit G.

Leading the automation journey

  • May 08, 2024
  • Review provided by G2

What do you like best about the product?
A very structured UI to manage AAP and the automation workflows
What do you dislike about the product?
We are in early stages of rolling out Ansible; having a clear idea of architecture complexities would help
What problems is the product solving and how is that benefiting you?
- Infrastructure Automation
- Configuration management
- Integration with SNOW, Dynatrace