Scripting is not industrialising

The discussion was about Windows and I wanted to say so up front to head off the usual reflex: Windows lends itself very well to automation and that is not the point. I was simply adding a distinction we often paper over, between scripting or automating a task on one side and industrialising on the other. A CSV feeding a PowerShell script is already real progress, but you are still essentially doing scripting with templating and ad hoc orchestration. The boundary lies elsewhere and it is conceptual before it is technical.

The ad hoc script, useful and honest

Let us not look down on the script, it does the job and does it well. A CSV as input, a PowerShell loop that iterates, a couple of joins, a template generated on the fly: it is readable, it is immediate and for a one-off need or a modest fleet it is often the right answer. On the Unix side, the equivalent is a key/value .env inventory paired with a .ssh/config, SSH/SCP, well-structured bash and a templating engine like envsubst or mo. Every component is auditable, no magic involved and it runs anywhere there is a bash, a ksh or a zsh.

It is an excellent school and I still hold that knowing how to build that foundation by hand is a serious marker. But it is also, more or less, what Ansible does, while adding idempotence and hundreds of community-maintained modules; reinventing all of that in shell is educational but costly in production and since I have covered it elsewhere, in Ansible’s ancestor and in Unix frugality , I will not revisit it, because it is not the point of this article. The point is that even perfectly executed, that foundation remains a script and a script is not a platform.

What a platform adds and why it changes in kind

The difference is not a matter of code volume or tidiness: you can write magnificent shell that stays scripting and hideous YAML that nonetheless belongs to a platform. What tips it over is a set of properties that, taken together, change the nature of what you are building.

Desired state, first: you no longer describe a sequence of actions to run, but the target to reach and the tool handles the gap. Idempotence, which follows from it: replaying ten times produces the same result as once and it is that guarantee which turns an execution into convergence. The inventory as a source of truth, the variables and reusable roles that factor out knowledge instead of copy-pasting it from one script to the next. Secrets management, which stops being a file you dare not commit and becomes an integrated vault. And finally controlled execution, reporting and traceability: knowing who ran what, on which targets, with what result and being able to prove it.

A hand-rolled script can mimic each of these properties taken in isolation, I have coded homegrown idempotence checks, I have jury-rigged secret vaults in shell. But holding all of them, together, coherently and without burning your evenings on it, is precisely what a platform like Ansible or Salt gives you by construction. The script automates a task; the platform builds a reproducible, industrialised system. That is exactly where I place the boundary.

It is not a question of the system

An old myth needs killing along the way, because it always pollutes this kind of debate: these tools are not reserved for Linux. Ansible natively drives Windows via WinRM or PSRP, Salt also has Windows support with its minions and I have enough playbooks that speak Kerberos and CredSSP to assert that it works in production, not just on paper.

In other words, the CSV plus PowerShell on one side and the Ansible playbook on the other can target the exact same Windows fleet. The boundary does not run between two operating systems, it runs between two natures of tooling. Windows automates very well, once again and it is not Windows that anything is being set against: it is the ad hoc script, whatever the OS, set against the automation platform, whatever the OS.

The cost of the choice, both ways

What remains is not to turn this distinction into dogma, because industrialisation has a cost and it is not free to put in place. Deploying Ansible or Salt, structuring the inventory, writing clean roles, integrating a vault, wiring up the reporting, all of it demands an upfront investment that does not pay off for three machines you touch once a quarter. For that need, the CSV plus PowerShell or the .env plus bash stays the honest answer and pretending otherwise would be ceremony.

The real trade-off is one of scale and recurrence. As soon as a fleet grows, an operation repeats, you have to account for what ran, the script ends up recreating, badly and slowly, the properties a platform offers out of the box and that is the moment, not before, to move your energy from the tooling to the infrastructure. Scripting stays useful, sometimes sufficient; but scripting is not industrialising and conflating the two is expensive either way, whether you industrialise three machines or script a fleet of a thousand. For the rest of the artisanal tooling, what the script ignores and what the container displaces, I cover it in Docker and Ansible and inventory from DNS .

Where to land

The right question is not “shell or Ansible”, nor even “Linux or Windows”, it is “a task to automate or a system to industrialise”. If it is a task, script it, own it and do not apologise for a CSV plus PowerShell that does the job. If it is a system, with scale, recurrence and accounts to render, treat yourself to desired state, idempotence, inventory, secrets and traceability and let the platform carry what the script can only hold in appearance. The boundary is conceptual, it depends on neither the language nor the OS and it is by seeing it clearly that you stop paying the wrong price.