Two Tools, Two Philosophies
Infrastructure as code has become essential for managing modern environments, yet confusion persists around which tool fits which scenario. Terraform and Ansible both describe infrastructure declaratively, both execute changes automatically, and both integrate with version control. These surface similarities obscure fundamental differences in design philosophy and optimal use cases.
Terraform excels at provisioning—creating and managing the lifecycle of infrastructure resources. It models desired state, calculates dependencies, and determines the order of operations automatically. Ansible shines at configuration—installing software, modifying files, and orchestrating multi-step procedures across existing infrastructure. One declares what should exist; the other describes how to achieve a specific configuration.
The distinction matters because choosing the wrong tool for a task leads to fragile automation, convoluted workarounds, and maintenance nightmares. Teams often default to whichever they encountered first, creating Ansible playbooks that awkwardly provision cloud resources or Terraform configurations that contort themselves into configuration management roles.
Terraform's Sweet Spot: Resource Lifecycle Management
Terraform manages infrastructure through providers that expose APIs as declarative resources. Declaring an AWS VPC, Azure virtual network, or Cisco ACI tenant creates a dependency graph that Terraform traverses to determine creation order. Changes to declarations trigger calculated updates, additions, or deletions. State tracking enables drift detection and reconciliation.
This approach works brilliantly for infrastructure with clear API boundaries. Cloud resources, DNS records, network devices with structured APIs, and SaaS configurations all fit naturally. Terraform handles dependencies automatically—security groups before instances, subnets before route tables—without explicit ordering. Modules enable reusable patterns for common infrastructure components.
The state file makes Terraform powerful and occasionally problematic. It tracks what actually exists versus what should exist, enabling accurate change plans. However, state becomes a shared resource requiring coordination mechanisms, careful backend configuration, and occasional manual intervention when reality diverges unexpectedly from recorded state.
- Immutable infrastructure patterns where resources are replaced rather than modified
- Multi-environment deployments with variable-driven configurations
- Resource relationships with complex dependencies
- Infrastructure requiring precise drift detection and correction
Ansible's Domain: Configuration and Orchestration
Ansible executes tasks sequentially across target systems using SSH or API connections. Playbooks describe procedures—install this package, configure that service, copy these files—with conditional logic and variable substitution. Modules abstract system differences, allowing the same playbook to work across distributions or platforms with minor adjustments.
Configuration management represents Ansible's core strength. Installing application dependencies, configuring web servers, deploying application code, and managing configuration files all fit its task-oriented model naturally. Playbooks can orchestrate complex procedures: database migrations, rolling updates with health checks, or multi-stage deployment workflows.
Unlike Terraform's resource-centric approach, Ansible thinks in terms of operations performed against inventory. The same playbook can configure five servers or five hundred by adjusting inventory. No state file exists; Ansible checks current state at execution time and determines necessary actions. This stateless approach simplifies some scenarios but complicates drift detection.
- Application deployment and configuration management
- Operating system hardening and compliance enforcement
- Network device configuration changes requiring procedural steps
- Orchestration workflows spanning multiple systems or services
- Ad-hoc operational tasks and troubleshooting procedures
Common Mistakes and Anti-Patterns
Using Ansible to provision cloud infrastructure creates brittle automation. Modules exist for AWS, Azure, and other providers, but they lack Terraform's dependency resolution and state management. Playbooks grow complex tracking what exists, handling partial failures becomes awkward, and refactoring infrastructure requires careful manual coordination. The result resembles imperative programming masquerading as infrastructure code.
Conversely, forcing Terraform into configuration management roles produces equally problematic results. The null_resource with local-exec provisioners or remote-exec blocks essentially runs shell scripts, abandoning Terraform's declarative benefits. Configuration drift occurs silently because Terraform cannot detect file changes or package updates. Teams end up with pseudo-Terraform that lacks both proper lifecycle management and effective configuration control.
Another frequent error involves duplicating infrastructure definitions across tools. Terraform provisions a server, then Ansible playbooks hardcode IP addresses or instance IDs. Changes require updating multiple places, creating synchronisation headaches. Proper integration uses Terraform outputs as Ansible inventory sources, maintaining single sources of truth and enabling automatic propagation of infrastructure changes.
Integration Patterns That Actually Work
Successful automation uses each tool for its intended purpose. Terraform provisions infrastructure and outputs connection details, instance identifiers, or configuration parameters. Ansible consumes these outputs—directly or via dynamic inventory scripts—to configure the provisioned resources. This separation maintains clarity: infrastructure definitions live in Terraform, configuration procedures in Ansible.
For network automation specifically, Terraform handles resource creation in controller-based platforms like Cisco ACI or SD-WAN orchestrators. Ansible manages device configuration through CLI or API interactions, especially where procedural steps or complex validation logic appears. A Terraform module might provision an ACI tenant and EPGs, while Ansible playbooks configure routing protocols or access policies on individual switches.
CI/CD pipelines orchestrate both tools without conflating their responsibilities. Terraform plan and apply stages create or modify infrastructure. Subsequent Ansible playbook execution configures the changed infrastructure. Each tool's output feeds the next stage, creating a coherent automation workflow. YS Infomatics implements this pattern for network change pipelines, using Terraform for fabric-level changes and Ansible for device-specific configuration, with validation gates between stages ensuring each layer succeeds before proceeding.
The key lies in recognising that infrastructure as code encompasses multiple concerns. Provisioning, configuration, and orchestration all matter. Using the right tool for each concern—rather than forcing one tool to handle everything—produces maintainable, reliable automation that teams can actually understand and evolve over time.