The Evolution of Declarative Cloud Control on Google Cloud: From Terraform to AI-Driven InfraOps

Posted on by uplatzblog

I. The Established Paradigm: Terraform’s Hegemony in Google Cloud

A. Introduction to Terraform and the Declarative IaC Model

The management of modern cloud infrastructure has undergone a fundamental transformation, moving away from manual configuration and imperative scripting towards a more robust, automated paradigm. This shift is rooted in the practice of Infrastructure as Code (IaC), the process of managing and provisioning data center resources through machine-readable definition files rather than physical hardware configuration or interactive tools.1 This evolution was a direct response to the scaling difficulties and complexities introduced by the advent of utility computing and second-generation web frameworks in the mid-2000s.1

At the forefront of this movement is HashiCorp Terraform, an open-source tool that has become the de facto industry standard for IaC. Terraform enables engineers to define, provision, and manage infrastructure across a multitude of cloud providers and on-premises environments using a consistent workflow.2 Its core philosophy is declarative: instead of writing procedural steps to create resources, users define the desired end state of their infrastructure in configuration files. Terraform then takes on the responsibility of determining the necessary actions—creating, updating, or deleting resources—to achieve that state.

bundle-course—sap-technical-abap—abap-on-hana—bo—data-services—bw4hana—hana By Uplatz

The standard Terraform workflow is a three-step process designed for safety and predictability. First, engineers describe their target infrastructure in configuration files using HashiCorp Configuration Language (HCL), a syntax designed to be both human-readable and machine-friendly.2 These files, typically ending in .tf, serve as the blueprint for the environment.5 Second, the terraform plan command is executed. This crucial step evaluates the configuration, compares it to the last known state of the managed infrastructure, and generates a detailed execution plan. This plan outlines precisely what actions Terraform will take, providing a critical opportunity for review and validation before any changes are made to the live environment.2 Finally, upon approval, the terraform apply command executes the plan, making the necessary API calls to the cloud provider via specific plugins to bring the infrastructure into alignment with the declared configuration.2

 

B. The Google Cloud Provider: A Mature and Well-Supported Integration

 

Within the Google Cloud Platform (GCP) ecosystem, Terraform is not merely a supported tool; it is the most commonly used and deeply integrated solution for provisioning and automating infrastructure.2 This prominence is the result of a strong, collaborative relationship between HashiCorp and Google, which actively invests in the development and maintenance of the Terraform provider for Google Cloud.6

This commitment is exemplified by the use of “Magic Modules,” a unique, shared codebase that Google uses to auto-generate the code for both the stable google provider and the google-beta provider. This approach allows for the simultaneous development and release of support for new and emerging GCP features, ensuring that the Terraform provider ecosystem keeps pace with the rapid innovation of the cloud platform itself.2 This level of investment from Google signals a strategic endorsement of Terraform as a first-class citizen for managing GCP resources, a stark contrast to the support level for its own native tooling.

Further cementing this position, Google provides a wealth of official resources to support Terraform users. This includes a vast library of opinionated, deployable modules that serve as blueprints for common architectural patterns, as well as “Jump Start Solutions” that provide getting-started examples for various use cases.2 The official documentation is comprehensive, offering best practice guides, tutorials, and conceptual deep dives to help users of all skill levels effectively manage their GCP infrastructure with Terraform.7

 

C. Core Strengths: Why Terraform Dominates the GCP Landscape

 

Terraform’s dominance in the GCP ecosystem is built on a foundation of powerful features that directly address the core challenges of modern infrastructure management. These capabilities have enabled organizations to move away from the slow, error-prone, and unscalable practice of manually clicking through the cloud console.8

Reproducibility and Consistency: The primary benefit of Terraform is its ability to codify infrastructure, allowing the same configuration to be deployed multiple times to create identical development, test, and production environments. This ensures consistency, eliminates configuration drift between stages, and makes the entire infrastructure version-controlled, auditable, and reproducible.2

Execution Planning and Safety: The terraform plan command is arguably Terraform’s most critical feature. By generating a preview of all intended changes, it provides a powerful safety mechanism that allows teams to review and validate actions before they are applied. This “what-if” analysis prevents unexpected modifications and costly mistakes, which is essential when managing complex, business-critical systems.2

Modularity and Reusability: Terraform’s module system is a cornerstone of its effectiveness at scale. Modules allow teams to encapsulate common infrastructure patterns—such as a virtual machine with specific networking and security rules—into reusable, shareable blocks of code.2 This promotes the “Don’t Repeat Yourself” (DRY) principle, reducing code duplication, increasing readability, and simplifying the management of complex environments.5 Best practices dictate that these modules should be stored in separate, version-controlled repositories, allowing them to be consumed and updated across multiple projects and teams in a controlled manner.8

State Management: At the heart of Terraform’s operation is the state file, a JSON-formatted document (typically .tfstate) that serves as a database for the infrastructure under its control. This file maps the resources defined in the configuration files to the actual resources provisioned in the cloud.2 By maintaining this mapping, Terraform can track the current state of the environment, understand dependencies between resources, and intelligently plan the minimal set of changes required to reach the desired state on subsequent runs. This stateful awareness is what enables Terraform to perform incremental updates, creations, and deletions with precision.2

 

D. Critical Challenges and Operational Overhead at Scale

 

Despite its strengths, operating Terraform effectively at scale introduces a new set of significant challenges and operational burdens. The very components that make it powerful can become sources of complexity and risk if not managed with discipline and the right supporting tools.

State Management Complexity: The state file, while essential, is also Terraform’s Achilles’ heel. Storing the state file locally on an engineer’s machine is unworkable for any collaborative team, as it leads to versioning conflicts, overwrites, and a lack of security, as the file is not encrypted by default.5 The established best practice is to use a remote backend, such as a Google Cloud Storage (GCS) bucket, which provides centralized storage, versioning, encryption at rest, and, crucially, state locking. State locking prevents multiple users or automation pipelines from running terraform apply simultaneously on the same state, which would otherwise lead to data corruption.8 However, even with a remote backend, as infrastructure grows, state files can become large and unwieldy, slowing down operations. Furthermore, managing dependencies between resources defined in different state files (cross-state orchestration) is not a native feature and often requires adopting more complex “meta-tools” or building custom automation wrappers.9

Configuration Drift: A persistent challenge in any IaC workflow is “drift”—the phenomenon where the real-world state of infrastructure diverges from the state defined in the code. This is typically caused by manual changes made directly in the cloud console, outside of the Terraform workflow.8 When drift occurs, the state file becomes an inaccurate representation of reality, which can cause subsequent Terraform runs to fail or have unintended consequences.3 Mitigating this requires a disciplined approach that includes strict access controls to prevent manual changes and the implementation of continuous drift detection. A common practice is to run terraform plan on a regular schedule within a CI/CD pipeline to identify and alert on any discrepancies between the code and the live environment.8

HCL Limitations: While HCL is designed for readability, it is a Domain-Specific Language (DSL) and lacks the expressive power and rich tooling of a general-purpose programming language.9 Performing complex logic, such as conditional resource creation based on intricate data structures or advanced string manipulations, can be cumbersome and lead to verbose, difficult-to-maintain code. This limitation can slow down development cycles, especially when compared to more programmatic IaC approaches.3

Learning Curve and Operational Burden: User reviews and practical experience consistently point to a steep learning curve for mastering Terraform, particularly for those new to IaC concepts.3 Beyond the language itself, effective and secure use of Terraform in a production environment is not a simple matter of running commands. It demands a significant investment in building and maintaining robust CI/CD pipelines. These pipelines must enforce a gated promotion model (e.g., deploying to development, then staging, then production), integrate static code analysis tools for security scanning, and incorporate policy-as-code checks to ensure compliance with organizational standards. This entire supporting ecosystem represents a substantial operational investment and a hidden total cost of ownership.5

The success of Terraform as a foundational IaC tool has, in a sense, created the next generation of infrastructure challenges. Its core architectural decisions—a declarative DSL, an explicit state file, and a point-in-time “push” execution model—were revolutionary for enabling automation at scale. However, these same decisions are the root cause of the primary difficulties encountered when operating it in large, complex, and dynamic environments. The disconnection between the static state file and the ever-changing reality of the cloud environment necessitates a constant, vigilant process of drift detection. The state file itself becomes a centralized point of contention and a performance bottleneck. This has given rise to an entire ecosystem of “meta-tools” like Terragrunt, Atlantis, and commercial platforms like Spacelift, which exist primarily to manage the complexities of Terraform itself. This indicates that the next evolutionary step in cloud control must address these fundamental architectural limitations.

Furthermore, the extensive operational requirements for running Terraform securely and reliably in production have given birth to a specialized engineering discipline. The role of the “Platform Engineer” or “Terraform Operator” is now commonplace in many organizations. This role is dedicated not just to writing HCL but to building and maintaining the complex web of CI/CD pipelines, state backends, security protocols, and drift detection systems that surround the core tool. This reality refutes the simplistic notion of IaC as merely “writing code” and reveals a significant, often underestimated, operational cost that organizations must factor into their decision to adopt and scale Terraform.

 

II. GCP’s Native Tooling: An Analysis of Deployment Manager

 

A. Core Functionality and Architecture

 

Before Terraform’s ascent to industry dominance, Google Cloud offered its own first-party solution for infrastructure automation: Google Cloud Deployment Manager (DM). Launched in 2014, DM is an infrastructure deployment service designed to automate the creation and lifecycle management of GCP resources.11 Like Terraform, it operates on a declarative model. Users define the desired state of their infrastructure in a top-level configuration file, and Deployment Manager orchestrates the necessary Google Cloud API calls to bring the live environment into conformity with that definition.12

The primary configuration file for a DM deployment is written in YAML, a format chosen for its human readability.12 However, the real power and flexibility of DM come from its templating system. Instead of being limited to a static configuration, DM allows configurations to be broken down into reusable templates. These templates can be written in one of two powerful languages: Jinja2, a popular templating engine with a syntax similar to YAML, or, more significantly, Python.14 The ability to use Python allows engineers to leverage a full-featured, general-purpose programming language to generate their infrastructure configurations dynamically. This enables the use of programming constructs like loops, conditionals, and functions, offering a degree of programmatic control that surpasses the capabilities of HCL.17

 

B. Key Features and Intended Benefits

 

Deployment Manager was designed with several key features intended to provide a robust and repeatable deployment process for GCP-centric organizations.

Repeatable, Idempotent Deployments: The service automates the provisioning process, which inherently reduces the risk of manual errors. It is designed to be idempotent, meaning that a deployment can be run multiple times with the same configuration without causing unintended side effects or errors; if the resources already exist in the desired state, DM will simply report success without making changes.12

Preview Mode: Acknowledging the need for safety in infrastructure operations, DM includes a preview mode. This feature, analogous to terraform plan, allows users to see a detailed summary of the changes that will be made—which resources will be created, updated, or deleted—before committing to the deployment.12

Parallel Deployment and Dependency Management: To optimize for speed, DM can provision multiple resources in parallel. It also includes built-in dependency management; if one resource depends on another (e.g., a Compute Engine instance depending on a VPC network), DM will ensure they are created in the correct order.16

Managed State: As a fully managed, hosted service within GCP, Deployment Manager handles the state of deployments internally. This relieves the user of the significant operational burden associated with configuring, securing, and managing a remote state backend, a major point of complexity in the Terraform ecosystem.16

 

C. Significant Limitations and Decline in Prominence

 

Despite its promising features and native integration, Deployment Manager has largely failed to gain widespread adoption and has been effectively superseded by Terraform, even within Google’s own strategic recommendations. Its decline can be attributed to several critical limitations.

GCP-Only: By design, DM is a proprietary, GCP-native tool. This makes it a non-starter for the growing number of organizations adopting multi-cloud or hybrid-cloud strategies, as it cannot manage resources outside the Google Cloud ecosystem.13

Poor Feature Support and “Actions”: The most significant technical flaw of DM is its failure to keep pace with the rapid release of new GCP services. Support for new and even some existing resources is often severely delayed or entirely absent. To work around these gaps, users are forced to resort to an undocumented and officially unsupported feature called “actions”.18 An “action” is essentially a direct, imperative API call embedded within a declarative configuration. This practice breaks the core principles of IaC, as it introduces non-declarative steps that DM cannot track or manage, turning the configuration into a brittle, hybrid script. This reliance on unsupported hacks makes DM an unacceptable risk for serious production use.18

API Brittleness: Deployment Manager’s functionality is tightly coupled to the assumption that every GCP resource exposes a perfect, complete set of CRUD (Create, Read, Update, Delete) REST APIs. In reality, this is not always the case. If a service’s API is missing a method, particularly the delete method, DM’s lifecycle management breaks down. This can lead to situations where a deployment that created such a resource cannot be cleanly deleted, leaving orphaned resources and failing the entire teardown process.18

Google’s Own Recommendation: Perhaps the most telling indicator of DM’s status is that Google itself implicitly and explicitly recommends Terraform over its own product. Comprehensive official guidance, such as the Google Cloud security foundation white paper, provides detailed, prescriptive strategies for implementing IaC using Terraform. No equivalent guidance exists for Deployment Manager.18 This clear signal from the vendor itself serves as a strong directive to the market about which tool is considered strategic and production-ready.18

The Off-Ramp: DM Convert: Reinforcing its status as a legacy tool, Google has developed and provides DM Convert, a command-line utility with the specific purpose of migrating Deployment Manager configurations to other formats. The tool can convert DM’s YAML and template files into either Terraform HCL or the Kubernetes Resource Model (KRM), effectively providing a sanctioned off-ramp for users to move away from the platform.20

The history of Deployment Manager offers a compelling case study in the dynamics of platform ecosystems and the risks of adopting proprietary, single-vendor IaC tools. Launched in the same year as Terraform, DM initially held the advantage of tight native integration and the power of Python-based templating.13 However, this was not enough to compete with the powerful network effects of an open-source, multi-cloud standard. Terraform’s provider-based architecture allowed it to build a vast ecosystem supporting not just GCP, but AWS, Azure, and hundreds of other services.3 This broad utility attracted a massive community of users and contributors who, in turn, ensured the providers were rapidly updated to support new features. Deployment Manager, being proprietary, lacked this community-driven momentum. Over time, it appears even Google’s own internal engineering teams prioritized updating the open-source Terraform provider over maintaining parity for DM’s internal resource types, as evidenced by the persistent feature lag.18 The outcome is a classic example of an open ecosystem out-innovating a closed one, making Terraform the safer and more robust choice even for organizations operating exclusively on GCP.

Furthermore, Deployment Manager’s design occupies an awkward middle ground—an “IaC uncanny valley”—between a simple, restrictive DSL like HCL and a true, modern Infrastructure-as-Software approach like Pulumi or the AWS CDK. While its Python templates offered more programmatic power than HCL, they operated within a sandboxed, constrained environment that disallowed key software engineering practices.16 For example, a developer could not import a standard Python testing library to write unit tests for their infrastructure logic or leverage the vast ecosystem of packages from PyPI. This hybrid model ultimately failed to satisfy either of the market’s diverging preferences: the operational simplicity of a pure DSL or the full power and tooling of a general-purpose programming language. As the market polarized toward these two extremes, DM’s middle-ground approach became a developmental dead end.

 

III. The Kubernetes-Native Future: Config Connector and the GitOps Revolution

 

A. Introducing Config Connector: Configuration as Data

 

As organizations increasingly standardize on Kubernetes as their container orchestration platform, a new paradigm for infrastructure management has emerged, one that seeks to unify the control plane for both applications and the underlying cloud resources they consume. Google’s strategic entry into this space is Config Connector (KCC), a Kubernetes add-on that fundamentally changes the approach to managing GCP infrastructure.21

The core mechanism of Config Connector is to extend the Kubernetes API itself to make it aware of GCP resources. It achieves this by installing a collection of Custom Resource Definitions (CRDs) into a Kubernetes cluster.21 Each CRD represents a specific type of GCP resource, such as PubSubTopic, StorageBucket, or SQLInstance.24 With these CRDs in place, engineers can declare and manage GCP infrastructure using the exact same tools and formats they use for their Kubernetes applications: standard YAML manifests.4 An engineer wanting a new Cloud SQL database no longer writes HCL; instead, they write a YAML file with kind: SQLInstance and apply it to their cluster using kubectl apply. This approach, where infrastructure state is declared as data within the Kubernetes API, is often referred to as “Configuration as Data”.6

 

B. The Continuous Reconciliation “Pull” Model

 

The most profound difference between Config Connector and traditional IaC tools like Terraform lies in its operational model. Terraform operates on a point-in-time “push” model, where changes are only reconciled when an operator manually runs the terraform apply command.24 In contrast, Config Connector embodies the continuous reconciliation “pull” model that is native to Kubernetes.

Inside the cluster, a set of controller processes, deployed as part of KCC, are constantly running. These controllers “watch” the Kubernetes API server for any objects corresponding to the GCP resource CRDs.23 When a new SQLInstance object appears, the relevant controller sees it and makes the necessary API calls to GCP to provision the actual database. More importantly, the controller continuously monitors both the declared state in the Kubernetes object and the actual state of the resource in GCP. If it detects any discrepancy—for example, if someone manually changes a setting on the database in the GCP console—the controller will automatically and immediately act to revert that change, bringing the resource back into alignment with the state declared in the YAML manifest. This provides a powerful, real-time, and automatic drift correction mechanism that does not require any manual intervention or periodic scanning.6 In this model, the Kubernetes API server, backed by its etcd database, replaces the Terraform state file as the single source of truth for the desired state of all managed resources.4

 

C. Synergy with GitOps

 

The continuous reconciliation model of Config Connector makes it a perfect fit for GitOps workflows. GitOps is a methodology for continuous delivery that uses a Git repository as the single source of truth for both infrastructure and application definitions. When KCC is paired with a GitOps agent like Google’s Config Sync or popular open-source tools like ArgoCD or Flux, it enables a fully automated, end-to-end cloud management system.24

The workflow is elegant and powerful:

  1. A developer needs a new Pub/Sub topic. They create a YAML manifest for a PubSubTopic resource and commit it to a designated Git repository.
  2. The GitOps agent running in the Kubernetes cluster, which is configured to monitor that repository, detects the new commit and automatically applies the YAML manifest to the cluster’s API server.
  3. The Config Connector controller for Pub/Sub topics sees the new PubSubTopic object and immediately provisions the corresponding topic in GCP.24

This process creates a unified control plane where the entire state of an application and its required cloud infrastructure is defined declaratively in Git. Changes are made via pull requests, providing a clear audit trail and enabling peer review. The system is self-healing; any manual drift in the GCP environment is automatically corrected back to the state defined in Git. This allows organizations to manage both their Kubernetes workloads and their GCP infrastructure from a single, version-controlled source of truth, using a consistent, fully automated, and continuously reconciling process.24

 

D. Challenges and Considerations

 

While the Kubernetes-native approach offers a powerful vision for unified cloud management, adopting Config Connector comes with its own set of challenges and prerequisites.

The “Chicken and Egg” Problem: The most immediate practical challenge is that in order to use Config Connector, one must first have a running Kubernetes cluster. This initial cluster, along with its associated networking and IAM permissions, must be provisioned using a different tool—most commonly, Terraform.27 This creates a bootstrapping complexity and often results in a hybrid management scenario where Terraform is used to manage the core Kubernetes platform, and KCC is used to manage the resources deployed from that platform.28

Handling Immutable Fields: A significant operational hurdle arises from the fact that many fields on GCP resources are immutable, meaning they cannot be changed after the resource is created (e.g., the location of a storage bucket). If an engineer attempts to modify an immutable field in a KCC manifest, the controller cannot perform an in-place update. This can cause the Kubernetes object to become stuck in an UpdateFailed state. Resolving this often requires a disruptive, manual process of deleting the object (which triggers the deletion of the GCP resource) and then recreating it with the new value, which may not be feasible for stateful resources like databases.27

Dependency Management: While KCC can handle some resource dependencies, the mechanism for referencing outputs from one resource as inputs for another is not as mature or straightforward as Terraform’s interpolation syntax. For example, creating a complex hierarchy of GCP Folders and Projects, where the ID of a newly created Folder is required to create a Project within it, can be more difficult to express and manage in KCC compared to Terraform.28

Kubernetes Complexity: The most fundamental consideration is that this approach is predicated on an organization’s commitment to Kubernetes. Adopting, operating, and securing Kubernetes at a production level is a complex undertaking with its own steep learning curve and significant operational overhead.27 Config Connector is therefore best suited for organizations that are already heavily invested in the Kubernetes ecosystem and have the requisite skills to manage it effectively.4

The adoption of Config Connector represents more than a simple tool-for-tool replacement of Terraform; it signals a profound strategic shift in how an organization views its infrastructure. It is a commitment to elevating Kubernetes from a mere container orchestrator to the universal control plane for all cloud resources. This shift fundamentally changes the role of the infrastructure team. Their primary responsibility is no longer the direct, imperative provisioning of individual resources via pipelines, but rather the declarative management of the platform—the Kubernetes cluster and its fleet of controllers—that in turn provisions those resources. This is a move up the abstraction stack, aligning perfectly with the principles of the burgeoning Platform Engineering discipline, where a central team provides a curated, self-service platform for application developers. In this model, Kubernetes, supercharged with Config Connector, becomes that platform.

This paradigm also dissolves the traditional, often siloed, boundaries between “Application DevOps” and “Infrastructure DevOps.” By allowing infrastructure resource definitions like a SQLInstance or a StorageBucket to reside in the same Helm chart or Kustomize overlay as the application’s Kubernetes Deployment object, KCC enables a truly unified, application-centric delivery model.26 The infrastructure becomes just another component of the application’s versioned, deployable artifact. This reduces the coordination overhead and friction between teams, tightening the feedback loop for developers and empowering them to manage the full lifecycle of their application and its dependencies as a single, cohesive unit.

 

IV. A Comparative Matrix: Selecting the Right Declarative Tool for GCP

 

A. Introduction to the Decision Framework

 

The choice between Terraform, Deployment Manager, and Config Connector is not a simple matter of selecting the “best” tool, but rather a strategic decision that must align with an organization’s technical maturity, existing skill sets, operational model, and long-term cloud strategy. Each tool represents a distinct philosophy of infrastructure management with its own set of trade-offs. This section provides a direct, multi-faceted comparison to serve as a clear decision-making framework for technology leaders. The analysis is anchored by a comprehensive table that distills the key characteristics of each tool, followed by a deeper exploration of the most critical differentiators.

 

B. The Comparative Analysis Table

 

The following table provides an at-a-glance summary of the three declarative tools, comparing them across critical axes relevant to architectural and strategic planning.

Table 1: Comparative Analysis of GCP Infrastructure as Code Tools

Feature/Aspect HashiCorp Terraform Google Cloud Deployment Manager Google Cloud Config Connector
Paradigm Declarative IaC Declarative IaC Configuration as Data (Kubernetes-native)
Configuration Language HCL (HashiCorp Configuration Language) YAML with Jinja2 or Python templates Kubernetes Manifests (YAML)
Reconciliation Model Point-in-time “Push” (via apply command) Point-in-time “Push” (via deployment) Continuous “Pull” (via Kubernetes controllers)
State Management Explicit State File (local or remote backend) Managed by GCP Service Managed by Kubernetes API Server (etcd)
Ecosystem & Scope Multi-Cloud, extensive provider ecosystem GCP-only, limited to API-discoverable resources GCP-only, resources defined by CRDs
Maturity & Support Highly mature, industry standard, strong Google support Legacy, poor support for new services Actively developed, strategic for Google
Integration CI/CD pipelines, broad tool integration GCP-native services Kubernetes, GitOps tools (ArgoCD, Flux)
Ideal Use Case Multi-cloud/hybrid environments, traditional IaC workflows Simple, GCP-only deployments (largely superseded) Kubernetes-centric organizations, GitOps workflows
Key Challenge State management complexity, HCL limitations Feature lag, undocumented behavior, uncertain future Initial cluster setup, handling immutable fields

This structured comparison is strategically valuable because it transforms a complex technical evaluation into a format that directly supports high-level decision-making. For a technology leader, it clarifies the trade-offs inherent in each choice. For example, it starkly contrasts Terraform’s multi-cloud flexibility against Config Connector’s deep but platform-specific Kubernetes integration. Furthermore, it informs decisions about team structure and required capabilities; adopting Config Connector, as the table indicates, presupposes a strategic commitment to and deep expertise in the Kubernetes ecosystem. This artifact can then be used to communicate the rationale behind a chosen strategy to engineering teams, executive stakeholders, and other business units, creating a shared understanding of the technological path forward.

 

C. In-Depth Analysis of Key Differentiators

 

Operational Model (Push vs. Pull): The most fundamental difference lies in the reconciliation model. Terraform’s “push” model is event-driven and operator-initiated. A CI/CD pipeline runs terraform apply, and the infrastructure is updated at that specific moment. Between runs, the system is passive, making it susceptible to unmanaged drift.24 Config Connector’s “pull” model is continuous and autonomous. Its controllers are always active, constantly comparing the desired state in Kubernetes with the actual state in GCP and automatically correcting any deviations.6 This eliminates the concept of drift as a persistent problem, but requires the operational overhead of maintaining the Kubernetes control plane and the KCC controllers themselves. The push model offers explicit, gated control, while the pull model offers a self-healing, always-on system.

State Management Philosophy: The tools embody opposing philosophies on state. Terraform treats state as an explicit and critical artifact—the .tfstate file—that must be carefully managed, secured, and backed up.8 This file provides a detailed, centralized record of the managed infrastructure, but it is also a single point of failure and a major source of operational complexity. Config Connector, by contrast, embraces the Kubernetes philosophy that the API server is the ultimate source of truth. There is no separate state file to manage; the desired state is stored directly as objects in etcd, and the observed state is reflected in the .status field of those objects.4 This simplifies operations by eliminating state file management but distributes the state information across many individual Kubernetes objects, which can make obtaining a holistic view of the entire infrastructure more challenging.

Ecosystem and Portability: This is Terraform’s undisputed advantage. As a cloud-agnostic platform with a vast ecosystem of providers, it allows organizations to use a single tool, language, and workflow to manage resources across GCP, AWS, Azure, and on-premises data centers.3 This prevents vendor lock-in and is essential for any organization with a multi-cloud or hybrid strategy. Both Deployment Manager and Config Connector are, by design, GCP-specific tools.18 Adopting them means committing to a management paradigm that is not portable to other cloud environments, although KCC’s model is being replicated by other providers (e.g., AWS Controllers for Kubernetes).

Developer Experience and Required Skillsets: The choice of tool has significant implications for team structure and skills. Terraform and its HCL language are typically mastered by infrastructure specialists, SREs, and DevOps engineers. The workflow is centered around the command line and CI/CD pipelines. Config Connector, on the other hand, is deeply embedded in the Kubernetes ecosystem. Its user is someone who is already comfortable with kubectl, YAML manifests, and Kubernetes concepts.4 It appeals to Kubernetes-native SREs and application developers who want to manage their infrastructure dependencies alongside their application code. Deployment Manager’s use of Python/Jinja templates was an attempt to appeal to developers but, as discussed, its other limitations have made it a non-viable option for most new projects.18

 

V. Beyond Declarative DSLs: The Industry’s Pivot to YAML-Free Infrastructure

 

A. The “YAML Fatigue”: Limitations of Configuration-Based IaC

 

The discussion of infrastructure management on GCP is part of a broader industry-wide conversation about the tools and languages used to define the cloud. While declarative configuration files written in languages like HCL and YAML were a massive leap forward from manual processes and imperative scripts, their limitations have become increasingly apparent as infrastructure complexity has grown. A sentiment often described as “YAML fatigue” has emerged within the DevOps and platform engineering communities, stemming from the inherent fragility and verbosity of these formats.29

YAML, in particular, won early adoption due to its perceived human readability compared to JSON. However, this readability has proven to be an illusion at scale.29 The language is notoriously sensitive to whitespace and indentation, where a single misplaced space can break an entire configuration, leading to frustrating and time-consuming debugging sessions. More fundamentally, as a data serialization language, YAML lacks native support for essential programming constructs like loops, conditionals, and functions. This forces engineers to rely on external templating engines (such as Helm for Kubernetes or Jinja for Deployment Manager) to introduce any form of logic, adding another layer of complexity and tooling to the stack.29 Refactoring large YAML codebases is a difficult and error-prone task, and the cognitive overhead of navigating hundreds or thousands of lines of nested configuration becomes a significant drag on productivity.31

 

B. The Rise of Programmatic IaC: Infrastructure as Software

 

In response to these limitations, a new paradigm of “YAML-Free” or, more accurately, programmatic IaC has gained significant traction. This approach eschews domain-specific configuration languages in favor of using familiar, general-purpose programming languages to define, provision, and manage infrastructure.19

Pulumi is a leading proponent and example of this model. It is an open-source IaC platform that allows engineers to write their infrastructure definitions in languages they already know and use, including TypeScript, Python, Go, C#, and Java.19 This is not merely a templating system that generates YAML or JSON; the code written by the engineer is executed directly to provision the cloud resources. This approach unlocks the full power and maturity of modern software engineering ecosystems for infrastructure management.

The key benefits of programmatic IaC are profound:

  • Full Programming Constructs: Engineers are no longer constrained by the limitations of a DSL. They can use loops to create multiple similar resources, functions to abstract away complexity, classes to model infrastructure components, and conditional logic to build dynamic environments that adapt to different requirements.19
  • Superior Developer Tooling: This approach allows engineers to leverage the entire ecosystem of mature developer tools they use for application development. This includes powerful IDEs with features like autocompletion and inline documentation, sophisticated debuggers for stepping through infrastructure logic, robust testing frameworks for writing unit and integration tests for infrastructure code, and package managers for sharing and versioning reusable infrastructure components.34
  • True Reusability and Abstraction: While Terraform has modules, programmatic IaC enables a higher level of abstraction and reusability. Engineers can create true software libraries with well-defined interfaces (APIs) that encapsulate complex infrastructure patterns. These libraries can then be published to internal package repositories and consumed by other teams, promoting consistency and best practices in a highly scalable way.34

This shift is not limited to Pulumi. The popularity of tools like the AWS Cloud Development Kit (CDK) and the Cloud Development Kit for Terraform (CDKTF) demonstrates that this is a broad and growing industry trend, driven by a desire to apply the same rigor and practices of software engineering to the discipline of infrastructure management.29

 

C. The Role of Platform Engineering in Abstracting Complexity

 

The move towards programmatic IaC is deeply intertwined with the rise of Platform Engineering as a discipline. The ultimate goal is often not to force every application developer to write complex infrastructure code, but rather to empower a central platform team to build powerful, reusable abstractions that hide the underlying complexity.29

In this model, the platform team uses a programmatic IaC tool like Pulumi to build the foundational “scaffolding” of the infrastructure. They create robust, tested, and compliant components that represent “golden paths” for deploying resources. Application developers can then consume this infrastructure through a much simpler interface—perhaps a high-level API, a self-service UI in a developer portal like Backstage, or even a very simple configuration file that only exposes a few necessary parameters.29 This allows application teams to provision the infrastructure they need quickly and safely, without needing to become experts in the intricacies of cloud networking or security. The YAML and complexity are not eliminated entirely; they are abstracted away and managed by the specialist platform team, enabling the broader organization to move faster while maintaining governance and control.

This evolution from manual operations to scripts, then to declarative DSLs, and now to programmatic languages represents a clear maturity model for infrastructure management. Each successive stage offers a higher degree of abstraction, automation, and reliability. This progression suggests that the choice of an IaC tool is not a static, one-time decision. Instead, organizations can assess their current position on this maturity spectrum and strategically plan their evolution. A team might start with Terraform to establish a baseline of declarative control and then, as their needs for abstraction and dynamic configuration grow, pilot a programmatic tool like Pulumi for more complex components of their stack.

This trend also signals a re-convergence of application and infrastructure development. When the language used to define infrastructure (e.g., Python with Pulumi) is the same language used to write the application, the cognitive barrier for a developer to own their infrastructure is dramatically lowered. A TypeScript developer can use their existing skills and tools to define the databases, queues, and storage buckets their service requires. This facilitates a true “you build it, you run it” DevOps culture, empowering full-stack teams and potentially reducing the need for highly specialized, siloed infrastructure teams in certain contexts.

 

VI. The Next Leap: AI-Driven InfraOps with Gemini on Google Cloud

 

A. The Imperative for AI in Infrastructure Management

 

The landscape of cloud infrastructure is undergoing another seismic shift, driven by the widespread adoption of generative AI. The very act of building, training, and serving large-scale AI models creates an unprecedented level of infrastructure complexity. A recent Google Cloud report reveals that while an overwhelming 98% of organizations are actively exploring GenAI, they are simultaneously facing immense challenges related to legacy system integration, data governance, security, and the sheer complexity of the required infrastructure.35

The success of these GenAI initiatives is proving to be critically dependent on the underlying infrastructure, which must be not only powerful but also highly secure, scalable, performant, and cost-efficient.35 Traditional IaC approaches, even highly automated ones, are struggling to keep pace with the dynamic and demanding nature of these workloads. This creates a powerful feedback loop: deploying and optimizing AI workloads at scale requires a new generation of AI-powered infrastructure management, often termed AI Ops or InfraOps.37 Google is positioning its Gemini family of models as the core technology to power this next leap in declarative cloud control.

 

B. Level 1 – AI as Code Assistant: Gemini Code Assist

 

The most immediate and accessible application of AI in this domain is as a direct assistant to engineers writing infrastructure code. Gemini Code Assist is an AI-powered tool integrated directly into popular IDEs like VS Code and the JetBrains suite, designed to augment the developer workflow for a wide range of languages, including the HCL used by Terraform.40

Its capabilities go far beyond simple autocompletion. Gemini Code Assist can generate entire functions or blocks of code from natural language comments. An engineer could write a comment like # create a regional GKE cluster with 3 nodes and workload identity enabled and have Gemini generate the corresponding, syntactically correct HCL code.40 It can also help with understanding existing code, generating documentation, and writing unit tests.41

For enterprises, a key feature is the ability to customize the model based on an organization’s private source code repositories. This allows Gemini Code Assist to learn an organization’s specific patterns, modules, and best practices, and generate code suggestions that are not just technically correct but also compliant with internal standards.40 This acts as a direct productivity multiplier, accelerating the development of IaC configurations while simultaneously improving their quality and consistency.

 

C. Level 2 – AI as Cloud Strategist: Gemini Cloud Assist

 

Moving up the abstraction stack, Gemini Cloud Assist functions as a conversational AI strategist embedded within the Google Cloud console itself. It is designed to assist with higher-level planning, design, and operational tasks, leveraging the context of the user’s specific GCP projects and resources to provide tailored guidance.44

For infrastructure management, its capabilities represent a significant step beyond simple code generation:

  • Design and Build: Within a feature called the Application Design Center, users can describe their technical and business requirements in natural language. Gemini Cloud Assist can then collaboratively produce solution architectures and generate the corresponding IaC, including both Terraform configurations and gcloud CLI commands, to provision that architecture.44 It can also help generate and simulate organizational policies to ensure the design is compliant from the outset.
  • Diagnose and Resolve: When issues arise, Gemini Cloud Assist can create AI-driven investigations. By analyzing logs, error messages, and performance metrics, it can diagnose complex problems, identify root causes, and suggest remediation steps. For particularly difficult issues, it can even hand off the entire investigation context to a Google Cloud support case, streamlining the escalation process.44
  • Optimize Cost and Usage: The assistant can answer natural language questions about cloud spending (e.g., “What was my most expensive service last month?”) and provide proactive recommendations for cost optimization, such as identifying underutilized resources or suggesting more efficient machine types for a given workload.44

This level of assistance transforms the AI from a simple coding partner into a strategic advisor, helping engineers and architects make better, more informed decisions about their cloud infrastructure.

 

D. Level 3 – AI as Autonomous Agent: The Future of InfraOps

 

The ultimate vision for AI in infrastructure management extends beyond assistance to autonomous action. Google is actively developing AI agents capable of understanding high-level goals and executing complex, multi-step tasks to achieve them, with a “Human in the Loop” providing necessary oversight and approval.42

Early examples of this capability are already emerging. The Gemini CLI is an AI agent that operates within the command-line terminal, capable of understanding natural language commands to perform tasks like file manipulation, code analysis, and command execution.42 This represents a crucial step towards giving AI direct agency within the operational environment.

The future of InfraOps will involve translating high-level business intent into concrete infrastructure changes. An operator might issue a command like, “Prepare our e-commerce platform for a 5x traffic increase for the Black Friday sale, prioritizing reliability and cost-efficiency.” An advanced AI agent would then be able to:

  1. Analyze the current architecture and performance metrics.
  2. Design a scaled-up, resilient architecture.
  3. Generate the required IaC to implement the changes.
  4. Present the plan for human approval.
  5. Upon approval, execute the plan to deploy the changes.
  6. Monitor the system during the event and dynamically adjust resources as needed.
  7. After the event, automatically scale the infrastructure back down to its normal state.

This paradigm moves beyond declarative control, which defines “what” the infrastructure should be, to intent-based control, which defines “why” the infrastructure exists. The AI agent becomes responsible for determining and executing the “how,” ushering in a new era of automated, intelligent, and self-adapting cloud infrastructure.

The advent of AI assistants like Gemini is set to solve the “blank page” problem that has long been a hurdle in infrastructure development. No longer will an engineer need to create a new Terraform module or Kubernetes manifest from scratch. Instead, the workflow will begin with a natural language prompt, from which the AI will generate a context-aware, baseline configuration tailored to the specific project.43 This initial draft, even if imperfect, serves as a massive accelerator. This fundamentally shifts the critical human skills required for the job. The emphasis moves away from the rote mechanics of writing configuration syntax and towards the higher-value tasks of reviewing, validating, and securing AI-generated code. This has profound implications for how DevOps and platform engineering teams will need to be trained and skilled in the coming years.

Furthermore, the static nature of traditional IaC is ill-suited for the dynamic and costly reality of large-scale AI and ML workloads.36 A configuration defined and applied on Monday may be suboptimal by Tuesday as usage patterns shift. The future of InfraOps will not be about simply remediating drift back to a static, predefined state. It will involve AI agents that continuously monitor a rich stream of real-time data—performance metrics, cost information, security alerts—and dynamically suggest or, with permission, apply infrastructure changes. This represents a shift from reactive drift remediation to proactive, continuous optimization. An AI agent could observe an ML training job underutilizing its expensive GPU allocation and autonomously resize it to a more cost-effective machine type, or automatically shift a non-critical batch processing workload to cheaper Spot VMs, achieving a level of real-time efficiency that is impossible to attain with human-driven, point-in-time deployment cycles.

 

VII. Strategic Recommendations and Future Outlook

 

A. Synthesizing the Evolutionary Path

 

The journey of declarative cloud control on Google Cloud is a clear narrative of escalating abstraction and intelligence. It began with the rigid, vendor-locked model of Deployment Manager, which gave way to the flexible, multi-cloud, industry standard of Terraform. The paradigm then shifted with Config Connector, which introduced a Kubernetes-native, continuously reconciling model for a unified control plane. Now, we stand at the precipice of the next great leap, where programmatic IaC models are converging with AI to create a future of intent-driven, self-optimizing infrastructure. This is not a history of simple replacements, but of evolving paradigms, each with a valid and strategic place depending on an organization’s specific context, maturity, and goals.

 

B. Actionable Recommendations for Technology Leaders

 

Navigating this evolving landscape requires a nuanced strategy that recognizes the value of existing investments while preparing for the transformative potential of new technologies.

For Terraform-centric organizations: Terraform remains a robust, mature, and strategically sound choice, especially in multi-cloud or hybrid environments. The focus should be on maturing operational practices.

  • Invest in Automation: Double down on building robust, secure CI/CD pipelines that incorporate automated testing, security scanning, and policy-as-code checks.
  • Master State and Drift: Implement rigorous processes for managing remote state with locking and versioning. Establish automated, continuous drift detection to maintain the integrity of the IaC workflow.
  • Embrace AI Assistance: Begin integrating AI code assistants like Gemini Code Assist into developer workflows. This is a low-risk, high-reward step to immediately accelerate HCL development, improve code quality, and reduce the learning curve for new team members.

For Kubernetes-native organizations: If Kubernetes is the strategic heart of your technology platform, a move towards Config Connector for managing GCP resources is a compelling and logical step.

  • Pursue a Unified Control Plane: The operational simplicity and velocity gains from a single, GitOps-driven workflow for both applications and infrastructure are immense.
  • Plan for the Transition: Acknowledge and plan for the bootstrapping complexity. Develop a clear strategy for managing the initial Kubernetes cluster (likely with Terraform) and for migrating existing resources to KCC’s control.
  • Develop New Operational Patterns: Create runbooks and best practices for dealing with the unique challenges of the KCC model, such as handling updates to immutable resource fields and managing dependencies between Kubernetes-defined resources.

For organizations exploring “YAML-Free” IaC: For teams with strong software engineering talent, particularly those building complex, dynamic, or highly abstractable infrastructure platforms, piloting a programmatic IaC tool is a strategic imperative.

  • Target High-Complexity Areas: Identify areas where the limitations of HCL or YAML are causing the most friction—such as managing multi-environment configurations or building internal developer platforms—and use them as the initial use case for a tool like Pulumi.
  • Leverage Software Engineering Practices: Fully embrace the benefits of the paradigm by implementing comprehensive testing suites, building shared libraries, and integrating with existing software development tools to maximize productivity and reliability.

Preparing for the AI-Driven Future: Regardless of the current IaC toolchain, all organizations must begin preparing for the imminent impact of AI on infrastructure operations.

  • Start with Assistance: Encourage and support the use of AI assistants for code generation (Gemini Code Assist) and strategic design (Gemini Cloud Assist). This builds familiarity and trust in the technology.
  • Develop an Agent Strategy: Begin formulating a strategic roadmap for the eventual adoption of autonomous AI agents. This includes defining the use cases, establishing clear governance policies, and determining the necessary levels of human oversight and approval for automated actions. The future is about partnership with AI, not replacement by it.

 

C. Concluding Vision: The Future of Declarative Cloud Control

 

The future of cloud infrastructure management will not be defined by a single, monolithic tool. Instead, it will be a hybrid and layered system, combining the strengths of each evolutionary paradigm.

The foundation will be a robust, continuously reconciling control plane, a role for which Kubernetes is the leading contender. This control plane will manage the desired state of all resources, providing a self-healing and consistent base. The logic for defining and managing this state, especially for complex and reusable components, will be written using powerful, programmatic IaC tools that allow for true software engineering rigor.

Overlaying this entire stack will be a pervasive layer of artificial intelligence. This AI will serve as the primary interface for human operators, translating high-level business intent into low-level configuration. It will continuously monitor and optimize the running system for cost, performance, and security, moving beyond static declarations to dynamic adaptation. It will automate complex operational sequences, from initial deployment to incident response and capacity planning.

In this future, the role of the human infrastructure engineer will be elevated. They will evolve from a hands-on-keyboard provisioner, wrestling with YAML syntax and state files, to a strategic architect of this intelligent system. Their focus will be on defining the business outcomes, setting the policies and constraints, and acting as the ultimate supervisor for a fleet of AI infrastructure agents. The ultimate goal of this evolution is to create a truly intent-driven cloud: a resilient, efficient, and secure infrastructure that largely manages itself, freeing human talent to focus on delivering the innovation and value that drives the business forward.