You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
terraform/website/docs/intro/vs/cloudformation.mdx

44 lines
2.8 KiB

---
page_title: Terraform versus CloudFormation, Heat, and other infrastructure as code tools
description: >-
Learn how Terraform manages various cloud providers and services, such as AWS, OpenStack, Cloudflare, and DNSimple, versus CloudFormation, Heat, and other tools.
---
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
> [!IMPORTANT]
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
# Terraform versus CloudFormation, Heat, and other infrastructure as code tools
CloudFormation, Heat, and other infrastructure as code tools allow you to codify the details of infrastructure
into a configuration file. The configuration files allow
the infrastructure to be elastically created, modified and destroyed. Terraform
is inspired by the problems they solve.
Terraform similarly uses configuration files to detail the infrastructure
setup, but it goes further by being both cloud-agnostic and enabling
multiple providers and services to be combined and composed. For example,
Terraform can be used to orchestrate an AWS and OpenStack cluster simultaneously,
while enabling 3rd-party providers like Cloudflare and DNSimple to be integrated
to provide CDN and DNS services. This enables Terraform to represent and
manage the entire infrastructure with its supporting services, instead of
only the subset that exists within a single provider. It provides a single
unified syntax, instead of requiring operators to use independent and
non-interoperable tools for each platform and service.
Terraform also separates the planning phase from the execution phase,
by using the concept of an execution plan. By running `terraform plan`,
the current state is refreshed and the configuration is consulted to
generate an action plan. The plan includes all actions to be taken:
which resources will be created, destroyed or modified. It can be
inspected by operators to ensure it is exactly what is expected. Using
`terraform graph`, the plan can be visualized to show dependent ordering.
Once the plan is captured, the execution phase can be limited to only
the actions in the plan. Other tools combine the planning and execution
phases, meaning operators are forced to mentally reason about the effects
of a change, which quickly becomes intractable in large infrastructures.
Terraform lets operators apply changes with confidence, as they know exactly
what will happen beforehand.