Google Cloud engineering
Google Cloud is strongest where its own products are strongest — containers, data and machine learning. For products built around those, it is often the cleanest and cheapest place to run.
Where we use Google Cloud
Google Cloud is part of the stack on these 4 services. Each page covers how we work, what you get and what it costs to start.
Google Cloud in practice
Google Cloud is at its best where Google’s own strengths are: containers, data and machine learning. Cloud Run in particular is the least operational overhead available for a containerised service — you hand it an image and it scales, including to zero, billing only while requests are being served.
GKE is the most polished managed Kubernetes, which shows in day-two operations rather than on day one. And BigQuery removes the entire question of provisioning and tuning an analytics warehouse. For products shaped around those three things, GCP is frequently both cheaper and simpler than the alternatives.
What we build with Google Cloud
Cloud Run and GKE deployments, where scale-to-zero suits variable traffic and keeps idle cost near nothing.
BigQuery-backed reporting and the ingestion that feeds it.
Vertex AI and Vision APIs behind product features, hosted next to the data they operate on.
Is Google Cloud right for you?
Ask usA good fit when
- Containerised services with variable or spiky traffic
- Analytics workloads that suit BigQuery
- Machine learning close to the data
- Teams that want Kubernetes without operating the control plane
Probably not when
- Enterprises whose procurement is already committed elsewhere
- Workloads depending on AWS-specific managed services
- Teams with no GCP experience and no reason to build it
What we run alongside Google Cloud
The rest of the setup, and why each piece is there. We keep this list short on purpose — every dependency is something someone has to maintain.
- Cloud Run
- Containers with scale-to-zero. Often the cheapest way to run a service with uneven traffic.
- GKE Autopilot
- Kubernetes without managing nodes, billed per pod.
- Cloud SQL
- Managed Postgres or MySQL with automated backups and failover.
- BigQuery
- Analytical queries over very large datasets with nothing to provision.
- Artifact Registry
- Container images and packages next to where they are deployed.
Why Google Cloud
Let’s talkKubernetes done right
GKE is the most polished managed Kubernetes, which shows in day-two operations rather than day one.
BigQuery
Analytical queries over very large datasets without a warehouse to provision or tune.
Scale-to-zero pricing
Cloud Run bills only while requests are served, which suits internal tools and spiky workloads.
What we get called in to fix
Get a second opinionCold starts on Cloud Run
Scale-to-zero causing first-request latency. Minimum instances fix it — at a cost worth deciding deliberately.
BigQuery bills from full scans
Queries scanning entire tables because nothing is partitioned or clustered.
Over-permissive service accounts
Default accounts with project-wide editor rights, which is a large blast radius.
Unmanaged GKE node pools
Clusters sized generously at launch and never revisited against actual usage.
Google Cloud or the alternative
The comparisons we are actually asked to make, answered the way we would answer them on a call.
GCP for containers, scale-to-zero and analytics. AWS for breadth and enterprise familiarity.
Cloud Run for individual services — far less to operate. GKE once you need real orchestration across many workloads.
BigQuery unless you have specific reasons to run your own. There is very little to operate and the pricing model is manageable with partitioning.
AWS
Azure
Python
Docker
Go
Grafana
Java
Kubernetes
MongoDB
Node.js
PHPGot an idea? Let’s make it real.
Tell us the short version
This could be the first step towards a new and successful collaboration. A one-line idea and a finished spec are both fine — tell us the problem, the deadline you’re working to and what’s in your way.
Keep looking
Frequently asked questions
Sometimes — particularly for spiky container workloads and analytics. Comparisons only mean something against a real workload.
Often. For containerised services with variable traffic it is the least operational overhead available.
We can, but we usually advise against it. Multi-cloud doubles the operational surface and rarely pays for itself.
Yes, for stateless HTTP services. The considerations are cold starts and request timeouts, both of which are configurable and predictable.
We can, but we will ask why first. Migration is expensive, and the honest answer is often that the current setup should be optimised rather than moved.