Heat

What is Heat in cloud hosting?

Heat is the orchestration service for OpenStack that automates the deployment, configuration, and lifecycle management of cloud infrastructure. Instead of manually creating instances (virtual machines), networks, volumes, and security groups one by one, Heat allows you to define your entire infrastructure in a single template file. When you submit this template to Heat, it creates all the specified resources in the correct order, respecting dependencies between them.

Heat uses a declarative approach to infrastructure management. You describe the desired end state of your infrastructure in a template, and Heat determines how to achieve that state. This includes creating new resources, updating existing ones, or removing resources that are no longer needed. Heat tracks all resources it creates as a unit called a stack, making it easy to manage, update, or delete an entire application environment with a single command.

Related Terms

• Nova: The compute service that Heat uses to create and manage instances (virtual machines), such as web servers or database hosts defined in a template.
• Neutron: The networking service that Heat uses to create networks, subnets, routers, and floating IPs, such as isolated application networks with internet access.
• Cinder: The block storage service that Heat uses to create and attach volumes (persistent disks), such as database storage that survives instance reboots.
• Glance: The image service that Heat references to specify which operating system images to use when launching instances, such as Ubuntu or CentOS base images.
• Keystone: The identity service that authenticates Heat API requests and determines which projects and resources a user can access.

Why Heat Exists

Before orchestration tools, deploying a multi-tier application in the cloud required manually creating each component through the dashboard or CLI. A typical three-tier application might need: a private network, a subnet, a router, security groups, multiple instances, volumes for each instance, and floating IPs for public access. Creating these resources manually is slow, error-prone, and difficult to reproduce consistently.

Heat solves this problem by allowing you to define all infrastructure in a template. You write the template once, and Heat handles the creation process every time. This ensures that development, staging, and production environments can be identical. It also makes disaster recovery straightforward: if you need to rebuild an environment, you simply rerun the template rather than recreating each resource from memory.

Heat also manages resource dependencies automatically. If your database instance needs a volume attached before the application can start, Heat creates the volume first, waits for it to become available, and then launches the instance. Without orchestration, you would need to script this logic yourself or perform each step manually.

What Does Heat Actually Do?

• Parses templates: Heat reads HOT (Heat Orchestration Template) files written in YAML format and validates the resource definitions, parameters, and dependencies before deployment.
• Creates resources in order: Heat builds a dependency graph from your template and creates resources in the correct sequence, ensuring that a subnet exists before instances try to connect to it.
• Tracks resources as stacks: All resources created from a single template are grouped into a stack, allowing you to view, update, or delete the entire infrastructure as one unit.
• Supports parameters: Templates can accept input parameters at deployment time, allowing the same template to create differently-sized environments (such as small for development, large for production).
• Handles updates: When you modify a template and update the stack, Heat determines what changed and applies only the necessary modifications, creating new resources, modifying existing ones, or deleting removed resources.
• Rolls back on failure: If resource creation fails partway through, Heat can automatically roll back and delete any resources that were created, leaving the environment in a clean state.
• Integrates with other OpenStack services: Heat communicates with Nova, Neutron, Cinder, Glance, and other services through their APIs to provision the actual infrastructure.

When Would I Use Heat?

Heat is valuable when you need to deploy the same infrastructure repeatedly. If your team creates a new environment for each development branch, sprint, or customer, defining that environment in a Heat template eliminates manual setup work. Each deployment is consistent because it uses the same template.

Heat is also useful for complex deployments with many interdependent resources. A microservices architecture with multiple instance groups, load balancers, and private networks benefits from Heat's automatic dependency management. You define what you need, and Heat determines the creation order.

Infrastructure-as-code practices rely on Heat or similar tools. By storing templates in version control, you can track changes to your infrastructure over time, review modifications through pull requests, and roll back to previous configurations if needed.

Heat templates serve as living documentation of your infrastructure. New team members can read the template to understand what resources exist and how they connect, rather than exploring the dashboard or running discovery commands.

When Would I NOT Use Heat?

Heat adds complexity that may not be justified for simple deployments. If you need a single instance with a floating IP and no special networking, using the Horizon dashboard or OpenStack CLI directly is faster than writing a template.

Heat is specific to OpenStack. If your organization uses multiple cloud providers, Heat templates will not work on AWS, Azure, or Google Cloud. In multi-cloud scenarios, tools like Terraform offer provider-agnostic syntax that works across platforms. Terraform also supports OpenStack, making it a practical choice when you need both flexibility and standardization.

Heat requires learning HOT template syntax and understanding how OpenStack resources relate to each other. If your team already uses Terraform for infrastructure management, introducing Heat creates additional cognitive overhead and potential confusion.

Heat manages resources through its own tracking system. Resources created outside of Heat will not appear in stack listings. If you mix Heat-managed and manually-created resources, the environment becomes harder to maintain because some resources are tracked and others are not.

Real-World Example

Company A runs a web application with separate development, staging, and production environments. Each environment needs: one private network with a subnet, one router connecting to the external network, two web server instances behind a load balancer, one database instance with a 100GB volume attached, and security groups allowing HTTP/HTTPS traffic to web servers and PostgreSQL traffic to the database.

Before Heat, the operations team spent two hours setting up each new environment through the Horizon dashboard. They occasionally forgot steps, leading to debugging sessions when applications failed to connect to databases or load balancers could not reach backend servers.

After adopting Heat, Company A created a single template defining all resources. Parameters allow customization: the production template uses larger flavors and more instances, while development uses smaller resources. Creating a new environment now takes five minutes. The team runs one command, provides the environment name and size parameters, and Heat creates everything in the correct order.

When the development team needs to test a new feature, they spin up an isolated environment with the same command. After testing completes, they delete the stack, and Heat removes all associated resources. The operations team no longer receives requests to manually create or clean up environments.

Frequently Asked Questions

What is the difference between Heat and Terraform for OpenStack? Heat is OpenStack-native and deeply integrated with OpenStack services. Terraform is cloud-agnostic and supports multiple providers including OpenStack. Use Heat if you work exclusively with OpenStack and want native integration. Use Terraform if you manage infrastructure across multiple cloud platforms or prefer a single tool for all environments.

What happens if Heat fails to create a resource? Heat can roll back the entire stack, deleting any resources that were successfully created before the failure. This prevents partial deployments where some resources exist but the environment is unusable. You can also configure Heat to leave resources in place for debugging, then fix the issue and retry.

Can I convert an existing environment into a Heat template? OpenStack does not provide automatic export of existing resources to Heat templates. You must manually write a template describing your current infrastructure. Some third-party tools can help discover existing resources, but you will still need to verify and refine the generated template.

How do I update resources managed by Heat? Modify your template and run a stack update command. Heat compares the current stack state with the new template, determines what changed, and applies updates. Some changes require replacing resources (such as changing an instance's base image), while others can be applied in place (such as modifying security group rules).

Can Heat manage resources in multiple projects? A single Heat stack operates within one OpenStack project. If you need resources in multiple projects, you must create separate stacks in each project. Heat does not directly manage cross-project dependencies, though you can reference resources from other projects using their IDs if they are accessible.

Summary

• Heat is the OpenStack orchestration service that automates infrastructure deployment using declarative templates.
• Templates define all resources (instances, networks, volumes, security groups) and their dependencies in a single YAML file.
• Heat tracks resources as stacks, allowing you to create, update, or delete entire environments with one command.
• The service is best suited for repeatable deployments, complex multi-resource environments, and infrastructure-as-code workflows.
• For multi-cloud environments or teams already using Terraform, Heat may add unnecessary complexity compared to using a single cross-platform tool.