We changed our name from IT Central Station: Here's why
Get our free report covering VMware, Red Hat, Microsoft, and other competitors of SaltStack. Updated: January 2022.
564,143 professionals have used our research since 2012.

Read reviews of SaltStack alternatives and competitors

DevOps Consultant at a government with 501-1,000 employees
Consultant
Top 20
Enables us to efficiently manage an almost unlimited number of nodes
Pros and Cons
  • "Being a game-changer in configuration management software is what has made Ansible so popular and widespread. Much of IT is based on SSH direct connectivity with a need for running infrastructure in an agentless way, and that has been a big plus. SSH has become a great security standard for managing servers. The whole thing has really become an out-of-the-box solution for managing a Unix estate."
  • "Some of the modules in Ansible could be a bit more mature. There is still a little room for further development. Some performance aspects could be improved, perhaps in the form of parallelism within Ansible."

What is our primary use case?

We use it to configure operating systems, apply security, and for day-to-day management. Our use cases include collecting information from end nodes, rather than writing shell scripts or any other types of scripts, as was done historically, and rather than even logging in manually and collecting information from the nodes. These days, you write an Ansible playbook and it does things for you. And if you don't have a playbook, you can simply gather the facts from the nodes, and that's available out-of-the-box without writing anything. You simply utilize the Ansible modules.

Our Ansible deployment is for a hybrid environment. We have on-premises services that we use Ansible to configure as well as cloud instances.

How has it helped my organization?

Historically, lots of things had to be orchestrated manually. There weren't any great tools to do configuration management across multiple nodes. IT servers were physical but then moved into virtual, and with that change came the need to manage more and more nodes. It became quite time-consuming, and employing people to manage hundreds or thousands of servers wasn't really a great solution. Ansible, as an orchestrator, has filled the gap. It allows you to manage an almost unlimited number of nodes with a single body. That has been a great improvement in the way organizations manage their estates.

In addition, we're able to configure or deliver something to our end nodes step-by-step. You can have dependencies, types of conditions, between steps. For example, if something isn't present or it's not happening on that node, you can skip steps and move to another one. This ability definitely helps. In the past, a lot of things had to be done manually or with a semi-manual script. Ansible automates those things. As long as you've got your playbook written up and tested correctly, you can run it with confidence against your production system.

Ansible also saves us time when it comes to service deployment, moves, and updates. If we consider the effort involved in writing playbooks, and the effort to deploy them, Ansible saves 80 to 90 percent when it comes to the time involved in these scenarios.

Another advantage is that Ansible enables collaboration across teams. We're transparent. Whatever we deliver needs to be backed by the code. That code lives in source control. Anybody who is capable and wants to could grab that code. Playbooks are an example. They could simply apply them against the target. This is a form of collaboration, where one person does something and another can grab it and use it. Obviously you need source control, but multiple people can work on a specific project together and can have influence on that project, providing updates, features, and bug fixes to the project.

We have certainly seen an improvement in automation. With Ansible, you can pretty much automate everything. You work on a desired state. And we have been able to apply current, modern security standards to the estates. From a security perspective, our servers are now fully compliant with modern security standards. We are able to use Ansible to run some benchmarks against them to see if they're fully compliant.

What is most valuable?

Being a game-changer in configuration management software is what has made Ansible so popular and widespread. Much of IT is based on SSH direct connectivity with a need for running infrastructure in an agentless way, and that has been a big plus. SSH has become a great security standard for managing servers. The whole thing has really become an out-of-the-box solution for managing a Unix estate. Managing a Windows or Microsoft estate via Ansible is a little bit different and I believe that requires the installation of some agents.

Another advantage is that Ansible did not require us to change our existing infrastructure in any way. This issue ties in with the SSH connectivity. You don't have to prepare any infrastructure to use Ansible. When you provision an operating system, that SSH remote connection is available. It's embedded in the operating system. That means you don't have to enable anything. All you have to do is make sure you can reach the nodes, either via SSH, passwordless authentication, or possibly other mechanisms. We've only been using SSH, and it does the job very well.

What needs improvement?

Some of the modules in Ansible could be a bit more mature. There is still a little room for further development. Some performance aspects could be improved, perhaps in the form of parallelism within Ansible. 

Also, some of the Ansible versioning or backward compatibility, or Python changes, could have been handled a little bit better. 

But all these challenges could potentially be offset by the way you use Ansible. For instance, you could have Ansible Docker-ized and that would make your Ansible environment fixed and static and fully controlled. That way you wouldn't be worried about your server or your local workstation that is used for deployment.

These aren't huge issues, they are just things to keep in mind, but it all depends on how you use the product.

For how long have I used the solution?

I have been using Ansible for a good few years. I started five to seven years ago, by first writing Ansible playbooks, simply to orchestrate configuration management of the estate at that time. I was mainly using it on Linux servers.

What do I think about the stability of the solution?

The stability of Ansible is great. Historically, we have had some compatibility issues, such as during a Python change a library had to be downgraded. Other than that kind of minor issue, the product has been very stable.

What do I think about the scalability of the solution?

It's quite scalable. I don't think there are huge limits in terms of what you can do. I have not run any performance benchmarks for Ansible. I don't know how long it would take to upgrade 10,000 nodes compared to competitors. But I feel Ansible could be nicely scalable. An orchestrator would allow you to simply have Ansible containers, perhaps on Kubernetes, and they would run something against the nodes. Having multiple Ansible nodes, or multiple pods of Ansible containers, running code against targets in parallel, would be a scenario in which I could hardly imagine any limits.

We are managing between 1,000 to 2,000 servers.

My team is more of a development team, so we don't run Ansible on a daily basis for operations. We mostly program or develop robots that run Ansible when needed. As for other teams, I'm not sure how they use it, but whenever they need to collect something from these hosts or need to quickly push a similar update to all hosts, I think they would use Ansible. While it's not being used on a daily basis in our organization, it's certainly being used.

How are customer service and support?

The typical Red Hat support, the kind you access via their portal or email, can vary. Sometimes things are not done as quickly as you would want, but it's standard support and you get what you pay for. Moving up a level, if you were to get TAM support, things would improve a bit because you get dedicated technical contacts with whom you speak on a weekly basis. They help push things along. However, you're still tied to the Red Hat backlog and its engineering, which is not always the fastest. Often they have a different view and different priorities. We have had some cases where they have simply said, "We're not delivering this. We're not doing this," but they did not provide a rationale as to why. 

Overall, the results are mixed when it comes to support. It's not that bad, but there's room for improvement.

How would you rate customer service and support?

Neutral

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

I've used Puppet a little bit, but I quickly moved into Ansible as it became a standard over Puppet, Chef, and perhaps SaltStack. We moved quickly into Ansible. When Ansible was acquired by Red Hat, it quickly became a very interesting product. The first bullet point was the agentless infrastructure for Ansible.

Red Hat's open-source approach was also a factor for me, certainly. I'm an open-source enthusiast. It's a big plus that Ansible is an open-source project, and it's free. They gained popularity from that as well.

How was the initial setup?

When you need to use Ansible, you need to grab the Ansible binary. A typical method in Linux would be to use the Package Manager to install it. You could also use a Python-native method for installing it through pip.

Another good method would be to simply get your Ansible Docker-ized or pull a Docker image from a third-party repository and that image would have Ansible deployed in it. That way, every time you need to run Ansible, you could just an image and that image would provide the binary for Ansible.

The next step is related to your particular use case, what you need to use and how you need to use it. For example, if you want to write a small portion that does something, you simply instruct Ansible to use that code against the targets. By "targets" I mean you need to provide an inventory that you want to run your code against.

Another step that needs to happen in order to use Ansible nicely is to set up passwordless authentication to use SSH keys instead of passwords. That's what should probably happen together with installing or delivering Ansible binaries. Once you have these elements, binaries and authentication, your system is pretty much ready to be configured through Ansible.

Because I'm quite senior and specialized in Red Hat and, in general, a Linux expert, deploying Ansible literally takes me minutes.

Implementation strategy would vary from case to case, but one of the popular ways of deploying Ansible is to have a bastion host that allows you to access your estates over SSH keys and simply have Ansible running from that host. Ideally, you would like to see what Ansible is changing on every run so a good practice would be to have CI/CD orchestration for Ansible, using Jenkins or another CI/CD tool that allows you to keep historical logs on how Ansible behaves, and what has changed in an estate during an Ansible run. That would be the minimal implementation I would suggest for an organization.

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

We're not paying for it, but if you were to buy it, you would get Ansible Tower. That is what they are charging for, if I recall correctly.

Which other solutions did I evaluate?

Ansible seems to have been quite well received. There are competitors, or there were when I started using it several years ago, but Red Hat, with community development, has become the easiest to use, compared to Puppet or Chef. That is how Ansible gained popularity across the IT market.

Another element in why Ansible became so popular is the way things are being pushed to the end nodes. We're using existing SSH connectivity, which is a common way to manage Unix servers. That became available out-of-the-box. The competitors usually ask you to install agents and that brings with it challenges, such as how to orchestrate installing agents. Ansible does not suffer from that problem. Every Unix server must have SSH enabled by default and Ansible simply uses that.

What other advice do I have?

It's a great tool. It's easy to use. Do your own research and run a spike to compare Ansible with competitors and simply pick whatever suits you. But a great plus for Ansible is its simplicity.

For doing basic things, or things Ansible was designed for, you probably don't need special coding skills. All you likely need to know is how to properly structure a YAML file, and YAML is now a common language across development. However, if you were to do things that are a little bit more advanced in Ansible, Python would be something that you would want to study or be good at. That would help you write custom Ansible modules or provide further input into existing development to improve them or deliver additional bug fixes and features.

We spike the open-source version of Ansible Tower, and Tower is not difficult to learn if you have experience with Ansible and with Unix. Deployment of it is relatively easy. We have not found a great use case for it, to be honest. At that time, it was more for compliance and, maybe, a Chrome-job type of product, and we had the orchestration for that already.

When it comes to SLAs, I don't think Ansible has created a great change for us. Once you achieve a certain level of automation in an organization, you're probably not going to feel any changes when it comes to SLAs because you have already built that capability. Our SLAs are well maintained and are at a high standard, but I don't feel Ansible has had a huge influence on them because we were mature in that area. But perhaps for some organizations, it would have a significant effect on what they offer. Being able to do more via automation means services are up more than they might have been.

We are using other Red Hat solutions in our environment, including Red Hat Enterprise Linux, Red Hat OpenShift, Red Hat Satellite, and we have also used Red Hat Virtualization. All of these products integrate nicely with Ansible. It's mainly because they're fully backed by variations or just pure Red Hat Enterprise Linux. The integration is great. Whatever you can do on Linux, can probably be done on any other Red Hat products that are based on similar technology. There are no limits.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
Flag as inappropriate
Senior Technical Marketing Manager at a tech vendor with 1,001-5,000 employees
Real User
Top 10
Easy to deploy, offers embedded monitoring, and is very stable
Pros and Cons
  • "When it comes to managing both Red Hat and SUSE environments, it provides the support for live patching, which is something I really, really appreciate."
  • "I really would like to have a broader library of VCP's or playbooks that I can deploy."

What is our primary use case?

I'm a freelancer and I have a number of customers and I need to patch their systems. The beauty of SUSE Manager is that it supports different Linux systems such as Red Hat and SentOS, SLES, and Ubuntu.

What is most valuable?

When it comes to managing both Red Hat and SUSE environments, it provides the support for live patching, which is something I really, really appreciate.

The other thing that I use a lot as well is embedded monitoring. You can use these cool tools that you use in the cloud, such as Grafana Prometheus, to do monitoring of your system. 

Actually deploying stuff is quite easy.

What needs improvement?

I really would like to have a broader library of VCP's or playbooks that I can deploy. That's the only thing I would sometimes really need. I'd like a proper code library.

I would like to see some AI or machine learning or some mechanism that can predict my potential errors. For instance, if I'm running out of a space in my server X maybe it can raise an alert and tell me, "with the current consumption of a storage in the server in 10 days, you're going to run out of space." 

For how long have I used the solution?

I've used the solution since April of 2021.

What do I think about the stability of the solution?

It's quite stable. Usually, even though I manage different customers and I have sometimes connectivity problems with the VPN, I haven't had to reboot the system or the services whatsoever. I'm quite happy with that.

What do I think about the scalability of the solution?

I can't really speak to the scalability. I don't have a big environment. I have multiple small environments and I can connect easily to any of them, therefore, I'm happy.

I would increase my users if my customers added more servers, which may happen. I'm based in Spain and usually, the fiscal year tends to start in January and people are getting more money for the first quarter. I may get some servers for my customers or add some more customers to my list. I don't know if that will happen or not.

How are customer service and support?

I only opened a case when I did the update. They pointed me to the documentation and I felt silly as I could have also found that on the website without them. Beyond that, I didn't need to open any cases, which is good.

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

I also deal with Ansible and Salt. What I have are those solutions embedded into SUSE Manager as SUSE Manager supports both Salt and Ansible with the latest release. That was my driver to include 4.2 in my roadmap instead of just sticking with 4.1. I'd say that SUSE Manager goes beyond configuration management. Sometimes I also use Ansible as a standalone to string some VMs to the cloud and so on. That's great. However, my traditional configurations with Salt or Ansible are just not enough, which is why I also have SUSE.

How was the initial setup?

In terms of the initial setup process, I inherited the solution from someone who just passed over the business for me. I did not need to set it up. However, in relation to the maintenance process, I had to deploy one as we had this migration from SUSE Manager 4.1 to 4.2. It's not an initial setup. I had to spin another 4.2 box and then I migrated the content of my 4.1 environment to my 4.2 environment. It was quite smooth. The documentation was quite nice. I just followed the steps and I had no problems.

What was our ROI?

I haven't done an ROI evaluation yet as we have this new pricing model. What I can say is the savings are going to be good as it's not the same to deal with one tool as opposed to dealing with three tools. 

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

I don't have the exact cost on hand right now as that's something I tend to negotiate in my new year. Thus far, I didn't pay for it. That's going to happen mid-January or something like that. What I was told, by the person who had it before me was that when he made the comparison with other tools, it was cheaper due to the fact that now I basically have the SUSE Manager to manage all environments. In the past, he had Spacewalk to manage the SUSE stuff, and then he had Satellite to manage the record stuff and he had Landscape to manage the Ubuntu stuff. When he consolidated everything, he saved a lot of money.

One of the biggest benefits would be that it incorporates multiple managers in one platform saving you on licensing for multiple solutions. That said, at this time, I don't even know how much it's going to cost as they've changed the pricing this year. I got an email back in the summer saying that, in the past, I would pay for the server and then all the clients. Now, I don't have to pay for the server and then the clients anymore. I just have a flat fare where I can deploy as many servers as I want and everything will be included at the same price. 

The reality is that the server that I'm using right now is only 12 GBs of RAM and I'm considering doing an upgrade to 24GBs. When you include more functionalities and more features, you certainly need more resources. For me, the hardware would be the only real additional cost.

What other advice do I have?

I am a SUSE partner. 

I have a central server and then I'm connected to the VPN. That way, I can connect to all different customers.

I'd advise new users to certainly read the documentation, as that's what I tend to skip. However, it's an important step. Try to automate as much as you can. One of the most powerful things that I noticed when I arrived, was that it was underutilized, and there are all of these automation capabilities that SUSE Manager has. It's saved just so much time for me.

I'd rate the solution at a nine out of ten.

Which deployment model are you using for this solution?

On-premises
Disclosure: I am a real user, and this review is based on my own experience and opinions.
Flag as inappropriate
Get our free report covering VMware, Red Hat, Microsoft, and other competitors of SaltStack. Updated: January 2022.
564,143 professionals have used our research since 2012.