Hello all interested in Infrastructure as Code (IaC).
This article is for anybody who whats to learn little bit more about the IaC and how it evolved. It's more about the journey from past towards the present. It's all about my personal experience and preference.

IaC is a must, there is no exception. !!! Exclamation Mark !!!

But why? Lest take a look to the past first.

The story

I started my carrier as Linux admin some way back in nineties. The Linux was very fresh by that time, but mature enough to handle the work. There was also the Windows server family with Windows NT server and Windows 2000.
I used always Debian, do not remember now the exact version, but it does not matter in our story. I had reasonable similar start with both environments. Windows and Linux. I used them for several years in parallel with good results. Each of the systems had it cons and pros. Windows was better for managing users accounts with Active Directory (AD) and Linux was better in everything else.

Windows vs Linux

Why Windows cannot be professional solution for IaC? It's flawed from start. The Windows ecosystem is focused on GUI. That is the strongest and weakest part if it. You can do everything with GUI. That's good. But can you replicate it? If you are using English version, you are mostly OK. But fun starts when you use some localization. In my times it was Czech. Then it stat to be very confusing all. The translation is the part of the issue. If you know the English term, it not always translated as you expect. The other issue is with the sorting. The sorting of icons in the menu is simply different. So if you remember that that icons were sorted in some order. In Different language version they are not. Also often there was not simple way of switching language as in the Linux. Something with the licensing :(. If you bought Czech, then you could not use English, and if it was not simple switch like defining few variables in env. The other fun comes with newer versions. They tend to invent a wheel all over again, reshuffling thing little bit, creating more chaos in the process.
Strike down for Windows. I stopped using it...
The Linux had also GUI, but primary focus was for command-line. Everything could be done in command-line. And there was that structure i liked. Everything was in place. There were some differences after all, but even different distributions had always configuration in /etc, logs in /var/log and so on. So with little grepping you could work efficiently with any distribution and any version.
I do not use Windows servers any more, i do not plan to. I know there was some evolvement regarding the command-line interface, but i do not want to explore it anymore. Well I was using some Windows servers recently. But its pure pain, pain, pain.

Linux

So it was the Linux and it all started with |. You could write simple one liners to do interesting stuff and then you could write a simple bash script to do another better stuff. BUT
It all resulted in scripts nightmare. All servers were full of scripts. Various versions. Simply thousands of scripts. If you had large environment it was very hard to maintain. By that time all work was manual. Connect to server, run some script, change, run and again. If you had to manage several thousands of machines, it was difficult. There were some bastions or jumphost server from where you could run these scripts, from cron, or by hand or by some web page. It was difficult to provide variables for these scripts and it had many more issues. The description of these scripts were missing in 90% the same applies for description of parameters which can be supplied. It was obvious that this is not the way. Something had to change.

Puppet - Chef - Ansible - SaltStack

2005 - 2009 - 2012 - 2011

Its already quite a while, when these tools were released. I used them all for some extend. For me is the Ansible clear winner. Buts let hear the story why.

Push or Pull

It was quite a discussion at the beginning what is better. But after a while the winner was clear. NONE. It does not matter. It's always about use case. But these all these systems you can tune up to behave in opposite they were intended for.

Speed

It's always a big discussion about speed. But it is more about how you write it, or if your approach is good. But what i value most is ease of usage and stability of results. The speed contest would win Saltstack or chef, maybe puppet. But for me the speed is the least interesting metrics. If it takes long. You are doing something wrong anyway :-)

Agent or no Agent

In theory the agent wins. In practice its not so clear. There are few problems.

• upgrades of agents - In these old days, upgrading to a new major version was a thing. There was chicken and egg problem. You had old version of agents, which wont work with new code. and you could not upgrade to the new version of agent as it was not running on the old system. The only way was to upgrade all the systems at once and also the code base. Or create two servers with different versions of code. Or i don't upgrade at all and stick with the old version. :-) Clear winner OLD version.

• always syncing - You had to have good canary hosts to test your changes, or do some tricks to stop downloading the code all the time when you wanted to test something difficult. It happened to me that i made a mistake and messed up little bit firewall configuration on all servers so they had all ingress DENY. It was fun. At least they had egress working and were able to download fixed version.

• stuck - These agents were stuck so often for no reason. I had to kill them so many times. Even there were no other issues on the servers.

Ansible does not have agent. It's enough to have ssh and Python installed and you are good to go. No stuck agents. No need for canary hosts, and no such big troubles with upgrades. You have to resolve how to run in on whole infrastructure, but these days its easy. Pipeline in Gitlab CI or Jenkins or Argo or any other pipelining tools.
I never used that AnibleTower. It's too much GUI :-) Should I try?

Complexity and features

There is ton of comparison articles between those tools. I'll simply write what i like on Ansible and do no like on others.
Certainly puppet, chef and salt are very powerful tools. No doubt about that. But there is price for that. And the price is high. If you do not maintain order you will shoot yourself in the leg. As example it was very difficult to get what check will apply to the server. You never know which variables was taken, it was very confusing. you had to run it and pray. Once i found some variable changed inside some chef code on the very unexpected place. I was like. What the hell. The same thing applies to salt. I was able to read what it is doing, but it was more like any other programming language. No comments ever anywhere. The problems is you understand what what it is doing, but you don't know what was intention of that programmer who wrote it. And we all know that these systems can be extremely complex. With Ansible every piece of code starts with name Even most lazy admins tent to fill up at least some information there, which can be very helpfull in the future.
Often there is a need to run one timer. It can happen that you want to upgrade or simply do one time thing. With these agent tools, its not very simple. You had to have some other tool which you used for that job. That was inconvenient. Maybe these time it changed, but i doubt. With Ansible you can use the same inventory, the same variables, the same everything, for your freshly written one timer job. :-)

Ansible Summary

So after all, the Ansible is the clear winner. Its easy to debug, its easy to test, its easy to run, its easy to understand other admins work, It's very flexible and can be used to one timers or for repeatedly running jobs.

But story is not over yet. We are still not in present. Lets continue with in second part. Soon.

PS: What is your experience? Leave message in the comment section.