Simplifying Database Management with Config Connector

Overview

As Mesoform Athena evolved, we identified an opportunity to bring database deployment into the same Kubernetes-native operating model used across the wider platform.

Athena provides cross-cloud, cross-environment centralised monitoring and observability through the CAPM Stack. We extended this approach to database infrastructure, moving away from a separate deployment model and adopting the same declarative, repeatable approach we use across Athena.

Using Google Cloud Config Connector, managed PostgreSQL resources can be defined, reconciled and maintained through Kubernetes, alongside applications and other infrastructure. This brings database management into the same GitOps-driven workflow, reducing operational complexity while improving consistency and repeatability.

The result is a more unified approach to infrastructure management, with databases managed as part of the platform rather than as a separate operational concern.

 

The Challenge: The Overhead of Imperative Workflows

In a traditional IaC model (such as Terraform), provisioning cloud resources relies heavily on multi-file module hierarchies, remote state locking, and separate multi-stage CI/CD pipelines.

[ Code Changes ] ──> [ Plan Pipeline ] ──> [ State Lock ] ──> [ Apply Pipeline ]

As a platform scales, this pattern introduces noticeable friction:

• Pipeline Complexity: Managing distinct execution steps (plan, apply) for infrastructure outside the application release loop.
• State Management: Constant coordination around central .tfstate backends and lock files.
• Configuration Drift: Out-of-band changes are only flagged when a pipeline run is manually or sequentially triggered.

 

The Solution: Configuration-as-Data

Rather than maintaining separate tools and pipelines to manage infrastructure, the Configuration-as-Data model leverages Kubernetes Custom Resource Definitions (CRDs) to declare the desired end-state of cloud resources. Software operators handle the continuous reconciliation behind the scenes.

[ Application & Infra Manifests ] ──> [ GitOps / kubectl ] ──> [ Operator Reconciliation ]

 

Minimal Declarative Resource Definition

By defining cloud resources directly in Kubernetes YAML (using tools like Google Cloud Config Connector), infrastructure is managed using the exact same workflows as application workloads:

dapiVersion: sql.cnrm.cloud.google.com/v1beta1
kind: SQLInstance
metadata:
name: platform-db-instance
spec:
databaseVersion: POSTGRES_13
region: us-central1
settings:
tier: db-g1-smal

(Note: Cloud SQL and Config Connector serve as a practical example here, but the declarative model applies universally across cloud infrastructure.)

 

Key Takeaways

• Reduced Code Footprint: Eliminates verbose module hierarchies in favour of concise, clear configuration files.
• Continuous Reconciliation: Operators actively reconcile desired infrastructure state in real time without waiting for external pipeline triggers.
• Unified Tooling: Developers declare infrastructure alongside application deployments using native kubectl and GitOps toolchains.
• Lower Cognitive Load: Developers work with a consistent set of tools and workflows, reducing context switching.
• Improved Security & Compliance: Applies consistent configuration and governance across database and platform resources.

 

---

 Looking to Modernise Your Platform?

Whether you're adopting managed cloud services, automating infrastructure with GitOps, or simplifying Kubernetes operations, Mesoform helps organisations build secure, scalable cloud platforms that are easier to operate and evolve.

Explore how we can help.