Infrastructure as Code: Maturity, Pitfalls, and the Road Ahead

Infrastructure as code (IaC) has completed its journey from a DevOps curiosity to a standard engineering practice. Terraform is ubiquitous. Pulumi is gaining ground in teams that prefer general-purpose programming languages. AWS CDK and similar tools have brought IaC into the application layer for teams deeply invested in specific cloud ecosystems. The question is no longer whether to adopt infrastructure as code — it is how to mature an IaC practice from basic resource provisioning to a genuinely robust, scalable, and maintainable infrastructure management discipline.

At DeepDots Ventures, we are investors in developer tools broadly and infrastructure tooling specifically, which means we spend a lot of time talking to teams at different stages of their IaC maturity journey. The patterns we observe — both the success patterns and the failure patterns — are remarkably consistent across organization types and sizes.

The IaC Maturity Curve

Level 1: Scripted provisioning. The baseline. Infrastructure is provisioned by scripts, typically bash or cloud CLI commands, that can be run in a defined order to produce a working environment. The scripts are rarely idempotent — running them twice produces errors or duplicate resources. Documentation is informal and often wrong. This level reduces manual click-ops but introduces its own maintenance burden.

Level 2: Declarative IaC. The team has adopted a declarative IaC tool — Terraform, Pulumi, CloudFormation — and is defining their infrastructure in configuration files. State management is addressed, though often imperfectly. Resources can be added and modified without manual intervention. The team has some confidence that the IaC definitions represent actual infrastructure state, at least most of the time. Drift — where the actual infrastructure diverges from the IaC definitions due to manual changes or failed applies — is a persistent concern.

Level 3: Modular and reusable IaC. The team has decomposed their infrastructure definitions into reusable modules. Common infrastructure patterns — VPC configurations, database clusters, Kubernetes node pools — are defined once and referenced by multiple consuming configurations. The module library is maintained with the same discipline as application code: versioned, tested, and reviewed. New infrastructure provisioning typically composes existing modules rather than writing new low-level resource definitions.

Level 4: Policy as code and compliance automation. Infrastructure policy — who can provision what, in which environments, under what conditions — is encoded in policy definitions that are automatically enforced rather than manually reviewed. Tools like Open Policy Agent, Sentinel (for Terraform Cloud), or cloud-native policy frameworks enforce security guardrails, cost controls, and compliance requirements as part of the IaC apply process. Audit trails are generated automatically.

Level 5: Infrastructure testing and drift detection. The team treats infrastructure code with the same testing discipline applied to application code. Integration tests verify that provisioned infrastructure behaves correctly, not just that it was created. Drift detection runs continuously, comparing actual infrastructure state against IaC definitions and alerting on divergence. Security scanning of IaC definitions happens in CI, catching misconfigurations before they reach production.

The Terraform Fork and Its Implications

HashiCorp's decision in August 2023 to change Terraform's license from MPL 2.0 to BUSL 1.1 — and the subsequent community fork, OpenTF (now OpenTofu), shepherded into the Linux Foundation — was a significant event in the IaC landscape. The practical impact on most Terraform users has been limited: the BUSL license restrictions apply to commercial use of Terraform to build competing products, not to organizations using Terraform to manage their own infrastructure.

But the license change created real uncertainty, and that uncertainty has had lasting effects on the Terraform ecosystem. A subset of organizations adopted a policy of preferring OpenTofu over Terraform for new deployments. Several significant Terraform tooling vendors shifted their roadmaps to ensure compatibility with both Terraform and OpenTofu. The fragmentation of the Terraform ecosystem, even if modest in practice, has reduced the network effects that made Terraform's position as the dominant IaC tool feel unassailable.

From an investment perspective, the Terraform fork story is a useful reminder that infrastructure tooling market position is more fragile than it appears, even for tools with enormous installed bases. The companies that build durable businesses in IaC tooling are those that provide genuine value beyond the core IaC runtime — policy enforcement, testing, drift detection, cost management, and the collaboration features that make IaC manageable at enterprise scale.

The Drift Problem

Infrastructure drift — the divergence between IaC definitions and actual infrastructure state — is one of the most consistently cited pain points among IaC practitioners. Drift occurs through manual changes in cloud consoles, failed or partial IaC applies, automated changes by cloud services (auto-scaling adjustments, security patch rollouts), and differences between the tool versions used at apply time and the current tool version.

Drift is not just an inconvenience. It is a reliability and security risk. Drifted infrastructure may behave differently than the team expects, causing outages or security gaps that the team is unaware of. Resolving drift when it is discovered is often a complex and risky operation, particularly for stateful resources like databases and storage systems where the actual state may contain production data that cannot be easily reconstructed from IaC definitions.

The tooling for continuous drift detection is improving but remains immature. Some IaC platforms provide built-in drift detection (Terraform Cloud, Spacelift), while others require custom automation. The quality and reliability of drift detection varies significantly across cloud providers and resource types. We see this as a specific, valuable product opportunity for companies building IaC tooling that is serious about enterprise adoption.

Cost Management Integration

One of the most underappreciated use cases for IaC tooling is infrastructure cost management. When infrastructure is defined as code, it becomes possible to analyze the cost implications of a proposed infrastructure change before it is applied — essentially a cost simulation layer that gives engineers and finance teams visibility into the cloud spend implications of every infrastructure change.

Tools like Infracost have pioneered this category, providing cost estimation integrated into CI/CD pipelines and pull request workflows. The category has attracted growing enterprise interest as cloud costs have become a significant and increasingly scrutinized line item in technology budgets. The integration of cost awareness into the IaC change workflow — so that engineers can see the expected cost impact of their infrastructure changes before merging — is a product approach that creates genuine value and is relatively defensible against cloud provider competition.

AI-Assisted Infrastructure Management

The AI revolution in developer tools is reaching IaC, and the implications are significant. AI tools that can generate, review, and explain infrastructure configurations are already available and improving rapidly. Natural language to Terraform — describing an infrastructure requirement in plain language and receiving correct, security-hardened Terraform code in response — is a capability that is genuinely useful and increasingly reliable.

More interesting, from our investment perspective, are AI systems that can analyze existing IaC definitions and identify optimization opportunities: cost reduction, security hardening, compliance gap remediation, and performance improvement. These systems require a combination of deep infrastructure knowledge and the ability to reason about complex dependency graphs, which makes them technically challenging to build well. The companies that crack this combination will have access to very large enterprise budgets.

We are also watching the emerging category of autonomous infrastructure remediation — systems that can detect infrastructure issues (drift, security misconfigurations, performance degradation) and automatically propose or apply remediation without human intervention. This is technically ambitious and carries real operational risk, but the potential productivity gains for platform engineering teams are substantial.

Our Investment Perspective

The IaC tooling market is large, active, and evolving quickly. The core provisioning layer — Terraform, Pulumi, OpenTofu, CDK — is reasonably commoditized, and we do not see compelling seed investment opportunities in competing directly with these platforms. The investment opportunity lies in the layer above: policy, testing, drift detection, cost management, collaboration, and the AI-assisted capabilities that are beginning to emerge.

We specifically focus on IaC tooling companies that have found a specific, high-value use case with clear enterprise buying intent — security and compliance automation, cost management integration, and AI-assisted remediation are the categories we watch most closely. If you are building in this space, we want to hear from you.