Google Cloud for the systems where the data is the product.
AI-native Google Cloud engineers for BigQuery data platforms, GKE and Cloud Run services, Pub/Sub back ends and Vertex AI workloads — managed as code and handed over with the runbook.
- Terraform
- BigQuery
- Dataflow
- Pub/Sub
- Cloud Run
- GKE
For systems where the hard part is the data.
Google Cloud is the platform we reach for when the hard part of a system is the data: an analytics estate that has outgrown its warehouse, a product whose value is a model trained on years of events, a pipeline that has to ingest messages at high volume and answer questions about them. BigQuery does the warehouse without servers to size, Pub/Sub and Dataflow do the streaming, and Vertex AI puts training, hosting and evaluation behind one set of APIs. Fewer moving parts for the same result.
It is also the cloud with the least ceremony for running containers. Cloud Run takes an image and gives back an HTTPS endpoint that scales to zero; GKE is managed Kubernetes from the company that started the project, and it shows in how little there is to operate. Our own products run on cloud infrastructure managed as code, and the Google Cloud estates we build get the same treatment: an organisation with folders and projects, everything in Terraform, everything observable. The service behind it is DevOps & Cloud; the analytics work on top is Data Engineering.
When we don’t: a Microsoft organisation with Entra ID, .NET and an enterprise agreement gets more from Azure; a team that needs the widest catalogue of managed services or already has deep experience elsewhere usually belongs on AWS; and a small web product can ship on Vercel without a cloud project at all. We are experienced across all three majors and financially neutral — the recommendation follows your constraints.
Six things we ship on Google Cloud.
BigQuery data platforms
Partitioned and clustered warehouses fed by Dataflow or Datastream, modelled in dbt, governed through Dataplex, and served to Looker, Power BI or the application directly. One truth for reports and models alike.
Streaming pipelines
Pub/Sub for ingestion, Dataflow for windowing, enrichment and exactly-once delivery into BigQuery or Bigtable — telematics feeds, clickstreams, transaction events — with dead-letter topics and replay from the first commit. Where Kafka already exists, we bridge rather than replace.
Services on Cloud Run and GKE
APIs and workers in Go, Node.js or Python on Cloud Run when the workload is request-shaped, GKE Autopilot when you run many services or need the Kubernetes ecosystem, with Cloud Deploy or ArgoCD for release.
Organisation and landing zone
Folders and projects per environment and workload, organisation policies for the rules that must not be broken, Shared VPC with Private Service Connect, and IAM through groups with workload identity for machines — the foundation the rest inherits.
ML and generative AI on Vertex AI
Training pipelines, model registry, endpoints and evaluation on Vertex AI, Gemini for retrieval-based assistants inside your project boundary, and the guardrail and evaluation layers from our AI & Machine Learning and MLOps practice around them.
Migrations
Database Migration Service for PostgreSQL and MySQL into Cloud SQL or AlloyDB, BigQuery Migration Service for Teradata and Redshift warehouses, and Migrate to Virtual Machines for the servers that must move as they are — under the Cloud Migration method.
When to choose it.
Choose Google Cloud when the centre of gravity is analytical: a warehouse measured in terabytes, streaming events at volume, models trained and served as part of the product. BigQuery’s separation of storage and compute means a small data team can run what would take a platform team elsewhere. It fits container-native teams who want Cloud Run’s simplicity or GKE’s maturity, and organisations already on Google Workspace, where identity and groups are in place.
Look elsewhere when the workload is Windows, .NET Framework or SQL Server — Azure can save you licensing money and operational friction — or when your team already has years of AWS experience and no analytics-heavy requirement to justify a change. Look elsewhere too when the product is a single small web application; a cloud organisation with projects, VPCs and IAM is more platform than it needs. We will say so before you commit.
A Cloud Run service that scales to zero and talks to the database over private IP.
resource "google_cloud_run_v2_service" "orders_api" {
name = "orders-api-${var.env}"
location = var.region
ingress = "INGRESS_TRAFFIC_INTERNAL_LOAD_BALANCER"
template {
service_account = google_service_account.orders_api.email
vpc_access {
network_interfaces { subnetwork = google_compute_subnetwork.services.id }
egress = "PRIVATE_RANGES_ONLY"
}
+ scaling { min_instance_count = var.env == "prod" ? 1 : 0 }
containers { image = "${var.registry}/orders-api:${var.image_tag}" }
}
}A typical Odeontech data-and-services estate on Google Cloud.
What the Google Cloud estates we hand over have.
- Everything in Terraform. No resource created in the console survives the next apply. Plans are reviewed in pull requests and applied by a pipeline, not a laptop.
- Least-privilege IAM as code. A service account per workload with only the roles it needs, IAM through groups for people, no downloaded keys, and workload identity federation for CI and external systems.
- Private by default. Cloud SQL and Memorystore on private IP, Private Google Access for the APIs, internal ingress on Cloud Run unless the service is meant to be public, and organisation policies that forbid public buckets and external IPs.
- Encryption with keys you control where the data class demands it: Cloud KMS customer-managed keys on BigQuery, Cloud SQL and buckets, with rotation on and key access reviewed like any other permission.
- Observability wired in. Cloud Monitoring and OpenTelemetry feeding Grafana dashboards, SLO-based alerts for the symptoms users feel, and audit logs routed to a project nobody can edit.
- Backups that have been restored. Retention per data class, cross-region copies and BigQuery snapshots for the datasets that matter, and a restore rehearsed and timed before go-live.
- Cost as a design input. BigQuery partitioning, clustering and slot reservations where scans are predictable, committed-use discounts for steady compute, scale-to-zero for everything bursty, and budgets with alerts per project.
- Residency decided early. Region choice, replication scope and access paths documented for KVKK and GDPR before the first resource exists, not after the audit.
What usually ships alongside the infrastructure.
- A Terraform repository per organisation layer and per workload, with environments and a documented promotion path
- A project and IAM map: which project holds what, which group can do which thing, and where the logs go
- CI/CD pipelines in Cloud Build or GitHub Actions that plan, scan, apply and deploy — with rollback tested, not assumed
- dbt models, tests and documentation for the warehouse, with lineage visible in Dataplex
- Grafana dashboards and alert policies for the four golden signals and pipeline freshness, exported as code
- A cost baseline with labels, budgets, slot and commitment registers reviewed regularly, at a rhythm agreed with you, and runbooks for deploy, rollback, restore and replay
Frequently asked questions
Neighbouring stacks and the services that use them.
A data platform or a Google Cloud estate to build.
Tell us how much data there is and what has to be true about it. A Google Cloud engineer reads it and replies in writing with how we would approach it.