标签：#fdi

Published June 17, 2026 by gyorgy Infrastructure used to be something you wrote separately from your application. Lately that boundary has been dissolving, and the vocabulary has not kept up. Three distinct ideas are getting blurred together, partly because they all start from the same place: your code already implies what infrastructure it needs, so why state it twice. They diverge sharply on what they do about that. Here is the short version, then the longer one. The short version Infrastructure as Code (IaC). You describe the infrastructure explicitly, in its own files. The tool turns those files into real resources. Total control, total verbosity, and your infrastructure definition lives apart from your application code. Framework-defined Infrastructure (FdI). The framework infers the infrastructure from your application code, and a managed platform provisions it for you. Almost no configuration, no drift between app and infra, but the inference only covers what the framework exposes, and the resulting infrastructure runs on the platform's rails. Infrastructure as Framework (IaF). The framework reads your applications and generates infrastructure code that you own, deployed into your own cloud accounts. The framework does the inferring, you keep the output and the account. Who writes the infra Who owns the output Where it runs Scope IaC You, by hand You Any cloud Anything you can express FdI The framework The platform The platform What the framework exposes IaF The framework You Your cloud accounts What the framework covers The rest of this is just those three rows, explained. Infrastructure as Code IaC is the established answer. You write declarations, in HCL or a general-purpose language, that spell out the resources you want: this VPC, this load balancer, this database, these IAM bindings. A tool like Terraform or Pulumi reads the declarations and reconciles your cloud to match. The strength is that nothing is hidden. Every resource is something you chose and