Fig. 1. Ansible runs tasks and exits; anything that needs continuous state or a change plan needs a different tool.

Ansible has a low barrier to entry, which is why it often becomes the first and then the only automation tool in a team. That usually works well for the first year and then increasingly badly, because the tool gets applied to jobs it was never designed for. Below is a comparison that helps decide before the playbook grows to three thousand lines.

What Ansible is good at

Configuring operating systems and services. Packages, configuration files, users, systemd units, firewall rules. This is the core of Ansible and here it works without reservations. Modules are idempotent, and a playbook reads like documentation.

Operational tasks across many machines. Certificate rotation, package updates in a controlled order, gathering facts from an entire fleet, a one-off configuration change. Being agentless means it works wherever there is SSH or WinRM.

Process integration. Ansible connects well to external tools over their APIs: image registries, ticketing systems, CI platforms. A workflow that prepares an environment after an ITSM request and reports back the result is a natural fit.

Windows environments. The win_* modules and WinRM make it possible to manage Windows Server where Group Policy does not reach or is too rigid. For a team that runs both Linux and Windows, one tool for both is a real saving.

What Ansible is bad at

Maintaining state over time. Ansible runs a playbook and exits. It does not watch whether the state holds. If you need continuous reconciliation, as in Kubernetes, you need a controller, not a playbook fired from cron every hour.

Managing Kubernetes resources. The kubernetes.core.k8s module works, but it describes resources imperatively, with no drift detection and no history in a repository. Manifests in Git plus a GitOps controller are the better tool. Ansible can bootstrap a cluster, but it should not run it day to day.

Complex logic. Nested loops, conditions depending on the results of earlier tasks, data transformations in Jinja2. It can be written, but it cannot be read or tested afterwards. When a playbook starts to look like a program, write a program, for example in Python, and call it from the playbook as a single task.

Infrastructure provisioning. Creating virtual machines, networks and volumes is possible, but tools built for it, such as Terraform or OpenTofu, do it with a change plan, state, and diffing. Ansible has none of that.

Rules that keep playbooks maintainable

  • Roles instead of long playbooks. A role does one job, has its own default variables and its own README. The playbook only composes roles.
  • Variables in the inventory, not in tasks. A task should be identical for every environment. Differences belong in the inventory.
  • check_mode must work. A playbook that cannot be dry-run is not fit for production.
  • Secrets outside the repository. Vault or an external secrets manager. An encrypted file in the repository is the minimum, not the goal.
  • Test on a clean system. A playbook that only works on a machine that is already half-configured is not idempotent, merely accidentally convergent.

Summary

Ansible is a tool for configuration and task orchestration, not for maintaining state and not for programming. Used in its role, it stays readable for years. Stretched into areas it was not designed for, it becomes another system nobody wants to touch.