What Is Infrastructure Orchestration? A Clear Definition for Platform Teams
- Daniel Bryant

- 11 hours ago
- 5 min read
In early 2024, I wrote about the three layers a platform needs to work: application choreography, platform orchestration, and infrastructure orchestration. Of the three, everyone assumes they already understand infrastructure orchestration, which is probably why it's rarely defined properly. Search the term today, and you'll still find engineers in r/devops asking each other what it actually covers. This is worth fixing with another short(er) blog sharing my experiences.
What infrastructure orchestration actually means
Infrastructure orchestration is the coordination of provisioning, sequencing, and lifecycle management across the underlying infrastructure resources, such as compute, network, storage, IAM roles, etc., so they come up in the right order and stay correct relative to each other across environments. It's the layer where engineers plan, build, and maintain the infrastructure everything else depends on. It's also not the whole platform on its own.
Where it sits in the three-layer model
In my original piece on this, I laid out three layers, each solving a different problem for a different group of people:
Application choreography, the UI, CLI, or workflow that lets developers code, ship, and run applications.
Platform orchestration, the "missing middle" that lets platform engineers design and apply platform components, policies, and workflows consistently, cutting sprawl and cognitive load.
Infrastructure orchestration, where engineers plan, build, and maintain the infrastructure resources across environments that the other two layers sit on top of.
These layers describe responsibilities rather than product categories. A single tool may address parts of more than one layer, but the distinction helps clarify which platform problems it solves.

The mistake I still see most often is organisations treating the first and third layers as the whole platform. Terraform provisions infrastructure, and a developer portal (potentially with a basic workflow engine) sits on top. This can look like a complete platform, but it isn't. Without the middle layer, every team ends up inventing its own version of policy and (fleet-wide) lifecycle workflows on top of the same infrastructure, which is exactly the sprawl I described back then: tools multiplying faster than anyone can standardise on them.
Why infrastructure orchestration and platform orchestration aren't the same thing
This distinction gets lost most often, including in plenty of vendor content that uses "orchestration" to mean almost anything involving automation. Infrastructure orchestration answers "how do these resources get provisioned and kept correct relative to each other?" Platform orchestration answers a different question entirely: "how do platform components, policies, and fleet-wide lifecycle workflows get applied consistently, so a developer can self-serve safely relative to company policy without raising a ticket?"
Kratix, which we build and maintain as open source, sits at the platform orchestration layer, coordinating on top of whatever infrastructure orchestration you already have, Terraform or Crossplane or a mix. It doesn't change how your infrastructure gets provisioned underneath. It gives that layer a governed, self-service way to reach developers.
Where this leaves platform teams
Infrastructure orchestration usually isn't the hard part. Most teams already have some version of it. The missing layer sits above it, coordinating what's already provisioned into something a developer can consume without a ticket. If you haven't read the original three-layer piece, start there. If you have, and you're trying to work out whether your own platform is missing that middle layer, platform orchestration is the place to look next.
FAQ
Q. Is infrastructure orchestration the same as automation?
No. Automation makes individual tasks happen without manual intervention. Orchestration coordinates multiple automated tasks, resources, and tools so they work together toward a desired outcome. A Terraform module can automate infrastructure creation, for example, but orchestration determines how that module relates to networking, identity, dependencies, approvals, and lifecycle changes elsewhere in the environment. Automation is a building block; orchestration is how those building blocks are coordinated as a system.
Q. Is infrastructure orchestration the same as Infrastructure as Code?
No. IaC describes infrastructure in code; orchestration coordinates those declarations and the resources they create. Terraform and OpenTofu let users declare infrastructure, and the tools perform basic orchestration of the generated resources (ensuring a subnet is created before adding a database, etc.). Tools such as Crossplane can additionally coordinate multiple resources and continuously reconcile them, while products such as Massdriver can orchestrate the execution and dependencies of IaC modules. IaC is therefore an ingredient of infrastructure orchestration, not necessarily the orchestration layer itself.
Q. What does infrastructure orchestration look like in practice?
Provisioning a new environment that needs a database, network configuration, and IAM role, in the right order, with each step's output feeding the next, then detecting and correcting drift as those resources change. That might involve Terraform or OpenTofu coordinated through pipeline tooling, Crossplane continuously reconciling a Composition, or a tool such as Massdriver managing the dependencies and execution of multiple IaC modules. The implementation varies; the defining characteristic is that the resources are being coordinated as a system rather than provisioned independently.
Q. What tools actually do infrastructure orchestration?
Many companies use a combination of tools, although each product could cover much of the orchestration layer itself. Terraform, OpenTofu, and Pulumi let users declare, compose, and provision infrastructure, and the tools themselves perform basic resource orchestration. Crossplane can continuously coordinate and reconcile multiple resources through Compositions, while Massdriver orchestrates IaC modules and their dependencies, execution, policies, and state.
The important distinction is less about the product category and more about whether the tooling coordinates multiple infrastructure resources as a system, rather than simply declaring or provisioning them individually.
Q. Is Massdriver an infrastructure orchestrator or platform orchestrator?
Massdriver spans some of both, though it is rooted in the infrastructure space. At the infrastructure layer, it coordinates IaC modules, dependencies, state, policies, and execution across tools such as Terraform, OpenTofu, Helm, and Bicep. It then exposes those infrastructure components through a catalogue and visual self-service experience for developers. That takes it beyond basic infrastructure provisioning and into concerns associated with platform orchestration.
The three layers aren't product categories per se; they're useful ways to distinguish the problems a platform needs to solve, and individual products can address more than one.
Q. Why do I need platform orchestration in addition to infrastructure orchestration?
Infrastructure orchestration coordinates the resources your platform runs on. Platform orchestration coordinates the capabilities your platform provides. It brings infrastructure, organisational policies, workflows, and other tools together into reusable capabilities that developers and AI agents can safely consume, then manages those capabilities consistently across environments over time.
Pipeline and IaC management tools such as HCP Terraform, Spacelift, and Atlantis can also address some platform orchestration concerns by providing sequencing, approvals, and lifecycle workflows around Terraform, without the broader coordination of a platform orchestration layer. However, beware of the "portals and pipelines" platform building antipattern!
In a nutshell, infrastructure orchestration ensures a database, network, and IAM configuration are provisioned correctly; platform orchestration turns them into a governed "database" capability your organisation can offer and maintain as part of its platform.



Comments