Infrastructure

Origin & evolution

For most of computing's history, infrastructure was provisioned by hand: someone racked a server, partitioned a disk, edited a config file. The shift came with cloud APIs, which made every resource scriptable, and with the practice that grew to exploit them. Kief Morris of ThoughtWorks defined infrastructure as code in his book of that name: managing infrastructure through definitions executed by tools, the same way application code is managed, rather than through manual steps in a console.

Two properties became central. The first is idempotency: a definition should reach the same end state no matter how many times it runs or what state it starts from. Declarative tools such as Terraform express a desired end state and reconcile reality to match it, which is what makes a component reproducible instead of a hand-built snowflake. The second is the mutable-versus-immutable choice. Mutable infrastructure is patched in place, which invites configuration drift as ad hoc changes accumulate. Immutable infrastructure replaces a component wholesale on every change, eliminating drift and giving every version a clean rollback.

The arc of the field has been to treat each component as a defined, versioned, disposable artefact. A database is no longer a precious machine someone tends; it is a declaration in a repository that any teammate can read, review, and rebuild. That reproducibility is what later let the same component slot cleanly into automated pipelines and monitoring.

How it works in practice

A team needs🫀NeedUserA user need, pain, desire, or constraintView reference → a Postgres database for a new service. Instead of clicking through a cloud console, they write a Terraform definition: instance class, storage size, backup retention, the security group that fences it off. They commit it, a teammate reviews the diff, and the pipeline applies it. The component now exists as a named, versioned object rather than tribal knowledge.

Because it is defined this way, the rest of the operational machinery attaches automatically. The CI pipeline🚇CI PipelineDevOps & PlatformA CI/CD pipelineView reference → that provisions it also wires a monitor to its connection-pool saturation. The component carries a service level objective🥅Service Level ObjectiveDevOps & PlatformA service level objective (SLO)View reference → of 99.95% availability, and the on-call rotation that covers the parent service inherits responsibility for it. Six weeks later, when a noisy-neighbour problem appears, the team bumps the instance class in the definition and re-applies, and the change is reviewable in the same place as the original. Nothing about the database lives only in someone's memory.

Infrastructure component vs. its neighbours

• Service. A service⚙️ServiceEngineeringA deployable service or microserviceView reference → is a running unit of application behaviour, an authentication API, a payments worker. An infrastructure component is the provisioned resource it consumes. One database component may underpin several services; one service may sit on compute, cache, and queue components at once. The component is provisioned; the service is deployed.
• Deployment📤DeploymentEngineeringA deployment eventView reference →. A deployment📤DeploymentEngineeringA deployment eventView reference → is the act of pushing a version of software onto infrastructure. The infrastructure component is the target of that act, the place the version lands. Provisioning the component and deploying onto it are distinct steps with distinct failure modes.
• Monitor. A monitor📺MonitorDevOps & PlatformA monitoring checkView reference → watches a component's health. The component is the observed; the monitor is the observer. A provisioned component with no monitor is a resource you are trusting blind, which the graph can flag.

In the graph

In the Unified Product Graph an infrastructure component is a hub in the operations region, the point where software meets the substrate it runs on. A product connects through product_runs_on_infrastructure_componentProductruns onInfrastructure Componenthierarchy, observation👁️ObservationUser ResearchA specific behaviour or statement observedView reference → attaches through infrastructure_component_monitored_by_monitorInfrastructure Componentmonitored byMonitorhierarchy, reliability commitments through infrastructure_component_committed_to_service_level_objectiveInfrastructure Componentcommitted toService Level Objectivehierarchy, and provenance through infrastructure_component_built_by_ci_pipelineInfrastructure Componentbuilt byCI Pipelinehierarchy. Those four edges let one query reconstruct a component's full operational context: what depends on it, who watches it, what it promises, and how it came to exist. A component missing any of them is a known shape of risk🎲RiskComplianceA risk to the product or businessView reference →, an unmonitored resource, an undefined provisioning path, that the structure makes visible rather than waiting for an incident🚨IncidentDevOps & PlatformA production incidentView reference → to reveal.