The Evolution of Ansible (Part 2): Terraform’s Role, the Collections Split, and the AI Era

Part 1 ended at a somewhat awkward moment in history: Ansible had won the traditional configuration management battle with its agentless architecture and minimalist YAML, but the main battlefield of operations work was quietly shifting away from simply configuring servers.

Starting in 2014, several turning points reshaped Ansible:

 2014 --- Terraform Emerges
      -> Provisioning (Day 0) and configuration (Day 1)
         settle into a decade-long division of labor
 2019 --- IBM Acquires Red Hat
      -> Entry into a large enterprise platform ecosystem
 2020 --- Collections Split
      -> Monolith decoupled; maintenance responsibilities
         pushed back to the community and hardware vendors
 2020-25- Competitors Sold Out
      -> Chef, Puppet, and SaltStack decline
         amid a wave of forks
 2026 --- Container & AI Waves
      -> Holding ground in network devices; exploring
         AI generation and execution governance

Over that decade, Ansible ceded some of its scope, redrew the boundaries of community governance, and found its footing again under pressure from immutable infrastructure and generative AI.

⭐️Why Terraform Didn’t Swallow Ansible—and Ansible Didn’t Swallow Terraform

When Terraform arrived in 2014, Ansible already had built-in cloud modules: creating EC2 instances, configuring VPCs, and attaching cloud storage volumes could all be done directly from a playbook. Judging by the feature list alone, Terraform did nothing Ansible could not do.

Yet a decade later, almost no one in the industry uses Ansible to manage the lifecycle of cloud resources, and few use Terraform to configure the internals of a server. Neither has absorbed the other. The key is state.

The Dividing Line: State Files

Terraform relies on a state file to record every resource it provisions. That state enables three core capabilities:

• Planning changes (plan): Read the state of remote resources, compare configuration and state, and propose the changes to be made.
• Detecting drift: Identify resource changes made outside the configuration when refreshing remote state.
• Destroying resources (destroy): Know exactly which resources it created, so it can cleanly remove them.

Ansible, by contrast, deliberately does not keep a state file. On every run, it connects directly to its targets to inspect their actual state, relying on module idempotence to move the system toward the desired state. This is exceptionally lightweight for managing a single server, but it faces structural limitations when working with cloud APIs:

• No change plan for the resource graph as a whole: Ansible’s --check dry-run mode depends on support from individual modules. Simulation is limited when later tasks depend on results that earlier tasks would produce only during an actual run. Terraform’s plan, meanwhile, can produce an overall change plan based on resource references and state, although external changes made after planning can still affect the outcome.
• Deletion must be explicitly declared: Removing a declaration from a playbook leaves the remote cloud resource untouched. Removing one from Terraform configuration, however, usually puts the corresponding infrastructure into the deletion plan; it is removed only after that plan is applied.
• Dependencies must be worked out manually: Terraform can automatically derive a DAG (directed acyclic graph) from resource references. Ansible tasks are primarily a linear list executed from top to bottom.

Terraform’s limitations are equally clear in the other direction: it focuses on the existence and attributes of resources, while configuring the operating system inside a running server is not its strength. Although Terraform provides provisioners for running commands after resource creation, the official documentation explicitly calls them a “last resort”, because they compromise the purity of the declarative state model.

Ansible’s decision to avoid state files and its decision to avoid installing agents are two sides of the same design philosophy: reduce the additional maintenance burden on both the control node and managed nodes. It does not need a Terraform-style resource state file, but inventories, credentials, and job records on enterprise platforms still need to be managed.

A Decade of Division Ends Under One Roof

Eventually, the industry settled into a clear division of labor: Terraform handles Day 0 infrastructure provisioning; Ansible takes over Day 1 system configuration. Both projects’ official teams have published multiple articles emphasizing that the tools complement each other rather than compete.

This division cost Ansible the fastest-growing cloud-native market, where resources are created and destroyed through APIs and discarded after use. It also helped Ansible retain its territory in long-lived physical machines and server operations.

That decade-long division reached its conclusion on February 27, 2025: IBM completed its $6.4 billion acquisition of HashiCorp. Terraform and Ansible, longtime rivals and partners, finally came together under the same parent company.

The Great Collections Split: Decoupling the Code, Redistributing Responsibility

Released on October 31, 2019, v2.9.0 was Ansible’s last release from a monolithic repository.

At the time, the ansible/ansible repository contained both the core engine and more than 3,000 modules. Its successor, v2.10.0, released on August 13, 2020, formally split the project into two layers:

 [ Ansible 2.9 Monolith ]
   ansible/ansible (Engine + 3,000+ Modules)
         |
         v
 [ Ansible 2.10+ Split ]
   +-- ansible-core
   |    Core Engine + Minimal Modules (file, copy, apt...)
   +-- Ansible Community Package
        ansible-core + 100+ Collections

• ansible-core (initially called ansible-base): Retains only the core scheduling engine and the most basic built-in modules, such as file, copy, template, package, apt, and yum. It is maintained directly by Red Hat’s core team.
• Ansible community package: Bundles more than a hundred independently maintained collections, preserving the out-of-the-box experience of pip install ansible. Users must switch to the full FQCN (Fully Qualified Collection Name, such as community.general.xxx) when calling modules.

The official engineering rationale was compelling: the monolithic repository had become too burdensome to maintain, and many modules had long been poorly maintained or even broken. After the split, each collection could follow its own release schedule. Hardware and cloud vendors could also update their modules freely without waiting for an Ansible core release.

Moving Maintenance Outward and Removing Unmaintained Collections

From an open-source governance perspective, however, the split meant that maintenance responsibilities formally moved out of Red Hat’s single repository and back to each collection’s maintainers and community.

The project established a strict removal process: when a collection lacks active maintenance for an extended period and its problems remain unresolved, it is marked as unmaintained and removed from the community package in the next major release.

The most emblematic case came in late 2024.

The community voted to remove community.network. On October 7, 2024, a community vote decided to remove community.network from the Ansible community package. Its last feature release had been in 2022, followed by only sporadic bug fixes over the next twelve months. Starting with Ansible 12, users who need the collection must install it themselves through ansible-galaxy.

This case exposed the cost of the split: continued releases of the core engine do not mean every collection has someone maintaining it. For enterprise users, vendor maintenance and certified support therefore became important selection criteria. The Uber case discussed later follows this path.

Why Has Ansible Never Been Forked?

Set Ansible’s history beside the OpenTofu fork triggered by Terraform’s switch to the BSL license in 2023. Ansible has gone through repeated community friction, including the major 2.10 split and narrower installation options for AWX, yet it has never faced a serious community fork.

There are three main reasons:

1. The licensing baseline has never changed: ansible/ansible has remained under GPLv3. Users’ existing software rights have never been revoked in fourteen years.
2. The boundary of commercialization was drawn early: AnsibleWorks established its strategy from the start—an open-source engine, with a proprietary UI and enterprise governance. Red Hat did not need to take back underlying assets it had already open-sourced, as HashiCorp did.
3. Upstream raised the barrier but did not close the door: AWX’s official installation method was narrowed to the AWX Operator on Kubernetes/OpenShift, eliminating lightweight Docker and RPM options and making self-hosting harder. But its features were not locked behind a commercial license.

Making software harder to use draws complaints; taking away existing rights drives forks.

Acquisitions and a Wave of Forks: Ansible’s Platform Integration Advantage

Between 2020 and 2022, first-generation configuration management tools were acquired one after another. Licensing and distribution policies also changed around this period, but the two were not always directly connected: Chef’s distribution policy changed before Progress acquired it.

Chef’s Cinc provides a community-built free software distribution, while Puppet’s OpenVox and Terraform’s OpenTofu continue their respective projects through forks. Together, these responses illustrate that source-code licensing and the conditions for obtaining official executable builds are two separate boundaries.

We’re not forking Puppet; Perforce is forking Puppet. What Perforce is doing right now is taking the open source code that we have collaborative used, debugged, written, collaborated, stared at and deployed on thousands of machines, and closing access to it to paying customers.

— Antoine Beaupré, Puppet community member

Ansible alone has kept the original promise of pip install ansible intact.

The Protective Umbrella of a Platform

Ansible holds one important advantage over these competitors: its integration into Red Hat’s enterprise operating system portfolio.

Red Hat’s core business is RHEL, and its enterprise customers also need patching, configuration, and compliance auditing. Ansible can grow within that existing customer base and support organization, while integrating with RHEL and OpenShift management. From this perspective, platform integration is an advantage that supports Ansible’s continued development, but it cannot by itself explain the different fates of these tools.

The IBM Era: From Standalone Automation to an Enterprise Control Plane

After IBM acquired Red Hat, the two companies pushed Ansible toward becoming a platform: it evolved from a CLI tool for running playbooks in a terminal into an enterprise automation control plane, Ansible Automation Platform (AAP).

 [ Enterprise Systems ]
        |
        | (Events/Webhooks)
        v
 [ Event-Driven Ansible (EDA) ]
        |
        | (Rulebook Match)
        v
 [ Automation Hub / Execution ]
        ^
        | (Certified Roles)
        |
 [ AAP Control Plane  ]

Three Key Technology Initiatives

1. Event-Driven Ansible (EDA, 2023): As Part 1 discussed, Ansible twice tried installing persistent processes on managed nodes in its early years, ultimately returning to pure SSH both times. EDA takes a different approach: it places the persistent event-listening logic on the control node rather than the managed nodes. Through rulebooks, it listens for monitoring alerts, webhooks, and Kafka messages and automatically triggers the corresponding playbooks without human intervention. This adds the real-time response capability that previously required a persistent agent, while preserving the agentless promise.

2. Certified content (Certified Collections): Red Hat introduced a certified content system in its commercial Automation Hub. Hardware and cloud vendors such as Cisco, Juniper, Arista, and AWS write the modules; Red Hat vets them and backs them with enterprise support. This formally turns the burden of maintaining the module ecosystem into a commercial incentive for vendors.

3. Execution Environments: These package ansible-core, Python, collections, and system dependencies into container images, which can be built with ansible-builder and stored in a registry. When the same playbook moves from a developer’s machine to CI or the automation platform, it can use the same dependency environment, reducing the “it runs locally, fails on another machine” gap.

These three initiatives address when automation is triggered, who maintains its content, and what environment runs it. The point of becoming a platform is to turn an individual’s automation work into processes that a team can reuse and manage.

Ansible in 2026: Holding Its Ground in Physical Hardware

As cloud-native applications shift entirely toward containers and immutable Kubernetes architectures, Ansible’s real value has retreated to areas container technology cannot cover: physical network devices, storage hardware, and compliance auditing.

How Uber Manages 5,000 Network Devices

In April 2026, Uber’s engineering team explained how it uses Ansible to manage 5,000 enterprise network devices across six continents and five regions:

• Scale: Switches, routers, external gateways, and firewalls, with individual device configurations that can reach 2,000 lines.
• Workflow: A nightly enforcement workflow, run every 24 hours, automatically backs up current configurations to Git, renders vendor-specific commands from Jinja templates, and pushes the changes.
• Selection criteria: Uber explicitly identified Ansible’s agentless architecture as the main reason for choosing it. Third-party daemons cannot be installed on switches and routers; only an SSH-based push model can provide unified management across hardware vendors.

Ansible is agentless: it doesn’t need a local daemon in the client to manage them.

— Uber Engineering Blog

 [ Uber NetOps CI/CD ]
          | (Nightly 24h Run)
          v
 [ Jinja2 Config Engine ] -- (Render Template)
          |
          v
 [ Certified Collections ] -- (SSH Push)
          |
          v
 5,000 Network Devices
      +-- Cisco Switches
      +-- Juniper Routers
      +-- Arista Gateways

This case illustrates Ansible’s position in 2026: immutable infrastructure can swallow application servers, but it cannot swallow physical network devices and on-premises data centers.

The AI Era: Will Playbooks Lose All Their Value?

For years, engineers’ most common complaints about Ansible have centered on the minutiae of YAML: remembering obscure module parameters, checking for indentation errors, and writing Jinja2 filters that are hard to debug.

As large language models (LLMs) became widespread, Red Hat launched Ansible Lightspeed, integrated with watsonx, in late 2023. It later added support for OpenAI, Gemini, and bring-your-own-model (BYOM) deployments, allowing operations staff to generate playbook tasks directly from natural-language prompts.

This often raises a question: if AI can produce shell and Python scripts at the click of a button, why do operations teams still need Ansible?

Less Syntax Work, More Value in Execution

AI reduces the cost of looking up module parameters, handling YAML indentation, and writing Jinja2 expressions. It does not decide the correct target state for a team. As producing playbooks becomes easier, the value of Ansible’s ecosystem is more likely to concentrate in three areas:

1. Idempotent modules and change previews: Declarative modules make repeated execution easier to control, while check mode helps preview changes for supported modules. But idempotence does not mean a configuration is correct, and a dry run is no guarantee of safety. For example, the shell module can offer only limited predictions through conditions such as creates and removes.
2. An operational interface with explicit parameters: Modules provide established parameters, operational semantics, and structured results. Compared with generating a new free-form script each time, this makes it easier for teams to constrain and inspect the operations a model proposes. They still need to verify the module’s capabilities and input values.
3. Platform-level authorization and auditing: AAP’s Automation Controller provides RBAC, credential management, and centralized job records. These capabilities come from the platform layer, not from ansible-playbook alone. When models join the workflow, teams still need to define clearly who can launch jobs and which targets those jobs can operate on.

Generating New Jobs or Triggering Approved Ones?

A model can participate in automation in two different ways. The first is to generate a new playbook for humans to review and test; Lightspeed’s code generation falls into this category. The second is to use platform APIs to trigger job templates that have already been reviewed, with limits on the available parameters and target scope.

The second approach makes risk easier to control: the model chooses which job to run, while its operations and permissions are defined in advance. Choosing the wrong job, parameters, or targets can still cause incidents, however. The value of the execution layer lies in making changes inspectable, explicitly authorized, and traceable. This is an assessment of AI automation architecture, not a claim that model-triggered jobs have become standard practice for all teams.

An Unexpected Dividend from History

Fourteen years ago, Ansible chose existing YAML over inventing a dedicated DSL to lower the barrier to development. That decision drew criticism over YAML’s limited expressiveness.

In the LLM era, the choice has gained another advantage: YAML is widely used in configuration files and automation workflows, and Ansible has accumulated public playbook examples and module documentation. Compared with inventing a narrowly used DSL, adopting a general-purpose format makes it easier to reuse existing tools and examples, with models generating the content and humans inspecting it.

It is therefore reasonable to infer that YAML makes Ansible easier to integrate with AI tools. This advantage comes from the widespread use of a general-purpose format and the accumulated resources of a public ecosystem. Actual generation quality still depends on whether the model understands Ansible’s modules, versions, and task semantics. That decision to avoid custom syntax unexpectedly lowered the barrier to adopting AI today.

Conclusion: The Next Role for a Mature Tool

From the division of labor with Terraform to the collections split and Uber’s network management, Ansible has continued to adjust the responsibilities it takes on. AI may change how playbooks are written, while mature modules, consistent execution environments, and platform authorization and auditing remain reasons for teams to use it to manage changes. Whether these capabilities remain in demand will determine its next role.